Concludiamo questa serie tecnica dedicata al Semantic Web presentando un esempio pratico. Lo scopo è realizzare un esempio di portale semantico con una navigazione delle informazioni più flessibile rispetto ai tradizionali sistemi di ricerca full-text .

Introduzione

Dopo aver parlato di RDF e RDFS (vedere [MOKA_SEMWEB_1] e [MOKA_SEMWEB_2]), di Ontologie e OWL (vedere [MOKA_SEMWEB_3] concludiamo questa serie tecnica dedicata al Semantic Web presentando un esempio pratico.
Lo scopo è realizzare un esempio di Portale semantico. L’idea di fondo è quella di arricchire semanticamente le informazioni alle quali accedere attraverso il portale, tale arricchimento permette di fatto una classificazione multidimensionale (faceted classification) delle informazioni con una conseguente navigazione delle informazioni più flessibile rispetto ai tradizionali sistemi di ricerca full-text (vedere[BMK_MC]).

SWAD-E Semantic Portal

L’esempio di Portale Semantico che verrà presentato è basato sul progetto Semantic Web Environmental Director (SWED). Il Portale, realizzato per scopi puramente didattici, fornirà un subset delle funzionalità disponibili del ben più ricco portale Semantico Mokabyte [MOKA-SWP].

Figura 1 – Moka Semantic web Portal (http://www.mokabyte-swp.it/SemanticPortal/)

Il progetto SWED fa parte di un progetto finanziato dalla Comunità Europea, denominato SWAD-Europe (Semantic Web Advanced Development) ed è stato sviluppato presso i laboratori Hewlett Packard a Bristol e presso ILRT (Institute for Learning and Research Technology) dell’Università inglese di Bristol.

Un prototipo di portale è raggiungibile all’indirizzo http://www.swed.org.uk/swed/index.html e mostra come creare una directory di organizzazioni e progetti ambientali all’interno del Regno Unito.

Il progetto SWED comprende anche il software (scaricabile gratuitamente) dal sito [SWED-TR] che permette di creare il proprio portale personalizzato.

L’esempio “ambientalista” è costituito dalla Web App di nome ‘portal’ contenuta all’interno del portal.zip.

La sua installazione è facile e immediata: basta installare la directory della Web Application in <>webapps.

Figura 3 – Il portale d’esempio installato su Tomcat in locale

Nella pagina principale si trovano gli argomenti suddivisi in diverse categorie (Topic of interest, Project type, Organisation Type, Activity, Operational area, Name) che facilitano la ricerca fungendo da filtro sulle informazioni d’interesse. I numeri all’interno delle parentesi indicano la cardinalità dei risultati per quella determinata categoria (facet). I vocabolari utilizzati per organizzare i dati secondo diverse gerarchie sono pubblicati utilizzando OWL per le ontologie e SKOS per i thesauri. SKOS è un vocabolario controllato progettato appunto per la costruzione di thesauri e, in questo ambito, viene impiegato per costruire una tassonomia [SKOS]. L’esempio SWED usa una combinazione di SKOS e OWL per definire un’ontologia e cinque thesauri.

Architettura

Si mostrerà ora una breve descrizione dell’architettura SWED (per dettagli vedere [SWED-S]).
I principali componenti dell’architettura sono il portal viewer e l’Aggregator.

Il portal viewer è l’interfaccia Web del Portale; è una Web Application Java che gira all’interno di un Servlet Container.

Le ontologie sono tipicamente memorizzate su file (RDFS, OWL o SKOS) e caricate in memoria mentre i dati RDF possono essere mantenuti o su file o su DB.

L’aggregator è il componente che si occupa di interrogare periodicamente (polling) una lista di siti configurati per aggiornare i dati RDF del portale in modo tale da essere consultabili dal portal viewer.

MVC

Il portal viewer è strutturato secondo il noto pattern Model-View-Controller (MVC).

Il controller dell’MVC è implementato con una Servlet (di nome Entry) che innesca l’azione corrispondente al valore del parametro HTTP action ed invoca l’opportuna vista (Velcocity template). Tutte le pagine del portale (View) vengono generate a partire da template Velocity (velocity-based template)
Velocity è un template engine opensource (Jakarta), attraverso i suoi template (.vm =Velocity Macro) si accede agli oggetti java presenti nel suo contesto[VELOCITY]. Il Velocity template engine è responsabile dell’opportuno rendering di tali pagine per creare la vista del portale. Questo meccanismo agevola la personalizzazione del “look and feel” del portale come si parlerà in seguito. Il Model è costituito da una serie di classi Java come Facet, FacetState, FilterState e DataStore. L’idea core per le ricerche nel portale è dividere lo “spazio di ricerca” in un set di dimensioni chiamate facet.
Ogni facet specifica alcune proprietà sulle quali effettuare le ricerche degli oggetti d’interesse. Queste possono essere semplici valori (es: lettera alfabetica) o ben piu’ complesse classificazioni gerarchiche.

L’oggetto DataSource Object incapsula tutte le informazioni riguardanti la configurazione del portale ed individua i dati su cui operare, le ontologie da utilizzare ed il rendering della vista da usare.

Come mostrato dall’architettura, all’interno del portal SWAD-E è presente il toolkit semantico di Jena, che fornisce una ricca interfaccia per elaborare dati RDF e OWL.

Di seguito si riporta un’immagine che descrive i principali oggetti del Model SWED.

Figura 7 – Il model MVC di SWED [HP]

È importante riportare che il Portale ha pieno supporto anche alle ricerche testuali visto che ingloba al suo interno un Lucene engine [LUCENE].
In ultimo, ma non per questo di minor importanza, con SWED viene deployato Joseki, per poter interagire direttamente con Jena attraverso il protocollo HTTP [JOSEKI].

Un esempio di Semantic Portal

Si mostreranno ora i passi principali eseguiti per personalizzare il Portale Semantico SWED al fine di adattarlo all’esempio riguardante la ricerca di articoli MokaByte scritti da Stefano Rossini e Alessandro Rocca.

Il portale è stato sviluppato partendo dalla versione minimale portalCore di SWED [SWED_PC].
Come scelta implementativa è stato definito un unico file OWL in cui accentrare sia l’ontologia che il thesauro, a differenza della versione pubblicata sul web in cui i thesauri sono riportati su differenti file SKOS.

Come personalizzare SWED

I principali passi da effettuare per personalizzare i dati, le ontologie ed il look end feel di SWAD-E richiedono la definizione di:

• Datasource, sorgenti dati da cui attingere le informazioni.
• Facet, definizione delle categorie di navigazione.
• Visualization Template, macro velocity per la definizione delle view.

Configurazione datasource

Per configurare i DataSource bisogna modificare il file <>WEB-INF/config/sources.n3. Tale file RDF, scritto in sintassi N3, contiene le proprietà di confogurazione con prefisso pcv. Ogni DataSource deve essere definito come una risorsa di tipo pcv:DataSource. Di seguito si riporta un esempio di definizione di DataSource:

[]    rdf:type pcv:DataSource ;
 rdfs:label "Kok Portal" ;
 pcv:encoding "ftd";
 pcv:order "90"^^xsd:integer ;
 dc:description "Micro family data set for testing" ;

Configurazione dei dati RDF

Con il tag pcv:sourceURL si configurano, come tipo di DataStore, i file di dati su cui il portale deve lavorare. Esempio:

pcv:sourceURL ;

Nell’esempio in questione il file articles.rdf contiene la lista degli articoli degli articolisti Mokabyte Rossini e Rocca. Nel caso in cui i dati fossero invece memorizzati su DB è possibile configurare l’opportuno data source JDBC. Ad esempio:

pcv:databaseURI "jdbc:mysql://localhost/swed" ;
 pcv:databaseModelName "SwedMain" ;
 pcv:databaseUser "user" ;
 pcv:databasePassword "password" ;
 pcv:databaseType "mysql";
 pcv:databaseDriver "com.mysql.jdbc.Driver" ;

Configurazione Ontologie

Tutte le ricerche a supporto della navigazione avverranno sui dati presenti nel file articles.rdf subordinatamente all’ontologia definita nel file OWL. Con il tag pcv:ontologySourceURL si configurano i file ontologici che il portale deve usare. Per esempio:

pcv:ontologySourceURL ;

Nell’esempio il file properties.owl contiene l’ontologia. Tale ontologia è stata creata con il tool Protègè [MOKA_SEMW_3] e definisce le tassonomie e le proprietà dell’esempio.

Figura 9 – Le proprietà dell’ontologia dell’esempio

Le tassonomie definite riguardano la classificazione degli articoli secondo le rubriche previste da Mokabyte (https://www.mokabyte.it/columns/index.htm) e la classificazione delle competenze del lettore.

Figura 10 – La classificazione delle rubriche di MokaByte

Configurazione regole di inferenza

In SWED è possibile derivare nuova conoscenza, mediante Jena, esplicitando le regole di inferenza [JENA_INF]. Attraverso tali regole si esprimono la chiusura transitiva e simmetrica. Per esempio:

Regola simmetrica
(?Y demo:collega ?X) -> (?X demo:collega ?Y)
  
Regola transitiva
(?f demo:padre ?a) (?u demo:fratello ?f) -> (?u demo:zio ?a)

Le regole di inferenza vengono inserite in un apposito file (p.e.: closure.rules), il quale deve essere configurato mediante la property pcv:closureRulesURL:

pcv:closureRulesURL   ;

All’interno del file closure.rules sono state definite le seguenti regole di inferenza.

Per derivare la chiusura transitiva sulla relazione moka:has_skill

(?P moka:has_skill ?T) -> (?P moka:has_skill_cl ?T) .
(?P moka:has_skill_cl ?T) (?T rdfs:subClassOf ?B)
 -> (?P moka:has_skill_cl ?B) .
  
Per derivare la chiusura transitiva sulla relazione moka:has_classification
(?P moka:has_classification ?T) -> (?P moka:has_classification_cl ?T) .
(?P moka:has_classification_cl ?T) (?T rdfs:subClassOf ?B)
 -> (?P moka:has_classification_cl ?B) .

Configurazione look and feel

Per quanto riguarda il look and feel (cioè la vista e gli stili da adottare nella presentation web) si deve configurare l’apposito file css per la definizione degli stili:

pcv:styleSheet "style.css" ;

Come detto precedentemente, la view di SWED è basata su velocity.

Esistono due principali template di visualizzazione. Un primo template view.vm, che funge da contenitore per altri template (header.vm, search.vm, viewFacets.vm, footerStart.vm, footerEnd.vm), che si occupa di definire il layout finale per la visualizzazione dei vari Facet e un secondo template pageview.vm, anch’esso contenente gli stessi template di view.vm, che si occupa di definire il layout per la visualizzazione della singola risorsa. Mediante la property pcv:template è possibile assegnare un particolare template velocity per la visualizzazione di una particolare risorsa.

pcv:template [a pcv:Template;
 pcv:templateContext "page" ;
 pcv:templateClass   demo:myClass ;
 pcv:templatePath    ;
];

Figura 12 – La View del portale di esempio (Velocità & CSS)

L’immagine in fig. 13 riassume le configurazioni fino ad ora effettuate.

Configurazione Facets

Configurati i dati sui quali il portale dovrà operare, è necessario definire la navigazione su tali dati. La navigazione è un aspetto che riguarda l’usabilità del portale e quindi la scelta di come guidare l’utente nell’esplorazione dovranno essere fatte in tal senso. Tecnicamente la navigazione viene configurata mediante la definizione dei Facet, che danno un impronta sulla classificazione e quindi sulla navigazione dei dati all’interno del portale.
I Facet vengono configurati mediante la proprietà pcv:facet per indicare una risorsa che specifica un’istanza della classe pcv:Facet. Attualmente esistono due sottoclassi concrete di pcv:Facet:

• pcv:HierarchicalFacet, le risorse vengono classificate secondo i concetti dichiarati gerarchicamente all’interno dell’ontologia.
• pcv:AlphaRangeFacet, le risorse sono raggruppate in ordine alfabetico sulla proprietà specificata.

I principali attributi che permettono di definire un facet sono:

• pcv:linkProp specifica la proprietà RDF che mette in relazione una risorsa con il valore di classificazione. Il Facet organizza le risorse secondo il valore di questa proprietà. Se i valori di classificazione rispecchiano una qualche forma di eredità, allora le regole di chiusura (vista in precedenza) permettono di aggiungere i valori ereditati.
• pcv:linkUpdateProp specifica la proprietà RDF che mette in relazione una risorsa con il valore di classificazione, senza elaborare alcuna forma di eredità. Di norma non deve essere differente dal valore di pcv:linkProp ma nel caso di Facet gerarchichi è utile avere due proprietà differenti, una per la classificazione diretta ed una per la chiusura della classificazione.
• pcv:facetBase, pcv:narrowP and pcv:widenP, in caso di Facet gerarchici queste proprietà definiscono la gerarchia di concetto. Il pcv:facetBase definisce il concetto più generale e normalmente non è visualizzato esplicitamente. Le altre due proprietà specificano come muoversi da un qualsiasi concetto verso concetti più specifici o più generali.
• pcv:order, numero intero che ordina il Facet. I Facet vengono visualizzati secondo una sequenza dettata da tale numero.
• rdfs:label, specifica il nome con cui il Facet verrà visualizzato.
• rdfs:comment, descrizione del Facet visualizzata insieme al nome del Facet (rdfs:label).

In fig. 14 si riportano le definizioni dei Facet utilizzate all’interno del portale.

I dati RDF

Dopo la panoramica relativa all’implementazione del Portale Semantico, si introdurranno i dati all’interno del file articles.rdf per verificare la giusta classificazione del portale. Il file RDF conterrà la seguente lista di articoli:

Per la creazione del file articles.rdf sono state utilizzate le API Jena [SEM_WEB_1]. Innanzitutto, per prima cosa è stata definita la classe Vocabulary wrapper per agevolare la creazione del file RDF [SEM_WEB_2]:

public class MOKADIC {
 /** 
The ontology model that holds the vocabulary terms
 */
 private static OntModel m_model = 
            ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null );
  
    /** 
The namespace of the vocabulary as a string
 */
 public static final String URI = "https://www.mokabyte.it/2007/09/moka/moka_owl#";
 /** 
The namespace of the vocabulary as a string
 */
 public static String getURI() {return URI;}
 /** 
The namespace of the vocabulary as a resource
 */
 public static final Resource NAMESPACE = m_model.createResource( URI );
 /** 
relation between Document class and Moka Classification Class
 */
 public static final ObjectProperty HAS_CLASSIFICATION = 
            m_model.createObjectProperty( URI + "has_classification" );
 /** 
relation between Document class and ProfessionalRole Class
 */
 public static final ObjectProperty HAS_SKILL = 
            m_model.createObjectProperty( URI + "has_skill" );
 . . .
 // Classi della tassonomia classificazione articoli 
    public static final OntClass MOKA_CLASSIFICATION = 
            m_model.createClass( URI + "MokaClassification" );
 public static final OntClass JAVA = m_model.createClass( URI + "Java" );
 public static final OntClass J2EE = m_model.createClass( URI + "J2EE" );
 public static final OntClass INTEGRATION = m_model.createClass( URI + "Integration" );
 public static final OntClass NEW_TRENDS = m_model.createClass( URI + "NewTrends" ); 
    public static final OntClass J2ME = m_model.createClass( URI + "J2ME" );
 public static final OntClass METHODOLOGY = m_model.createClass( URI + "Methodology" );
 . . . 
    // Classi della tassonomia classificazione skill articolisti
 public static final OntClass PROFESSIONAL_ROLE 
= m_model.createClass( URI + "ProfessionalRole" );
 public static final OntClass ARCHITECT = m_model.createClass( URI + "Architect" );
 public static final OntClass DEVELOPER = m_model.createClass( URI + "Developer" );
 public static final OntClass PROJECT_MANAGER 
= m_model.createClass( URI + "ProjectManager" );
 public static final OntClass WEB_DESIGNER = m_model.createClass( URI + "WebDesigner" );
}
 

Poi si creano le varie triple RDF per descrivere i 10 articoli precedentemente elencati:

public class CreateRdfForPortal {
  
private String CLASS_NAME = "CreateRdfForPortal";
  
private static final String FILE_NAME =
"C:/installed/apache-tomcat-5.5.23/webapps/KokPortal/data/kok/articles.rdf";
  
public static void main (String args[]) {
new CreateRdfForPortal().makeRdf();
}
  
    public void makeRdf(){
 try{ 
// create an empty model
Model model = ModelFactory.createDefaultModel();
. . . . .
  
 //(1)Architetture di Integrazione(I) - N. 105 - Marzo 2006
  
 Resource articoloResource 
= model.createResource("https://www.mokabyte.it/Article1")
.addProperty(RDF.type, MOKADIC.MOKABYTE_ARTICLE) 
.addProperty(RDFS.label, "Architetture di Integrazione(I)")
.addProperty(RDFS.comment, "Articolo di Mokabyte (https://www.mokabyte.it)")
// Moka tags
.addProperty(MOKADIC.HAS_TITLE, "Architetture di Integrazione(I)") 
.addProperty(MOKADIC.HAS_AUTHOR,"S. Rossini") 
.addProperty(MOKADIC.HAS_DESCRIPTION, "Articolo Mokabyte")   
.addProperty(MOKADIC.HAS_ARTICLE_URL, 
"https://www.mokabyte.it/cms/article.run?articleId
=C8Q-6EC-UH5-JH6_7f000001_7470813_5118d028")
// Classificazione JavaClass (ontologia JavaCLASS)
.addProperty(MOKADIC.HAS_CLASSIFICATION, MOKADIC.INTEGRATION)
// Classificazione skill lettore
.addProperty(MOKADIC.HAS_SKILL, MOKADIC.ARCHITECT);
  
. . . . .
// (10) Networking in Java: RMI-la teoria - N.43 - Luglio/Agosto 2000
  
articoloResource = model.createResource("https://www.mokabyte.it/Arcticle10") 
.addProperty(RDF.type, MOKADIC.MOKABYTE_ARTICLE)
.addProperty(RDFS.label, "Networking in Java: RMI-la teoria")
.addProperty(RDFS.comment, "Articolo di Mokabyte (https://www.mokabyte.it)")
// Moka tags 
.addProperty(MOKADIC.HAS_TITLE, "Networking in Java: RMI-la teoria")
.addProperty(MOKADIC.HAS_AUTHOR,"S. Rossini") 
.addProperty(MOKADIC.HAS_DESCRIPTION, "Articolo Mokabyte") 
.addProperty(MOKADIC.HAS_ARTICLE_URL, 
"https://www.mokabyte.it/2000/07/reti5_teoria.htm")
// Classificazione JavaClass (ontologia JavaCLASS)
.addProperty(MOKADIC.HAS_CLASSIFICATION, MOKADIC.JUMP_START)
// Classificazione skill lettore
.addProperty(MOKADIC.HAS_SKILL, MOKADIC.DEVELOPER);
  
FileOutputStream fos = new FileOutputStream(FILE_NAME);
model.write(fos);  
  
        . . . . .

La prova consiste nel navigare tra i facets e per vedere che gli articoli inseriti siano stati catalogati in modo corretto.

Come si vede in fig. 17 gli articoli vengono catalogati correttamente. Ci sono 4 articoli relativi alla sezione integazione, 3 relativi alla metodologia, 2 di New Trend e 1 della sezione Jump start. La classificazione relativa allo skill target dell’articolo presenta 5 Articoli per Sviluppatori, 8 per architetti, 3 per capo progetti e nessuno per Web Designer.

Proviamo ora a fare una ricerca ?semantica?. Vogliamo recuperare i soli articoli cha trattano di Metodologia e che sono adatti per lettori a cui interessa lo sviluppo. Partendo da una navigazione per classificazione degli articoli, si recuperano dapprima i soli articoli relativi a Metodologia e poi si selezionano tra questi i soli interessanti da un punto di vista dello skill per la categoria Developer. Il risultato è rappresentato dall’unico articolo risultante dall’intersezione dei due criteri di ricerca.

Conclusioni

Con questo articolo finisce la serie di articoli dedicati al Semantic Web. In questo ultimo articolo abbiamo ripassato, con l’ausilio di un esempio pratico, quanto descritto nei tre precedenti articoli [MOKA_SEMW_1], [MOKA_SEMW_2] e [MOKA_SEMW_3].

Riferimenti

[MOKA_SEMW_1] A. Rocca – S. Rossini, “Semantic Web. I parte: Introduzione a RDF, principi e Data Model”, MokaByte 119, Giugno 2007

[MOKA_SEMW_2] A. Rocca – S. Rossini, “Semantic Web. II parte: RDFS e vocabolari controllati”, MokaByte 120, Luglio/Agosto 2007

[MOKA_SEMW_3] A. Rocca – S. Rossini, “Semantic Web. III parte: Web Ontology Language (OWL)”, MokaByte 121, Settembre 2007

[SWAD-Europe]
http://www.w3.org/2001/sw/Europe/

[SWED] The Semantic Web Environmental Directory
http://www.swed.org.uk/swed/index.html

[SWED-TR] SWED Technical Resources
http://www.swed.org.uk/swed/swed_technical_resources.htm

[SWED-S] SWAD-E Portal structure
http://www.swed.org.uk/swed/doc/portal-structure.html

[SWED-EX] Esempio SWED
http://www.swed.org.uk/swed/servlet/Entry?action=v

[MOKA-SWP]
http://www.mokabyte-swp.it/SemanticPortal/

[JENA_INF]
http://jena.sourceforge.net/inference/

[VELOCITY]
http://velocity.apache.org/

[SKOS]
http://www-dimat.unipv.it/biblio/isko/doc/skos.htm

[BMK_MC]
M. Ballarin, “SKOS. Un sistema per l’organizzazione della conoscenza”
http://www-dimat.unipv.it/biblio/isko/doc/skos.htm

V. Marino,”Classificazioni per il Web: i vantaggi dell’adozione di schemi a faccette”
http://www.aib.it/aib/contr/marino1.htm

The Knowledge Management Connection
http://www.kmconnection.com/DOC100100.htm

Stefano Rossini

Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.

Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.

Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).

Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.

Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.

Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242