Protocollo di metadata harvesting OAI-PMH Lavoro pratico 2

Transcript

1 Docente: prof.silvio Salza Candidato: Protocollo di metadata harvesting OAI-PMH

2 Open Archive Initiative OAI (Open Archive Initiative) rendere facilmente fruibili gli archivi che contengono documenti prodotti in ambito accademico; promuovere la produzione in ambito scientifico/universitario. Obiettivo: Sviluppare e promuovere standard di interoperabilità per facilitare la disseminazione efficiente dei contenuti

3 Open Archives Initiative Protocol for Metadata Harvesting Protocollo OAI-PMH: protocollo leggero utilizzato per condividere metadati; fornisce un framework per l interoperabilità, totalmente indipendente dal contesto applicativo, basato sul metadata harvesting.

4 Modello funzionale Data Provider: amministrano quei sistemi che supportano l OAI-PMH come strumento per poter esporre i metadati; Service Provider: usano i metadati dei repository dei Data Provider, raccolti tramite il protocollo, per costruire dei servizi a valore aggiunto (es. ricerca unificata su più archivi, analisi citazionale, reference linking).

5 Modello funzionale Tra i Service Provider e i Data Provider esiste un rapporto client/server basato sui concetti di harvester e repository: un harvester è un applicativo di tipo client tramite il quale il Service Provider può effettuare sei tipi richieste al repository del Data Provider per fare l'harvesting dei metadati; un repository è un server, gestito dal Data Provider, accessibile in rete e in grado di processare le richieste OAI e restituire dei risultati formattati secondo determinate regole.

6 Modelo strutturale del protocollo OAI-PMH

7 Modello dei dati Risorsa oggetto a cui sono associati i metadati; Vista come elemento esterno dal protocollo OAI-PMH; Item contenitore di tipo logico a partire dal quale vengono diffusi i metadati. ha un identificatore unico all'interno dello scope del repository di cui fa parte; l'identificatore segue la sintassi URI: oai:identificatore_archivio:identificatore_record Schema (fisso) Dominio registrato Univoco nel repository

8 Modello dei dati Record sono i metadati espressi in un singolo formato; identificato univocamente dalla combinazione: identificatore item + metadataprefix + datestamp I record OAI presentano tre parti: header: identificatore unico, datestamp, setspec, deleted (opzionale); metadata: veri e propri metadati espressi in un singolo formato (es. DC); about (opzionale): specificare informazioni sui diritti e le condizioni d'uso dei metadati o sulla loro provenienza;

9 Modello dei dati

10 Organizzare gli item I repository possono organizzare gli item in set (collezioni) L'organizzazione dei set può essere piatta, cioè una semplice lista, o gerarchica Esempio di organizzazione gerarchica: Istituzioni Oceanside University of Nebraska Valley View University of Florida Un item può appartenere a un set, diversi set o a nessun set

11 Selective Harvesting L'harvesting selettivo permette di limitare la ricerca dei metadati da raccogliere mediante l'uso dei seguenti criteri: datestamps: è possibile selezionare i record creati, cancellati o modificati in un certo range temporale; appartenenza a un insieme (Set): vengono restituiti solo i record che appartengono al set specificato.

12 Principali caratteristiche del protocollo basato sul protocollo HTTP; sei tipi di richieste; le richieste usano il metodo GET o il metodo POST; risposte sono codificate in sintassi XML; risposte devono usare la codifica con rappresentazione UTF8 di unicode; supporta la disseminazione di record in diversi formati di metadati (almeno Dublin Core); unica URL base per tutte le richieste: internet host, porta datestamp; messaggi di errore; controllo di flusso; compressione delle risposte;

13 Richieste OAI-PMH 1) Identify: per ottenere informazioni generali sul repository (es. l'url base); 2) ListMetadataFormats: recupera la lista dei formati dei metadati resi disponibili da un repository; 3) ListSets: per recuperare la struttura dei set (partizioni); 4) ListIdentifiers: recupera solo gli headers dei record; 5) ListRecords: per ottenere la lista di record di un repository; 6) GetRecord : per recuperare un singolo record da un repository;

14 Controllo di flusso I verbi ListRecords, ListIdentifiers e ListSets restituiscono delle liste di entità, rispettivamente record, headers e set Queste liste possono essere di notevoli dimensioni e può essere utile partizionarle in una serie di richieste e risposte Il partizionamento della risposta utilizza i concetti di lista incompleta e resumptiontoken

15 Controllo di flusso

16 Coodici di stato, errori e eccezioni Il protocollo OAI-PMH distingue i propri errori dai codici di stato del protocollo HTTP I repository devono indicare gli errori relativi ad eventi particolari che possono avvenire a seguito delle richieste inviategli, includendo uno o più elementi di tipo error nella risposta (badargument,badresumptiontoken, badverb CannotDisseminateFormat, iddoesnotexist, norecordsmatch, nometadataformats, nosethierarchy)

17 Data Provider: prerequisiti metadati per la descrizione delle risorse; web server, accessibile via the Internet( es. Apache, IIS); datestamp per i record di metadati (creazione o ultima modifica): base URL come identificatore unico d archivio; identificatore unico per ogni item del repository; formati di metadati (almeno Dubline Core); programming interface / API; controllore di flusso che implementi il resumptiontoken (opzionale, ma fortemente consigliato); organizzazione degli item in set (opzionale); possibilità di inviare risposte compresse all'harvester

18 Data Provider: architettura

19 Service Provider: prerequisiti Server connesso ad Internet: l harvester del Service Provider, che costituisce un portale di servizi a valore aggiunto per l utente finale; database relazionale o XML opportunamente progettato per contenere i metadati raccolti dai vari repository; ambiente di programmazione: capace di effettuare richieste HTTP ai server web, richieste a database server e includa un parser XML.

20 Service Provider: architettura

21 Aggregatori, cache e proxy E' previsto nell'immediato futuro l'uso di aggregatori, cache e proxy Questi servizi permetteranno di effettuare un harvesting più sofisticato Introdurranno un livello di complessità non riscontrabile nella semplice relazione tra Service Provider e Data Provider Problematiche: gestione dei namespace degli identificatori e provenienza dei record