Salvatore Vassallo  Università degli Studi di Pavia
STANDARD DESCRITTIVI E STANDARD DI METADATI IN SISTEMI ARCHIVISTICI E INTERSETTORIALI:  RIFLESSIONI SU MODELLI CONCETTUALI...
<ul><li>La sfida dell’interoperabilità, della gestione di standard descrittivi differenti e di formati dati differenti   <...
<ul><li>Punto di snodo e di contatto fra “mondi” diversi (liste di autorità, thesauri, luoghi, percorsi virtuali etc.) </l...
<ul><li>Soluzione usuale </li></ul><ul><ul><li>Complesso data model legato però a uno specifico formato (o comunque a un m...
<ul><li>Possibilità di affiancare diversi formati di struttura dati (anche parallelamente in contenitori come METS) </li><...
<ul><li>Utilizzato dove si hanno molti possibili campi usati in piccoli blocchi: </li></ul><ul><ul><li>Studi clinici </li>...
EAV model – DAMS Tratto da Stonemind consulting – Licenza CC-BY-SA
EAV model – ICA-AtoM Tratto da Qubit Wiki – Licenza CC-BY-SA
<ul><li>Debolezza/Fragilità: assenza di struttura </li></ul><ul><li>Query inefficienti </li></ul><ul><li>Poca chiarezza ne...
<ul><li>Mappe di siti (sitemap) :   anche se possono essere usate per creare una mappa di un sito (si veda xSiteable) </li...
<ul><li>13250-1: Overview </li></ul><ul><li>13250-2: Data Model </li></ul><ul><li>13250-3: XML syntax (XTM 2.0) </li></ul>...
Topic Maps – In breve Persona Vassallo, Salvatore  Nome Formale Standard descrittivi e standard di metadati Relazione Scri...
<ul><li>Assenza di struttura </li></ul><ul><li>Query inefficienti </li></ul><ul><li>Poca chiarezza nel disegno del sistema...
Upcoming SlideShare
Loading in …5
×

Vassallo Standard Descrittivi E Standard Di Metadati

1,193 views

Published on

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,193
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Il titolo potrà sembrare molto generico e in parte slegato poi dalla presentazione che seguirà. In questo senso è bene chiarire subito quale sarà il focus della relazione.
  • Si intende discutere di possibili soluzioni tecnologiche e modelli di dati per affrontare la sfida dell’interoperabilità avendo in mente non solo una discussione teorica o filosofica, ma progetti concreti, nello specifico la realizzazione di un Digital Asset Management Systems (in breve un sistema che sia in grado di gestire la fase SIP, ma, perché no anche DIP del modello OAIS, cioè, semplificando, di gestire la fase di inserimento dei metadati negli oggetti digitalizzati e favorire la loro disseminazione). Dunque sarà necessario un breve riassunto di quale sono le problematiche da affrontare per un simile progetto e di quali siano, in generale, le sfide da affrontare nel gestire oggetti che afferiscono a beni culturali di ambito diverso e che quindi necessitano di essere descritti in maniere differenti (spesso parallele) secondo standard descrittivi differenti e secondo formati di struttura dati o di interscambio differenti. Si procederà quindi prendendo in esame quattro diverse possibili soluzioni, confrontandole e infine proponendo una che non è necessariamente la migliore tout court o la maggiormente adeguata nel caso di un digital asset management system, ma che è una soluzione che personalmente ritengo abbastanza convincente e che, sicuramente, è stata fin qui poco esplorata almeno in Italia, soprattutto nell’ambito dei beni culturali.
  • Cosa si intende per interoperabilità e flessibilità, in termini generali, ma soprattutto nello specifico cioè nella creazione di un digital asset management system? In questo intervento non entrerò nell’analisi su quali siano i punti di maggior contatto fra i mondi diversi che appartengono allo stesso sistema solare dei beni culturali (tematica estremamente interessante e centrale, sicuramente da approfondire nel momento di discussione e nel documento finale, sviluppando i diversi punti forniti dall’intervento di Stefano Vitali). In questa presentazione vorrei invece limitarmi all’aspetto tecnologico ovvero come permettere la coesistenza di standard descrittivi differenti garantendo la necessaria flessibilità. Un semplice esempio slegato dal software che l’università di Pavia sta sviluppando: cosa dovrebbero fare, dal punto di vista tecnico, ma anche concettuale gli attuali sistemi archivistici (sias, siusa, siasfi, plain etc) qualora volessero implementare completamente nuovi standard come india o isdf? Nel caso migliore, cioè dove, rispettivamente le funzioni e i soggetti conservatori sono gestiti come entità a se stanti (e dunque in tabelle separate), bisognerà espandere il numero dei campi di queste tabelle e creare svariate relazioni. Nel caso peggiore, cioè se le funzioni, ad esempio, sono viste come attributo del soggetto produttore bisognerà ripensare l’intero modello con ovvi impatti (onerosi) sul data model e sulla sua implementazione. Nel nostro caso si vuole certamente evitare di dover re ingegnerizzare il sistema ad ogni nuovo standard descrittivo di un determinato ambito o, peggio, ad ogni nuova versione dello standard. Questo però è solo la punta dell’iceberg, è necessario che il sistema sia in grado di digerire e affiancare standard descrittivi differenti (dal punto di vista descrittivo un conto è se stiamo digitalizzando una monografia, un conto se si digitalizzano mappe un altro ancora se si vuole digitalizzare pergamene all’interno di un fondo archivistico). Un obiettivo ulteriore è poi quello di poter importare e esportare nei differenti formati diffusi, sia come contenitori (ovvero MAG, pur con i suoi limiti, di cui si è discusso negli interventi precedenti, METS, MPEG21 etc) sia per quello che riguarda i cassetti per riempire questi contenitori (il cassetto della descrizione, dal nostro punto di vista, deve poter essere in fase di importazione/esportazione ead, dublin core, dublin core qualificato, mods, onix etc).
  • Qual è dunque la soluzione adottata fin qui per rispondere a queste esigenze? Generalmente si disegna un proprio modello cercando di individuare le entità in gioco, gli elementi descrittivi per ognuna di essa e le relazioni che intercorrono fra di loro. Dopo di che la soluzione più gettonata è quella di usare un database relazionale. Il problema è quale data model usare nel nostro caso. Sicuramente uno piuttosto generico e profondo da permetterci di rapportarci con diverso formati e diversi standard descrittivi. Ma quale? Adagiarsi su un tracciato simile a quello proposto da Europeana? I vantaggi di una simili soluzione sono soprattutto i vantaggi dettati da soluzioni piuttosto usate e collaudate. L’interoperabilità potrà, in parte, essere garantita da quell’operazione piuttosto di moda che è il mapping fra formati differenti. Parlando di crosswalk non si può non citare l’opera meritoria del getty institute che ha prodotto una vera matrice di confronto fra standard di metadati e il lavoro di godby, morfrom, implementato da oclc nel suo “traduttore” di metadati online. Gli svantaggi sono rappresentati in particolar modo dalla rigidità del data model: cosa accadrebbe qualora si volesse implementare uno standard descrittivo di nuova uscita o una versione di un nuovo standard (si pensi alla rivoluzione copernicana che è stata la seconda versione di ISAAR)? Come gestire poi i casi in cui il formato che si vuole mappare con il nostro data model è maggiormente strutturato? Generalmente questo non può che portare a perdita di dettaglio.
  • Una possibilità potrebbe essere quella di non legarsi a un determinato data model, ma di utilizzare direttamente documenti XML specifici per le differenti esigenze di descrizione. Bisogna descrivere materiale archivistico, bene incardino la descrizione in un record ead, si parla di lista di autorità ecco eac-cpf, materiale bibliografico? Mods o, a volersi male, marcxml etc. METS favorisce tutto questo, a differenza ad esempio i MAG, perché è agnostico dal punto di vista del formato di descrizione e, come un mobile ikea, può essere composto da diversi cassetti di metadati descrittivi anche paralleli. Ci sono alcuni esempi di realizzazioni che vanno in quest’ottica: l’università di Pavia ha realizzato un piccolo prototipo di sistema informativo sull’editoria cattolica del novecento dove le descrizione dei differenti agenti sono in eac (purtroppo si tratta ancora della versione precedente e non del novello eac-cpf), gli archivi e le biblioteche storiche sono descritti con EAD e le famiglie editoriali e le famiglie di opere sono espresse utilizzando MODS frbrizzato in maniera simile a quanto proposto dalla perseus digital library. Ancora, nel campo della gestione degli oggetti digitali, va citato codex[ml] prodotto del Cilea, un prodotto che utilizza direttamente i file xml, in MAG. Codex[ml] è un sistema estremamente interessante e da molti punti di vista funzionale, tuttavia mostra quanto questa soluzione non sia poi così flessibile in quanto un passaggio da MAG a METS è oneroso e si tratterebbe comunque di uno specifico profilo di METS.
  • Gli entity attribute value model, sono modelli generici che permettono di gestire numeri elastici di metadati afferenti anche a dominio e a profili applicativi differenti. Sostanzialmente dal punto di vista logico gli elementi in gioco sono: le entità (ad esempio nel caso di dati clinici il paziente, eventualmente il ricovero etc), gli attributi (i metadati, gli elementi descrittivi) e il valore che questi assumono Semplificando molto dunque avremo una tabella di questo tipo… In realtà in entity avremo una foreing key che rimanda a un&apos;altra tabella, così come nel caso degli attributi ci sarà una relativa tabella in cui ad esempio potremo indicare il datatype di un determinato attributo, l’etichetta (eventualmente traducibile), il profilo a cui appartiene etc. Ma questo modello è utilizzato solo per dati clinici in cui, cioè, si ha una miriade di possibili rilevazioni e questi dati sono compilati solo in piccola parte ad ogni analisi?
  • No, ad esempio questo è una proposta proprio per un digital asset management systems. Anche se l’immagine non è molto ingrandita spero si possa vedere come vi sia una tabella per gli attributi con le caratteristiche di cui si parlava prima che permette in sostanza di definire un numero arbitrario di metadati e di profili. Ciò ovviamente non risolve magicamente i nostri problemi, questi in parte si trasferiscono all’interfaccia, ma ci permette di ragionare su un data model elastico e flessibile alle nostre esigenze.
  • Nello specifico del mondo archivistico si può portare ad esempio il data model di ica-atom, un software per la pubblicazione di descrizioni archivistiche sviluppato con il finanziamento di ICA, Unesco etc. In particolare già ora ica-atom può passare da un modello disegnato su ISAD, a mods o a dublin core. Come si può vedere ogni diverso elemento è (relazione IS A con la tipica freccia prevista da uml) un oggetto qubit, lo sono anche i diversi term, organizzati in tassonomie che rappresentano appunto i diversi metadati e i vari profili.
  • Quali sono gli aspetti negativi degli entity attribute value model? Non esiste una struttura (se non in fase di modellazione) tutto è gestito solo dall’interfaccia Difficoltà di interrogare un database così costruito Il valore… il “value” non è vincolato a un datatype della colonne Mancanza di strumenti e di procedure collaudate, invece diffusi per i consolidati database relazionalì
  • Infine un’ultima alternativa: le Topic Maps… A dispetto del nome non sono né mappe di siti né mappe mentali o concettuali. Neanche possono essere identificate con mappe di navigazione grafiche, anche se possono essere visualizzate come rete di collegamenti (utilissimo qualora si volesse visualizzare un’ontologia). Non sono XML, XTM (xml topic maps) è solo uno dei tanti formati di serializzazione, una topic maps può benissimo essere immagazzinata in un database
  • Dunque che cosa è? Topic Maps è una tecnologia per la rappresentazione, il collegamento e l’interscambio della conoscenza definita come standard ISO 13250. Spesso è stata vista in contrapposizione con RDF raccomandazione del W3C. Senza entrare nel dettaglio è sicuramente vero che sono tecnologie simili, ma con alcune differenze che giustificano la presenza di entrambe. In realtà ISO 13250 è una famiglia di standard che tratta vari livelli della tecnologia, dal data model sino alla notazione grafica da usare in fase di modellazione. Allo standard 13250 si affiancano due standard uno per un linguaggio vincolato (ovvero per definire schemi per la validazione) e l’altro per uno specifico linguaggio di interrogazione delle Topic Maps
  • Un esempio in breve per illustrare i vari costrutti di questa tecnologia. Ecco un topic ovvero la rappresentazione di un soggetto (cioè un qualunque elemento del discorso) che ha come topic type Persona, ha un topic name con un determinato tipo di topic name. Questo topic è associato (rappresentazione della relazione) con un altro topic (con il suo tipo di topic e topic name). L’associazione ha uno specifico tipo di associazione e i topic attori della relazione potranno avere differenti ruoli, a seconda della loro funzione all’interno dell’associazione, Infine un topic può avere delle occorrenza (sorta di associazioni binarie interne al topic, potremmo intenderle come elementi descrittivi del topic) che avrà un determinato tipo di occorrenza. Tutti questi costrutti possono avere un determinato ambito di validità chiamato scope. Sostanzialmente questi sono gli elementi in gioco. Si può immaginare che utilizzando un simile strumento si possa arrivare alla stessa astrazione e flessibilità del caso degli eav model.
  • In cosa le Topic Maps possono superare i limiti degli eav model? TMCL il linguaggio vincolato per designare schemi per la validazione potrebbe superare l’assenza di struttura, è possibile definire modelli/template che validino una determinata topic map (ad esempio specificando che un complesso archivistico debba avere una e una sola denominazione, che un soggetto produttore debba avere almeno una forma autorizzata del nome etc) Il limite delle query inefficienti è superato utilizzando linguaggi specifici per interrogare questa tecnologia come TMQL o come tolog (basato su prolog) La poca chiarezza nel disegno non è tanto un limite degli eav model, ma da imputarsi a chi è preposto alla modellazione e alla produzione di documentazione. Ovviamente avere uno standard come GTM che si occupa esplicitamente di fornire la notazione grafica per la modellazione in topic maps e la produzione degli esempi è un indubbio vantaggio. Il limite di non poter vincolare il tipo di dato rimane, anche in questo caso però in parte può essere superato dal TMCL indicando che un determinato tipo di occorrenza può avere solo un datatype o indicare possibili valori attraverso regular expression Infine la mancanza di strumenti è completamente coperta dalla presenza di numerosi topic maps engine, motori che si occupano di gestire, importare, esportare, etc topic maps disponibili pressoché per ogni linguaggio di programmazione (i più noti sono in java, C#, C++, Ruby , php e javascript). Ecco, terminerei qui l’intervento che vuole essere solo un punto iniziale di discussione (anche per evidenziare le possibilità offerte da tecnologie non ancora del tutto esplorato, sopratutte nei nostri ambiti) e non vuole essere un punto di arrivo.
  • Vassallo Standard Descrittivi E Standard Di Metadati

    1. 1. Salvatore Vassallo Università degli Studi di Pavia
    2. 2. STANDARD DESCRITTIVI E STANDARD DI METADATI IN SISTEMI ARCHIVISTICI E INTERSETTORIALI: RIFLESSIONI SU MODELLI CONCETTUALI E APPLICATIVI Salvatore Vassallo – Università degli Studi di Pavia [email_address]
    3. 3. <ul><li>La sfida dell’interoperabilità, della gestione di standard descrittivi differenti e di formati dati differenti </li></ul><ul><li>Possibili soluzioni </li></ul><ul><ul><li>Crosswalk </li></ul></ul><ul><ul><li>Formati XML </li></ul></ul><ul><ul><li>Entity-attribute-value model </li></ul></ul><ul><ul><li>Topic Maps </li></ul></ul><ul><li>Confronto fra le diverse soluzioni </li></ul><ul><li>Conclusioni </li></ul>Di cosa parleremo Digital Asset Management Systems
    4. 4. <ul><li>Punto di snodo e di contatto fra “mondi” diversi (liste di autorità, thesauri, luoghi, percorsi virtuali etc.) </li></ul><ul><li>Poter implementare facilmente nuovi standard e nuove versioni di standard descrittivi (es ISDIAH e ISDF) </li></ul><ul><li>Poter affiancare standard descrittivi differenti (es ISAAR(CPF)-FRAR) </li></ul><ul><li>Poter gestire in fase di importazione e esportazioni formati differenti (MAG-METS-MPEG21 EAD-DCMES-DCTERMS-MODS-ONIX) </li></ul>Sfida interoperabilità e necessità di flessibilità
    5. 5. <ul><li>Soluzione usuale </li></ul><ul><ul><li>Complesso data model legato però a uno specifico formato (o comunque a un modello definito e finito) </li></ul></ul><ul><ul><li>Quale formato come base? </li></ul></ul><ul><li>Vantaggi </li></ul><ul><ul><li>Soluzioni collaudate </li></ul></ul><ul><ul><li>Possibilità di utilizzare una serie di strumenti diffusi per ottimizzare il risultato </li></ul></ul><ul><ul><li>Possibilità comunque di dialogare con formati diversi attraverso crosswalk </li></ul></ul><ul><li>Svantaggi </li></ul><ul><ul><li>Gestire nuovi standard descrittivi o nuove versioni di standard </li></ul></ul><ul><ul><li>Nuovi formati di struttura dati o elementi non mappabili </li></ul></ul><ul><ul><li>Quanto questa soluzione è realmente flessibile? </li></ul></ul>RDBMS
    6. 6. <ul><li>Possibilità di affiancare diversi formati di struttura dati (anche parallelamente in contenitori come METS) </li></ul><ul><li>Possibilità di utilizzare database XML nativi o estensioni di database </li></ul><ul><li>Utilizzare il formato appropriato per ogni standard descrittivo </li></ul><ul><li>Esempio Editoria Cattolica del Novecento </li></ul><ul><ul><li>EAC per la descrizione degli agenti coinvoli </li></ul></ul><ul><ul><li>MODS (FRBRizzato) per la gestione delle collezioni </li></ul></ul><ul><ul><li>EAD per archivi e biblioteche storiche </li></ul></ul><ul><li>L’esperienza di Codex[ml] sviluppato dal Cilea, DAMS basato interamente su XML </li></ul>Sistema basato su XML
    7. 7. <ul><li>Utilizzato dove si hanno molti possibili campi usati in piccoli blocchi: </li></ul><ul><ul><li>Studi clinici </li></ul></ul><ul><ul><li>File di configurazione </li></ul></ul><ul><ul><li>Cloud computing </li></ul></ul><ul><li>Tutto viene ricondotto a: </li></ul><ul><ul><li>Entity </li></ul></ul><ul><ul><li>Attribute </li></ul></ul><ul><ul><li>Value </li></ul></ul>EAV model - Caratteristiche Entity Attibute Value Oggetto digitalizzato Titolo La divina commedia
    8. 8. EAV model – DAMS Tratto da Stonemind consulting – Licenza CC-BY-SA
    9. 9. EAV model – ICA-AtoM Tratto da Qubit Wiki – Licenza CC-BY-SA
    10. 10. <ul><li>Debolezza/Fragilità: assenza di struttura </li></ul><ul><li>Query inefficienti </li></ul><ul><li>Poca chiarezza nel disegno del sistema </li></ul><ul><li>Mancanza di controllo vincolante sul valore dei campi </li></ul><ul><li>Impossibilità di utilizzare meccanismi collaudati nei RDBMS </li></ul><ul><li>Inefficacia di altri strumenti standard </li></ul><ul><li>Il formato non è “digerito” facilmente dai comuni RDBMS </li></ul>EAV model – Limiti
    11. 11. <ul><li>Mappe di siti (sitemap) : anche se possono essere usate per creare una mappa di un sito (si veda xSiteable) </li></ul><ul><li>Mappe grafiche : anche se possono essere visualizzate in maniera grafica (con vizigator o usando le librerie hypergraph, touchgraph, graphviz) </li></ul><ul><li>Mappe mentali o mappe concettuali </li></ul><ul><li>XML : XTM – XML Topic Maps è soltanto uno dei formati di serializzazione </li></ul>Topic Maps – Cosa non sono
    12. 12. <ul><li>13250-1: Overview </li></ul><ul><li>13250-2: Data Model </li></ul><ul><li>13250-3: XML syntax (XTM 2.0) </li></ul><ul><li>13250-4: CXTM (Canonicalization) </li></ul><ul><li>13250-5: Reference Model </li></ul><ul><li>13250-6: CTM (Compat Notation) </li></ul><ul><li>13250-7: GTM (Graphical Notation) </li></ul><ul><li>18048: Topic Maps Query Language </li></ul><ul><li>19756: Topic Maps Constraints Language </li></ul>Topic Maps – Cosa sono Una tecnologia per la rappresentazione e lo scambio dell’informazione e della conoscenza, definito come standard ISO
    13. 13. Topic Maps – In breve Persona Vassallo, Salvatore Nome Formale Standard descrittivi e standard di metadati Relazione Scritto da Scrive Scritto Scrittore Topic Topic Type Topic Name Type Topic Name Il tema della relazione è… Italiano Abstract Association Association Type Association Role Type Occurrence Occurrence Type Scope note
    14. 14. <ul><li>Assenza di struttura </li></ul><ul><li>Query inefficienti </li></ul><ul><li>Poca chiarezza nel disegno del sistema </li></ul><ul><li>Mancanza di controllo vincolante sul valore dei campi </li></ul><ul><li>Impossibilità di utilizzare meccanismi collaudati nei RDBMS </li></ul><ul><li>Inefficacia di altri strumenti standard </li></ul><ul><li>Il formato non è “digerito” facilmente dai comuni RDBMS </li></ul>Topic Maps vs EAV model TMCL TMQL/Tolog GTM Datatype dell’occurrence - TMCL? Topic Maps Engine: motori per gestire Topic Maps disponibili in diversi linguaggi

    ×