L’obiettivo del progetto OpenERCH, come discusso nel capitolo prece- dente, consiste nella creazione di un dataset che racchiude la descrizione delle informazioni relative a beni artistici e culturali (musei, teatri e siti in generale) in modo formale secondo l’ontologia CIDOC-CRM. Lo scopo finale `e quello di pubblicare tali dati all’interno della rete Linked Data, rendendoli disponbili all’utilizzo da parte anche di applicazioni software in relazione a tutte le altre informazioni presenti nel Web of Data. La creazione di tale dataset `e avvenuta a partire da un insieme di dati non strutturati e tenendo conto dei principi proposti dal Linked Data. Al fine di proporre un esempio di utilizzo combinato delle informazioni ottenute, il progetto comprende an- che un’applicazione mash-up di esempio.
La figura 4.3 presenta l’architettura generale di OpenERCH, illustrandone le principali componenti e le relazioni tra esse presenti. I dati iniziali, oggetto di conversione, sono presenti all’interno di un database in cui sono conservati prevalentemente sottoforma di schede di catalogazione: ad ogni oggetto `e assegnata una lista di propriet`a che ne descrivono le varie caratteristiche. La descrizione degli oggetti `e pertanto effettuata, all’interno di tale base di dati, prevalentemente tramite un elenco di valori testuali associati a ciascuno di essi. Come descritto nella sezione 3.1, tutte le informazioni presenti in questo database sono presentate all’interno del portale Samira grazie al quale pos- sono essere consultate e ricercate tramite un apposito sito web. L’attivit`a di conversione `e effettuata su due tipologie di dati estratte dal database: un in- sieme di metadati generali di identificazione e localizzazione di ogni oggetto e un’altra collezione di dati pi`u specifici di descrizione che permettono di otte- nere le informazioni pi`u dettagliate relative ad ognuno di essi (si rimanda alla
4.2 Architettura generale 79
Figura 4.3: Diagramma di Deploy che mostra l’archittura generale di OpenERCH indicando le componenti principali e le loro connessioni.
sezione 3.2 per una descrizione dettagliata di entrambe le categorie). I primi sono ottenibili direttamente dal portale Samira in formato CSV1, mentre gli
altri sono estratti dal database in formato XML secondo uno specifico sche- ma aderente agli standard di catalogazione previsti e descritti in [ACG98]. L’attivit`a di conversione vera e propria `e effettuata dalla componente soft- ware chiamata Trasformatore che si occupa, a partire dai file di dati appena indicati estratti dal database, di leggere le singole informazioni e creare a
1Il CSV (comma-separated values) `e un formato basato su file di testo utilizzato per l’importazione ed esportazione (ad esempio da fogli elettronici o database) di una tabella di dati. In questo formato le informazioni relative ai diversi oggetti sono presentate su righe diverse (ad esempio una riga per ogni record di un database), che a loro volta sono divise in campi (ad esempio le singole colonne di una record di un database) separati da un apposito carattere separatore, in genere rappresentato dalla virgola.
partire da esse degli statement RDF che le descrivano in base al modello ontologico proposto da CIDOC-CRM. La trasformazione comprende anche un’attivit`a di inferenza effettuata da un ragionatore. Tale componente si occupa di ottenere, a partire dagli statement di base prodotti inizialmente dal trasformatore, ulteriori triple eventualmente non presenti ma che posso- no essere dedotte in base a quanto indicato nell’ontologia, descritta a sua volta tramite il linguaggio OWL. Il ragionatore si occupa di inferire nuova informazione anche in base ad una serie di regole di inferenza fornitegli in input secondo uno specifico linguaggio. L’utilizzo del ragionatore permette di semplificare e rendere pi`u facilmente comprensibile e modificabile l’attivit`a di conversione, permettendo al trasformatore di occuparsi solo della conver- sione di base prevista per ogni singola tipologia di informazione, lasciando ad eventuali regole esterne o al modello ontologico il compito di fornire tut- te le triple aggiuntive che possono essere dedotte da questa informazione di base. Man mano che gli statement vengono prodotti e che le risorse vengono create, il trasformatore ha anche il compito di individuare, tramite una serie di interrogazioni in linguaggio SPARQL rivolte ai dataset esterni presenti nel Linked Data (descritti nella sezione precedente), eventuali altre risorse con le quali effettuare dei collegamenti.
L’attivit`a di conversione e inferenza effettuata dal trasformatore permette di ottenere le informazioni strutturate nella forma di triple RDF. Affinch´e queste possano essere correttamente raccolte ed accedute, formando un vero e proprio dataset, `e necessario che vengano raccolte all’interno di un RDF Store, ossia un componente che si occupa di mantenere i dati creando un repository che permette di ottenerli tramite diverse modalit`a: una sorta di DBMS semantico. Lo store di dati utilizzato nell’ambito di OpenERCH `e rappresentato da Sesame, un framework gratuito che mette a disposizione diversi strumenti per la gestione di dati in RDF, tra cui soluzioni per la me- morizzazione di dati e API e librerie per il loro reperimento. Nello specifico lo store utilizzato `e rappresentato da un’applicazione web che funziona facendo utilizzo dell’application server Tomcat ; tale applicazione permette, trami-
4.2 Architettura generale 81
te interfacce grafiche di configurazione, di creare dei repository che possono essere popolati caricando, da file o tramite modalit`a alternative, i dati in for- mato RDF. Questi possono poi essere acceduti sia tramite query SPARQL che tramite metodi di accesso alternativi messi a disposizione da spacifiche librerie per Java. Come mostrato nell’architettura di figura 4.3 le triple RDF ottenute dalla trasformazione vengono caricate in Sesame ottenendo un vero e proprio dataset che a sua volta presenta dei collegamenti con altri dataset esterni, proprio come previsto dalle specifiche Linked Data.
Come spiegato nella sezione 3.3.2, il dataset di OpenERCH pu`o essere ac- ceduto sia richiedendo specifiche rappresentazioni delle varie risorse in esso contenute che tramite l’utilizzo di un endpoint SPARQL. Tale risultato `e ga- rantito da un’applicazione web, anch’essa basata sull’ambiente di esecuzione Tomcat, che permette di accedere ai dati nelle modalit`a appena indicate. Questa applicazione si occupa prevalentemente di garantire la deferenziazio- ne degli URI associati alle varie risorse del dataset: a seconda della risorsa a cui l’URI si riferisce e della rappresentazione richiesta essa recupera, tramite apposite interrogazioni, i dati ad essa associati e li converte per ottenere un documento che li esponga nella modalit`a indicata. `E, inoltre, tale applica- zione a rappresentare l’endpoint per le interrogazioni SPARQL: essa infatti riceve le query, si occupa di eseguirle sullo store e restuire i risultati cos`ı ottenuti nei formati richiesti. Essa contiene inoltre l’interfaccia grafica che permette di effettuare le interrogazioni direttamente via web. Maggiori det- tagli sulle attivit`a appena indicate sono riportati in sezione 4.4.
L’ultima componente nel diagramma di figura 4.3 `e rappresentata dall’appli- cazione ERCH-Mashup (descritta in sezione 3.4). Anch’essa non `e altro che un’applicazione web che gira su Tomcat e che racchiude una serie di servizi e pagine web create dinamicamente in base alle ricerche effettuate e alle vi- sualizzazioni di dati aggiuntivi richieste. Le informazioni da essa presentate sono pertanto reperite tramite query SPARQL sia sul repository interno che sugli endpoint messi a disposizione dai dataset esterni del Linked Data. `E importante sottolineare ancora una volta che tale applicazione rappresenta
solo un esempio di utilizzo dei dati creati e delle potenzialit`a del Web of Da- ta, pertanto non `e parte essenziale dell’architettura di OpenERCH, almeno per quanto concerne la messa a disposizione dei dati.