GloServ: Global Service Discovery Architecture

1. GloServ: Global Service Discovery Architecture Knarig Arabshian and Henning Schulzrinne IRT internal talk April 26, 2005

2. Overview • Motivation • Overview of OWL • Architecture • Registration • Querying • Future Work

3. Motivation • Why Global Services • Ubiquitous computing is becoming prevalent in today’s society • Traveler visiting a new city wants to know all classical music events. • Doctor visiting a hospital wants to know medical services in this hospital. • Visitor in starbucks wants to know if it offers local internet TV. • What are the Challenges? • Service description and querying • Server bootstrapping on global scale Service discovery should be global

4. OWL Overview • OWL: Web Ontology Language • Developed by World Wide Web Consortium (W3C) • Approved as a standard for the Semantic Web • Why OWL? • Service description: creating a service classification ontology • Server bootstrapping: using service classification to map services to servers • Three sublanguages of OWL • OWL Lite • OWL DL • OWL Full

5. OWL Sublanguages Choose OWL DL for GloServ: • A service class represents a collection of individuals • Use OWL DL reasoners such as Racer to check for the soundness of OWL documents • OWL Lite • Least expressive of the three sublanguages • Supports a classification hierarchy (like RDFS) • Supports core constraints of classes and properties. • OWL DL • Extends OWL Lite to include description logics (disjointness, union, intersection, etc.) • Supports maximum expressiveness • All conclusions are guaranteed to be computable and decideable (finishing in finite time) • Includes all OWL language constructs • OWL Full • Similar to OWL DL • Main difference: a class can be treated simultaneously as a collection of individuals and as an individual in its own right

6. Characteristics of OWL • Classes • Contain individuals, which are instances of the class and other subclasses • Set operators on classes • Union, intersection and complement • Equivalence, disjointness, enumeration • Property • Binary relation that specifies class characteristics • Two types of properties: datatype and object properties • Datatype properties: • Relations between instances of classes and RDF literals or XML schema datatypes (string, integer, etc.) • Object properties: • Relations between instances of two classes • Logical capabilities of properties: transitive, symmetric, inverse and functional.

7. OWL Examples Ontology Mapping <owl:ObjectProperty rdf:ID="locatedIn"> <rdf:type rdf:resource="&owl;TransitiveProperty" /> <rdfs:domain rdf:resource="&owl;Thing" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> <Region rdf:ID="SantaCruzMountainsRegion"> <locatedIn rdf:resource="#CaliforniaRegion" /> </Region> Object Property <owl:Class rdf:ID="TexasThings"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn" /> <owl:allValuesFrom rdf:resource="#TexasRegion" /> </owl:Restriction> </owl:equivalentClass> </owl:Class> Intersection Disjointness <owl:Class rdf:ID="WhiteWine"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Wine" /> <owl:Restriction> <owl:onProperty rdf:resource="#hasColor" /> <owl:hasValue rdf:resource="#White" /> </owl:Restriction> </owl:intersectionOf> </owl:Class> <owl:Class rdf:ID="Pasta"> <rdfs:subClassOf rdf:resource="#EdibleThing"/> <owl:disjointWith rdf:resource="#Meat"/> <owl:disjointWith rdf:resource="#Fowl"/> <owl:disjointWith rdf:resource="#Seafood"/> <owl:disjointWith rdf:resource="#Dessert"/> <owl:disjointWith rdf:resource="#Fruit"/> </owl:Class>

8. Composing Ontologies • Create a primitive tree which is a hierarchical tree of primitive concepts • Resides on the top level of the ontology • Constructed so that each concept has only one parent and disjoint siblings • Primitive skeletons distinguish two types of concepts: • Self-standing concepts: concepts include “things” that are part of the physical world such as “animals” or “organizations” • Partitioning concepts: values that partition self-standing concepts such as “small,medium, large” • By using primitive skeletons, the evolution, sharing and re-use of ontologies is greatly simplified. • Once primitive skeleton is formed, descriptions and definitions are created to express the relations between those primitives.

9. Original Ontology Primitive Skeleton

10. GloServ Architecture • Hybrid hierarchical and peer-to-peer architecture • Hierarchy • High-level services established hierarchically • Primitive skeleton ontology used for separating high-level services • Each node will know about other high-level servers by looking up primitive ontology model • Disjoint servers are handle service classes that are completely unrelated to each other • Peer-to-Peer • Servers who hold information about the same or equivalent service class connected to each other in a peer-to-peer network • Load distribution during query processing • Faster querying when the data is distributed according to content and each server handles a set of information.

11. GloServ Architecture

12. Elements within a GloServer • Service Classification Ontology • Not prone to frequent changes--distributed and cached across the GloServ network • Each high level service will have a set of properties that will be inherited by all of its children. • Additional properties may exist for particular service type • Thesaurus Ontology • maps synonymous words to each of the service terms in the service classification ontology • greater degree of accuracy in finding the correct server • P2P Data structure (CAN lookup table) • Constructed according to the data in each class (class instances) • Each instance represents a registered service. • Connects servers of the same type to each other in a peer-to-peer network. • Novel mapping algorithm combines benefits of OWL and CAN to map content of service instances to nodes in a peer-to-peer network.

13. Server Bootstrapping 1)Query for “inn” comes in 4)Send the query to the closest high-level server that is known 2)Map the word “inn” to “hotel” 3)Look up the domain of the equivalent server or closely related server in the primitive skeleton ontology

14. CAN: Content Addressable Network • Structured peer-to-peer network • Uses key-value pair • D-dimensional space divided amongst nodes • Each node is aware of its logical neighbors • Key is hashed to a point P in D-dimensional space • Host at point P provides value for the key

15. Mapping OWL to a CAN • OWL instances may have: • l mandatory object properties • m optional object properties • n data properties (mandatory or optional) • All possible property combinations: • Converting OWL instances to vector keys <owl:Class rdf:ID="Sports"> <rdfs:subClassOf rdf:resource="#Activity"/> <hasKey>1</hasKey> </owl:Class> <owl:Class rdf:ID="Adventure"> <rdfs:subClassOf rdf:resource="#Activity"/> <hasKey>2</hasKey> </owl:Class> <owl:Class rdf:ID="SightSeeing"> <rdfs:subClassOf rdf:resource="#Activity"/> <hasKey>3</hasKey> </owl:Class>

16. Mapping Vector Keys to CAN • CAN is most appropriate peer-to-peer network for exact and approximate matching • Generated vector keys distributed in a CAN • Instead of using random keys for each dimension, use the generated keys by using a property per dimension for the d-dimension key

17. GloServ Querying • When the correct gloserver is contacted, it obtains the user query. • Query input done either through user form, or by automatically filling out an OWL ontology skeleton • Anticipate that GloServ will be used in context-aware and pervasive computing environments where a user’s preferences are detected and user input relied on • Query propagation either depends on user satisfaction or automatically travels to all possible routes up to a threshold value

18. GloServ Querying • Exact matching • Populated properties of the query are analyzed • Exact query combination is generated • If user is querying for Sports activity in Arizona then <3,1> vector key is generated and mapped to server handling these properties. • Approximate matching • Keys of geographically nearby locations and related activities to sports are generated • All combinations of these are queried for to give the user an approximate result. • Related keys obtained by finding all classes that are related to the property value

19. GloServ Registration • Keys generated same way as in querying • Registration information distributed to nodes carrying related information. • If registration node not leaf node • reference to the registration instance propagates to other related servers (node’s children or related siblings) • Related servers are determined by observing service classification ontology

20. Related classes in ontology • BackPackersDestination and BudgetHotelDestination are related siblings (not disjoint) • The class Destination specifies possible • travel destinations • Subclasses: BackPackersDestination • and BudgetHotelDestination • asserted necessary and sufficient conditions of BackpackersDestination class: • Necessary and sufficient conditions of BudgetHotelDestination are: • These related classes will have access to each other’s information

21. Conclusion and Future Work • GloServ is a hybrid hierarchical and peer-to-peer global service discovery system • It uses OWL for service classification, server bootstrapping, service querying and registration • Extend GloServ to be used in context-aware environments • Discover user’s context and provide appropriate services • Design extensions to GloServ that monitor users and service usage