Nella parte precedente abbiamo definito una ontologia che in questo articolo utilizzeremo per l‘implementazione di un modello di catalogazione di software e progetti open source. L‘architettura proposta è solo un prototipo sperimentale, ma fornisce comunque un valido punto di partenza per comprendere struttura e funzionamento del nostro help desk semantico.
Come implementare il modello
Dopo l’introduzione fatta nel primo articolo della serie, proponiamo una architettura per l’implementazione di un modello di catalogazione di software e progetti open source basato su una ontologia come definita nella puntata precedente.
L’architettura presentata è solo un prototipo sperimentale che mira a definire un framework riusabile e scalabile per applicazioni semantiche; ciò viene fatto tramite una netta separazione delle ontologie (definite nell’articolo precedente) e della parte applicativa (totalmente intercambiabile) per mezzo di un middleware semantico che fornisce servizi e un unico punto di accesso alle ontologie.
Un caso applicativo del framework deriva dalla necessità di fornire un tool (o un insieme di tool) che permetta a un utente di Front-Desk sui Software Open Source di consultare l’ontologia dei progetti e di immetterne di nuovi o modificare/aggiornare le caratteristiche di quelli già esistenti.
Nello specifico i requisiti funzionali possono essere riassunti come segue:
- navigazione dell’ontologia sfruttando il paradigma del “faceted browsing”;
- ricerca (testuale e non) nell’ontologia;
- possibilità di navigare in maniera semantica fra le varie relazioni definite;
- modificare le proprietà dei progetti opensource già presenti;
- aggiunta di nuovi progetti all’ontologia.
L’idea di base è quella di fornire principalmente le funzionalità di Data Entry e di Browsing dell’ontologia integrandole nel portale interno di Imola. Il portale è basato su Liferay e quindi le funzionalità dovranno necessariamente essere integrate come portlet.
Si tenga presente che il vincolo di progettazione “Portlet Oriented” non implica necessariamente lo sviluppo di portlet, in quanto in alcuni casi è possibile trasformare una normalissima webapp in portlet con un minimo sforzo; laddove ciò non fosse possibile esiste sempre la possibilità di sfruttare una tipologia di portlet speciale chiamata “iFrame Portlet” che permette il semplice wrapping di una applicazione esterna in un iFrame.
Architettura generale
A partire dal modello del framework semantico mostrato nella prima parte di questa serie, si definisce più nel dettaglio una possibile architettura per l’implementazione dell’OSS Front-Desk.
Nel diagramma troviamo (a destra) l’ontologia (modello + istanze) che costituisce il modello ontologico di dominio e i dati indipendente dallo strato applicativo. Il modello di base è DOAP esteso poi dalle altre due ontologie per il maturity model e per le categorie di progetti (rispettivamente OSMMO e OSCAT). Si noti che queste ontologie sono definite statiche nel senso che vengono sviluppate una tantum e utilizzate per modellare le istanze e le relazioni fra i progetti con le valutazioni di maturità e la categorizzazione.
Il blocco di mezzo rappresenta il middleware semantico, ossia la piattaforma incaricata di mantenere le ontologie, organizzarle e gestirle secondo un modello a astratto (p.e.: named graph) e soprattutto di fornire servizi e possibili punti di ingresso per il lato applicativo. In questo modo si disaccoppia la parte delle ontologie dalla parte applicativa per mezzo di una specie di ESB o provider di servizi semantici. Nel nostro caso si è deciso di usare una nuova piattaforma open source chiamata OpenAnzo [ANZO] che vedremo più avanti nel dettaglio.
Al middleware semantico sono stati “agganciati” due servizi http (nello specifico due servlet) che permettono l’importazione all’interno del middleware delle nuove istanze di progetti e la pubblicazione su richiesta dei progetti catalogati e classificati in formato RDF/OWL.
Per finire abbiamo un livello applicativo costituito per ora da un semplice modulo di Data Entry che produce RDF che vengono importati tramite l’Import Service e una applicazione per visualizzare e navigare fra i progetti opensource usando il la tecnica del faceted browsing che viene alimentato (harvasting automatico) tramite il Get Service.
Il modulo di Data Entry verrà utilizzato prevalentemente da consulenti o comunque personale preposto all’aggiornamento e inserimento dei progetti Open Source di interesse per il gruppo, mentre il modulo di Faceted Browsing sarà di fatto l’interfaccia di navigazione e consultazione delle ontologie per il personale preposto al Front Desk e che quindi dovrà fornire direttamente consulenza a chi la richiede (per esempio per via telefonica).
Data Entry: SWED Data Entry Module
Ai fini di poter testare il front desk si è deciso di non implementare un sistema di data entry da zero ma di adattarne uno già esistente e perfettamente integrato con SWED. Il modulo si chiama appunto SWED Data Entry [SDE] ed è stato sviluppato come applicazione aggiuntiva a SWED per poter creare istanze RDF utilizzando form HTML generate automaticamente a partire da una definizione a sua volta in RDF.
Una volta effettuato il deploy del modulo su Tomcat (è un semplice WAR), a partire dal vocabolario RDF (in arancio) per la modellazione delle form (itemtype) e dall’ontologia di dominio di cui si vuole generare le istanze (in giallo), si dovrà creare una istanza RDF (in viola) che definisca il mapping e la tipologia di relazione fra i suoi campi di input e i relativi concetti dell’ontologia di dominio (es. campo di testo con label “nome” per il valore di doap:name). Questa operazione verrà “eseguita una tantum” in fase di configurazione del Data Entry. Nell’esempio 1, riportato di seguito, vediamo il file di configurazione RDF per SDE in formato Turtle:
. . .
[] a itemtype:FieldGroup;
itemtype:hasStyle "basic";
itemtype:hasPriority "1";
rdfs:label "Main details" ;
itemtype:hasScopeNote "Basic Information About Your Project" ;
# hidden fields
itemtype:hasField
[
a itemtype:Field;
itemtype:controlsProperty rdf:type ;
itemtype:hasStyle "simpleField" ;
itemtype:hasDefault swed:prorg;
rdfs:label "type " ;
itemtype:hasScopeNote
"The RDF type (ie prorg)";
itemtype:hasPriority "98" ;
itemtype:hasValue "Resource";
itemtype:hasScope "Item";
itemtype:visible "false" ;
itemtype:hasUIType itemtype:Field
];
itemtype:hasField
[
a itemtype:Field;
itemtype:controlsProperty swed:has_prorg_type ;
itemtype:hasStyle "simpleField" ;
itemtype:hasDefault swed_prorgtype:Project ;
rdfs:label "prorg type " ;
itemtype:hasScopeNote
"The type of prorg (project, organisation, part_of_organisation)";
itemtype:hasPriority "99" ;
itemtype:hasValue "Resource";
itemtype:hasScope "Item";
itemtype:visible "false" ;
itemtype:hasUIType itemtype:Field
];
. . .
In fase di run-time, invece, SDE genererà dinamicamente a partire da questo RDF di configurazione la form HTML per il data entry che una volta compilata e inviata produrrà il relativo RDF istanza per l’ontologia di dominio.
Per far ciò viene usato una opportuna Servlet chiamata RDFit che legge i campi e le informazioni provenienti dalla form (molte delle quali sono campi) e genera il file rdf istanza dell’ontologia di dominio. A questo punto il file generato (vedi esempio 2 riportato sotto, con l’istanza RDF di progetto DOAP generata dal servlet RDFit) sarà pronto per essere automaticamente importato nel middleware semantico.
<rdf:RDF
xmlns_semblog="http://jena.hpl.hp.com/semblog#"
xmlns_rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns_foaf="http://xmlns.com/foaf/0.1/"
xmlns_doap="http://usefulinc.com/ns/doap#"
xmlns_dc="http://purl.org/dc/elements/1.1/"
xmlns_swed="http://www.swed.org.uk/2004/02/swed#">
="http://https://opensso.dev.java.net/public/use/index.html"/>
stable
OpenSSO Enterprise 8.0 Update 1
2009-05-15
8.0
Identity and Access Management
OpenSSO
OpenSSO Enterprise
2008-11-01
="http://https://opensso.dev.java.net/servlets/ProjectIssues"/>
="http://https://opensso.dev.java.net/source/browse/opensso/"/>
="http://https://opensso.dev.java.net/servlets/ProjectMailingListList"/>
Solaris 9-10 OS on SPARC x86 and x64 , Linux,
Windows Server 2003 Enterprise Edition,
Windows xp, Windows Vista
Java
The Open Web Single Sign-On Project, also referred to as OpenSSO,
is an open development effort based on the source code for
Sun Java System Access Manager, a core identity infrastructure product
offered by SunMicrosystems, Inc. The goal of OpenSSO is to provide an extensible
foundation for an identity services infrastructure that will facilitate
single sign-on (SSO) for web applications hosted on web and application
servers in the public domain.
OpenSSO project include Open Federation, which is an open source project
based on the identity federation and web services framework developed
for Sun Java System Access Manager and Sun Java System Federation Manager.
Open Federation provides an extensible framework to support these features.
Identity services infrastructure for single sign-on
and Federation management
Middleware semantico + servizi: OpenAnzo
La piattarfoma di middleware semantico che abbiamo scelto di adottare è OpenAnzo [ANZO].
Il progetto OpenAnzo deriva direttamente da una fork di un progetto conosciuto come Boca [BOCA] e di altri componenti dell’ IBM Semantic Layered Research Platform.
Il progetto è ovviamente open source e unisce ad un sistema di triple-storing RDF organizzati per Named Graph (grafi nominati), una piattaforma completa ed estendibile di middleware semantico. Ciò costituisce una possibile base per la creazione di complesse applicazioni enterprise basate sulle tecnologie semantiche (RDF, OWL, SPARQL). Anche se la descrizione dettagliata di OpenAnzo esula dagli scopi di questo articolo, di seguito riportiamo la lista delle principali caratteristiche della piattaforma:
- supporto per utenti multipli (via LDAP);
- client e service distribuiti;
- funzionamento offline;
- sistema di ESB integrato per la comunicazione fra i vari servizi;
- real-time notification (via JMS);
- organizzazione e gestione delle ontology per Named Graph;
- versioning delle ontologie;
- controllo degli accessi e transazioni con precondizioni.
Le funzionalità principali del server Anzo sono accessibili tramite un client o a linea di comando o tramite le più potenti API. Nel nostro caso sono state utilizzate le API per poter implementare i servizi di import e di pubblicazione (get service) necessari per agganciare rispettivamente il sistema di Data Entry e di Faceted Browsing.
Abbiamo quindi sviluppato due servlet che sono state aggiunte per comodità all’interno del modulo SDE: AnzoImport e AnzoGet.
AnzoImport è la servlet connessa all’SDE la quale riceve tramite parametri di get l’URL dell’RDF generato da importare in Anzo e il nome del NamedGraph in cui importarlo. Di seguito riportiamo un estratto del codice che usando le API di AnzoClient effettua l’import:
...
String rdfURLStr = request.getParameter(AnzoParameters.RDF_URL_PARAM_NAME);
String namedGraph = request.getParameter(AnzoParameters.NAMED_GRAPH_URI_PARAM_NAME);
if (namedGraph==null) namedGraph = AnzoParameters.DEFAULT_NAMED_GRAPH;
if (rdfURLStr==null) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST,
"rdfUrl parameter must be specified
(i.e. http://example.org/graph.rdf).");
return;
}
else {
URI namedGraphUri = MemURI.create(namedGraph);
URL rdfURL = new URL (rdfURLStr);
InputStream inStr = rdfURL.openStream();
Reader in = new InputStreamReader(inStr);
anzoClient.importStatements(in, DEFAULT_RDF_FORMAT, null, namedGraphUri,
null, new INamedGraphInitializer[0]);
response.getWriter().println("Anzo Server used =
"+_anzoHost+":"+_anzoPort+"");
response.getWriter().println("AnzoImport Result: RDF
"+rdfURL.toString()+" successfully imported as namedGraph
"+namedGraph+"");
}
...
Abbiamo detto che SDE, tramite un servlet chiamato RDFit, genera un file RDF che rappresenta una istanza di un progetto DOAP (si veda Esempio 2). Una volta generato il file SDE mostra una pagina riassuntiva con le informazioni immesse in forma di tabella e alcune azioni e link che si possono fare.
Nel nostro si è modificata questa schermata (una pagina JSP) in modo da aggiungere un link generato dinamicamente che puntasse al servlet AnzoImport e con i parametri necessari (URL dell’RDF generato e namedGraph usato). Di seguito riportiamo un esempio di link per effettuare l’import:
http://localhost:8181/doap_data_entry/AnzoImport?rdfUrl =http://localhost%3A8181/doap_data_entry/rdfit/TestProject.rdf&namedGraphUri =http://imolinfo.it/doap/allProjects
Per importare quindi l’ontologia all’interno di OpenAnzo basterà cliccare “Pubblica tramite Anzo” nella pagina riassuntiva come si vede nella figura 4.
Faceted Browsing: SWED
Per la consultazione dell’ontologia si è deciso di usare SWED portal, [SWED] un progetto opensource che già in passato abbiamo avuto modo di usare e descrivere su MokaByte.
SWED permette di configurare il faceted browsing di ontologie predefinite locali o eventualmente anceh esterne importate tramite un modulo chiamato Harvester.
Lo harvester di SWED può essere configurato per puntare a più URL web da cui andare periodicamente a caricare le ontologie su cui effettuare il faceted browsing.
Nel nostro caso abbiamo configurato l’harvester di SWED per puntare alla servlet AnzoGet la quale genera su richiesta l’ontologia di tutte le istanze dei progetti inseriti tramite SDE.
Anzo fa questo automaticamente in quanto tutti i progetti vengono inseriti nel medesimo namedGraph e di conseguenza, quando viene richiesto il named graph http://imolinfo.it/doap/allProjects, Anzo provvede a restituire tutte le istanze in un unico file RDF nel formato richiesto. Di seguito riportiamo la configurazione dell’harvaster che abbiamo inserito nel file di configurazione “harvesterBootstrap.n3” di SWED:
... <http://localhost:8181/doap_data_entry/AnzoGet?namedGraphUri =http://imolinfo.it/ontologies/doap_instances> a :HarvestSource ; :trusted "a bootstrap root source" . ...
Come si nota si tratta semplicimente di uno statemente RDF in formato n3 che specifica l’URL dell’AnzoGet servlet più i relativi parametri come sorgente di SWED. Per quanto riguarda la servlet, di seguito riportiamo un estratto del codice che legge come parametri il nome del NamedGraph e il formato richiesto (RDF, Turtle, n3, etc.) ed effettua una richiesta (GET) al server ANZO usando le API dell’AnzoClient.
...
this.connectToAnzo();
String rdfURLStr = request.getParameter(AnzoParameters.RDF_URL_PARAM_NAME);
String namedGraph = request.getParameter(AnzoParameters.NAMED_GRAPH_URI_PARAM_NAME);
if (namedGraph==null) namedGraph = AnzoParameters.DEFAULT_NAMED_GRAPH;
if (rdfURLStr==null) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST,
"rdfUrl parameter must be specified (i.e. http://example.org/graph.rdf).");
return;
}
else {
URI namedGraphUri = MemURI.create(namedGraph);
URL rdfURL = new URL (rdfURLStr);
InputStream inStr = rdfURL.openStream();
Reader in = new InputStreamReader(inStr);
anzoClient.importStatements(in, DEFAULT_RDF_FORMAT, null, namedGraphUri,
null, new INamedGraphInitializer[0]);
response.getWriter().println("Anzo Server used = "+_anzoHost+"
:"+_anzoPort+"");
response.getWriter().println("AnzoImport Result: RDF "
+rdfURL.toString()+" successfully imported as namedGraph
"+namedGraph+"");
}
...
Una volta attivato l’harvester di SWED, il portale sarà popolato con gli stessi progetti inseriti o modificati in tempo reale dal Data Entry e saranno navigabili tramite gli opportuni facet configurati.
Figura 5 – Pagina principale di navigazione di SWED.
Conclusioni
Il progetto è assolutamente “work in progress” e quello che abbiamo mostrato è solo un prototipo. Restano quindi ancora molti punti aperti come per esempio la catalogazione usando l’ontologia OSSCAT in fase di Data Entry, l’aggiunta delle maturity note e del ranking e la modifica delle varie proprietà dei progetti.
Ciò che però importa è sicuramente il fatto che l’architettura sviluppata è molto scalabile e permette di sostituire/aggiungere i vari blocchi applicativi. Disaccoppiando infatti il livello ontologico e il livello applicativo tramite un middleware semantico come OpenAnzo che offre un livello di servizi alle applicazioni, è possibile per esempio sviluppare un modulo di data entry molto più sofisticato e accattivante per esempio con GWT, integrarlo magari come portlet in una piattaforma a portale come Liferay e tanto altro. In ogni caso il data entry dovrà sempre utilizzare un servizio di AnzoImport o qualche cosa di simile.
Stesso dicasi per la parte di Faceted Browsing. Si potrebbe pensare di impiegare un qualsiasi sistema di faceted browsing dotato di harvester come Longwell (più moderno e graficamente avanzato). Un sistema ancora più avanzato potrebbe effettuare query SPARQL su Anzo e magari tramite un opportuno servizio capace di ritornare i risultati dopo una sessione di inferenza su un reasoner.
Insomma se allo stato attuale non possiamo dire ancora di aver implementato la soluzione definitiva, possiamo però dire di aver sviluppato una architettura semantica scalabile e modulare che è ottimo punto di partenza per gli sviluppi futuri.
Riferimenti
[ANZO] Progetto Open Anzo
http://www.openanzo.org/index.html
[SDE] SWED Data Entry module
http://www.swed.co.uk/swed/swed_data_entry.war
[BOCA] Boca Project
http://ibm-slrp.sourceforge.net/
[SWED] Semantic Web Environmental Directory
http://www.swed.co.uk/swed/index.html