“Al GruppoImola siamo convinti che le tecnologie semantiche siano il salto epocale tecnologico prossimo venturo. Quindi ci interessiamo di quello che succede nel mondo, ancora poco visibile, di chi se ne occupa credendoci, e abbiamo avviato alcune iniziative a questo proposito”.
Questo primo articolo su MokaByte concretizza l‘annuncio apparso a Dicembre 2006 sul Wiki Gruppoimola Tech Trends. Attraverso questa nuova serie, condivideremo con voi la nostra visione del Semantic Web con la stessa passione e lo stesso entusiasmo che ci accomuna sin dal 1996, con la nascita di Java e di MokaByte.

Ormai è storia. Tim Berners-Lee, tra il 1989 e il 1991, lavorando presso il CERN di Ginevra creò il Web. Il Web, prima del suo lavoro, semplicemente non esisteva. Nei quasi venti anni successivi si è evoluto, arrivando alle nuove frontiere di oggi: Web 2.0, Social Networking, AJAX, mashup di contenuti e browser inteso non più come strumento di navigazione, ma come piattaforma che in alcuni contesti renderà  il sistema operativo una pura formalità .

La figura 1 riporta la rappresentazione grafica della proposta originale di Berners-Lee al CERN nel 1989. [1] Analizzando lo schema, è possibile notare come il diagramma espone concetti quali: “Tim ha scritto questo documento (wrote)” oppure “Questo documento descrive… (describes)” o ancora “includes”; il diagramma racchiude sia le associazioni tra le singole pagine statiche (refers to), sia la definizione di meta-informazioni semantiche delle relazioni e dei contenuti.

Figura 1 – Schema del World Wide Web proposto da Tim Berners-Lee al CERN

Le associazioni statiche, oltre al linguaggio ipertestuale, sono la parte del web utilizzata ad oggi. E la parte semantica? Semplicemente, in questi anni, non è (ancora) stata implementata. Questo non vuol dire però che sia stata abbandonata: il lavoro svolto da Tim Berners-Lee e dal W3C (fondato dallo stesso Berners-Lee nel 1994) è indirizzato, da sempre, verso questo obiettivo: XML, WSDL, XML Schema, XPath, RDF, OWL, SPARQL sono tutte Recommendation (standard) e/o Working Draft del W3C, sulla roadmap del Semantic Web. I motivi alla base dell‘avvio rallentato della parte semantica del Web sono più di carattere tecnologico e pratico che di tipo concettuale o di design: la rete, intesa come composizione di strutture hardware, di applicazioni software e di standard condivisi, non era (e probabilmente non è ancora) completamente pronta a supportare un‘infrastruttura Web Semantica. Si può fare una similitudine con i linguaggi interpretati, come Java: il concetto di pCode esiste dagli anni Settanta, ma la diffusione di linguaggi come Java e C# è arrivata solo a fine anni Novanta, inizi anni Duemila. perché? Uno dei principali motivi è di tipo infrastrutturale: l‘harware dei PC disponibili non era in grado si supportare, con un costo accettabile, il carico di lavoro indotto da una JVM. Analogamente i concetti di base per un Web Semantico erano già  definiti negli anni Novanta, ma erano troppo critici, da un punto di vista tecnico, per poter essere implementati e utilizzati a livello globale.

Il Semantic Web oggi

Stabilito che il Web è stato ideato con un‘intrinseca struttura semantica e che il W3C ha lavorato per più di dieci anni per definire gli standard a supporto di questo paradigma, a questo punto viene naturale porsi domande tipo: cosa comporta implementare il Semantic Web? perché devo interessarmi alle strutture semantiche? A cosa servono? Quale relazione c‘è tra Semantic Web e una ICT sempre più rivolta all‘ottimizzazione dei costi e alla valorizzazione del business aziendale? È un modello rivolto alle aziende, agli utenti “singoli” o a entrambe le categorie? La risposta data da Berners-Lee è esposta in un articolo pubblicato da Scientific American nel maggio del 2001 [2], che raccomandiamo come lettura a completamento di questo articolo. A una prima lettura, l‘articolo sembra molto distante dalla realtà  di oggi, e si posiziona al confine tra scienza applicata e fantascienza (chissà  se pensavano lo stesso i lettori di Jules Verne nel 1865!); ma gli scenari proposti non sono meno impossibili rispetto ad affermare, nel 1982: “la prossima volta che il capitano della nostra nazionale di calcio alzerà  la Coppa del Mondo, lo vedremo in digitale, seduti in spiaggia, grazie a un videofonino”. Gli scenari presentati da Berners-Lee sono futuristici, ma le tecnologie a supporto sono reali. Sono standard del W3C, sono implementate, o sono in procinto di esserlo, sia da tutte le più importanti realtà  dell‘IT (tra cui Oracle, IBM, HP, tanto per citare qualche big), sia da una nuova generazione di start-up (Radar Networks, Metaweb Technologies, Cerebra, acquisita da WebMethods in Agosto 2006, o la stessa SensibleLogic del Gruppo Imola); sono argomenti di studio e dottorato in tutte le università  di informatica e oggetti di ricerca di gruppi di lavoro al MIT, a Berkeley, a Cambridge e Bristol (HP Labs). Sono l‘evoluzione naturale del Web e saranno parte integrante del nostro prossimo futuro.

Ma torniamo alla domanda iniziale: che cosa è e a cosa serve il Semantic Web? La risposta è semplice, o quasi. Le strutture semantiche migliorano la condivisione e il trattamento delle informazioni, aziendali e non. Il Semantic Web è un insieme di tecnologie che si pone l‘obiettivo di rendere le informazioni comprensibili ed elaborabili da programmi, in modo da creare nuova conoscenza, in una serie di computazioni finite, a partire dalle informazioni iniziali e dalle loro relazioni. Con le tecnologie del Semantic Web sarà  possibile definire una base cognitiva distribuita che va oltre il singolo dato, aggregando le fonti informative in un‘unica entità  di conoscenza strutturata, interrogabile da agenti di ricerca basati su criteri semantici. La figura 2 riporta il digramma di un‘ipotesi abbastanza realistica, prodotta da Radar Networks, relativa ai tempi necessari per l‘adozione del Semantic Web da parte dei fornitori (aziendali e individuali) dei contenuti del Web.

Figura 2 – Un‘ipotesi dei tempi e dei coinvolgimenti dei gruppi nell‘evoluzione del Web [3]

Ricerca semantica vs ricerca testuale

Obiettivo degli standard alla base del Semantic Web è creare una rete spontaneamente predisposta alle ricerche semantiche. Attualmente, per interpretare il significato di una parola, i motori di ricerca ne analizzano il contesto in base alle parole adiacenti, non in base alla definizione semantica della parola stessa. Alcuni esempi: “pesca” (il frutto) e “pesca” (pescare), “miglio” (unità  di misura delle lunghezze) e “miglio” (il cereale), “boa” (il serpente) o “boa” (il galleggiante di segnalazione). Se provate a fare una ricerca con Google, ad esempio per “boa” o “pesca” i risultati sono un mix dei loro diversi significati. L‘algoritmo di ricerca di Google, per quanto sofisticato sia, non li distingue. Aggiungendo un‘altra parola, come “boa nautica” o “pesca frutta”, le prime pagine dei risultati sono contestualizzate meglio, ma non è così anche per le successive. Altri motori di ricerca, ancora in fase embrionale, come Powerset o TextDigger saranno in grado di distinguere le parole omografe dal loro contesto e probabilmente suggerire quale dei significati utilizzare come criterio di ricerca. Ma, in entrambi i casi, si tratta sempre di analisi testuale, non semantica; si analizzano le parole vicine a quella richiesta per cercare di interpretarne il contesto. L‘approccio del Semantic Web è invece radicalmente differente: la parola, o anche l‘immagine o il file multimediale, sono contrassegnati con un tag semantico. Si potrebbe quindi avere una struttura del tipo pesca e pesca, boa, boa e così via.

Da qui, il problema si sposta a un livello superiore : cosa sono, per il Semantic Web un o un ? perché e non ? Quale relazione c‘e tra e , o più genericamente tra , e ? Gli acronimi XML, OWL e RDF utilizzati all‘inizio dell‘articolo, servono appunto a questo, a definire la struttura semantica delle informazioni. Vediamoli nel dettaglio.

Semantic Web Stack

Il Semantic Web è uno stack tecnologico formato da più componenti in cui ogni livello è la base per gli standard definiti ai livelli superiori, come mostrato nella figura 3.

Figura 3 – Semantic Web Stack

URI, Unicode, XML, Namespaces, XML Query e XML Schema dovrebbero essere concetti ben noti ai lettori di MokaByte; sono tecnologie ordinarie anche per Java. Chi non ha dimestichezza con questi termini, può trovare una spiegazione esaustiva al sito del W3C, www.w3c.org o, in italiano su www.w3c.it e http://it.wikipedia.org. La sigla meno conosciuta è IRI: fortunatamente non ha nulla a che vedere con l‘italiana IRI (Istituto per la Ricostruzione), ma è l‘acronimo di Internationalized Resource Identifiers, un draft del W3C [5] a complemento delle URI che utilizza il set di caratteri Unicode per la definizione delle risorse. Risolve, concettualmente, il problema della definizione di URI con caratteri diversi dal subset di caratteri US-ASCII previsti per la scrittura di un‘URI. In pratica, adesso un‘URI può essere scritta con caratteri cirillici, hindi, cinesi o altro. Dato che il Semantic Web è un‘idea globale, deve di conseguenza essere costruito a partire da standard universali, non limitato ai caratteri latini.

Strutture RDF

Analizziamo la seguente struttura XML:

      ciliegio    10  
      noce    100  

Le informazioni sono descritti tramite metadati, ovvero tramite dati che descrivono le risorse informative stesse. Si può quindi affermare che un file strutturato in questo modo è semplice, chiaro, tutti possono capire che è un catalogo di mobili, che descrive oggetti comuni che tutti conosciamo e così via… Ma rimangono alcuni punti da chiarire: che cosa è un catalogo, un prezzo, una sedia, un tavolo o un legno? Ovviamente è chiaro a tutti noi, ma per un “agente”, ovvero per un programma software che deve interpretare le informazioni, che cosa è un “catalogo”? Se la nostra struttura fosse

sarebbe la stessa cosa? Per le persone sì, è ovvio; ma un sistema di ricerca per cataloghi e listini, come fa a sapere cosa è un “catalogo” e che un “listino” è pressapoco sinonimo di “catalogo”? Questo è il ruolo dell‘RDF e delle Ontologie nel Semantic Web.

RDF, framework per la descrizione delle risorse, è una raccomandazione (standard) del W3C, rilasciata nel febbraio 2004 congiuntamente alle specifiche OWL, che analizzeremo in seguito. Lo standard è costruito a partire dalle tecnologie URI e XML: tutte le regole che si applicano alle URI e all‘XML si applicano di conseguenza all‘RDF. Il W3C definisce l‘RDF così: “The Resource Description Framework (RDF) is a general-purpose language for representing information in the Web.”[4]. Sempre secondo il W3C, lo scopo dell‘RDF è, tra l‘altro, di fornire dei metadati per le risorse Web ed essere per i dati applicativi quello che il World Wide Web è per l‘ipertesto, per poter elaborare i dati al di fuori del contesto in cui sono stati creati e consentire ad agenti software il trattamento delle informazioni reperibili sul web [4].

La struttura di uno statement (asserzione) RDF è composta di una tripla, ovvero da un Soggetto, un Predicato e un Oggetto (o, equivalentemente, Risorsa – Proprietà  – Valore).

Figura 4 – Strutture RDF

Una Risorsa è una qualunque entità  associabile a un‘URI. Questo concetto racchiude quindi sia le risorse fisiche sia le risorse concettuali. Una Proprietà  (Predicato) descrive la relazione tra una risorsa (Soggetto) e l‘Oggetto (Valore) della relazione. Mentre una Proprietà  è a sua volta una Risorsa, identificata a sua volta da un‘URI, l‘Oggetto può essere una Risorsa o un Literal, ovvero una stringa di caratteri o altro tipo nativo (numero, data, booleano etc…).

Un classico esempio utilizzato per illustrare un‘asserzione RDF è la frase:

https://www.mokabyte.it/rdftest.html ha un creator il cui valore è Mario Rossi 

Ricordiamo che l‘URI identifica univocamente una risorsa sulla rete. Definendo le risorse con i relativi URI, la formulazione in RDF diventa ():

https://www.mokabyte.it/rdftest.html: soggetto

http://dublincore.org/2003/03/24/dces#creator: predicato

https://www.mokabyte.it/staffID/12345: oggetto

La nostra asserzione utilizza ora termini univoci per tutta la rete: esiste una sola pagina https://www.mokabyte.it/rdftest.html, un solo creator (la risorsa definita nel Vocabolario di DublinCore alla pagina http://dublincore.org/2003/03/24/dces#creator) e, anche se esistono molti Mario Rossi, esiste un solo StaffID 12345 in MokaByte, che ha il nome di Mario Rossi.

A questo punto, possiamo estendere l‘esempio andando ad aggiungere proprietà  all‘oggetto “Mario Rossi”, che può essere una Risorsa o un Literal. In questo caso è una risorsa (ha un URI associato). La risorsa può quindi essere a sua volta il soggetto di altre asserzioni RDF. Ad esempio:

https://www.mokabyte.it/staffID/12345 ha un nome il cui valore è Mario Rossi
https://www.mokabyte.it/staffID/12345 ha un‘email il cui valore è mrossi@moka.it
https://www.mokabyte.it/staffID/12345 ha un numero di telefono il cui valore è 54321

Lo standard prevede anche una notazione grafica per le asserzioni RFD; applicando questa notazione al nostro esempio, otteniamo il seguente diagramma:

Figura 5 – Notazione grafica RDF realizzata con IsaViz [6]

Un‘altra notazione prevista è la formalizzazione RDF/XML. Utilizzando questo formato, le asserzioni diventano:

	xmlns_rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
	xmlns_rdfs="http://www.w3.org/2000/01/rdf-schema#" 
	xmlns_prefix1="https://www.mokabyte.it/rdftest/termini#" 
	xmlns_prefix2="http://www.w3.org/2000/10/swap/pim/contact#">

    
        
        Mario Rossi
        
    

Oltre alle tre notazioni degli esempi, vi sono altri formati, come N-Triples [7] e Notation 3 (N3) [8]. Le notazioni sono tra loro equivalenti, ed è possibile passare da un formato all‘atro; gli strumenti a supporto di RDF, come IsaViz, sono in grado di trasformare assert RDF da una notazione all‘altra. La scelta del formato da utilizzare è solitamente relativa al contesto: in un documento di presentazione di un progetto, la notazione grafica risulta sicuramente più leggibile, mentre per le pagine Web si usa spesso la notazione XML. Un esempio sono i feed RSS 1.0 (RDF Site Summary) [9], utilizzati per il Web Syndication [10] di blog, wiki etc.

Vocabolari

Prima di passare alle caratteristiche dell‘ RDF Schema, è necessario stabilire una terminologia comune per i concetti di vocabolario, tassonomia, thesaurus e ontologia. Una descrizione molto interessante, a cui ci siamo allineati, è riportata al sito http://www.metamodel.com [11]. Tutti sanno cosa è un vocabolario: un elenco di parole cui è associato uno o più significati. Il Semantic Web estende questa nozione, con il concetto di “vocabolario controllato”, ovvero un set di parole non ambigue e non ridondanti (solitamente) sotto il controllo di un‘authority che ne garantisce l‘integrità  inoltre, ogni termine in un vocabolario RDF è associato a uno e un solo URI, che ne identifica univocamente il significato. Questo risolve il problema delle parole omografe.

RDF Schema

Il puro RDF serve unicamente per descrivere modelli di dati e può esprimere semplici affermazioni come “una pesca costa 1 euro”, “una particolare pesca è un frutto” e così via. Tuttavia quando si usa RDF per descrivere gli oggetti di un particolare dominio (il mercato ortofrutticolo ad esempio), è indispensabile tenere conto della natura stessa del dominio, in termini di categorie o classi di oggetti del dominio, di relazioni possibili tra gli oggetti e di regole cui queste relazioni devono sottostare per essere “valide”. A questo “insieme di meta-informazioni valide per un dominio di interesse”, ci si riferisce solitamente col nome di “ontologia”.

RDFS è un‘estensione di RDF (è “scritta in RDF”) che introduce dei costrutti cui attribuisce una semantica (significato) particolare, consentendo di creare semplici Ontologie. I principali costrutti di RDFS [12] sono

rdfs:subClassOf

e

rdfs:subPropertyOf

che consentono di organizzare in tassonomie le classi e le relazioni (Properties) del dominio a seconda della loro generalità . Possiamo ad esempio dire che la classe “pesca” è una sottoclasse della classe “frutto”, o ancora che “essere il migliore amico di una persona” è una sotto-proprietà  (una relazione meno generale) di “conoscere una persona”. Partendo da un‘Ontologia RDFS di riferimento e da un modello di dati espresso in RDF, un agente software “intelligente” (o meglio “non stupido”) può usare queste meta-informazioni per fare dei semplici ragionamenti sui dati: se Mario è il miglior amico di Dino allora Mario conosce Dino. Questo processo chiamato Reasoning (“ragionamento”) è uno dei principi cardine del Semantic Web, in quanto consente di inferire nuova conoscenza ricavando affermazioni che non erano specificate esplicitamente nei dati iniziali, Tante più caratteristiche o vincoli strutturali del dominio posso esprimere con il mio linguaggio ontologico, tanto più potente potrà  essere il ragionamento che posso applicare ai dati.

Ma tutto questo non è sufficiente per poter arrivare a strutture semantiche capaci di garantire ragionamenti “reali” agli agenti software. Ad esempio, in RDFS non è possibile dire “una persona può avere una sola madre”: un ragionatore RDFS non è quindi in grado di segnalare che una base di dati in cui una persona ha due madri non è valida; allo scopo di potenziare questa espressività  in termini di “restriction” (vincoli) è stato creato un linguaggio (o meglio una famiglia di linguaggi) basato sulla Logica Descrittiva chiamato OWL.

La famiglia OWL

Ontologia è definita [11] come un vocabolario controllato determinato attraverso un linguaggio ontologico; per il Semantic Web il linguaggio è il Ontology Web Language (OWL) [13]. Come abbiamo visto precedentemente, RDFS da solo non è sufficiente a descrivere le informazioni in modo che un agente possa effettuare ragionamenti complessi in completa autonomia; RDFS si limita a definire le relazioni di ereditarietà , il concetto di risorsa, di proprietà , di collezione e poco altro, ma non riesce a descrivere completamente le relazioni che intercorrono tra le risorse. Il linguaggio OWL parte dai concetti base di RDFS e li estende, introducendo costrutti per la definizione delle cardinalità  e delle relazioni tra le classi, oltre a definire concetti avanzati per le proprietà  come simmetria, transitività , inverso o ancora informazioni relative alla versione di un‘ontologia o alle annotazioni ad essa associate. Le ontologie sono classificate secondo un sistema a scatole cinesi

• OWL Lite
• OWL DL
• OWL Full

Esse sono organizzate in maniera che la Full incapsula la DL che a sua volta incapsula la Lite. Ogni valida ontologia OWL Lite è quindi una valida ontologia DL, che è a sua volta una valida ontologia Full. Le differenza tra le tre ontologie risiede nel numero di costrutti a disposizione del linguaggio corrispondente e nelle garanzie di computazionabilità  e decidibilità . Vediamole nel dettaglio.

• OWL Lite: è il linguaggio più semplice, che supporta i fabbisogni minimi per la definizione di tassonomie e thesaurus.
• OWL DL: include un‘estensione dei costrutti del linguaggio rispetto a OWL Lite, ma ha al contempo delle restrizioni rispetto ad OWL Full che garantisce che le operazioni effettuate sull‘ontologia siano computazionalmente complete e che possano essere risolte in un numero di operazioni finite (decidibilità ).
• OWL Full: Utilizza gli stessi costrutti di OWL DL, ma non ha le stesse costrizioni. È il linguaggio più espressivo e completo per la definizione di un‘ontologia, ma perde la caratteristica di decidibilità  (non sempre è possibile ragionare sui dati e attendere un risultato) tipiche di OWL Lite e DL.

Ad esempio, con OWL DL se una classe C è la sotto-classe di una classe A, non può essere al contempo un‘istanza di un‘altra classe B. Con OWL Full invece non vi sono restrizioni di questo tipo, con il risultato di poter incorrere in loop infiniti durante l‘esecuzione dei programmi e perdere di conseguenza le garanzie di completamento computazionale. Questa caratteristica rende anche più difficile realizzare, rispetto a OWL Lite e OWL DL, agenti software che possono eseguire ragionamenti e inferenze semantiche con ontologie OWL Full.

Per completezza di informazione, si devono segnalare due problematiche relative a OWL.

A livello semantico (ovvero di significato che si dà  ai termini come Classe, Istanza, etc.), vi sono delle incompatibilità  tra OWL (Lite e DL) e RDFS; tali incompatibilità  sono conciliate da OWL Full. Data la specificità  tecnica delle ragioni alla base delle incompatibilità , ne rimandiamo l‘approfondimento a un prossimo articolo di questa serie, che analizzerà  più dettagliatamente le semantiche alla base di RDF(S) e OWL.

Più vincoli esistono (ossia più una ontologia si avvicina ai domini reali), più il ragionamento è oneroso, in termini di complessità  e tempo di computazione. Questo è il principale motivo per cui, al momento, OWL è utilizzato poco (o per niente) in applicazioni Semantic Web reali.

Sicurezza

Trasversali a tutti i livelli sono le tematiche relative alla sicurezza. Considerato che la base per il Semantic Web è l‘XML, tutte le tecnologie relative alla sicurezza XML sono utilizzabili per autorizzare, autenticare e proteggere sistemi semantici. I concetti alla base della sicurezza applicativa possono essere riassunti nei seguenti punti:

• autenticazione: verificare e classificare le credenziali dell‘utente del sistema;
• autorizzazione: classificare i livelli di informazioni a cui un utente o un gruppo di utenti possono accedere e fornire, in base al risultato del processo di autenticazione i diritti di accesso al sistema;
• integrità : verificare che l‘informazione non sia stata manipolata da terzi durante il tragitto sulla rete;
• riservatezza: crittografare, tramite chiavi, le informazioni trasmesse sulla rete;
• tracciabilità : utilizzo di firme digitali per poter provare, anche legalmente, le azioni eseguite da un utente nel sistema (non repudiation).

Per le strutture XML sono a disposizione numerosi standard tecnologici che soddisfano questi requisiti, e dal punto di vista del Semantic Web è ininfluente quale standard o tecnologia si voglia scegliere. I punti salienti da sottolineare sono:

• granularità : la sicurezza deve poter essere gestita a granularità  fine, ossia a livello di singolo elemento XML; questo deve valere per tutte le aree della sicurezza: autenticazione, autorizzazione, integrità , riservatezza e tracciabilità ;
• standard: è importante che la tecnologie prescelte siano uno standard consolidato e accettato dal mercato, in modo da poter essere facilmente integrabili tra loro.

Se prendiamo in esame scenari complessi, dove le informazioni devono attraversare più server e accedere a servizi eterogenei, la granularità  del livello di sicurezza diventa importante: devo poter autenticare, tracciare, autorizzare ogni singolo elemento del file XML che trasporta le informazioni. Il motivo è abbastanza ovvio: un server deve poter trattare alcune informazioni con granularità  diversa rispetto ai servizi seguenti o precedenti. A supporto delle proprie implementazioni di Semantic Web, è quindi importante utilizzare tecnologie allineate a questo paradigma.

Gli ultimi gradini dello stack

Se le parti dello stack analizzate fino ad ora sono coperte da standard consolidati o in via di consolidamento, lo stesso non si può dire per i livelli più alti. Le specifiche relative al linguaggio per l‘esecuzione di query semantiche (SPARQL) è una Working Draft del W3C [14] (anche se vi sono già  diversi strumenti che la supportano), mentre le parti superiori sono ancora a livello di condivisione e consolidamento delle di idee di base. Questo non rappresenta comunque un problema: gli standard RDF e OWL sono targati febbraio 2004: ci vorrà  del tempo prima che le applicazioni raggiungano un grado di maturità  tale da poter utilizzare i servizi di Logica, Verifica (Proof) e Fiducia (Trust) presenti in cima allo stack. E in quel momento, gli agenti semantici ipotizzati da Berners-Lee [2] saranno, probabilmente, una realtà  quotidiana.

Applicabilità  e applicativi

Dopo aver illustrato le caratteristiche tecnologiche del Semantic Web, ne rimangono da illustrare i campi di applicabilità  e le tipologie di applicativi che si possono costruire oggi. Senza far correre troppo la fantasia, attualmente l‘applicabilità  è primariamente dedicata a soluzioni intranet, in particolare rivolte alla creazione e condivisione di basi di dati interrogabili semanticamente, e a soluzioni internet verticali, ovvero basate su motori semantici, come ad esempio il Semantic Web Portal di MokaByte (MokaByte-SWP). La condivisione di strutture dati semantiche distribuite sulla rete è ancora un miraggio, e non solo per la mancanza di ontologie di riferimento comuni per la definizione di dizionari interoperabili. Un altro campo di applicazione nell‘immediato futuro Semantic Web sono gli scenari di integrazione della Semantic Integration, i Semantic Web Services e la Semantic SOA. Ma vediamo qualche esempio di scenari in cui applicare le tecnologie del Semantic Web.

Ricerche e database semantici

Attualmente, per i sistemi DB vi sono una serie di tecnologie consolidate come Data Mining, DataWarehousing, OLAP (On Line Analytical Processing) che danno risultati predicibili a partire da database ben strutturati. Il problema subentra, quando si deve/vuole lavorare con database eterogenei e integrare informazioni non registrate nel DB come documenti di testo o PDF, grafici, immagini, fogli di calcolo etc., che spesso racchiudono dati aziendali più utili di quelli immagazzinati nel DB stesso. In questo caso, la definizione del sistema informativo con ciclo di vita orientato alle ontologie normalizza semanticamente le tipologie e il contenuto delle informazioni e consente di effettuare ricerche a livello di metadati sia tra basi di dati eterogenee sia con documenti esterni ai DB, ma comunque annotati secondo l‘ontologia aziendale. In pratica, per arrivare a ricerche semantiche, serve prima definire gli schemi per l‘ontologia del dominio di lavoro, applicarla ai dati aziendali (annotazione semantica del sistema e estrazione dei metadati), definire un sistema per la navigazione e l‘interrogazione dei dati e costruire applicazioni User Friendly su questi layer per il loro utilizzo da parte degli utenti.

Definizione di Web Services

WSDL e le ontologie condividono lo stesso linguaggio (XML) e gli stessi servizi (XML Schema, Namespace etc.), ma si posizionano a livelli decisamente differenti risultando, di fatto, complementari. La descrizione del servizio WS fornito da WSDL non è implementabile con OWL, cosi come le relazioni semantiche tra le classi espresse da OWL non sono tracciabili con WSDL. In questo scenario, un‘ontologia può essere utilizzata con i risultati che ne conseguono ai diversi livelli

A basso livello, con OWL si possono descrivere le classi utilizzate come input/output da un messaggio WSDL. La candiate recommendation SAWSDL (Semantic Annotation for WSDL) [15] del W3C definisce uno standard per l‘utilizzo di ontologie all‘interno di file WSDL.

ad alto livello, è possibile descrivere i servizi offerti dal WebServices tramite un‘ontologia. Questo è un passo obbligato nel momento in cui i WebServices diventano parte di un‘architettura a servizi posizionata ai gradini più alti della roadmap SOA, dove si prevede il discovery dinamico dei servizi. Se si vuole che questa funzione sia esplicata direttamente dal servizio e non dal programmatore del servizio, il servizio deve poter agire in un contesto semantico in cui poter effettuare ragionamenti comparativi tra servizi sintatticamente eterogenei ma semanticamente uguali. In questo ambito, è stato proposto lo standard Web Service Modeling Ontology (WSMO), attualmente catalogato come Submission del W3C [16].

Semantic Integration

Lo sviluppo di architetture a servizi risolve il problema dell‘integrazione a livello tecnologico e architetturale [17], ma non definisce come integrare i dati provenienti dai database eterogenei sottesi ai servizi SOA. In questo caso, una definizione semantica delle basi dati che partecipano al dominio architetturale, e la creazione di ontologie sia per la definizione sia per la correlazione dei metadati, consente l‘astrazione e la normalizzazione delle informazioni scambiate dai servizi e ne consente l‘integrazione senza conoscerne la struttura a priori.

Conclusioni

In questa introduzione al Semantic Web abbiamo cercato di sviluppare l‘argomento da due punti di vista: il primo prettamente tecnologico, legato a standard e tecnologie, e il secondo allargato alle evoluzioni del Semantic Web e alla sua applicabilità  nei contesti architetturali e aziendali in cui lavoriamo. In entrambe i casi, abbiamo potuto constatare che il Semantic Web è un argomento vasto, composto da decine di standard più o meno consolidati con numerosi campi di applicabilità . Nei prossimi numeri di questa serie cercheremo di approfondire i temi qui esposti, con articoli sia tecnologici sia architetturali, che forniranno le conoscenze di base necessarie per l‘utilizzo degli strumenti – e in particolare tool Open Source, come da tradizione MokaByte – per il design, l‘implementazione e l‘integrazione di servizi e sistemi semantici, con cui costruire il nuovo Semantic Web.

Riferimenti

[1] Dan Brickley, “Semantic Web History: Nodes and Arcs 1989-1999. The WWW Proposal and RDF”
http://www.w3.org/1999/11/11-WWWProposal/

[2] Tim Berners-Lee – James Hendler – Ora Lassila, “Scientific American”, maggio 2001
http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21

[3] Nova Spivack, “Diagram: Beyond Keyword (and Natural Language) Search”, marzo 2007
http://novaspivack.typepad.com/nova_spivacks_weblog/2007/03/beyond_keyword_.html

[4] W3C, RDF/XML Syntax Specification (Revised), W3C Recommendation, 10 February 2004
http://www.w3.org/TR/rdf-syntax-grammar/

[5] W3C, Internationalized Resource Identifiers (IRIs)
http://www.w3.org/International/O-URL-and-ident

[6] W3C, IsaViz: A Visual Authoring Tool for RDF
http://www.w3.org/2001/11/IsaViz/

[7] W3C, N-Triples, W3C RDF Core WG Internal Working Draft
http://www.w3.org/2001/sw/RDFCore/ntriples/

[8] Tim Berners-Lee, “Notation 3, a readable language for data on the Web”
http://www.w3.org/DesignIssues/Notation3

[9] RDF Site Summary (RSS) 1.0, Official Specification
http://web.resource.org/rss/1.0/

[10] RDF Site Summary 1.0 Modules: Syndication
http://web.resource.org/rss/1.0/modules/syndication/

[11] “What are the differences between a vocabulary, a taxonomy, a thesaurus, an ontology, and a meta-model?”
http://www.metamodel.com/article.php?story=20030115211223271

[12] W3C, RDF Vocabulary Description Language 1.0: RDF Schema, W3C Recommendation 10 February 2004
http://www.w3.org/TR/rdf-schema/

[13] W3C, OWL Web Ontology Language Overview, W3C Recommendation 10 February 2004
http://www.w3.org/TR/owl-features/

[14] W3C, SPARQL Query Language for RDF, W3C Working Draft 4 October 2006
http://www.w3.org/TR/rdf-sparql-query/

[15] W3C, Semantic Annotations for WSDL and XML Schema, W3C Candidate Recommendation 26 January 2007
http://www.w3.org/TR/sawsdl/

[16] W3C, Semantic Web Services Interest Group
http://www.w3.org/2002/ws/swsig/

[17] Marco Piraccini – Stefano Rossini, “Service Oriented Architecture Parte IV: la Roadmap”, MokaByte 103, Gennaio 2006
https://www.mokabyte.it/cms/article.run?articleId=9C8-XES-NSG-CL5_7f000001_7470813_65e6ee3b