Owl S Restricted

OWL-S //Restricted!
Liberamente estratto e sintetizzato da
OWL-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 Profile
OWL-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 Class
La 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 profilo
presentedBy: è l'inverso di presents e indica che un dato profilo descrive un servizio
Nome del servizio, Contatti e Descrizioni
Alcune 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 servizio
Un profilo può avere al massimo un nome e una descrizione ma può presentare tante informazioni
di contatto quante il provider ne vuole offrire.
Descrizione Funzionale
La 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 Profile
Vi 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).
ServiceParamater
serviceParameterName: 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.
ServiceCategory
La 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 processo
taxonomy: 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 prodotto
Le 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 Processi
Per 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 espressioni
Ingressi 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"/>

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 rdf:ID="hasClient">
<rdfs:subPropertyOf rdf:resource="#hasParticipant"/>

<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:range rdf:resource="#Parameter"/>

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

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

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

• 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:range rdf:resource="#Result"/>

• 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 rdf:ID="hasResultVar">
<rdfs:label>hasResultVar</rdfs:label>
<rdfs:range rdf:resource="#ResultVar"/>

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

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

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:range rdf:resource="&rdf;#XMLLiteral"/>


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 rdf:ID="realizes">
<rdfs:domain rdf:resource="#AtomicProcess"/>
<rdfs:range rdf:resource="#SimpleProcess"/>
<owl:inverseOf rdf:resource="#realizedBy"/>

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 Compositi
Un 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"/>

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 parametri
Per 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"/>
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 rdf:ID="fromProcess">
<rdfs:domain rdf:resource="#ValueOf"/>
<rdfs:range rdf:resource="#Perform"/>

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
Grounding
Il 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 WSDL
L'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 SOAP
Per 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

Owl S Restricted

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Owl S Restricted

Similar to Owl S Restricted (20)

More from Sebastiano Merlino (eTr)

More from Sebastiano Merlino (eTr) (20)

Owl S Restricted