Web Ontology Language for Web Services
# Web Ontology Language for Web Services

Die Web Ontology Language for Web Services (kurz OWL-S), vormals DAML-S, ist eine Spezifikation zur semantischen Auszeichnung von Webservices. OWL-S setzt dabei stark auf Erweiterungen: OWL-S spezifiziert Ontologien, um einen Service auf technischer Ebene semantisch zu beschreiben – um die fachspezifische Funktionalität eines Services semantisch zu verdeutlichen ist jedoch immer eine zusätzliche Ontologie notwendig, die die entsprechende Fachdomäne abdeckt.

Zum Beispiel sind zur Beschreibung eines Services für den Verkauf von Büchern über OWL-S hinausgehende Ontologien zur Beschreibung von Transaktionen zum Verkauf und zur Beschreibung von Büchern notwendig. OWL-S selbst bietet nur die Ontologien zur Beschreibung der für jedweden Service notwendigen Beschreibung von Vorbedingungen zur Service-Ausführung, der Eingabe- und Ausgabedaten und der Nebeneffekte des Services.

Anders als der Name vermuten lässt, handelt es sich bei OWL-S also nicht um eine Erweiterung von OWL, d. h., es werden keine neuen Sprachelemente definiert. OWL-S ist eine mittels OWL spezifizierte domänenspezifische Sprache für die Beschreibung von Web Services.

## Ziele von OWL-S

OWL-S soll

* automatisches Web Service Discovery (Auffinden),
* automatisches Web Service Invocation (Ausführen),
* automatisches Web Service Composition and Interoperation (Zusammensetzen und Verbindung) und
* automatisches Web Service Monitoring (Überwachen)

ermöglichen.

## Aufbau von OWL-S

OWL-S ist auf Basis der folgenden drei Fragen aufgebaut:

* Was macht der Service? (Service Profile)
* Wie wird dies gemacht? (Service Model)
* Wie wird der Service angewendet? (Service Grounding)

### Service Profile

Das Service Profile dient in erster Linie dem Service Discovery und enthält Informationen über die Organisation, die der Service anbietet, die Vorbedingungen, Ein- und Ausgabewerte, sowie Eigenschaften und Nutzen des Services (engl. IOPEs – Inputs, Outputs, Preconditions und Effects). Salopp ausgedrückt handelt es sich beim Service Profile um Werbung für den Service. Sobald der Service zur Benutzung ausgewählt wurde (d. h. nach der Service Discovery) wird das Service Profile nicht mehr gebraucht. Zur Nutzung des Services kommt dann vielmehr die Service-Beschreibung zum Einsatz, die im Service Model enthalten ist.

### Service Model

Das Service Model dient der tatsächlichen Ausführung des Services und beschreibt es als Prozess. Hierbei wird zwischen atomaren und zusammengesetzten Prozessen, sowie einfachen (abstrakten und nicht ausführbaren) Prozessen unterschieden. Das Service Model (auch Process Model genannt) beschreibt, wie ein Client den Service nutzen kann. Es beschreibt die Eingabe- und Ausgabedaten, Vorbedingungen und Auswirkungen (IOPEs) einzelner Services. Diese können sich von denjenigen IOPEs, die im Service Profile beschrieben sind stark unterscheiden. Sie können theoretisch sogar einen vollständig anderen Service beschreiben. Dies wäre jedoch weder für den Service-Anbieter noch für den Nutzer zielführend.

### Service Grounding

Das Service Grounding beinhaltet Protokoll-, Format- und Adressierungsdetails und stellt daher Informationen zur Realisierung der eher abstrakten Information der anderen Ebenen zur Verfügung. Hierbei wird WSDL verwendet. Das Grounding stellt eine Art Mapping zwischen dem Service Model und technischer Ausführungsebene dar, d. h., es werden z. B. Eingabe- und Ausgabenachrichten vom Service Model in entsprechende WSDL-Elemente übersetzt. Prinzipiell sind auch weitere Groundings denkbar, die sich nicht auf WSDL stützen. Aufgrund der großen Verbreitung und Akzeptanz von WSDL ist das WSDL-Grounding jedoch das einzige, das in der W3C-Submission konkret beschrieben wird.

