Roma, III riunione Progetto Azalea 2 febbraio 2003 Susanna Peruginelli

1. Roma, III riunione Progetto Azalea 2 febbraio 2003 Susanna Peruginelli E-Mail: Susanna.Peruginelli@libero.it 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 UNIMARC • Record MARC21 • Record ISO 2709 • Record MARC-XML • Schemi di metadati (CORC) • CORC-Record Dublin Core • CORC-MARC21 • HTML-DC • XML-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 è loschema di metadati per eccellenza, ma il minimo comune denominatore fra diversi schemi. Nessun conflitto con il MARC!

11. I 15 elementi di Dublin Core Contenuto Manifestazione Data Formato Tipo di risorsa Identificatore Titolo Soggetto Descrizione Copertura Fonte Relazione Lingua Responsabilità Creatore Creatore sec. Editore Diritti

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: Guidasu 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’informazioneScelte 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 di • metadati. 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