1 Roma, III riunione Progetto Azalea 2 febbraio 2003 Susanna Peruginelli Introduzione ai metadati - Dublin Core e.

Presentazione sul tema: "1 Roma, III riunione Progetto Azalea 2 febbraio 2003 Susanna Peruginelli Introduzione ai metadati - Dublin Core e."— Transcript della presentazione:

1 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 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 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 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 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 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) CORC-Record Dublin Core CORC-MARC21 HTML-DC XML-DC

7 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 patientEnglish patient Evoluzione: scambio - interoperabilità con schemi di metadati

8 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 9 La proliferazione degli schemi di metadati Situazione: Gli schemi di MD nascono da progetti e iniziative specifiche (Schemi) (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(Mapping metadata formats Conversione verso uno schema elementare (DC) (Mappatura ICCU)

10 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 11 I 15 elementi di Dublin Core Titolo Soggetto Descrizione Copertura Fonte Relazione Lingua Creatore Creatore sec. Editore Diritti Data Formato Tipo di risorsa Identificatore Contenuto Responsabilità Manifestazione

12 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 QualifiersQualifiers Elementi DC in italiano (ICCU) http://www.iccu.sbn.it/dublinco.html

13 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)(DC.dot) Metadata UKOLN software tools: http://www.ukoln.ac.uk/metadata/software-tools

14 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 applicazioneProposta di AudienceAGLS 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 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 scambioGuida http://www.ifla.org/VII/s13/guide/metaguide03.htm BDI: Biblioteca digitale italiana http://www.iccu.sbn.it/bdi.htmlhttp://www.iccu.sbn.it/bdi.html Metadata Server /State and University Library, Goettingen. http://www2.sub.uni-goettingen.de/metaguide/index.html

16 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 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 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 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 descriptionsNLM Type Content descriptions b) MCM Resource TypesMCM Resource Types Uso dell’elemento relazione (Es.: Testo – Immagine)

20 20 Schema: Evidence Based Medicine (EBM), Hiyoshi Media Center, Kejo - Giappone Integrazione di: ricerche sperimentali + esperienze cliniche + valori del paziente Elaborazione dello schema EBM: SchemaSchema 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 21 Schema di metadati EBM

22 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 recordEsempio di record Assistenza agli autori e intervento sull’indicizzazione analitica dei siti Stesura di specifiche sui MD

23 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 tipiLista di risorse Esempio record CISMeF Siti CISMeF

24 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 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 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