Content uploaded by Knarig Arabshian
Author content
All content in this area was uploaded by Knarig Arabshian
Content may be subject to copyright.
GLOSERV: GLOBAL SERVICE DISCOVERY USING THE OWL WEB ONTOLOGY LANGUAGE
K. Arabshian1, H. Schulzrinne1, D. Trossen2 and D. Pavel2
1Columbia University, United States
2Nokia Research Center, United States
ABSTRACT
Due to the growth in ubiquitous computing technology
in the past few years, the need for context-aware service
discovery across wide area networks is becoming
prevalent. Current service discovery protocols lack in
the ability to scale to large networks as well as
semantically describe services. Thus, we propose
GloServ, which is a global service discovery
architecture that locates services throughout wide and
local area networks. Intelligent agents within GloServ
use the OWL Web Ontology Language to provide
detailed service descriptions, and provide users with
automatic registration and querying. This paper
discusses a revision of GloServ that uses the OWL Web
Ontology Language, as its ontology for describing
services instead of the Resource Description Framework
Schema (RDFS). We will describe how OWL is used
for automated registration and querying of services
throughout a global network.
1. INTRODUCTION
GloServ is a global service discovery architecture that
addresses the need for wide area service discovery for
ubiquitous and pervasive computing. It operates on wide
area as well as local area networks. Any type of service
is handled which may include events, location-based
services, communication or web services.
There are many different scenarios global service
discovery systems are useful in. Imagine an avid
traveler who is interested in different events or services
that are taking place in a particular city. A New Yorker
visiting Paris, for instance, wants to be notified of all the
concerts taking place in Paris. When he lands in the
airport, his device will issue a query pertaining to his
preference, such as classical music concerts, and then
try to locate classical concerts in that area. Another
example would be of a doctor visiting another hospital
who wants to discover different medical services. The
doctor issues a query and obtains the types of services
she is interested in automatically.
Originally, GloServ was designed using the Resource
Description Framework Schema (RDFS) [5]. However,
RDFS has a main limitation in that it provides only a
hierarchical classification of services. Thus, we have
redesigned the system to use an ontology for service
descriptions such as the OWL Web Ontology Language [1],
which has been adopted as the ontology of choice for the
future of the Semantic Web. An ontology defines the terms
used to describe and represent an area of knowledge. OWL
defines classes and the relationships between them as well
as their various properties. Rather than just having a
hierarchical relationship between classes, OWL is a logic-
based language that provides greater detail in describing the
relationships between classes. It expresses various class
relationships using Boolean expressions, equivalence and
inverse relations, quantification and other logical semantics.
By using OWL, intelligent agents within GloServ servers
can automatically decide where services should be
registered to and how they should be queried for.
Below, we describe the details of the GloServ revision.
Section 2 discusses related work. An overview of OWL is
given in Section 3. Motivation for an ontology-based design
is described in Section 4. Section 5 describes ontologies that
will be used in GloServ. The system architecture, automated
registration and querying is described in Section 6. The
implementation of the revision and future work of GloServ
is discussed in Section 7. Finally, we conclude in Section 8.
2. RELATED WORK
Service discovery protocols in use today include SLP [11],
standardized by the IETF, Sun Microsystem's Jini [13], and
Microsoft's UPnP (Universal Plug and Play) [9].
Additionally, [15] describes an Internet telephony gateway
location protocol for voice over IP applications. This
protocol architecture called Brokered Multicast
Advertisements (BMA) addresses the problem of an IP host
finding the IP address of the appropriate gateway in order
for a call to be made to a user on the PSTN. These service
discovery protocols have various similarities and
differences. We will look at a few of these protocols briefly
in this section.
SLP has three main components: User Agents (UA) which
perform service discovery on behalf of a client, Service
Agents (SA) which advertise location and characteristics of
the service on behalf of the service, and Directory Agents
(DA), which are optional, record available services and also
respond to service requests from UAs. In SLP, there are
two modes of operation: one includes the DA and the
other does not. When a DA exists, the UAs learn about
services by unicasting messages to the DA. Otherwise,
UAs send multicast messages to the SAs and learn
about available services. When a DA is present, there is
faster response time and thus it is scalable to larger
networks.
Jini is built on top of the Java object and RMI system.
Service registries, similar to SLP's DAs, are used to
register service proxy objects and act as lookup
services. Through a discovery process, a client
downloads the service proxy and invokes it to access the
service. The Java class hierarchy defines services and
their attributes.
UPnP differs from SLP and Jini in that it doesn't have a
central service registry but services just multicast their
announcements to control points that are listening to
these messages. Control points can also multicast
discovery messages and search for devices within the
system. XML describes the services in greater detail.
The Universal Description, Discovery and Integration
(UDDI) [16] specification is used to build discovery
services on the Internet. UDDI provides a consistent
publishing interface and allows programmatic discovery
of services. Services are described in XML and
published using a Publisher's API. Consumers access
services by using the Programmer's API built on top of
SOAP. Services in UDDI are stored in a centralized
business registry. The main drawback of UDDI is that it
has a centralized architecture and does not span to a
global area.
Recently there have been developments in wide area
service discovery. INS/Twine [18] and Ninja [17]
describe two such systems. Both systems use XML to
describe services. However, INS/Twine maps strands of
hierarchically partitioned data to a structured peer-to-
peer system. Ninja, on the other hand, organizes servers
dynamically into hierarchies and issues upward queries
using Bloom filters.
GloServ differs from all of these systems in that it is
globally scalable by incorporating a hybrid hierarchical
and structured peer-to-peer architecture. It also has
greater logical capabilities in its use of OWL-DL for its
architectural design and service descriptions. The main
difference between using OWL and any other attribute-
value or XML description mechanism is that OWL not
only classifies services hierarchically but also allows
logical restrictions on class relationships. By using
OWL, the relationships of the services to each other are
known. According to these classifications, the service
discovery architecture is constructed. The logical
capabilities of OWL aid in finding the appropriate service
classes within the system as well as in content distribution
and query propagation.
3. OVERVIEW OF OWL
In our previous paper [4], we used RDF and RDFS to
classify services hierarchically. However, the World Wide
Web Consortium has recently approved OWL as a standard
for the Semantic Web. OWL builds on RDF and RDF
Schema and adds more vocabulary for describing properties
and classes such as: relations between classes, cardinality,
equality, richer typing of properties, characteristics of
properties, and enumerated classes. Below we give an
overview of the sublanguages of OWL and the
characteristics of OWL Classes and Properties.
3.1 Sublanguages of OWL
There are three sublanguages in OWL: OWL Lite, OWL DL
and OWL Full. OWL Lite is the least expressive of the three
sublanguages. Although it is a bit more expressive than
RDFS that in addition to supporting a classification
hierarchy, it also provides simple constraints of classes and
properties. OWL DL is modeled after description logics and
supports maximum expressiveness while retaining
computational completeness (all conclusions are guaranteed
to be computable) and decidability (all computations will
finish in finite time). OWL DL includes all OWL language
constructs. OWL Full is the most expressive of the three
sublanguages. The main difference between OWL DL and
OWL Full is that in OWL DL, a class is only expressed as a
collection of individuals and cannot be regarded as an object
in and of itself. However, in OWL Full, a class can be
treated simultaneously as a collection of individuals and as
an individual in its own right. Due to this difference, OWL
Full cannot be completely supported by OWL Description
Logic Reasoners to check for soundness. We have chosen to
use OWL DL for two reasons: 1) a service class will only
represent a collection of individuals and does not need to be
an individual in its own right and 2) we would like to use
OWL DL reasoners such as Racer to check for the
soundness of OWL documents.
3.2 Characteristics of OWL Classes and Properties
User-defined classes in OWL are all subclasses of the root
class owl:Thing. A basic class contains individuals, which
are instances of the class, and other subclasses. In addition,
OWL supports set operators on classes such as union,
intersection and complement. It also allows class
enumeration and disjointness.
A property is a binary relation that specifies class
characteristics. There are two types of simple
properties: datatype and object properties. Datatype
properties are relations between instances of classes and
RDF literals or XML schema datatypes. Object
properties are relations between instances of two
classes. Properties can also have greater logical
capabilities such as being transitive, symmetric, inverse
and functional.
Ontology mapping is useful for combining a set of
ontologies and seeing where various equivalences lie.
Classes and properties can be equivalent. Individuals,
which are instances of classes, can be categorized as the
same or different from each other.
3.3 OWL-based Languages
Due to the flexibility of the OWL ontology, specialized
OWL-based languages are now being created for
specific applications such as service discovery. OWL-
based languages for service discovery require languages
that give structure to describing and querying services.
Two such languages we are considering are OWL-S [6]
and OWL-QL [8] which are used for services and
querying respectively.
OWL-S is an upper ontology that allows services to be
expressed by three main components: the service profile
for advertising and discovering services; the process
model, which gives a detailed description of a service's
operation; and the grounding, which provides details on
how to interoperate with a service, via messages. All
three components do not have to be used at once, but
based on the need of the service. Since GloServ is in its
initial stage of service discovery, only the service
profile is utilized and the description within the profile
is written in OWL DL. However, once GloServ extends
to service access and execution, the other two
components will be used as well.
The OWL Query Language (OWL-QL) is a formal
language and protocol that allows querying and
answering agents to conduct a query-answering
dialogue in ontologies represented by OWL. The design
of OWL-QL makes certain assumptions which fit
perfectly with the GloServ architecture. It provides a
generic query-answering dialogue system that can be
easily implemented in the Semantic Web.
4 ONTOLOGY-BASED SYSTEM DESIGN
This section aims at motivating the ontology-based
system design. For this, we will use the example of an
architecture for distributed context-aware applications. We
will first briefly outline this architecture before describing
the use of ontologies in such system.
4.1 A System for Distributed Context-aware
Applications
Figure 1 shows the architecture of our system. It enables
distributed context-aware applications throughout the
Internet, i.e., it supports the acquisition of context
information from distributed sources in the Internet together
with the discovery of these sources. As context information,
[7] generally describes “any information that characterizes
the situation of an entity”. Examples for such information
are location, time, activity, or affective state of a person.
The acquisition of the information is based on access
policies defined by the context owner. Note that it is not
intended to dive into the depth of this particular architecture
rather than to motivate the use of ontologies for particular
pieces of information provided throughout the system.
However, the work in [14] outlines issues regarding
implementing the system in Figure 1 within a SIP-based
environment.
The shown architecture provides different roles within the
system. The context consumer and provider engage in a
provisioning relationship for a particular piece of context
information, such as location, time, activity etc. Access
policies of particular context information are defined by the
context owner (such as the person whose location is
provided), the policies being hosted at the authorization
policy server. The discovery of context providers is
implemented in the discovery server. The ontology server
Figure 1: Architecture of distributed context-
aware applications
hosts different system-specific ontologies and related
functionality (e.g., implementing algorithms for
selecting appropriate ontologies for different usages). In
addition to the system ontology server, ontologies in the
Internet can be used, possibly within different vertical
application areas, such as health care, mobile work force
etc. Such usage is enabled through pointing to these
ontologies through URLs.
4.2 Use of Ontologies For Context Provisioning and
Discovery
In Figure 1, the major piece of information in this
system is the particular context provided to the context
consumer. In this, the context provider constitutes a
particular form of a service provider, namely
provisioning requested context information. The system
in Figure 1 supplements the functionality of context
acquisition with support of access policies and
discovery of particular context providers, similar to
general-purpose service provisioning environments. As
generally described in [4], ontologies are used for
various purposes within such system:
Automated context provider discovery: In a context-
aware environment, a context consumer needs to know
which context provider could potentially deliver the
context it needs. For example, an application may need
to know the people within 20 meters vicinity of the user.
In order to provide such information, the application
needs to find the context provider that can provide this
kind of information. With the use of ontologies, each
context provider can model the kind of context
information it provides and advertise it to a service
registry. This will enable context consumers to
automatically discover providers by querying for
appropriate characteristics of the required services,
which can be mapped by the discovery server onto the
available registered context provider.
Automated context acquisition invocation: Service
invocation in a context-aware system, i.e., the
acquisition of particular context information, is
supposed to happen in an automated manner, i.e., there
is no need for the user to manually configure provider
relationships or edit configuration information.
Ontologies provide a declarative and computer-
interpretable description of the parameters for remote
service invocation methods. Hence, a context consumer
is able to interpret the required input and expected
output from the ontology description.
Automated context (de-)composition and
interoperation: High-level services do not need to be
atomic, i.e., provided by a single entity as a single service.
Instead, it is possible that a high-level service is composed
of different sub-services, along a well-defined goal. In a
context-aware system, such service composition can be seen
as a high-level context description that can be decomposed
into further subcomponents, eventually into atomic pieces of
context information. Such decomposition even enables to
replace pieces of context information throughout the
runtime of the provisioning in cases where such piece of
context information is no longer available but can be
replaced by alternative sources. For that, the prerequisites
and consequences of using individual pieces of context are
to be defined in a proper ontology.
Automated execution monitoring: Through the runtime of
a particular context acquisition, the context consumer might
want to know the status of the acquisition. The use of
ontologies allows for defining declarative descriptions for
the state of execution of the acquisition.
In conclusion, the use of ontologies generally facilitates
automation of discovery, provisioning, execution and
composition of services, i.e., of all major parts in the service
execution environment. This is achieved through separating
the semantics of the particular functionality from the
specifics of its provisioning. Ontologies such as OWL-S
allow such separation through definition of service models,
process models and the particular grounding within a
particular provisioning system, as outlined in the previous
section. The remainder of the paper will focus on the
enablement of automated discovery. We will generally
describe the modeling of services and their registration
within a system, such as the one presented in Figure 1.
5 GLOSERV ONTOLOGIES
5.1 Service Classification Ontology
In the previous version of GloServ, services were
categorized hierarchically and accessed through URIs that
were descriptive of the service and its location. However,
with the use of ontologies, services need not be classified
only hierarchically but using first order logic, as provided in
OWL, we can create more complex service classification.
A separate classification system similar to North American
Industry Classification System (NAICS) [2] classifies
services and establishes ontologies that describe each type
of service. An authority such as ICANN [3] delegates the
top-level services and events to individual GloServ servers.
The service categorization is similar to a yellow pages
directory. Although the categories may change from time to
time, they are not expected to change drastically or
frequently, which gives us the ability to pre-define the
service classification and implement caching in local
user agents.
An ontology needs to be created that describes all
service classes and their set relationships. There are
many ways to compose ontologies. [20] and [19]
describe a few. [19] describes an ontological
engineering method that provides a modularized
approach to classification and allows the most flexibility
when combining various ontologies. It uses an
analogous method of database normalization in order to
normalize ontologies. General domains (or classes),
within in an ontology, are put in disjoint hierarchical
trees, which creates a primitive skeleton. The main goals
of normalization are to allow modules to be re-used and
separated from the whole and to evolve independently
of each other. These characteristics are necessary in any
ontological-based system. We have chosen this method
for service classification and describe the details of how
services are classified below.
The main features of OWL DL include primitive and
defined classes (or concepts), properties, restrictions and
axioms. A primitive class is one that is described by
necessary conditions whereas a defined class is
described by necessary and sufficient conditions.
Practically, thismeans that primitive classes are in a
hierarchical class/subclass relationship, while defined
classes describe equivalences. Properties relate classes
to each other and can themselves be hierarchical as well.
Restrictions quantify the property-class pair and axioms
declare classes disjoint or imply other classes. These
features can be used in a variety of ways in order to
produce meaningful ontologies. However, as described
in [19], the best approach to identify modules is to first
create a primitive tree which is a hierarchical tree of
primitive concepts. The primitive skeleton resides on
the top level of the ontology and is constructed in such a
way that each concept has only one parent and disjoint
siblings. Once this primitive skeleton has been formed,
descriptions and definitions are created to express the
relations between those primitives. Primitive skeletons
should also distinguish two types of concepts: Self-
standing
concepts and Partitioning concepts. Self-standing
concepts include “things” that are part of the physical
world such as “animals” or “organizations”. Partitioning
concepts, on the other hand, are values that partition
self-standing concepts such as “small,medium,large”.
Other partitioning concepts may be location-based. By
using primitive skeletons, the evolution, sharing and re-
use of ontologies is greatly simplified.
5.2 Thesaurus Ontologies
Since there are multiple terms that can describe a certain
service, using OWL's equivalence relations, services can be
classified into their equivalence classes within a thesaurus
ontology. For example, the service “restaurant” can be made
equivalent to “dining”. This ensures that a user searching for
services synonymous to the service listed in the
classification ontology will be found. As terms continue to
evolve, the only thing that needs to change is removing or
adding classes to these ontologies.
5.3 Ontologies for distributing GloServ servers
For location-based services, GloServ servers are distributed
according to location. Besides maintaining a service
ontology, a location ontology of all the GloServ servers
within an area is also maintained. The location ontology will
consist of location classes with at least one “hasServer”
property that points to a GloServ server within the vicinity.
Each GloServ server will maintain an ontology of services
in its current vicinity. A central governing authority such as
ICANN needs to maintain this location ontology of GloServ
servers as well.
A benefit to using a location OWL ontology is that locations
need not only be classified hierarchically but by other user-
defined properties. For instance, using the symmetric
property in OWL, an “adjacentRegion” property can be
established so that all locations that are near each other can
be automatically identified through symmetry. For instance,
when looking for a service in a certain region of Manhattan
such as the Upper West Side, this region can have the
symmetric property of being adjacent to Midtown and
Upper East Side. If a user is querying for a certain store in
the Upper West Side, and the GloServ server in that area
does not have that store, the servers in the adjacent regions
are automatically searched.
GloServ servers may also be distributed by other means
besides location. For instance, event-related services,
communication or web services may not be tied to a
particular location, but can be categorized according to
service within the service classification ontology. This
distributes GloServ servers according to specific service
classification. For the purposes of this paper, we will focus
mainly on location-based services and describe such an
architecture.
6. GLOSERV ARCHITECTURE
6.1 Server Bootstrapping
The GloServ architecture consists of servers connected as a
hybrid network of hierarchical and peer-to-peer nodes. The
high-level services are established in a hierarchical format.
The service classification ontology is used for separating
these high-level services. Since it is expected that there
will be a limited number of high-level servers, each will
know about other high-level servers that are disjoint
from it. By using this ontology model, any server will
be able to get to its children as well as to those servers
that are disjoint from it very quickly.
Besides organizing high-level servers, we need to
establish servers that are related to each other. Servers
who hold information about the same or equivalent
service class, will be connected to each other in a
structured peer-to-peer network. The motivation for
using a peer-to-peer network is for load distribution
during query processing. Querying is faster when the
data is distributed according to content and each server
handles a set of information. In general, there are
several ways to do load distribution. If you replicate the
registrations across all servers, there is no need for a
structured peer-to-peer system. However, the servers
will hold so much content that query processing will be
slow for a single server. Thus, a peer-to-peer network
establishes a robust and scalable environment for
querying. Figure 2 gives an overview of the architecture
of the GloServ system.
6.2 Service Registration in GloServ
The previous design of GloServ allowed the service
provider to choose where to register itself in the service
hierarchy, the current version of GloServ automates this
process where a user only provides its service type and
an intelligent Service Agent deduces which GloServer
the document should be registered in. Below we
describe the registration mechanism using the restaurant
service as an example.
Registration can have either a web-based front end or
another means of transferring information. In a web-
based mechanism, a user will fill out a generic
registration form of a service category. However, if this
is a type of service that doesn't need any human
interaction for registration, the registration mechanism
can follow another protocol where ontologies are
exchanged, parsed and information sent via automated
programs. We are currently focusing on web-based
registration of services for the purpose of this paper, but we
do plan on extending GloServ to encompass all types of
automated services as well in the future.
When a restaurant service provider registers within
GloServ, it will go to a generic GloServ site and enter in the
keyword of its service type. The Service Agent will look up
an equivalent term in the thesaurus ontology. It will
recognize various user inputs such as “inn” or “motel” as a
hotel service and retrieve the hotel registration ontology. If
no terms are found, then it will display all of its closely
related service categories to the user who can then choose
the category that matches its own.
Once the service category is identified, and the service
registration ontology is retrieved, it is converted to an
HTML form for the service provider to fill out. For instance,
a default hotel registration ontology would probably need
certain values such as: location information, price range,
rating, activity, etc. However, in addition to default tags, a
user can enter extra text information that it wants the servers
to be aware of such as “music” and “dress code.” This free
text information is entered under the “hasFreeText” property
slot of the ontology. By combining ontological searches
with free text searches, there is a greater probability of
finding a service that matches the user's query specifically.
For location-based services, as in the case of hotels, the
registration information of the service provider is sent to the
GloServer nearest to the service provider. The nearest
GloServer is determined by mapping the location of the user
and retrieving the GloServer URI from the location
ontology. Once the GloServer is identified, a Service Agent
within the GloServer inserts a reference to the ontology
under the correct service type.
Fi
g
ure 2: GloServ Architecture Although all GloServers will share the same high-level
service classification ontology, each GloServer node might
defer in further breakdown of service classification. For
instance, restaurants are in abundance in New York City.
Thus, each GloServer can have a detailed breakdown of the
restaurant service class according to the types of restaurants
it has in its vicinity. Subclasses are created for: fast food
restaurants, fine dining restaurants, and ethnic restaurants.
Each subclass is related to each other in various ways. Fast
food restaurants are classified as the inverse of fine dining
restaurants. Certain fine dining restaurants will have values
from ethnic restaurants. The service agent will look through
the ontology submitted by the service provider and place a
reference to the restaurant's ontology and URI under the
branches that correspond to the appropriate class
restrictions. Figure 3 illustrates how services can be
classified using OWL.
6.3 User Querying in GloServ
When a user issues a query in GloServ, the query will
be first handled by any GloServer. As mentioned above,
the user will first choose the type of service it is looking
for. Once the server that is most likely to have the
service the user is searching for is contacted, the query
is distributed among the peer servers of that service type
according to the key values.
When the correct GloServer is contacted, it obtains the
user query. Query input is guided by the service class's
OWL ontology. As mentioned before, query input can
be done either through a user form, or by automatically
filling out an OWL ontology skeleton. We anticipate
that GloServ will be used in context-aware and
pervasive computing environments where a user's
preferences can be detected and user input can be relied
on in order to get an accurate query. Thus, we employ a
similar method to OWL-QL where the user can indicate
when it is satisfied with the query results via a query-
answering dialogue. If it is satisfied, the query
propagation terminates. Otherwise, it continues sending
either the same or modified query until all results are
found. If the query is not human-centric, then query
propagation automatically travels to all possible routes
up to a threshold value. If the user was querying for
hotels, the
Fi
g
ure 3: Exam
p
le of service classification ontolo
gy
hotel server would send a form of all its properties so that
the user could specify values it is querying for. If the hotel
server is a leaf node within the service classification
hierarchy, then it is apparent that the query will only remain
in its immediate peer network of other hotel servers.
However, if it has further children or related siblings that
hold similar information to it, the query is sent to these
related nodes as well.
The user will fill out any number of fields in the form. The
general fields that are filled out are object properties such as
the location or the activity. As long as users specify a few
object properties, then the query will be directed to the
correct server in the peer-to-peer network. Otherwise, if
only datatype properties are issued, then all servers within
the peer-to-peer network will be contacted.
When a user queries in GloServ, the query is sent to a local
intelligent User Agent (UA). A local UA has a cached copy
of the GloServer distribution ontology. This information is
cached and periodically renewed to update any changes
within the classification. When a user issues a query, it is
automatically connected to a local UA. The web interface
for querying for services is similar to registration. A generic
GloServ query website will be presented to the user for
querying. This interface can be changed according to device
capabilities.
When the UA receives the user query, it looks through a
thesaurus ontology that maps the words to possible
classes and properties within the service classification
system similar to the registration mechanism mentioned
above. It issues the query pattern to the Service Agents
residing in the nearest GloServer. Similar to OWL-QL,
a query-answer dialogue begins and the user is able to
see the answers to the query. If the user is not satisfied
with any of the query results after a few query-answer
sessions, the UA searches the adjacent GloServers. This
goes on until the query propagation value n has been
reached or the user has found what she is looking for.
Figure 4 gives an overview of the query propagation.
The free text portion of the OWL documents is used for
further analysis. If there are no hits to the user's queries,
then the free text portion of the OWL documents is
matched to the text query of the user. Possible results
are presented to the user. It is also used to filter out
existing queries. If the user's query results in many hits,
the text portion is analyzed to see if the results can be
filtered out.
In addition, context information can be used to improve
the query results. As mentioned in Section 4, context
acquisition itself may be deemed as a service within
GloServ. When administering a context-aware query in
GloServ, the query will first go through the context
servers in order to determine the correct context of the
user. It will then go through the service registries to find
the service that pertains to the user's context.
7. IMPLEMENTATION AND FUTURE WORK
Currently, we are implementing a prototype of the revised
GloServ system using Protégé [10] and Racer [12]. Protege
is an open-source development environment for ontologies
and knowledge-based systems. The OWL Plugin is an
extension of Protege that supports OWL. The Protege OWL
Plugin provides a user-friendly environment to edit and
visualize OWL classes and properties. It also has a graphical
user interface that allows users to define logical class
characteristics in OWL and execute description logic
reasoners such as Racer. Protege's flexible architecture
makes it easy to configure and extend the tool. Protege has
an open-source Java API for the development of custom-
Fi
g
ure 4: Overview of GloServ
q
uer
y
p
ro
p
a
g
ation
tailored user interface components or arbitrary Semantic
Web services. The initial phase of the GloServ
implementation concentrates on establishing service
discovery with the core components of GloServ using a few
specific ontologies. Registration and querying performance
will be tested on the initial system once it is complete. The
second phase of the GloServ design will look into the
creating extensions for accessing services, having a service
rating system, policy establishment, and security guidelines.
8. CONCLUSION
We have described a redesign of GloServ, a global service
discovery architecture, using the OWL Web Ontology
Language. GloServ functions both on a wide area as well as
a local area network. It applies to a broad range of services
that are defined flexibly using OWL ontologies. GloServ
server distribution is specified in ontologies which allows
for greater versatility. Service registration and querying for
services also becomes automated and user-friendly due
to the use of ontologies.
9. ACKNOWLEDGEMENT
This work is supported by a grant from Nokia Research
Center.
REFERENCES
1. OWL, 2004. http://www.w3.org/2004/OWL/
2. North American Industry Classification System,
http://www.naics.com
3. Internet Corporation for Assigned Names and
Numbers, http://www.icann.org
4. Arabshian, K., and Schulzrinne, H., 2004. “Gloserv:
Global service discovery architecture”, In First Annual
International Conference on Mobile and Ubiquitous
Systems: Networking and Services (Mobiquitous)
5. Brickly, D., and Guha, R., 2004. “Rdf vocabulary
description language 1.0: Rdf schema”, W3c proposed
recommendation, World Wide Web Consortium
6. OWL-S Coalition, 2004. “OWL-S: semantic markup
for web services”
7. Dey, A., 2001. Personal and Ubiquitous Computing,
Vol. 5, No. 1, “Understanding and using context”
8. Fikes, R., Hayes, P., and Horrocks, I., 2003. “OWL-
QL - a language for deductive query answering on the
semantic web”, Technical report, Stanford University
9. UPnP Forum, 2003. “UPnP device architecture 1.0”,
Technical report
10. Gennari, J., Musen, M., Fergerson, R., Grosso, W.,
Crubézy, M., Eriksson, H., Noy, N., and Tu, S., 2002.
“Evolution of protégé: An environment for knowledge-
based systems development”, Technical report, Stanford
University
11. Guttman, E., Perkins, C., Veizades, J., and Day. M.,
1999. “Service location protocol, version 2”, RFC 2608,
Internet Engineering Task Force
12. Haarslev, V., and Moller, R., 2004. “Racer user's
guide and reference manual version 1.7.19”, Concordia
University, Tehcnical University of Hamburg-Harburg,
University of Hamburg
13. Sun Microsystem, 1999. “Jini architectural overview”,
Technical report
14. Pavel, D., and Trossen, D., 2004. “Context provisioning
and sip events”, in Workshop on Context Awareness at 2nd
Conference on Mobile Systems, Applications, and Services
(MobiSys), Boston, MA, USA
15. Rosenberg, J., and Schulzrinne, H., 1998. “Internet
telephony gateway location”, in Proceedings of the
Conference on Computer Communications (IEEE Infocom),
pages 488--496, San Francisco, California
16. U. D. D. I. UDDI technical white paper. White paper,
UDDI (Universal Description, Discovery and Integration),
Sept. 2000.
17. S. D. Gribble, M. Welsh, R. von Behren, E. Brewer, D.
Culler, N. Borisov, S. Czerwinski, and R. Gummadi. The
ninja architecture for robust internet-scale systems and
services. 35(4):473–497, Mar. 2001.
18. M. Balazinska, H. Balakrishnan, and D. Karger.
Ins/twine: A scalable peer-to-peer architecture for
intentional resource discovery, 2002.
19. A. Rector. Modularisation of domain ontologies
implemented in description logics and related formalisms
including owl. In 2nd International Conference on
Knowledge Capture (K-CAP), Sanibel Island, FL, 2003.
20. M. Horridge, A. Rector, N. Drummond, H. Knublauch,
and H. Wang. A user oriented owl development
environment designed to implement common patterns and
minimise common errors. In 3rd International Semantic
Web Conference (ISWC2004), Hiroshima Prince Hotel,
Hiroshima, Japan, Nov 2004.
