Verwaltung der Ontologie

Mote 1 Sensor A

Gateway

Proxy Sensor A Mote 3

Mote 2 Sensor B

Sensor B

Diensteverzeichnis Registry Sensor A Sensor B

... ...

Abbildung 6.8:Anwendungsbeispiel: Nutzung des Gateways

Beschreibung von drahtlosen Sensoren

Eine vollständige Beschreibung eines Sensors auf der Basis des herangezogenen OWL-S Standards erfordert eine relativ große Menge an Speicher und Transfervolumen. Der Einsatz eines solchen Standards auf Systemen wie beispielsweise den TMotes ist nicht sinnvoll. Möglichkeiten diesem zu begegnen bestehen meist in Ansätzen wie:

• Kompression der Beschreibung [RHS09].

• Reduzierung auf wesentliche Aussagen.

• Nutzung geeigneter, ressourcensparender Formate und Auszeichnungssprachen.

• Verweis auf externe, öffentlich zugängliche Speicherorte mit der vollständigen Beschreibung des Sensortyps.

Aktuell wird die zweite Variante angewandt. In weiteren, aktuell durchgeführten Arbeiten am Rahmenwerk werden auch die anderen Ansätze weiter verfolgt.

Erfüllung von QoS Anforderungen

Aktuell werden Anfragen direkt an den jeweiligen drahtlosen Sensor weitergeleitet. Die direkte Anfrage eines Sensors erfordert eine Reihe von Aufrufen, welche dazu möglicherweise über mehrere drahtlose Sensoren weiterge-leitet werden müssen. Eine solche Anfrage würde einen erhöhten Zeitaufwand mit sich führen, wodurch mögliche QoS Anforderungen verletzt werden könnten. Zum einen wird diese Herausforderung durch den Mechanismus zur Vorhaltung von Sensorinformationen (engl.Prefetching) adressiert. Zum anderen behandeln aktuelle Arbeiten am Rahmenwerk mögliche Ansätze zur aktiven Weitergabe von Sensordaten eines drahtlosen Sensors in Richtung des Gateways.

Web Ontology Language (OWL)

Die Web Ontology Language wird in vielen Arbeiten zur Beschreibung von Ontologien genutzt [Lac05] und bietet sehr umfangreiche Funktionalitäten.

"The OWL Web Ontology Language is designed for use by applications that need to process the content of information instead of just presenting information to humans. OWL facilitates greater ma-chine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics."¹¹

Zudem existiert eine Reihe von Werkzeugen, welche sich mit OWL einsetzen lassen (siehe Abschnitt 6.2.2). Für die Integration der Ontologie in das Rahmenwerk wurde in dieser Arbeit ebenfalls OWL genutzt.

OWL nutzt zwei grundlegende Elemente zur Beschreibung einer Ontologie: DieKlassenundEigenschaften. Die Eigenschaften lassen sich wiederum aufteilen in:

• ObjectProperty:Beziehungen zwischen Objekten.

• DatatypeProperty:Beziehungen von Objekten zu Datentypen.

• AnnotationProperty:Beschreibung von Objekten.

• OntologyProperty:Beziehungen zu anderen Ontologien.

Das folgende Beispiel zeigt die Anwendung der verschiedenen Eigenschaften:

<!-- Definition of new ObjectProperty -->

<owl:ObjectProperty rdf:ID="daughterOf"/>

<!-- Definition of new DatatypeProperty -->

<owl:DatatypeProperty rdf:ID="wasBorn">

<rdfs:domain rdf:resource="#Person"/>

<rdfs:range rdfs:resource="&xsd;date">

</owl:DatatypeProperty>

<Person rdf:ID="Person1">

<!-- Usage of predefined Annotation Property -->

<rdfs:comment>the object representing a parent</rdfs:comment>

</Person>

<Person rdf:ID="Person2">

<daughterOf rdf:resource="#Person1"/> <!-- ObjectProperty -->

<wasBorn>2001</wasBorn> <!-- DatatypeProperty -->

</Person>

Als Eigenschaften können sowohl vordefinierte Elemente von OWL und RDF(S) genutzt werden, als auch eigene definiert werden. Eine vordefinierte Eigenschaft ist die subClassOf. Sie wird genutzt, um Hierarchien zwischen Klassen aufzubauen. In dem folgenden Beispiel wird einem Mobiltelefon die Oberklasse Telefon zugewiesen:

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

<rdfs:subClassOf>

<owl:Class rdf:ID="Phone"/>

</rdfs:subClassOf>

</owl:Class>

Dies bedeutet, dass einMobiltelefonauch zu der Klasse derTelefonegehört und daher alle Eigenschaften von der KlasseTelefonerbt und diese gegebenenfalls erweitert.

Editoren wie Protégé unterstützen unter anderem die Nutzung und Darstellung der Klassen anhand dieser Ei-genschaft. Über eine Hierarchie lässt sich gut eineTaxonomieaufbauen. Diese spezielle Form einer Ontologie lässt zwar keine Quer-Beziehung zwischen Klassen zu, ist aber für viele Anwendungsfälle ausreichend. Für den grund-legenden Ansatz der ontologiebasierten Suche dieser Arbeit ist eine solche Taxonomie ebenfalls ausreichend. Für weiterführende Arbeiten kann dieser Ansatz jedoch bei Bedarf erweitert werden.

11http://www.w3.org/2004/OWL/

6 Realisierung 151

Grundstruktur der verwendeten Ontologie

Die Grundstruktur der verwendeten Ontologie ist in Abbildung 6.9 dargestellt. In dem Rahmenwerk wird die semantische Beschreibung der Daten benötigt. Daher ist der Ursprungsknoten für alle DatentypenData. Darunter gliedern sich die Beschreibung inSubjekte,EigenschaftenundBeziehungenauf. DieSubjektebeschreiben die Objekte auf die sich eine Information bezieht, die Eigenschaftumfasst die Zustände oder Informationen des Sensors und mittelsBeziehungenlassen sich Relationen zwischen Objekten ableiten.

Abbildung 6.9:Grundstruktur der Ontologie

Die Abbildung 6.10 zeigt den Ausschnitt derSubjekteim Detail dargestellt. Hierbei lässt sich erkennen, dass in den Anwendungsszenarien bisher Benutzer, Orte und Endgeräte im Vordergrund standen. Diese Subjekte lassen sich jeweils weiter untergliedern. Wie bereits in Abschnitt 6.3.1 erläutert, handelt es sich bei dieser Ontologie nur um eine Grundstruktur, welche jederzeit um weitere Elemente ergänzt werden kann.

Abbildung 6.10:Ausschnitt aus der Ontologie

Erweiterung der Ontologie

Wie in Abschnitt 4.5.4 erläutert ist es notwendig, die Ontologie zu erweitern, falls neue unbekannte Sensortypen an das System angebunden werden sollen. Hierzu wurde der Ansatz des Ankersentwickelt und umgesetzt. Der Entwickler eines Sensors kann einen neuen Sensor in das System integrieren, ohne selbst die Ontologie bearbeiten zu müssen. Er hat die Möglichkeit einen neuen Sensortyp in die Ontologie einzuhängen, indem er eine Reihe von möglichen Anknüpfungspunkten (die Anker) vorgibt. Die Anker können direkt in der semantischen Annotation der Schnittstelle benannt werden:

152 6.3 Sensorverzeichnis

/**

* @return Property@DeviceData@Activity@PhoneActivity@SkypeActivity

* @expirationTime 10000

*/

public String getSkypeStatus();

In dem dargestellten Beispiel wird ein zum Startzeitpunkt des Rahmenwerkes unbekannter Skype-Sensor ange-bunden. Hierbei wird der Anker vor den eigentlichen Sensortyp gestellt (es können mehrere Anknüpfungspunkte mit „@” angegeben werden). Ist der Skype-Sensor dem System noch nicht bekannt, so wird dieser an den Sensortyp PhoneActivityangehängt, indem eine Beziehung über die EigenschaftsubClassOf(siehe Abschnitt 6.3.1) hergestellt wird.