Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

179 dicembre
, anno 2012

D2R Server per mappare e importare ontologie da DB relazionali

III parte: Dump, importazione di modelli, Jena e consigli utili

Avatar

Matteo Busanelli

Nato a Imola nel 1978, ha conseguito la laurea Specialistica in informatica nel 2005 presso l‘Università di Bologna con una tesi sull‘"Estrazione di Ontologie da Framework standardizzati EDI/XML". Per tre anni ha lavorato come ricercatore presso il centro ENEA di Bologna seguendo progetti sull‘applicazione di tecnologie semantiche a framework e standard per l‘interoperabilità come ebXML o UBL, pubblicando insieme ad altri ricercatori diversi articoli su tali argomenti.
Attualmente è consulente presso Imola Informatica S.r.l. dove si occupa di piattaforme Java EE based e progetti sul Semantic Web, e i suoi interessi principali si orientano alle piattaforme enterprise basate su middleware semantici, Ontology Engeenering e alle interfacce basate su AJAX e GWT.

Matteo Busanelli e Vittoria Caranna

Vittoria Caranna

Vittoria Caranna è nata a Rimini nel 1982. Lauretasi in Ingegneria Informatica presso l‘Università degli studi di Bologna nel dicembre del 2007, da gennaio 2008 lavora per il Gruppo Imola.
Svolge attività di consulenza, in particolare per quanto riguarda le tematiche architetturali e di processo.

MokaByte

D2R Server per mappare e importare ontologie da DB relazionali

III parte: Dump, importazione di modelli, Jena e consigli utili

Matteo Busanelli e Vittoria Caranna

Matteo Busanelli e Vittoria Caranna

  • Questo articolo parla di: DataBase & elaborazione dei dati, Frameworks & Tools

In questa terza e ultima parte della serie su D2R Server, ci occupiamo di altri e non meno importanti aspetti inerenti il nostro strumento di mapping di ontologie da DB relazionali. Affrontiamo infatti il dump RDF, l’importazione di modelli, l’uso delle API D2R con JENA, e non manchiamo di fornire alcune indicazioni e note pratiche derivanti dall’esperienza d’uso.

Creazione e uso del dump

Un altro modo molto utile di utilizzare il mapping di D2R è quello di generare un dump RDF dell’ontologia.

Figura 1 – Generazione di un dump RDF dell’ontologia.

 

Possibili impieghi del file di dump possono essere:

  • apertura e modifica con un tool di sviluppo per ontologie (es. TopBraid o Protege’);
  • applicazione ad uno strumento di navigazione facet browsing come SWED.
  • importazione dentro a Semantic Media Wiki tramite SEMI;
  • generazione diagrammi e grafici con TopBraid o Protege o altri tool;
  • importazione del dump in un triple-store tipo OpenAnzo o JENA-SDB;
  • Connessione a un altro endpoint SPARQL (soluzione al problema delle federated query) tipo JENA-JOSEKI
  • e poi… spazio alla fantasia!

Per generare il dump con D2R a partire da un file di mapping è possibile utilizzare il comando dump-rdf.bat (o dump-rdf per Linux) da prompt (nella root di d2r-server), come illustrato di seguito.

> dump-rdf.bat -m custom_mappingD2R_UnionMapping_Prog_e_Req.n3 -f N3 -b
    http://www.imolinfo.it/ontologie/esempio_corso/istanze# -o dump_esempio.n3

Con questo comando si specifica nell’ordine:

  • -m: percorso relativo o assoluto del file di mapping;
  • -f: formato del file di mapping (default “RDF/XML“, “RDF/XML-ABBREV“, “N3“, “N-TRIPLE“);
  • -b: il namespace da associare all’ontologia generata;
  • -o: il nome del file di output;

Per una lista completa sui parametri da passare a dump-rdf si veda la documentazione ufficiale [5].

Una volta terminato il dump (su DB molto grandi e mapping complessi può impiegare anche qualche minuto), avremo un file con tutte le istanze (e anche parte del modello se non specificato diversamente con serveVocabulary) valorizzate e pronte per essere utilizzate come da elenco sopra.

Di seguito riportiamo un estratto del file N3 generato nell’esempio in (dump_esempio.n3):

@prefix :         .
@prefix foaf:    .
@prefix rdfs:    .
@prefix spec-m:  .
@prefix d2r:      .
@prefix xsd:     .
@prefix owl:     .
@prefix map:     .
@prefix rdf:     .
@prefix vocab:   .
@prefix doap:    .
@prefix skos:    .
 
:person-2
    a     foaf:Person ;
    rdfs:label "Claudio Bianchi"^^xsd:string ;
    foaf:currentProject :progetto-3 ;
    foaf:family_name "Bianchi"^^xsd:string ;
    foaf:firstName "Claudio"^^xsd:string ;
    foaf:mbox "claudio.bianchi@esempio-corso.it"^^xsd:string .
 
spec-m:data_inizio
    a     rdf:Property .
 
spec-m:ProgettoSoftware
    a     rdfs:Class .
 
:progetto-2
    a     spec-m:ProgettoSoftware ;
    rdfs:label "Libro unico del lavoro"^^xsd:string ;
    doap:maintainer :person-1 ;
    spec-m:data_fine "2011-03-31T00:00:00"^^xsd:dateTime ;
    spec-m:data_inizio "2011-01-01T00:00:00"^^xsd:dateTime .
 
   .
   . 
   .
 
:testcase-2-fun_1-1
    a     spec-m:TestCase ;
    rdfs:label "Accesso alla sezione di documenti LUL"^^xsd:string ;
    spec-m:ha_input "Accesso alla sezione di documenti LUL"^^xsd:string ;
    spec-m:ha_output_atteso
          "Visualizzazione della lista con tutti i documenti"^^xsd:string ;
    spec-m:progetto_relativo
          :progetto-2 ;
    spec-m:test_case_di :requisito-fun_1 .
 
:testcase-3-fun_100-1
    a     spec-m:TestCase ;
    rdfs:label "Inviare un … il pulsante ricevi"^^xsd:string ;
    spec-m:ha_input "Inviare un messaggio alla casella, … ricevi"^^xsd:string ;
    spec-m:ha_output_atteso
          "Il messaggio inviato appare nella lista"^^xsd:string ;
    spec-m:progetto_relativo
          :progetto-3 ;
    spec-m:test_case_di :requisito-fun_100 .
 
:progetto-3
    a     spec-m:ProgettoSoftware ;
    rdfs:label "Web Mail Legalmail"^^xsd:string ;
    doap:maintainer :person-2 ;
    spec-m:data_fine "2011-04-14T00:00:00"^^xsd:dateTime ;
    spec-m:data_inizio "2011-04-12T00:00:00"^^xsd:dateTime .
 
doap:maintainer
    a     rdf:Property .
 
:person-3
    a     foaf:Person ;
    rdfs:label "Marco Nei"^^xsd:string ;
    foaf:currentProject :progetto-4 ;
    foaf:family_name "Nei"^^xsd:string ;
    foaf:firstName "Marco"^^xsd:string ;
    foaf:mbox "marco.neri@esempio-corso.it"^^xsd:string .
 
    .
    .
    .

 

Importazione modelli

Per i tool che usano o necessitano dell’importazione dei modelli usati, come per esempio TopBraid, è possibile effettuare l ‘import da dentro l’IDE, specificando i file che si vogliono importare oppure si riesce a generare con D2R lo statement di import in modo che il file possa già dichiarare il modello importato.

Di seguito si riporta un esempio per aggiungere l’import di un modello solo e la specifica del namespace relativo alle istanze:

map:Ontology a d2rq:ClassMap;
    d2rq:dataStorage map:database;
    d2rq:uriPattern "http://www.mps.it/ontologie/EA/v1.0/state-model-mps-istanze" ;
    d2rq:class owl:Ontology;
    .
 
map:Ontology_Import
    rdf:type d2rq:PropertyBridge ;
    d2rq:belongsToClassMap
          map:Ontology ;
    d2rq:constantValue ;
    d2rq:property owl:imports;
    .

Dove:

  • “http://www.mps.it/ontologie/EA/v1.0/state-model-mps-istanze” va sostituito con il namespace delle istanze che si sta generando (il base URI senza “#“)
  • va sostituito con il namespace del modello che si vuole importare nel file di istanze. Se il modello è più di uno (nel caso dello state model solitamente basta lui che a sua volta include il resto) si andranno a specificare più PropertyBridge, ognuno con il suo import (p.e.: Ontology_Import_1, Ontology_Import_2 etc.).

Questi namespace saranno specifici a seconda del contesto.

Uso delle API D2R con JENA

Uno degli aspetti più interessanti di D2R è costituito dalla possibilità di usarlo per via programmatica, direttamente integrato con lo JenaModel. Ciò di fatto permette di riprodurre tutte le funzionalità del servizio e del dump da un programma Java e in particolare di poter trattare come un normale modello di JENA una istanza di D2R che mappa una o più sorgente dati.

D2R Server Update

Esiste anche una estensione prototipo di D2R Server che oltre a mappare in lettura permette di utilizzare il linguaggio di update SPARQL Update (non standard) per scrivere sulle sorgenti mappate.

Questa funzionalità aprirebbe le porte a una visione architetturale più consistente e ampia in cui D2R recita un ruolo centrale nell’integrazione completa (bidirezionale) fra il mondo delle ontologie e quello delle sorgenti RDB [7].

Note e consigli

Nei paragrafi seguenti riportiamo alcuni consigli e appunti derivanti dall’esperienza sul campo. L’intento è quello di riportare casi o soluzioni a problemi che possono verificarsi facilmente quando si crea un mapping con D2R.

Creazione di Tassonomie da File Excel

Un mapping tipico che viene richiesto è quello a partire da sorgenti piuttosto piatte come i fogli di calcolo tipo Excel, in cui sono state riportate in qualche modo delle tassonomie, magari anche complesse.

Ora, in una ontologia ci sono due modi per rappresentare una tassonomia:

  1. tramite una alberatura di classi OWL;
  2. tramite una alberatura di istanze.

Il primo caso è utile quando si dovranno di fatto creare vere e proprie istanze di quella tassonomia con tanto di ereditarietà multipla (es. Classificazione di concetti inerenti i progetti: ProgettoXYZ is-a Progetto). In questo caso, stiamo parlando di classi di modello e quindi, solitamente, la generazione delle classi viene fatta a mano. In alternativa è possibile generarle anche con D2R definendo un ClassMap su owl:Class e dei PropertBridge per mappare le meta relazioni rdfs:isSubClassOf, rdfs:label e rdfs:comment.

Alcuni punti critici

Una situazione cui fare attenzione: generare una tassonomia di classi OWL in maniera automatica da una alberatura esistente può portare ad avere un modello pesante e semanticamente scorretto in quanto le classi sarebbero solo una alberatura senza una vera caratterizzazione (relazioni e proprietà) e molto spesso potrebbero non rispettare il concetto di “sottoinsieme di” previsto dalla semantica di owl:Class. Per esempio, potrebbe capitare di avere un’ alberatura basata sulla relazione “fatto_di” o “contiene”.

Un esempio potrebbe essere un processo fatto di sottoprocessi che lo compongono e magari ogni sottoprocesso è fatto di attività. Questa è una tassonomia, ma non è intesa come la intende OWL a livello di modello (owl:Class e rdfs:isSubClassOf). La semantica di meta-modello di OWL è quella di sotto-insieme ossia:

se B isSubClassOf A e C rdf:type B allora C è anche istanza di A

Pertanto è necessario verificare bene che tipo di soluzione adottare.

Il secondo caso invece è indicato quando ogni nodo dell’albero di classificazione non dovrà essere istanziato ma usato come possibile riferimento da altre istanze per connotare una particolare classificazione relativa ad una precisa tassonomia.

Un esempio di questo caso potrebbe essere una tassonomia di processi o di aree o una categorizzazione di componenti architetturali che possa essere puntata da istanze di componenti software per indicarne il posizionamento nella classificazione architetturale. Per esempio, l’istanza di ComponenteSoftware MySQL_5.1 è classificato architetturalmente come RDBMS o più genericamente come Storage.

Come adattare il foglio di calcolo

Per velocizzare questo tipo di mapping e quindi creare una struttura tassonomica basata su una classe di tipo nodo e delle istanze legate fra loro da una relazione gerarchica da padre a figlio, a partire da una rappresentazione Excel, molto spesso è necessario adattare il file Excel stesso per rendere più semplice e ripetibile il mapping con D2R.

Il template di Excel rappresenta una tassonomia astratta a tre livelli con una sola radice (figura 2).

Figura 2 – Il template di Excel.

 

Nel template, ogni colonna rappresenta un livello della tassonomia. La struttura dell’Excel è predefinita e deve rispettare la seguente regola:

“Ogni nodo di livello M ha almeno una cella per cui la cella successiva è vuota. Questa riga servirà al mapping per istanziare quel nodo al livello M della tassonomia e specificare suo padre come valore della cella con l’eccezione della prima colonna (nodo radice) che non avrà padre.”

Nell’esempio dell’immagine, la cella <3,B> ha la cella <3,C> vuota e quindi può essere riconosciuta dal classMap condizionale per i nodi di livello 2 (3-1 perche’ la prima riga viene considerata di header anche dal mapping). Stessa cosa dicasi per la cella <2,A> che mappa il nodo root di livello 1 e la cella <4,C> che mappa il nodo di livello 3.

Nel file di mapping verrà quindi definito un ClassMap condizionale per ogni livello in cui la condizione della regola appena citata è relativa al suo livello e a cui sarà attaccato un PropertyBridge relativo per la creazione del padre.

La classe di nodo

Di seguito si riporta l’esempio per la creazione delle istanze di Taxonomic-Node a livello 2 con padre di livello 1:

map:Secondo_Livello a d2rq:ClassMap;
    d2rq:dataStorage map:database;
    d2rq:condition "Tassonomia$.secondo_livello <> ''" ;
    d2rq:condition "Tassonomia$.terzo_livello IS NULL" ;
    d2rq:uriPattern "@@Tassonomia$.secondo_livello|urlify@@";
    d2rq:class :Taxonomic-Node;
    . 
 
map:Secondo_Livello_Label
      :type d2rq:PropertyBridge ;
    d2rq:belongsToClassMap map:Secondo_Livello;
    d2rq:property rdfs:label ;
    d2rq:datatype xsd:string ;
    d2rq:column "Tassonomia$.secondo_livello" ;
    .
 
map:Secondo_Livello_isSubNodeOf a d2rq:PropertyBridge;
    d2rq:belongsToClassMap map:Secondo_Livello;
    d2rq:property :isSubNodeOf;
    d2rq:uriPattern "@@Tassonomia$.primo_livello|urlify@@";
    .   

Si noti che oltre all’istanza e al collegamento col padre (isSubNodeOf) viene anche mappata la label.

Atra nota importante riguarda la definzione della classe di nodo. È necessario definire una classe Taxonomic-Node per poter associare ad essa la proprietà riflessiva isSubNodeOf e da essa istanziare tutti i nodi di tutti i livelli connessi tramite questa proprietà. Ovviamente è possibile decidere di usare una classe diversa esistente (esempio SKOS concept) o una definita diversamente.

Dump in TopBraid

Di seguito si mostra il risultato del dump-rdf caricato in TopBraid (si vedono solo due livelli perche’ il terzo è stato mappato come foglia e quindi è relazionato ai nodi di secondo livello con una relazione diversa (isLeafOf anziche’ isSubNodeOf).

Figura 3 – Il risultato del dump RDF caricato in TopBraid.

Best practice di modellazione

Il motivo per cui si preferisce sempre usare una relazione da figlio a padre (p.e.: rdfs:isSubClassOf o isSubNodeOf o isLeafOf) per generare tassonomie è che risulta, dal punto di vista computazionale, più semplice gestire delle relazioni da uno a pochi (padri) che da uno a molti (figli). È quindi best practice di modellazione usare sempre relazioni tassonomiche che vanno verso la radice e non verso le foglie.

È consigliato quindi usare questo approccio per adattare in primis il file di Excel da cui si deve partire, in modo che rispetti la regola precedentemente illustrata

Problemi negli uriPattern con “-“

Si è notato che D2R non riesce ad effettuare correttamente le query quando nell’uriPattern ci sono caratteri come “-“. Per esempio, se un uri Pattern è del tipo:

d2rq:uriPattern "@@Temp-late$.secondo_livello@@";

cioè, il nome della colonna che si sta mappando contiene il carattere “–“, il dump darà un messaggio di errore del tipo mostrato in figura 4.

Figura 4 – Problemi incontrati con il carattere “-“.

 

Per risolvere questo problema si consiglia di non usare il carattere “trattino” in questione.

Conclusioni

Terminiamo qui questa serie di articoli su D2R server: chiaramente non è stato possibile trattare ogni aspetto di questo tool, ma speriamo di aver trasmesso l’interesse per questo versatile e potente strumento suscitando nei lettori curiosità per continuare le loro ricerche e fornendo qualche “dritta” derivante dall’uso sul campo.

Riferimenti

[1] Un tutorial abbastanza completo sull’uso di D2R Server con un DB MySQL

http://sw.cs.technion.ac.il/d2rq/tutorial

 

[2] Guida per connettere una sorgente relazionale mappata tramite D2R con l’endpoint JOSEKI 2

http://www4.wiwiss.fu-berlin.de/bizer/d2rmap/usecases/joseki/D2R4joseki2.pdf

 

[3] D2R/Update Server, un tutorial sull’uso di D2R Server per effettuare query con SPARQL Update e quindi andare in scrittura sul DB

http://d2rqupdate.cs.technion.ac.il/tutorial

 

[4 ] SPARQL 1.1 Update. W3C Working Draft

http://www.w3.org/TR/2009/WD-sparql11-update-20091022/

 

[5] La documentazione ufficiale riguardo il dump-rdf

http://d2rq.org/d2rq-language#dumprdf

 

[6] Linguaggio SPARQL Update

http://www.w3.org/TR/2009/WD-sparql11-update-20091022/

 

[7] Verso l’integrazione completa fra il mondo delle ontologie e quello delle sorgenti RDB.

http://d2rqupdate.cs.technion.ac.il/

 

Facebook
Twitter
LinkedIn
Avatar

Matteo Busanelli

Nato a Imola nel 1978, ha conseguito la laurea Specialistica in informatica nel 2005 presso l‘Università di Bologna con una tesi sull‘"Estrazione di Ontologie da Framework standardizzati EDI/XML". Per tre anni ha lavorato come ricercatore presso il centro ENEA di Bologna seguendo progetti sull‘applicazione di tecnologie semantiche a framework e standard per l‘interoperabilità come ebXML o UBL, pubblicando insieme ad altri ricercatori diversi articoli su tali argomenti.
Attualmente è consulente presso Imola Informatica S.r.l. dove si occupa di piattaforme Java EE based e progetti sul Semantic Web, e i suoi interessi principali si orientano alle piattaforme enterprise basate su middleware semantici, Ontology Engeenering e alle interfacce basate su AJAX e GWT.

Matteo Busanelli e Vittoria Caranna

Vittoria Caranna

Vittoria Caranna è nata a Rimini nel 1982. Lauretasi in Ingegneria Informatica presso l‘Università degli studi di Bologna nel dicembre del 2007, da gennaio 2008 lavora per il Gruppo Imola.
Svolge attività di consulenza, in particolare per quanto riguarda le tematiche architetturali e di processo.

Matteo Busanelli e Vittoria Caranna

Matteo Busanelli e Vittoria Caranna

Tutti gli articoli
Nello stesso numero
Loading...

L’evoluzione di Java: verso Java 8

VII parte: Java SE 8. Quasi Lamdba'

Appunti di UX design

III parte: Iniziare una professione nuova

Progettazione, sviluppo e gestione del change con modelli UML, framework e strumenti open source

IV parte: Requisiti del piano della configurazione

Command Query Responsibility Segregation pattern

III parte: Introduzione ad Axon framework

AlloyUI e applicazioni web

I parte: Introduzione al framework

Liferay Symposium 2012, Milano

Resoconto della giornata

Nella stessa serie
Loading...

D2R Server per mappare e importare ontologie da DB relazionali

II parte: Gestione del modello e uso del server online

D2R Server per mappare e importare ontologie da DB relazionali

I parte: Primi passi con D2R

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte