Web Semantico

MokaByte Marzo 2007 - Introduzione al Semantic Web

Visit site: http://www2.mokabyte.it/cms/article.run?articleId=YPB-QB7-E2Q-B8B_7...

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: http://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 (): http://www.mokabyte.it/rdftest.html: soggetto http://dublincore.org/2003/03/24/dces#creator: predicato http://www.mokabyte.it/staffID/12345: oggetto La nostra asserzione utilizza ora termini univoci per tutta la rete: esiste una sola pagina http://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: http://www.mokabyte.it/staffID/12345 ha un nome il cui valore è Mario Rossihttp://www.mokabyte.it/staffID/12345 ha un'email il cui valore è mrossi@moka.ithttp://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: 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 http://www2.mokabyte.it/cms/article.run?articleId=9C8-XES-NSG-CL5_7f000001_7470813_65e6ee3b

Skimmed by victorgodot at Apr 07, 2008