OWL-S //Restricted!Liberamente estratto e sintetizzato daOWL-S: Semantic Markup for Web Services (http://www.w3.org/Submission/OWL-S/)

La strutturazione dell'ontologia dei servizi è motivata dalla necessità di fornire tre tipi essenziali di conoscenza su un servizio:

– Che cosa fornisce il servizio ad un potenziale cliente ? La risposta a questa domanda è contenuta nel “profile”, che è usato per annunciare il servizio

– Come è usato il servizio ? La risposta a questa domanda è contenuta nel “process model” attraverso la classe ServiceModel. Ogni istanza della Classe Service usa la proprietà describedBy per riferirsi ad un ServiceModel.

– Come si interagisce con il Servizio ? La risposta a questa domanda è contenuta nel “grounding”. Un grounding fornisce i dettagli sui protocolli di trasporto usati. Ogni istanza della classe Service si riferisce ad una classe ServiceGrounding.

Ogni istanza della classe Service rappresenta un distinto servizio pubblicato. Ogni istanza di Service presenta (presents) una descrizione tramite ServiceProfile, è descritto da (describedBy) una descrizione ServiceModel e supporta (support) una descrizione ServiceGrounding.Il ServiceProfile fornisce le informazioni necessarie per trovare il servizio mentre ServiceModel e ServiceGrounding danno

informazioni su come usare il servizio, una volta trovato.Il profilo del servizio dice cosa fa il servizio in modo tale da essere comprensibile: contiene una descrizione del servizio, limitazione alla qualità del servizio e prerequisiti necessari per l'uso del servizio.Il modello del servizio dice al cliente come usare il servizio fornendo dettagli sul contenuto di una richiesta e su sotto quali condizioni si ottengano determinati risultati dopo la richiesta del servizio. Il modello viene anche usato da agenti per la composizione di servizi.Il grounding del servizio specifica nei dettagli come un agente può accedere ad un servizio descrivendo i protocolli di comunicazione,il formato dei messaggi oppure le porte su cui contattare il servizio. Inoltre il ServiceGrounding deve specificare per ogni tipo di input e output contenuto nel modello come scambiare i dati di quel tipo con il servizio (in altre parole indicare la tecnica di servializzazione da usare)L'uppur ontology dei servizi impone sono due vincoli alle cardinalità di queste proprietà: ogni servizio deve avere al massimo un ServiceModel e ogni ServiceGrounding deve essere associato ad un solo servizio (questo non impedisce di avere più ServiceGrounding distinti per un solo servizio). Non sono specificate cardinalità minime per le proprietà present e describedBy e inolte non sono specificate cardinalità massime per le proprietà present e support.

Service ProfileOWL-S fornisce una possibile rappresentazione del ServiceProfile tramite la classe Profile. Quest'ultima descrive il servizio come una combinazione di tre tipi di informazione:

• Le informazioni sul Provider sono le informazioni che si riferisco all'entità che fornisce il servizio

• La descrizione delle funzionalità del servizio è espressa in termini di trasformazioni attuate dal servizio. Essa specifica gli input necessari e gli output generati dal servizio, inoltre

fornisce dettagli sulle precondizioni per l'uso del servizio e sugli effetti previsti.• La descrizione di un'insieme di proprietà che descrivono alcune feature del servizio. Il primo

tipo di informazione, che potrebbe essere contenuta in questa descrizione, specifica la categoria del servizio. Il secondo tipo di informazione potrebbe essere una valutazione della qualità del servizio. L'ultimo tipo di informazione è una lista non limitata di parametri del servizio che possono contenere qualsiasi tipo di informazione( come il massimo tempo di risposta o la disponibilità geografica del servizio).

Il profilo fornisce una descrizione concisa del servizio ma una volta selezionato un servizio il cliente interagirà con il modello. Anche se il profilo ed il modello giocano ruoli differenti questi non sono altro che due rappresentazioni diverse dello stesso servizio quindi ci si aspetta che input, output, precondizione ed effetti (IOPE) del profilo siano uguali agli IOPE del modello. OWL-S tuttavia non impone nessun vincolo tra il profilo e il Process Model che possono quindi essere inconsistenti senza invalidare l'espressione.ServiceProfile ClassLa classe ServiceProfile fornisce una superclasse per ogni tipo di descrizione di alto livello del servizio. Vi è una relazione bidirezionale tra il servizio ed il profilo.presents: descrive la relazione tra un'istanza del servizio e una istanza del profilopresentedBy: è l'inverso di presents e indica che un dato profilo descrive un servizioNome del servizio, Contatti e DescrizioniAlcune proprietà del profilo forniscono alcune informazioni leggibili dagli umani ma difficilmente processabili da una macchina. serviceName: indica il nome del servizio offerto e può essere usato come identificatore.textDescription: fornisce una breve descrizione del servizio che riassume cosa offre il servizio, cosa richiede per funzionare e ogni ulteriore informazione che il compilatore del profilo ritiene utile.contactInformation: fornisce un meccanismo per riferirsi ai responsabili del servizioUn profilo può avere al massimo un nome e una descrizione ma può presentare tante informazioni di contatto quante il provider ne vuole offrire.Descrizione FunzionaleLa classe Profile di OWL-S rappresenta due aspetti della funzionalità del servizio: la trasformazione delle informazione (rappresentata da input e output) e le variazioni di stato prodotte dall'esecuzione del servizio(rappresentate da precondizioni ed effetti).hasParameter: ha come punto terminale un'istanza Parameter dell'ontologia del processo. Da notare il fatto che la classe Parameter modella la nostra idea che sia Input che Output (entrambi sottoclassi di Parameter) sono coinvolti nella trasformazione di informazione e sono differenti da Precondition e Effect. Non ci aspettiamo quindi che questa classe sia istanziata ma il suo ruolo è quella di rendere esplicita questa conoscenza all'ontologia.hasInput: ha come punto terminale un'istanza di Input come definito nell'ontologia di processo.hasOutput: ha come punto terminale un'istanza di Output come definito nell'ontologia di processo.hasPrecondition: specifica una delle precondizioni del servizio e ha come punto terminale un'istanza di Precondition come specificato nello schema dell'ontologia di processo.hasResult: specifica uno dei risultati del servizio, come definito dalla classe Result nell'ontologia di Processo. Il risultato specifica sotto quali condizioni vengono generati gli output e quali cambiamenti nel dominio sono stati prodotti durante l'esecuzione del servizio.Attributi di ProfileVi sono altri attributi per descrivere un servizio come le garanzie di qualità fornite dal servizio, una possibile classificazione del servizio o altri parametri addizionali.serviceParameter: è una lista estendibile di proprietà che può accompagnare la descrizione del profilo. Il valore di una proprietà è un'istanza della classe ServiceParameter (descritta in seguito).serviceCategory: si riferisce ad un elemento di una ontologia o tassonomia dei servizi. Il valore di tale proprietà è un'istanza della classe ServiceCategory (descritta in seguito).ServiceParamaterserviceParameterName: contiene il nome del parametro e può essere un litteral oppure l'URI di un

parametro del processo.sParameter: punta al valore del parametro all'interno di un'ontologia OWL.ServiceCategoryLa classe ServiceCategory descrive le categorie di servizi sulla base di una classificazione che può essere al di fuori OWL-S e possibilmente al di fuori OWL.categoryName: è il nome effettivo della categoria, che potrebbe essere un literal oppure l'URI del parametro del processotaxonomy: memorizza un riferimento alla schema della tassonomia. Può essere l'URI della tassonomia, o un URL in cui risiede la tassonomia, o il nome della tassonomia o qualsiasi altra cosa. value: punta al valore contenuto in una specifica tassonomia. Vi possono essere più valori per ogni tassonomia, quindi non viene aggiunta nessun'altra restrizione.code: per ogni tipo di servizio memorizza il codice associato ad una tassonomia.Specifica del tipo di servizio e del prodottoLe due proprietà, serviceClassification e serviceProduct, sono utilizzate per specificare il tipo di servizio e il tipo di prodotti che vengono gestiti dal servizio. I valori delle due proprietà sono istanze di classi specificate nelle ontologie OWL dei servizi e dei prodotti. Le proprietà serviceClassification e serviceProduct sono simili alla proprietà serviceCategory descritta in precedenza, ma differiscono perchè i valori delle proprietà sono istanze OWL invece che stringhe che si riferiscono a qualche tassonomia non descritta in OWL.serviceClassification: definisce una mappatura da un profilo ad un'ontologia OWL di servizi.serviceProduct: definisce una mappatura da un profilo a un ontologia OWL di prodotti.

Modellare Servizi come ProcessiPer avere una visione dettagliata su come interagire con un servizio, questo può essere visto come un processo. E' importante capire che un processo non è un programma da eseguire ma una descrizione dettagliata delle modalità con cui un cliente può interagire con il servizio. Un processo atomico è una descrizione di un servizio che si aspetta un messaggio (possibilmente complesso) in ingresso e ritorna in risposta un messaggio (possibilmente complesso). Un servizio composto è un servizio che mantiene uno stato.Un processo può avere due fini. In primo luogo, esso è in grado di generare e ritornare nuove informazioni a partire dalle informazioni fornite e dallo stato il mondo. La produzione di informazioni è descritta attraverso input e output del processo. In secondo luogo, un processo può produrre un cambiamento nello stato del mondo. Questo passaggio è descritto dalle precondizioni e dagli effetti del processo.Un processo può avere un qualsiasi numero, anche zero, di input, output, precondizioni ed effetti. Output ed effetti possono dipendere dalle condizioni che sono presenti nel mondo al momento dell'esecuzione del processo.Parametri ed espressioniIngressi e uscite sono sottoclassi di una classe generale denominata Parameter. E' conveniente identificare i parametri con ciò che in SWRL (il linguaggio per esprimere le regole di OWL) sono chiamate variabili.

<owl:Class rdf:about="#Parameter"> <rdfs:subClassOf rdf:resource="&swrl;#Variable"/></owl:Class>

Ogni parametro ha un tipo, specificato usando un URI.

<owl:DatatypeProperty rdf:ID="parameterType"> <rdfs:domain rdf:resource="#Parameter"/> <rdfs:range rdf:resource="&xsd;anyURI"/></owl:DatatypeProperty>

<owl:Class rdf:ID="Parameter"> <rdfs:subClassOf> <owl:Restriction>

<owl:onProperty rdf:resource="#parameterType" /> <owl:minCardinality rdf:datatype="&xsd;#nonNegativeInteger"> 1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>

Inputs e outputs sono sottoclassi di parameter :

<owl:Class rdf:ID="Input"> <rdfs:subClassOf rdf:resource="#Parameter"/></owl:Class>

<owl:Class rdf:ID="Output"> <rdfs:subClassOf rdf:resource="#Parameter"/></owl:Class>

Un processo non eseguirà senza che le sue precondizioni siano soddisfatte. Se e quando un processo verrà eseguito, questo avrà vari effetti. Precondizione ed effetti sono rappresentati come formule logiche espresse in uno dei vari linguaggi logici.

owl:Class rdf:ID="Expression"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#expressionLanguage"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger"> 1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#expressionBody"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger"> 1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>

<owl:ObjectProperty rdf:ID="&expr;#expressionLanguage"> <rdfs:domain rdf:resource="&expr;#Expression"/> <rdfs:range rdf:resource="&expr;#LogicLanguage"/> </owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="expressionBody"> <rdfs:domain rdf:resource="#Expression"/></owl:DatatypeProperty>

In seguito mostriamo un esempio di una precondizione espressa usando il linguaggio logico KIF.

<Description rdf:about="#process2"> <hasPrecondition> <expr:KIF-Expression> <expr:expressionBody> (!agnt:know_val_is (!ecom:credit_card_num ?cc) ?num) </expr:expressionBody> </expr:KIF-Expression> </hasPrecondition> </Description>

Parametri dei Processi e Risultati

I processi vengono connessi ai loro IOPE usando le proprietà visualizzate nella seguente tabella:

Proprietà Range Kind

hasParticipant Participant Thing

hasInput Input Parameter

hasOutput Output Parameter

hasLocal Local Parameter

hasPrecondition Condition Expression

hasResult Result Speciale...

• Partecipant

Un processo coinvolge due o più agenti. Il primo è il cliente, TheClient, dal cui punto di vista il processo è descritto. L'altro è il server, TheServer, che è l'elemento principale del servizio con cui il cliente dialoga. Se ci fossero altri agenti possono essere elencati usando la proprietà hasPartecipant.

<owl:ObjectProperty rdf:ID="hasParticipant"> <rdfs:domain rdf:resource="#Process"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasClient"> <rdfs:subPropertyOf rdf:resource="#hasParticipant"/></owl:ObjectProperty>

<process:Parameter rdf:ID="TheClient"><process:Parameter rdf:ID="TheServer">

• Input e Output

Un processo atomico riceve un solo messaggio in ingresso ma può avere più input. Questo perché un messaggio può portare informazioni su tanti dati di input: il modo con cui questo messaggio trasmetterà i dati deve essere specificato nel grounding. Lo stesso discorso vale per gli output.

<owl:ObjectProperty rdf:ID="hasParameter"> <rdfs:domain rdf:resource="#Process"/> <rdfs:range rdf:resource="#Parameter"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasInput"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Input"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasOutput"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Output"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasLocal"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Local"/></owl:ObjectProperty>

• Precondizioni e Risultati

Se un processo ha delle precondizioni allora questo non può essere eseguito con successo se le

condizioni non sono soddisfatte. In OWL-S, se una precondizione è falsa, le conseguenze dell'esecuzione del processo sono indefinite.

L'esecuzione di un processo può comportare cambiamenti nello stato del mondo (effetti) e nell'acquisizione di nuove informazioni da parte del richiedente (output). Generalmente non si collegano direttamente i processi agli effetti e agli output in quanto questi possono cambiare al variare del contesto. Usiamo il termine result (risultato) per riferirci ad un insieme di effetti e output.

<owl:Class rdf:ID="Result"> <rdfs:label>Result</rdfs:label></owl:Class>

<owl:ObjectProperty rdf:ID="hasResult"> <rdfs:label>hasResult</rdfs:label> <rdfs:domain rdf:resource="#Process"/> <rdfs:range rdf:resource="#Result"/></owl:ObjectProperty>

• Condizionare gli Output e gli Effetti

Dichiarato un result, un process model può descriverlo attraverso quattro proprietà.

<owl:ObjectProperty rdf:ID="inCondition"> <rdfs:label>inCondition</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Condition"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasResultVar"> <rdfs:label>hasResultVar</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="#ResultVar"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="withOutput"> <rdfs:label>withOutput</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="#OutputBinding"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasEffect"> <rdfs:label>hasEffect</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Expression"/> </owl:ObjectProperty>

La proprietà inCondition specifica le condizioni sotto le quali si ottiene questo risultato e non un altro. Le proprietà withOutput e hasEffect specificano cosa accade quando la condizione è vera. La proprietà hasResultVar dichiara le variabili che sono contenute nella inCondition. Queste variabili dette ResultVar sono simili alle Local: le Local sono contenute nelle precondizioni e servono per specificare le condizioni nei risultati, gli output e gli effetti mentre le ResultVar sono contenute nelle condizioni dei result e servono a descrivere gli output e gli effetti associati a tale condizione.

Infine vi è un altro descrittore di output chiamato resultForm. Quest'ultimo non è attaccato ad un variabile ma ad un risultato:

<owl:DatatypeProperty rdf:ID="resultForm"> <rdfs:label>resultForm</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&rdf;#XMLLiteral"/>

</owl:DatatypeProperty>

Lo scopo di resultForm è quello di fornire un modello astratto di output XML inviato al cliente. Nel caso di processi con molti Result, può essere estremamente utile specificare altre caratteristiche (oltre a quelle contenute nel grounding) di un messaggio di output che indichino quale risultato si è verificato, risparmiandoci l'onere di introdurre dei campi in output che codifichino tale informazione oppure di lasciare al cliente la possibilità di inferire tali dati dagli altri cambi. Per queste situazioni esiste resultForm.

Processi Atomici e Semplici

<owl:Class rdf:ID="Process"> <rdfs:comment> The most general class of processes </rdfs:comment> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#AtomicProcess"/> <owl:Class rdf:about="#SimpleProcess"/> <owl:Class rdf:about="#CompositeProcess"/> </owl:unionOf></owl:Class>

I processi atomici corrispondono alle azioni che un servizio può eseguire se impegnato in una singola interazione; i processi compositi corrispondono ad azioni che necessitano di protocolli multi-step e/o azioni su diversi server; i processi semplici forniscono un meccanismo di astrazione per rappresentare lo stesso processo da più punti di vista.I processi atomici sono direttamente invocabili tramite un messaggio appropriato e non hanno sotto-processi: non fanno altro che prendere un input, fare qualcosa e restituire un output. Inoltre ogni processo atomico deve fornire un grounding che permetta la costruzione dei messaggi.

<owl:Class rdf:ID="AtomicProcess"> <owl:subClassOf rdf:resource="#Process"/></owl:Class>

Un processo semplice non è invocabile e non è associato ad un grounding, ma come i processi atomici è ideato per avere un esecuzione in un solo passo (single-step). Un processo semplice è usato come mezzo di astrazione e può servire o a fornire un modo specializzato di usare dei processi atomici oppure una rappresentazione semplificata di un processo composito. Nel primo caso il SimpleProcess è realizzato dal processo atomico (realizedBy) mentre nel secondo caso il SimpleProcess si espande nel processo composito(expandsTo).

<owl:Class rdf:ID="SimpleProcess">

<rdfs:subClassOf rdf:resource="#Process"/> <owl:disjointWith rdf:resource="#AtomicProcess"/></owl:Class>

<owl:ObjectProperty rdf:ID="realizedBy"> <rdfs:domain rdf:resource="#SimpleProcess"/> <rdfs:range rdf:resource="#AtomicProcess"/> <owl:inverseOf rdf:resource="#realizes"/></owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="realizes"> <rdfs:domain rdf:resource="#AtomicProcess"/> <rdfs:range rdf:resource="#SimpleProcess"/> <owl:inverseOf rdf:resource="#realizedBy"/></owl:ObjectProperty>

Inoltre per ogni processo atomico ci sono sempre due partecipanti il client ed il server:

<owl:Class rdf:about="#AtomicProcess">

<rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasClient"/> <owl:hasValue rdf:resource="#TheClient"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#performedBy"/> <owl:hasValue rdf:resource="#TheServer"/> </owl:Restriction> </rdfs:subClassOf>

</owl:Class>

Processi CompositiUn processo composito può essere decomposto in altri processi (compositi o no) e la sua decomposizione può essere specificate dei costrutti di controllo come Sequence. Un processo composito non è un comportamento che il servizio avrà ma un comportamento che il client potrà mantenere nel mandare e ricevere una serie di messaggi. Se un processo composito ha un effetto di insieme un client deve eseguire l'intero processo per ottenere l'effetto.Un aspetto importante di un processo composito è la descrizione di come si organizzano gli input e gli output dei vari sotto-processi.

<owl:Class rdf:ID="CompositeProcess"> <rdfs:subClassOf rdf:resource="#Process"/> <owl:disjointWith rdf:resource="#AtomicProcess"/> <owl:disjointWith rdf:resource="#SimpleProcess"/> <rdfs:comment> A CompositeProcess must have exactly 1 composedOf property. </rdfs:comment> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Process"/> <owl:Restriction> <owl:onProperty rdf:resource="#composedOf"/> <owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger"> 1</owl:cardinality> </owl:Restriction> </owl:intersectionOf></owl:Class>

Un processo composto deve avere una proprietà composedOf che indichi la struttura di controllo usando un ControllConstruct. Ogni costrutto di controllo è associato con una proprietà addizionale chiamata components che indica il costrutto di controllo innestato di cui è composto. Ad esempio un istanza del costrutto di controllo Sequence ha una proprietà components che punta ad una lista di costrutti di controllo(ControlConstructList).Qualsiasi processo composito può essere considerato un albero i cui nodi non terminali sono etichettati con i costrutti di controllo, ognuno dei quali è specificato utilizzando components. Le foglie dell'albero sono invocazioni di altri processi, indicate come istanze della classe Perform.<owl:Class rdf:ID="Perform"> <rdfs:subClassOf rdf:resource="#ControlConstruct"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#process"/>

<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger"> 1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>

La proprità process di una classe Perform indica il processo che deve essere eseguito. Quando un processo viene eseguito come un passo in un processo più vasto, vi deve essere indicato da dove vengono gli input del processo eseguito e dove vanno a finire gli output.

– Sequence: una lista di costrutti di controllo da fare in ordine.– Split: i componenti di un processo Split sono un insieme di componenti(processi) che vanno

eseguiti concorrentemente. Lo Split si completa quando ogni suo componente è stato schedulato per l'esecuzione

– Split+Join: il processo consiste di un'esecuzione concorrente di una serie di processi componente con una Barrier Synchronization. Un processo Split+Join finisce quando ogni processo componente termina. Quindi con Split e Split+Join, possimo definire processi che hanno una sincronizzazione parziale.

– Any-Order: permette ai processi componenti di essere eseguiti in qualsiasi ordine ma non concorrentemente. Le esecuzioni di processi in un costrutto Any-Order non si possono sovrapporre.

– Choice: chiama per l'esecuzione un singolo costrutto di controllo da un determinato insieme di costrutti: uno qualunque dei costrutti di controllo dati può essere scelto per essere esguito.

– If-Then-Else: la classe If-Then-Else è un costrutto di controllo che ha le proprietà ifCondition, then e else che contengono aspetti diversi del costrutto. La semantica di questo costrutto è la seguente: “Controlla la condizione ifCondition; se è Vera fai then, se Falsa fai else”.

– Iterate: il costrutto Iterate non fa nessuna assunzione sul numero di iterazioni da fare o quando iniziarle, terminarle o riprenderle: l'avvio, la terminazione e le condizioni di mantenimento dell'iterazione dovrebbero essere specificate attraverso una whileCondition o una untilCondition. Iterate è una classe “astratta”, nel senso che non è abbastanza dettagliata per essere istanziata in un modello. E' definita per servire come superclasse comune di Repeat-Until, Repeat-While e altri costrutti di iterazione che potrebbero essere necessari in futuro.

– Repeat-While e Repeat-Until: Entrambi iterano fino a quando una condizione diventa falsa o vera, in base alle convenzioni dei linguaggi di programmazione. Repeat-While controlla la condizione, esce se è falsa oppure esegue l'operazione se è vera e quindi itera. Repeat-Until esegue l'operazione, controlla la condizione e se è vera esce altrimenti itera. Quindi Repeat-While può anche non eseguire mai mentre Repat-Until esegue almeno una volta.

Specificare il flusso dei dati e binding dei parametriPer collegare gli output di un processo con l'input del successivo possiamo utilizzare un corto circuito che porti gli output così come sono agli input. In certe situazioni è però necessario manipolare gli output e derivarne degli input. In OWL-S queste relazioni vanno specificate attraverso i Binding, un oggetto astratto con due proprietà: toParam, che contiene il nome del parametro, e valueSpecifier, che contiene una descrizione del valore. Per consentire la specificazione dei valori nel miglior modo possibile nel maggior numero di situazioni, sono stati resi disponibili quattro tipi:valueSource, valueType, valueData, e valueFunction. I binding vengono dichiarati dove vengono utilizzati quindi se un processo A usa gli output di un processo B, il binding verrà dichiarato nel processo B.Il range di valueSource è un semplice oggetto della classe ValueOf, specificato completamente dalla sua proprietà theVar e fromProcess. Se un binding con toParam = p ha valueSource = s con la proprietà theVar= v e fromProcess = R, significa che il parametro p di questo processo v parametro di R.<owl:Class rdf:ID="ValueOf">

<rdfs:label>ValueOf</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#theVar"/> <owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger"> 1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#fromProcess"/> <owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger"> 1</owl:maxCardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>

<owl:ObjectProperty rdf:ID="theVar"> <rdfs:domain rdf:resource="#ValueOf"/> <rdfs:range rdf:resource="#Parameter"/> </owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="fromProcess"> <rdfs:domain rdf:resource="#ValueOf"/> <rdfs:range rdf:resource="#Perform"/></owl:ObjectProperty>

Sia valueFunction che valueData usano gli XML literal per codificare espressioni arbitrarie.Produce una nuova classe usata per catturare i dataflows in output dal ParentPerform(ossia il perform del passo precedente). L'output non può essere dichiarato una volta per tutte, perché in presenza di costrutti come IfThenElses questo dipenderà da quale ramo della condizione verrà scelto dall'agente. Quindi, al punto in cui i dati necessari per calcolare l'output sono conosciuti, si inserisce uno pseudo-passo Produce per dire quale sarà l'output.

Fissare un servizio ad una realizzazione concreta attraverso il GroundingIl grounding di un servizio specifica i dettagli sulle modalità di accesso al servizio - dettagli che hanno a che fare principalmente con il protocollo e formati dei messaggi, la serializzazione, il trasporto, e l'indirzzamento. Un grounding, può essere pensato come una mappatura da una descrizione astratta ad una concreta specifica di quelle descrizioni del servizio necessarie al fine di interagire con il servizio - in particolare, per i nostri scopi, gli ingressi e le uscite dei processi atomici. Si noti che in OWL-S, sia il ServiceProfile che il ServiceModel sono pensati come rappresentazioni astratte; solo il ServiceGrounding ha a che fare con livello concreto di specifica.La funzione di un OWL-S grounding è di mostrare come gli input e output (astratti) di un processo atomico devono essere realizzati concretamente come i messaggi, che trasportino gli ingressi e le uscite in qualche formato specifico di trasmissione.Relazioni tra OWL-S e WSDLL'uso di WSDL per il grounding permette allo sviluppatore di servizi di avvalersi del meccanismo di astrazione ed espressione dell'OWL-S e basarsi sul lavoro già sv.olto attraverso WSDL ( come protocolli e meccanismi di trasmissione). WSDL / XSD non è in grado di esprimere la semantica di una classe OWL. Allo stesso modo, OWL-S, così com'è attualmente definito, non ha i mezzi per esprimere le informazioni di binding che WSDL riesce catturare.Un grounding OWL-S/WSDL è basato sulle seguenti tre corrispondenze tra OWL-S e WSDL.

1. Un processo atomico in OWL-S corrisponde ad una operazione WSDL. Un processo atomico con sia input che output corrisponde con una operazione WSDL request-response. Un processo atomico con solo ingressi con una operazione WSDL one-way, mentre uno con solo output corrisponde con una operazione WSDL notification. Un processo composto con

input e output e con l'invio di output ad un altro processo corrisponde una operazione WSDL solicit-response.

2. Gli input di un processo atomico in OWL-S corrispondono alle parti di un messaggio di input WSDL; similmente gli output di un processo atomico in OWL-S corrispondono alle parti di un messaggio di output WSDL.

3. I tipi (descritti tramite classi OWL) degli input e output di un processo atomico OWL-S corrispondono con la notazione estensibile di abstract type in WSDL.

Per costruire un grounding OWL-S/WSDL si deve prima individuare, in WSDL, i messaggi e le operazioni con le quali si può avere accesso ad un processo atomico, e quindi specificare corrispondenze (1) – (3).Grounding OWL-S di un servizio tramite WSDL e SOAPPer il grounding OWL-S permette l'uso di binding WSDL come SOAP. Fare il grounding con WSDL e SOAP implica la costruzione di una descrizione del servizio in WSDL con tutte le sue parti: (types, message, operation, port type, binding, e costrutti service ). Nel caso in cui il tipo di una parte del messaggio WSDL un tipo OWL questo può essere definito o nella sezione types di WSDL oppure in un documento a parte e riferito usando owl-s-parameter.Le estensioni OWL-S sono introdotto come segue:

1. In una parte(part) della definizione del messaggio(message) WSDL l'attributo owl-s-parameter può essere usato per specificare il nome completamente qualificato di un oggetto input o output OWL-S (istanze della classe Parameter) che corrisponde a quella determinata parte del messaggio.

2. Nel caso in cui una parte del messaggio usi un tipo OWL, l'attributo encodingStyel dell'elemento WSDL binding deve contenere un valore del tipo “http://www.w3.org/2002/07/owl'' (oppure relativo a versioni successive) per indicare che questa parte del messaggio deve essere serializzata come una classe istanza di un dato tipo (così come descritto nella versione di OWL indicata)

3. In ogni elemento WSDL operation, l'attributo owl-s-process può essere usato per usato per indicare il nome del processo atomico OWL-S a cui corrisponde tale operazione.

La classe OWL WsdlGrounding, sottoclasse di Grounding, stabilisce il meccanismo tramite cui possiamo riferire i costrutti WSDL in OWL-S. Ogni istanza di WsdlGrounding contiene una lista di istanze WsdlAtomicProcessGrounding.Ogni istanza WsdlAtomicProcessGrounding per riferirsi ad uno specifico elemento WSDL usa le seguenti proprietà:

• wsdlVersion: l'URI che indica la versione di WSDL in uso.• wsdlDocument: l'URI del documento WSDL a cui si riferisce questo grounding.• wsdlOperation: L'URI del operazione WSDL corrispondente a questo determinato processo

atomico.• wsdlService, wsdlPort (opzionale): L'URI di un servizio WSDL (o una porta) che fornisce

l'operazione descritta.• wsdlInputMessage: Un oggetto che contiene gli indirizzi in notazione URI della definizione

WSDL messaggio che trasporta l'input di un dato processo atomico.• wsdlInput: Un oggetto che contiene una coppia di mappatura, per una parte del messaggio

WSDL di input. Ciascuna di queste coppie è rappresentata tramite un'istanza di WsdlInputMessageMap. Un elemento della coppia (espresso con la proprietà wsdlMessagePart), individua la parte del messaggio utilizzando un URI. L'altra parte dice come derivare questa parte del messaggio dagli input del processo atomico OWL-S. Nel caso più semplice basta indicare l'URI di un oggetto input (usando la proprietà owlsParameter) mentre in casi più complessi si usa la proprietà xlstTrasformation per definire uno script XLST che genererà la parte del messaggio a partire da un'istanza del processo atomico.

• wsdlOutputMessage: simile a wsdlInputMessage ma per gli output• wsdlOutput: simile a wsdlOutput ma per gli output