Parlando di Semantic Web è spesso difficile capire come la architettura generale del sistema possa funzionare. Dire che una ontologia, attraverso i metadati, comunichi le caratteristiche di un ogetto, specificando tutte le sue relazioni è una cosa che si può capire abbastanza facilmente. È facile per i programmatori che hanno una esperienza di linguaggi a oggetti, ma è facile anche per una qualsiasi persona che abbia provato ad usare un navigatore semantico.
Quello che spesso è più difficile spiegare è che in una vera architettura semantica l'ontologia non funziona mai per se stessa, non è mai isolata e sufficiente. L'architettura delle ontolgie deve essere molto modulare. Ci sono alcune ontologie che devono descrivere un dominio, altre che descrivono i processi, altre le risorse, altre sono delle ontologie di altro livello e come lavoro si occupano di collegare fra loro più ontologie.
Questo punto è cruciale. I linguaggi ontologici, l'organizzazione dell'informazione secondo schemi e metadati, ha senso solo all'interno di uno scenario di questo tipo. Altrimenti resta valida la frequentissimo obiezione che propongono i programmatori: "Le stesse cose posso farle con un linguaggio ad oggetti".
Da un punto di vista sintattico questo è permesso dal fatto che ogni cosa (Documento, classe di una ontologia, asserzioni) nei linguaggi ontologici è rappresentata come una risorsa (URI). Questo permette di definire nel proprio schema elementi riferendosi ad altri schemi.
In questo articolo però non intendiamo affrontare la prospettiva sintattica. Vogliamo dedicarci a quella architetturale. Se le ontologie si devono organizzare modularmente bisogna che le applicazioni che si servono delle ontologie lo sappiano.
I Web Services sono un primo ambito nel quale si è incominciato a utilizzare le ontologie a servizio di applicazioni specifiche. Guardando a questo settore di sviluppo del Semantic Web si è in grado di coglierne un aspetto cardine: il fatto che l'uso di ontologie ha senso solo se è definito un processo che ci spiega come e quando usarle.
In pochissime parole: cosa è un Web Service?
Nella rete i flussi di dati si organizzano in base a richieste alle quali seguono risposte. I Client sono applicaioni che richiedono qualche cosa, i Server sono applicazioni che inviano questo qualche cosa (per chi fosse completamente a digiuno di informatica è sufficiente pensare all'Explorer che richiede a un server la pagina html che abbiamo digitato nella barra degli indirizzi). In pratica i Web Services sono la definizione di una serie di regole per accedere a un servizio fornito da una certo Server. Le regole su cui accordarsi possono essere relativa al al protocollo, alla sintassi, alla semantica, oppure alle unità di misura utilizzate, per esprimere dei dati.
Il compito di un linguaggio che descrive un Web Services è di definire quando una transazione è compatibile per entrambe le applicazioni che si stanno impegnando a produrla. Per capire meglio proviamo a descrivere una semplice transizione.
Per prima cosa parte una richiesta dal client. Si ha qui la descrizione del tipo di servizio desiderato in termini di input spedito e output accettatto: cerco un servizio di acquisto cd.
Un mediatore fornisce una lista di servizi compatibili e si occupa poi di scegliere il servizio adatto al Client. Il mediatore è una parte della applicazione che a seconda degli scenari può essere o sul Client o sul Server o ancora in un terzo luogo.
A questo punto il Client invoca una query definendo il valore degli attributi richiesti: cerco il cd Germi del gruppo Afterhours.
La transazione si chiude con la risposta del Server che ritorna i valori di select della query.
È abbastanza facile intuire come in un situazione di questo tipo la semantica diventi fondamentale. Regole chiare di semantica (relazione tra termini e struttura delle operazioni) possono facilitare diversi compiti, come:
- Localizzare i servizi
- Negoziare i contrasti e i protocolli di comunicazione
- Invocare messaggi con sintassi valida
- Interpretare i risultati
- Utilizzare composizioni di servizi
Fornire i linguggi per la gestione dei Web Services delle possibilità espressive dei linguaggi per il Semantic Web è quindi una operazione che può portare solo vantaggi. Può migliorare i rapporti di modularità e la divisione dei compiti tra una ontolgia e l'altra. Può rendere la definizione delle transazioni tra servizi molto più flessibile ed efficace.
DAML-S: un'introduzione
La più importante proposta in questa direzione è rappresentata da DAML-S: DARPA Agent Markup Language for Services.
Questo linguaggio può avvalersi di almeno tre importanti caratteristiche. Possiede una ontologia di alto livello che descrive le proprietà di servizi e le azioni disponibili per un agente. È espresso in sintassi DAML+OIL (uno dei linguaggi più espressivi e meglio inseriti negli standard del Semantic Web). Fornisce agli agenti un linguaggio di markup a loro comprensibile.
L'obiettivo di DAML-S è di descrivere un servizio. A livello più alto un servizio è descritto specificando quattro classi fondamentali: Resource, ServiceProfile, ServiceGrounding, ServiceModel.
ServiceProfile
Questo ramo dell'ontologia sviluppa le proprietà e le relazioni che permettono di descrivere il Servizio. Presentare il processo con cui si sviuluppa un servizio può essere utile per vari motivi: ad esempio per descriverlo agli utenti, in pratica pubblicizzarlo, oppure per descriverne le proprietà ad altri servizi che ne fanno richiesta.
Per descrivere il servizio si possono descrivere i Parametri del Servizio: precondizioni, input, output, effetti. Si possono descrivere gli Attori che entrano in gioco nel Servizio. I Tempi di risposta. La Categoria del Servizio, collegandola tramite nome e URI ad una categoria definita da qualche altra parte.
ServiceModel
Questo ramo permette di descrivere il processo all'interno del quale il servizio si inserisce. Spiega in pratica attraverso quali passaggi il servizio dovrà lavorare.
Si può qui definire se il processo sia Atomico, Semplice o Composto. Si può definire diversi tipi di Controllo delle operazioni: Sequenziale, Concorrente, Condizionale e a Iterazione.
ServiceGrounding.
A partire da questo ramo è possibile specificare in che modo comunicare all'interno del Servizio. Protocolli di comunicazione, mecchanismi di Trasporto, linguaggi di comunicazione ecc. Insieme al Service Model gli attributi e le relazioni qui inserite consentono di ottenere tutto quanto necessario all'utilizzazione del Servizio. Da questo ramo si hanno classi che consentono di agganciare servizi tradizionali quali WSDL.
Resource.
Sotto questa classe si inserisono le localizzazioni di tutte le risorse che si sono richiamate nelle precedenti classi usate per descrivere il Servizio.
Per conludere questo velocissimo sguardo su DAML-S dobbiamo ancora chiarire una cosa. Questo linguaggio intende sostituire linguaggi più semplici come WSDL? La rispista è sicuramente no. L'obiettivo non è sostituirli ma integrarli, espanderli. Non è però subito facile capire quale sia il punto di collegamento tra i due linguaggi. Questo per il fatto che il punto di collegamento è sovrapposto. Ci sono alcune cose, come il ProcessModel che possono essere definite solo in DAML-S Altre cose, come i processi atomici, gli input output, le operazioni, possono essere edescritti sia servendosi di DAML-S che di WSDL. Altre ancora, come i protocolli, si descrivono unicamente in WSDL.
In pratica i progettisti di DAML-S hanno voluto permettere una integrazione flessibile tra i due linguaggi, in modo che a seconda della applicazione e dei casi, si potesse segliere dove collegare la descrizione del servizio.
Questa presentazione è chiaramente molto sintetica. Per chi desidera approfondire il tema non possiamo che consigliare la pagina ufficiale del progetto [http://www.daml.org/services]
