Semantic Web Services Mario Arrigoni Neri

Le generazioni del WEB Internet fase 1: contenuti statici Pagine HTML Risorse FTP L’utente sa cosa vuole e dove recuperarlo Internet fase 2: applicazioni web Personalizzazione del livello presentation.. VB-Script, J-Script, DHTML Contenuti dinamici (Servlet, JSP, ASP, Applet, …) L’applicazione interagisce con l’utente Internet fase 3: semantic web Documenti “leggibili” da agenti artificiali Servizi utilizzabili da agenti artificiali

Aspetti dinamici del sem-web Infomazione ricerca estrazione rappresentazione interpretazione manutenzione UDDI, WSDL, SOAP Web Services OWL-S Semantic WS Dinamico Applicazioni WWW RDF, RDF(S), OWL Semantic Web Statico URI, HTML, HTTP Sintattico Semantico

Linguaggi di supporto UDDI WSDL SOAP URI HTML HTTP Dinamico Statico Accesso/ ricerca Descrizione Accesso/ fruizione

Stato dell’arte - architettura UDDI: fornisce ai client un meccanismo per trovare i web service. Un registro UDDI è simile ad un “corba trader”, o ad un DNS di applicazioni WSDL: definisce i servizi come una collezione di terminali di rete o porte. Ogni porta è descritta da un indirizzo di rete; insiemi di porte definiscono i servizi SOAP: fornisce un sistema standard per costruire messaggi di richiesta e le risposte fornite dai singoli servizi. Sostanzialmente è un sistema per eseguire chiamate RPC su una rete tramite HTTP (ma non solo…) WS-Security WS-Routing etc… WSDL BPEL4WS XML UDDI WSDL SOAP HTTP

Ciclo di vita 2 3 1 4 5 WSDL - Web Service Description Remote Web Service Repository (Web Sites) Write Client Code Service Requestor Invoke Web Service Manual Lookup SOAP Request SOAP Response WSDL - Web Service Description SOAP - Web Service Message Protocol WSDL File Web service Publish Web 1 2 3 4 5 HTTP GET

Il messaggio SOAP SOAP Envelope SOAP Header Header Bock Header Bock SOAP Body Body subelement Body subelement

Elementi WSDL Type – è il contenitore per le definizioni di tipi di dato. Ogni definizione fa riferimento ad un particolare sistema di tipi, come ad esempio XSD Message – una definizione astratta e tipizzata dei flussi di dati da e verso il servizio Operation – una descrizione astratta di un’azione svolta dal servizio Port type – un insieme di operazioni supportate da uno o più nodi Binding – un protocollo concreto ed una specifica del formato dei dati per un particolare port type Port – un singolo nodo definito come la combinazione di un binding e di un indirizo di rete Service – una collezione di nodi (interdipendenti)

UDDI – classificazione – 2 UDDI utilizza tre tipologie distinte di registri: Contengono informazioni sul business: nome, descrizione, contatti Informazioni sulla classificazione del business e sui tipi di servizi forniti Informazioni su come ottenere (usare) un determinato servizio: es. l’URL del descrittore WSDL White Pages Yellow Pages Green Pages

E la semantica? Nel quadro fin qui delineato tutti i vari linguaggi descrivono la struttura di servizi e messaggi da un punto di vista sintattico Recentemente i Web Service hanno incominciato a trarre beneficio dagli avanzamenti del Semantic Web E’ infatti facile evidenziare vari errori dovuti a fraintendimenti sintattici: Livello di contenuto: il servizio ritorna “Milano”, mentre il richiedente si aspetta “MI” Livello di unità di misura: conversione da cm a pollici Livello di messaggio: Il servizio restituisce una estensione come la coppia <larghezza, altezza>, mentre il cliente richiede l’area

Servizi “semantic based” Ricerca automatica del servizio: WS adatti ad erogare il servizio richiesto. L’informazione necessaria per la ricerca viene fornita in maniera machine-processable (semantic UDDI). Il formalismo dovrebbe essere usato dal responsabile del servizio per pubblicarlo Invocazione automatica: Invocazione manuale: l’utente compila una form / codifica un codice che invia messaggi SOAP / usa un’interfaccia SOAP generata automaticamente Partendo dalla descrizione formale di altro livello del servizio l’invocazione viene eseguita automaticamente Composizione di servizi: data una descrizione del servizio desiderato e dei servizi disponibili, un sistema artificiale è in grado di comporre WS semplici per costruire servizi complessi Monitoraggio dell’esecuzione: con una rappresentazione della struttura dinamica del servizio si può tenere traccia dello stato corrente ed eventualmente del punto nel workflow in cui si è verificato un errore

OWL-S Come descrivere la semantica? Alcuni tentativi autonomi nati all’interno della comunità dei WS Dato che esistono linguaggi generali per descrivere ontologie (OIL, DAML+OIL, OWL), perché non usare quelli? In realtà OWL-S (OWL for Services) non è altro che una particolare (TOP) ontology per la descrizione di servizi Occorre evidenziare i principali concetti da rappresentare: domande Cosa richiede il servizio agli utenti (umani/artificiali) e cosa fornisce loro? Service Profile Come opera? Service Model Come viene usato? Service Grounding

ser:ServiceGrounding OWL-S top ontology xmlns:ser = “http://www.daml.org/services/owl-s/1.0/Service.owl#” ser:ServiceGrounding rdfs:domain rdfs:range ser:provides rdfs:range owl:Thing ser:Service ser:supports owl:inverseOf rdfs:domain ser:providedBy rdfs:range owl:inverseOf rdfs:domain rdfs:domain ser:supportedBy rdfs:domain ser:describedBy ser:ServiceProfile rdfs:range ser:presents owl:inverseOf rdfs:range owl:inverseOf Un servizio ha al più un modello Un grounding è supportato da uno ed un solo servizio ser:presentedBy ser:ServiceModel ser:describes

Invocation, Interoperation OWL-S top ontology Publication Profile Discovery Simulation Process Model Selection Verification Composition Invocation, Interoperation Grounding Monitoring, Recovery Development … Deployment … Use …

Service Profile – 1 Che organizzazione fornisce il servizio? Tre relazioni (non funzionali): serviceName: fornisce il nome del servizio, può essere utilizzato come identificativo del servizio textDescription: breve descrizione del servizio. contactInformation: fornisce un riferimento a persone responsabili del servizio. Il range della relazione può essere ristretto a seconda delle necessità: FOAF, VCard, ecc.. xmlns:prof = “http://www.daml.org/services/owl-s/1.0/Profile.owl#” <owl:ObjectProperty rdf:ID=“contactInformation”> <rdfs:domain rdf:resource=“#Profile”/> </owl:ObjectProperty>

Service Profile – 2 Che funzione fornisce il servizio? Definito tramite IOPE (relazioni funzionali): Input: flusso di dati in ingresso (numero di carta di credito) Output: flusso di dati in uscita (ricevuta) Precondition: vincoli sullo stato del mondo (carta valida) Effects: effetti sul mondo reale (addebito sulla carta) L’ontologia del profilo non fornisce un vocabolario specifico, ma prende in prestito quello (più esteso) dell’ontologia di processo

Service Profile – 3 Quali caratteristiche ha il servizio? xsd:string prof:serviceParameterName ser:ServiceProfile prof:ServiceParameter owl:Thing prof:sParameter rdfs:subClassOf prof:serviceParameter prof:Profile xsd:string prof:categoryName prof:code prof:taxonomy prof:ServiceCategory prof:value prof:serviceCategory

proc:CompositeProcess Service Model – 1 La descrizione del servizio si affida all’ontologia dei processi: prof:hasProcess proc:ProcessModel proc:Process rdfs:subClassOf = U ser:ServiceModel proc:SimpleProcess owl:disjointWith proc:AtomicProcess proc:CompositeProcess

Service Model – 2 IO (PE) proc:UnConditionalOutput proc:Condition proc:coCondition rdfs:domain rdfs:subClassOf proc:hasOutput proc:ConditionalOutput rdfs:domain rdfs:subClassOf rdfs:subPropertyOf proc:Process proc:hasParameter proc:Parameter rdfs:subPropertyOf rdfs:subClassOf proc:hasInput proc:Input

Service Model – 3 (IO) PE proc:UnConditionalEffect proc:Condition proc:ceCondition rdfs:range rdfs:subClassOf rdfs:domain proc:hasEffect proc:ConditionalEffect rdfs:domain proc:Process proc:hasPrecondition proc:Precondition rdfs:domain rdfs:range

Service Model – 4 Unconditional Effect / Output proc:UnConditionalEffect proc:ceCondition owl:Restriction owl:onProperty rdfs:subClassOf = owl:cardinality proc:ConditionalEffect ∩ proc:UnConditionalOutput proc:coCondition owl:Restriction owl:onProperty rdfs:subClassOf = owl:cardinality proc:ConditionalOutput ∩

Service Model – 5 Rapporti tra tipi di processi … proc:AtomicProcess realizes realizedBy proc:SimpleProcess expand collapse proc:CompositeProcess proc:Process U composedBy proc:ControlConstruct = components proc:ProcessComponent rdfs:subClassOf proc:Sequence … proc:Repeatuntil

Service Model – 6 ControlConstruct proc:ControlConstruct proc:components owl:Restriction rdf-sh:List owl:onProperty owl:subClassOf owl:allValuesFrom ∩ proc:ProcessComponentBag owl:subClassOf proc:Split-Join owl:subClassOf owl:allValuesFrom proc:Repeat-While owl:Restriction owl:domain owl:Restriction proc:whileProcess proc:whileCondition rdf-sh:rest owl:allValuesFrom owl:range proc:ProcessComponent proc:Condition rdf-sh:first

Il problema del binging In vari momenti è necessario identificare componenti IOPE tra i loro: Associare input e precondizioni ed output con gli effetti Associare i/o dei processi composti con quelli dei componenti Associare input ed output di sottoprocessi tra di loro Soluzione standard: uso le variabili (ovviamente) OWL non permette di usare in maniera “nativa” delle associazioni tra variabili rdfs:domain rdfs:range proc:ProcessComponent proc:sameValues rdf:List proc:atProcess proc:ValueOf proc:theParameter rdfs:domain rdfs:domain proc:Process proc:Parameter

Il Grounding Il Grounding associa al servizio il modo in cui può essere effettivamente utilizzato E’ possibile associare un grounding solo a servizi con processo atomico Tecniche particolari per il grounding comportano la derivazione di sottoclassi di “ServiceGrounding”, come ad esempio “WSDLGrounding” Ogni messaggio è da intendersi astratto, fino a quando non viene interessato da una risorsa di tipo “ServiceGrounding”

OWL-S e WSDL Il grounding WSDL fornisce una (complessa) ontologia per associare ogni “pezzo” di OWL-S ad un frammento WSDL Un processo atomico con in ed out corrisponde a una operazione request-response Un processo atomico con input ma senza output corrisponde ad una operazione one-way Processi con output ma senza input corrispondono alle operazioni di notifica Un processo composto con input ed putput, e con l’invio dell’output precedente alla ricezione dell’input è un’operazione solicit-response. OWL-S Process Model DL-Based Types Atomic Process Inputs / Outputs Operation Message Binding (SOAP) WSDL

Associazione con un WSDL – 1 Sono dati tre casi: In una parte della definizione del messaggio WSDL l’attributo owl-s-attribute indica l’URI della descrizione OWL dell’oggetto in input e/o output. In questo caso seguendo il ramo parameterType in OWL-S si ottiene la descrizione semantica Se una parte del messaggio usa un tipo OWL è possibile definire l’attributo encodingStyle=“http://www.w3.org/2002/07/owl” In tutti gli elementi operation in WSDL l’attributo owl-s-process può indicare il processo atomico in OWL-S WSDL rdfs:domain rdfs:range gro:WsdlGrounding gro:hasAtomicProcessGrounding gro:WsdlAtomicProcessGrounding gro:wsdlVersion gro:wsdlDocument gro:wsdlOperation gro:wsdlnputMessage gro:wsdOutputMessage gro:wsdlnputs gro:wsdOutputs OWL-S

Associazione con un WSDL – 2 Come traduco i messaggi da OWL-S a WSDL ? gro:wsdlnputs gro:WsdlAtomicProcessGrounding gro:WsdlinputMessageMap gro:wsdlMessagePart xsd:string gro:xsltTransformation gro:owlsParameter owl:Thing proc:Parameter Caso complesso Caso semplice

Risorse I servizi, in quanto processi, operano su risorse OWL-S fornisce una rudimentale ontologia delle risorse, che le distingue a seconda della loro natura Allocation Types ConsumableAllocation ReusableAllocation Capacity Types DiscreteCapacity ContinuousCapacity Resource Composition AtomicResource UnitCapacityResource BatchCapacityResource AggregateResource ConjunctiveAggregateResource DisjunctiveAggregateResource reusable(R) & use(A,R,T)  capacity(R, start(T)) = capacity(R, end(T)) consumable(R) & use(A,R,T)  capacity(R, start(T)) > capacity(R, end(T)) replenish(A,R,T)  capacity(R, start(T)) < capacity(R, end(T))