1 Roma, III riunione Progetto Azalea 2 febbraio 2003 Susanna Peruginelli E-Mail: [email protected] Introduzione ai metadati - Dublin Core e sua applicazione
May 02, 2015
1
Roma, III riunione Progetto Azalea2 febbraio 2003
Susanna Peruginelli
E-Mail: [email protected]
Introduzione ai metadati - Dublin Core e sua applicazione
2
Argomenti trattati
• Gli strumenti a disposizione per la descrizione dei documenti: formati bibliografici, FRBR, schemi di metadati
• L’integrazione di risorse, schemi di metadati e significato di Dublin Core
• L’evoluzione in atto
• Alcune applicazioni di metadati alla documentazione medica
3
Due ambienti e tecniche per l’accesso ai documenti
1. Biblioteche: un mondo uniforme (Regole catalogazione, formati, protocolli)
Precisione
2. Web: un mondo diversificato (Diversità attori, materiali, esigenze…)
Caos????
4
L’accesso alle risorse su web: la situazione ancora oggi
Lynch: “Internet, e in particolare la sua collezione di risorse multimediali conosciuta come WWW, non è nata per gestire la pubblicazione sistematica e il recupero dell’informazione nello stesso modo in cui le biblioteche sono abituate a fare…
La Rete si è evoluta in un deposito caotico… e si rende necessario qualche cosa di molto simile ai tradizionali servizi di biblioteca per organizzare, garantire l’accesso e conservare l’informazione in rete…” [uso di metadati](Searching the Internet / C. Lynch, «Scientific American», 276, 1997, p.52-56)
5
Il mondo del web ha scoperto… la necessità di strumenti per la ricerca, l’accesso, lo scambio
• Regole di catalogazione [ Semantica ] (-)
• Sistemi di codifica dei dati [ Semantica ] (+)
• Strutture standard per comunicare i dati (XML) [ Sintassi ] (+)
Sono ‘scoperte’ ben note alle biblioteche (Regole catalogazione; ISBD; MARC; Norma ISO 2709...)
6
Strumenti per la ricerca e l’integrazione
di risorse
• Formati bibliografici MARC MARC 21, UNIMARC ed inoltre: IBERMARC, MALMARC, INTERMARC….Record UNIMARCRecord MARC21 Record ISO 2709 Record MARC-XML
•Schemi di metadati (CORC)CORC-Record Dublin CoreCORC-MARC21 HTML-DCXML-DC
7
Che ne sarà del MARC ?Come evolverà?
• Ancora per quanti anni ???? Elementi di resistenza: - esperienza diffusa - strumento di normalizzazione bibliografica - ragioni economiche
• Le critiche: Complessità - Formato piatto - Formato ‘di nicchia’
• Struttura ISO 2709 XML
• Record MARC multilivello e dinamici modellati su FRBR? Esempio: English patient
• Evoluzione: scambio - interoperabilità con schemi di metadati
8
L’evoluzione in atto
•Progetti (portali, subject gateways, metaopac….) per l’integrazione di risorse
•proliferazione di schemi di metadati, profili di applicazione, ‘mappature’ fra diversi schemi
•Strumenti per la creazione e gestione di metadati
•Istituzioni con ruolo guida e iniziative di sostegno all’implementazione di metadati: medatati ‘generalisti’ e specialistici (es: CISMeF-Medicina)
9
La proliferazione degli schemi di metadati
Situazione:Gli schemi di MD nascono da progetti e iniziative specifiche (Schemi) http://www.fis.utoronto.ca/special/metadata/overview.htm
Esigenza (Duplice): • Specificità nella descrizione, ma anche…• Interoperabilità con altri schemi per integrare risorse eterogenee
Soluzioni per l’integrazione:• Conversione-mappatura fra schemi (Mapping metadata formats• Conversione verso uno schema elementare (DC) (Mappatura ICCU)
10
Principi alla base di uno schema standard elementare
•Gli strumenti (regole e formati) delle biblioteche sono efficaci, ma costosi e non adottabili in massa
•Lo scambio fra applicazioni necessita di un modello di dati semplice, anche derivabile dalla conversione di schemi di metadati più complessi (MARC compreso!)
•Questo schema è (al momento...) Dublin Core (ISO 15836: 01/2003), ma….
Dublin core non è lo schema di metadati per eccellenza, ma il minimo comune denominatore fra diversi schemi. Nessun conflitto con il MARC!
11
I 15 elementi di Dublin Core
TitoloSoggettoDescrizioneCoperturaFonte RelazioneLingua
CreatoreCreatore sec.EditoreDiritti
DataFormatoTipo di risorsaIdentificatore
Contenuto
Responsabilità
Manifestazione
12
Caratteristiche di Dublin Core •Semplicità: linguaggio elementare, adatto alla comunicazione (‘pidgin’)
•Gli elementi sono tutti opzionali e ripetibili
•Internazionale: elementi e specifiche in 23 lingue
•Applicabilità a risorse diverse
•Sintassi indipendente (HTML, XML…)
•Estensibilità: la descrizione è arricchibile Qualifiers
•Elementi DC in italiano (ICCU) http://www.iccu.sbn.it/dublinco.html
13
La creazione di metadati
•In record separato (in un database) o incorporato nel documento
•Derivazione automatica dalla codifica dal documento elettronico
•Creazione manuale
•Generatori di Dublin Core (DC.dot)Metadata UKOLN software tools: http://www.ukoln.ac.uk/metadata/software-tools
14
Profili di applicazione e registri: strumenti essenziali in progetti di
biblioteca digitale
• Profilo di applicazione Un insieme di elementi (metadati) selezionati da schemi diversi e
combinati in un nuovo schema HEALTHInsite (Proposta di Audience) AGLS Profilo di applicazione
• Registri: Dizionari elettronici utili per identificare, interpretare, ri- utilizzareschemi di metadati e profili di applicazione http://desire.ukoln.ac.uk/registry/index.php3
15
Iniziative istituzionali per lo sviluppo dei metadati
•DC Metadata Initiative : mantiene Dublin Core e i profili
http://dublincore.org
•IFLA: Ottobre 2003: Guida su struttura, contenuto, applicazione di record di metadati Core of cores: modello di 10 elementi per lo scambio
http://www.ifla.org/VII/s13/guide/metaguide03.htm
•BDI: Biblioteca digitale italiana http://www.iccu.sbn.it/bdi.html
•Metadata Server /State and University Library, Goettingen. http://www2.sub.uni-goettingen.de/metaguide/index.html
16
Metadati e risorse mediche
• Sviluppo di portali, subject gateways, metacataloghi, applicazioni locali
• Dubbi sulla totale affidabilità e rilevanza delle risorse Internet
• Uso di metadati e selezione di risorse di qualità
• Molteplicità di ‘creatori’ di metadati - Necessità di collaborazione fra autori e documentalisti-bibliotecari
17
Applicazioni per l’accesso a risorse mediche:
Caratteristiche
• Esame approfondito dell’esistente in vista della adozione di schemi e della scelta di metadati
• Un elemento fondamentale da definire: il tipo di risorsa
• Adozione di Dublin Core come alternativa economica a modelli di descrizione più elaborati (es.: MARC)
• Attenzione alla specificità della documentazione medica: definizione di elementi specifici e profili di applicazione
18
Alcuni progetti
• Medical Core Metadata (MCM) – Oregon University
• Schema Evidence Based Medicine (EBM) - Kejo
• HealthInsite - Australia
• Catalogue & Index des Sites Medicaux Francophones (CISMeF)
• National Institute of Environmental Health Sciences (NIEHS) – USA
• E molti altri….http//www.chu-rouen.fr/documed/dc.html
19
Medical Core Metadata (MCM) - Oregon University
• Progetto cooperativo.
• Problemi per utenza: Dove cercare, Cercare per tipo di risorsa, Verificare la qualità dell’informazione
Scelte precise: - quali tipi di risorse indicizzare e come identificarle
(schema intuitivo) - Uso di Dublin Core, termini MeSH, precisazione dei
tipi di risorse: a) NLM Type Content descriptions b) MCM Resource Types
• Uso dell’elemento relazione (Es.: Testo – Immagine)
20
Schema: Evidence Based Medicine (EBM), Hiyoshi Media Center, Kejo
- Giappone
• Integrazione di: ricerche sperimentali + esperienze cliniche +
valori del paziente
• Elaborazione dello schema EBM: Schema
a) 15 elementi DC + b) 8 elementi dello schema Administrative Core (AC:
provenienza e gestione dei MD) + c) Liste EBMC (protocolli clinici, es.: terapia,
prognosi, diagnosi, eziologia…) e EBMS (tipi di studi) + d) ‘Raffinamenti’ dell’elemento Descrizione: abstract,
commentari.. Esempio record EBM
21
Schema di metadati EBM
22
HealthInsite, Australia
Creazione di: a) S/w per la creazione di MD b) Schema= Profilo di applicazione (15 elementi DC + altri elementi degli schemi AGLS e HI). Esempio di record
• Assistenza agli autori e intervento sull’indicizzazione analitica dei siti • Stesura di specifiche sui MD
23
Catalogue & Index des Sites Medicaux Francophones (CISMeF),
Osp. univ. di Rouen
• Guida strutturata a risorse: 10.000 record circa. Aggiornamento settimanale: 50 siti
• Schema di MD : a) 11 elementi DC (no: altro autore, copertura, relazione, soggetto) + b) 8 elementi CISMeF (istituzione, città, provincia o Stato, paese, destinatario, tipo di accesso, costi e sponsor)• Uso di termini MeSH, Tipi di pubblicazione MEDLINE, Lista di tipi di risorse Esempio record CISMeF Siti CISMeF
24
Progetto National Institute of Environmental Health Sciences
(NIEHS), USA
• Esigenza di uno schema: a) semplice e stabile: economicità e facilità formazione del personale b) flessibile c) interoperabile (possibilità di conversioni)
• Scelta di Dublin Core (15 elementi) e XML per la rappresentazione dei record
• Definizione di un Profilo di Applicazione NIEHS con qualificatori, elemento Audience (Destinatario), Caratteristiche degli elementi (obbligatorietà, ripetibilità…) Schema
25
Punti critici
• Schemi in continua evoluzione, applicazioni ‘giovani’
• Molteplicità di ‘creatori’ di metadati. Difficoltà di convincere gli autori
• Uso di DC nelle biblioteche: record bibliografico verso record dimetadati. Record DC come risultato di una conversione? Record di base per poi arricchire la catalogazione? Per risorse mai catalogate? Per la raccolta di più schemi da fornitori diversi (vedi protocollo OAI)?
• Varietà nella documentazione degli schemi: spesso assenza di regole di catalogazione; problemi di uniformità
• Scarsa documentazione sull’efficienza di DC per la ricerca
26
Raccomandazioni • Analizzare : - le collezioni da gestire - gli utenti dei servizi
• Applicare il più possibile metadati e profili standard,
esaminando applicazioni affini e consultando i registri
• Concepire Dublin Core come formato ‘ponte’ o come schema di base, riconoscendo il valore di formati e schemi specifici per l’indicizzazione delle risorse