OWL-Web Ontology Language

Seminar Report

On

“OWL – WEB ONTOLOGY LANGUAGE”

Submitted By:
Ruchira Moondra

Under the Guidance of:

Prof. Mrunal Bewoor

DEPARTMENT OF COMPUTER ENGINEERING

BHARATI VIDYAPEETH UNIVERSITY,
COLLEGE OF ENGINEERING, PUNE.
2006-2007

1
OWL-Web Ontology Language

CERTIFICATE

This is to certify that Ms. RUCHIRA MOONDRA, of class B.E.-Computer1,

Roll No.63, has successfully completed her seminar work on the topic

“OWL – Web Ontology Language”

under the able guidance of Prof. Mrunal Bewoor towards the partial
fulfillment of the requirement for the degree of Bachelor of Engineering in
Computer Engineering of Bharati Vidyapeeth Deemed University College of
Engineering, Pune during the academic year 2006-2007.

Prof. Mrunal Bewoor Prof. [Link]

(Seminar Guide) (Head of Department)

Date:
Place:Pune

ACKNOWLEDGEMENT

2
OWL-Web Ontology Language

Inspiration and guidance are invaluable in every aspect of life, especially in the fields of
academics, which I have received from my respected seminar guide Prof. Mrunal Bewoor,
who has put her careful guidance through which I am able to complete my seminar work.
Also I would like to thank Prof. S.H. Patil, Head of Department, Computer Engineering and
Information Technology, for his kind and invaluable guidance all through.

I would also thank all the staff members and my classmates who directly or indirectly helped
me, time to time.

RUCHIRA MOONDRA
B.E. COMPUTER-1
ROLL NUMBER-63

3
OWL-Web Ontology Language

INDEX

[Link] 1
1.1 Why OWL? 1
1.2 Design goals 2
1.3 Requirements 3
1.4 Objectives 6
1.5 The three sublanguages of OWL 9
1.6 Language Synopsis 11

2. OWL-S: Semantic Markup for Web Services 14

2.1 Introduction: Services on the Semantic Web 14

2.2 Some Motivating Tasks 15
2.3 An Upper Ontology for services 17
2.4 Services Profiles 20

3. Modeling Services as Processes 23

3.1Grounding a Service to a Concrete Realization 25
3.2 Relationships between OWL-S and WSDL 26
4. Version Information 33
5. Future Directions 34
6. Conclusion 35
7. Glossary 36
8. References 37

Figure Index
1. Top level of the service ontology 18
2. Selected classes and properties of the Profile 22
3. Top level of the process ontology 24
4. Mapping between OWL-S and WSDL 26
5. Top level of the process ontology 30

Table Index
1. OWL Lite Synopsis table 12
2. OWL DL and Full Synopsis 13

4
OWL-Web Ontology Language

CHAPTER-1
1
OV
E
R
V
I
E
W

1. Introduction [5]

This seminar describes the OWL Web Ontology Language. OWL is intended to be used when the
information contained in documents needs to be processed by applications, as opposed to
situations where the content only needs to be presented to humans. OWL can be used to explicitly
represent the meaning of terms in vocabularies and the relationships between those terms. This
representation of terms and their interrelationships is called an ontology. OWL has more facilities
for expressing meaning and semantics than XML, RDF, and RDF-S, and thus OWL goes beyond
these languages in its ability to represent machine interpretable content on the Web. OWL is a
revision of the DAML+OIL web ontology language incorporating lessons learned from the design
and application of DAML+OIL.

1.1 Why OWL?

The Semantic Web is a vision for the future of the Web in which information is given explicit
meaning, making it easier for machines to automatically process and integrate information
available on the Web. The Semantic Web will build on XML's ability to define customized tagging
schemes and RDF's flexible approach to representing data. The first level above RDF required for

5
OWL-Web Ontology Language

the Semantic Web is an ontology language what can formally describe the meaning of terminology
used in Web documents. If machines are expected to perform useful reasoning tasks on these
documents, the language must go beyond the basic semantics of RDF Schema. The OWL Use
Cases and Requirements Document provides more details on ontologies, motivates the need for a
Web Ontology Language in terms of six use cases, and formulates design goals, requirements and
objectives for OWL.

OWL has been designed to meet this need for a Web Ontology Language. OWL is part of the
growing stack of W3C recommendations related to the Semantic Web.

 XML provides a surface syntax for structured documents, but imposes no semantic
constraints on the meaning of these documents. [13]
 XML Schema is a language for restricting the structure of XML documents and also
extends XML with datatypes. [14]

 RDF is a datamodel for objects ("resources") and relations between them, provides a simple
semantics for this datamodel, and these datamodels can be represented in an XML syntax. [

 RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a
semantics for generalization-hierarchies of such properties and classes. [15]

 OWL adds more vocabulary for describing properties and classes: among others, relations
between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing
of properties, characteristics of properties (e.g. symmetry), and enumerated classes.

1.2 Design goals

Design goals describe general motivations for the language that do not necessarily result from any
single use case. Along with the Use Cases, these motivate the Requirements and Objectives in
Sections 4 and 5. In this section, we describe eight design goals for the web ontology language, in
particular those dealing with:

 using established ontologies

 changing established ontologies

6
OWL-Web Ontology Language

 integrating established ontologies

 detecting inconsistencies across ontologies and instances of use
 providing a balance between expressivity and scalability when creating ontologies
 avoiding unnecessary complexity which may discourage widespread adoption
 maintaining compatibility with other standards
 supporting internationalization

For each goal, we describe the tasks it supports and explain the rationale for the goal. We also
describe the degree to which RDF and RDF Schema supports the goal.

1.3 Requirements [11]

The use cases and design goals motivate a number of requirements for a web ontology language.
The Working Group currently feels that the requirements described below are essential to the
language. Each requirement includes a short description and is motivated by one or more design
goals from the previous section.

R1. Ontologies as distinct resources

Ontologies must be resources that have their own unique identifiers, such as a URI
reference.

Motivation: Shared ontologies

R2. Unambiguous concept referencing with URIs

Two concepts in different ontologies must have distinct absolute identifiers (although they
may have identical relative identifiers). It must be possible to uniquely identify a concept in
an ontology using a URI reference.

Motivation: Shared ontologies, Ontology interoperability

R3. Explicit ontology extension

7
OWL-Web Ontology Language

Ontologies must be able to explicitly extend other ontologies in order to reuse concepts
while adding new classes and properties. Ontology extension must be a transitive relation;
if ontology A extends ontology B, and ontology B extends ontology C, then ontology A
implicitly extends ontology C as well.

Motivation: Shared ontologies

R4. Commitment to ontologies

Resources must be able to explicitly commit to specific ontologies, indicating precisely

which set of definitions and assumptions are made.

Motivation: Shared ontologies

R5. Ontology metadata

It must be possible to provide meta-data for each ontology, such as author, publish-date,
etc. These properties may or may not be borrowed from the Dublin Core element set.

Motivation: Shared ontologies

R6. Versioning information

The language must provide features for comparing and relating different versions of the
same ontology. This should include features for relating revisions to prior versions, explicit
statements of backwards-compatibility, and the ability to deprecate identifiers (i.e., to state
they are available for backwards-compatibility only, and should not be used in new
applications/documents.)

Motivation: Ontology evolution

R7. Class definition primitives

8
OWL-Web Ontology Language

The language must be able to express complex definitions of classes. This includes, but is
not limited to, sub classing and Boolean combinations of class expressions (i.e.,
intersection, union, and complement).

Motivation: Balance of expressivity and scalability, Ontology interoperability,

Inconsistency detection

R8. Property definition primitives

The language must be able to express the definitions of properties. This includes, but is not
limited to, sub properties, domain and range constraints, transitivity, and inverse properties.

Motivation: Balance of expressivity and scalability, Ontology interoperability,

Inconsistency detection

R9. Data types

The language must provide a set of standard data types. These data types may be based on
XML Schema data types [XML-SCHEMA2].

Motivation: Compatibility with other standards, Ease of use

R10. Class and property equivalence

The language must include features for stating that two classes or properties are equivalent.

Motivation: Ontology interoperability

R12. Attaching information to statements

The language must provide a way to allow statements to be "tagged" with additional
information such as source, timestamp, confidence level, etc. The language need not
provide a standard set of properties that can be used in this way, but should instead provide
a general mechanism for users to attach such information. RDF reification may be one

9
OWL-Web Ontology Language

possible way to accommodate the requirement, although reification is a somewhat

controversial feature.

Motivation: Shared ontologies, Ontology interoperability

R13. Classes as instances

The language must support the ability to treat classes as instances. This is because the same
concept can often be seen as a class or an individual, depending on the perspective of the
user. For example, in a biological ontology, the class Orangutan may have individual
animals as its instances. However, the class Orangutan may itself be an instance of the class
Species. Note, that Orangutan is not a subclass of Species, because then that would say that
each instance of Orangutan (an animal) is an instance of Species.

Motivation: Ontology interoperability

R14. Cardinality constraints

The language must support the specification of cardinality restrictions on properties. These
restrictions set minimum and maximum numbers of individuals that any single individual
can be related to via the specified property.

Motivation: Balance of expressivity and scalability goal,, Inconsistency detection

R15. XML syntax

The language should have an XML serialization syntax. XML has become widely accepted
by industry and numerous tools for processing XML have been developed. If the web
ontology language has an XML syntax, then these tools can be extended and reused.

Motivation: Compatibility with other standards

R17. Supporting a character model

The language should support the use of multilingual character sets.

10
OWL-Web Ontology Language

Motivation: Internationalization, Compatibility with other standards

1.4 Objectives

In addition to the set of features that should be in the language (as defined in the previous section),
there are other features that would be useful for many use cases. These features will be addressed
by the working group if possible, but the group may decide that there are good reasons for
excluding them from the language or for leaving them to be implemented by a later working group.
Some of these objectives are not fully defined, and as such need further clarification if they are to
be addressed by the language. Note that the order of the objectives below does not imply relative
priority or degree of consensus.

O1. Layering of language features

The language may support different levels of complexity for defining ontologies.
Applications can conform to a particular layer without supporting the entire language. A
guideline for identifying layers may be based on functionality found in different types of
database and knowledge base systems.

Motivation: Balance of expressivity and scalability

O5. Chained properties

The language may support the composition of properties in statements about classes and
properties. An example of the use of property composition would be the assertion that a
property called uncleOf is the same as the composition of the fatherOf and brotherOf
properties.

Motivation: Balance of expressivity and scalability

O8. View mechanism

11
OWL-Web Ontology Language

The language should support the ability to create ontology views, in which subsets of an
ontology can be specified or concepts can be assigned alternate names. This is particularly
useful in developing multicultural versions of an ontology. Note that this requirement may
be satisfied by having multiple ontologies and using an ontology mapping mechanism.

Motivation: Internationalization, Ontology interoperability

O9. Integration of digital signatures

The W3C XML Digital Signature specification is an important building block for
communication among untrusted properties, which is important for many ontology
applications. The web ontology language should be designed in a way that makes it
straightforward to use XML Signatures.

Motivation: Compatibility with other standards

O10. Arithmetic primitives

The language should support the use of arithmetic functions. These can be used in
translating between different units of measure.

Motivation: Ontology interoperability

O11. String manipulation

The language should support string concatenation and simple pattern matching. These
features can be used to establish interoperability between ontologies that treat complex
information as a formatted string and those that have separate properties for each
component. For example, one ontology may represent an e-mail address as a single string,
while another may divide it into a string for user name and a string for server name. To
integrate the two ontologies, one would need to specify that the concatenation of the user
name, the '@' character, and the server name is equivalent to the single value used in the
first ontology.

12
OWL-Web Ontology Language

Motivation: Ontology interoperability

O12. Aggregation and grouping

The language should support the ability to aggregate information in a way similar to SQL's
GROUP BY clause. It should allow counts, sums, and other operations to be computed for
each group. This would allow interoperability between ontologies that represented
information at different levels of granularity, and could relate things such as budget
category totals to budget line item amounts, or the number of personnel to individual data
on employees.

Motivation: Ontology interoperability

O13. Procedural attachment

The language should support the use of executable code to evaluate complex criteria.
Procedural attachments greatly extend the expressivity of the language, but are not well-
suited to formal semantics. A procedural attachment mechanism for web ontologies should
specify how to locate and execute the procedure. One potential candidate language would
be Java, which is already well-suited to intra-platform sharing on the Web.

Motivation: Ontology interoperability

O15. Complex data types

The language should support the definition and use of complex / structured data types.
These may be used to specify dates, coordinate pairs, addresses, etc.

Motivation: Compatibility with other standards, Ease of use

1.3 The three sublanguages of OWL

OWL provides three increasingly expressive sublanguages designed for use by specific
communities of implementers and users.

13
OWL-Web Ontology Language

 OWL Lite supports those users primarily needing a classification hierarchy and simple
constraints. For example, while it supports cardinality constraints, it only permits
cardinality values of 0 or 1. It should be simpler to provide tool support for OWL Lite
than its more expressive relatives, and OWL Lite provides a quick migration path for
thesauri and other taxonomies. Owl Lite also has a lower formal complexity than
OWL DL, see the section on OWL Lite in the OWL Reference for further details.
 OWL DL supports those users who want the 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, but they can be used only under certain restrictions (for example,
while a class may be a subclass of many classes, a class cannot be an instance of
another class). OWL DL is so named due to its correspondence with description
logics, a field of research that has studied the logics that form the formal foundation
of OWL.

 OWL Full is meant for users who want maximum expressiveness and the syntactic
freedom of RDF with no computational guarantees. For example, in OWL Full a class
can be treated simultaneously as a collection of individuals and as an individual in its
own right. OWL Full allows an ontology to augment the meaning of the pre-defined
(RDF or OWL) vocabulary. It is unlikely that any reasoning software will be able to
support complete reasoning for every feature of OWL Full.

“Each of these sublanguages is an extension of its simpler predecessor, both in what can be
legally expressed and in what can be validly concluded. The following set of relations hold.
Their inverses do not.

 Every legal OWL Lite ontology is a legal OWL DL ontology.

 Every legal OWL DL ontology is a legal OWL Full ontology.
 Every valid OWL Lite conclusion is a valid OWL DL conclusion.
 Every valid OWL DL conclusion is a valid OWL Full conclusion. “

14
OWL-Web Ontology Language

Ontology developers adopting OWL should consider which sublanguage best suits their
needs. The choice between OWL Lite and OWL DL depends on the extent to which users
require the more-expressive constructs provided by OWL DL. The choice between OWL DL
and OWL Full mainly depends on the extent to which users require the meta-modeling
facilities of RDF Schema (e.g. defining classes of classes, or attaching properties to classes).
When using OWL Full as compared to OWL DL, reasoning support is less predictable since
complete OWL Full implementations do not currently exist.

“OWL Full can be viewed as an extension of RDF, while OWL Lite and OWL DL can be
viewed as extensions of a restricted view of RDF. Every OWL (Lite, DL, Full) document is
an RDF document, and every RDF document is an OWL Full document, but only some RDF
documents will be a legal OWL Lite or OWL DL document. Because of this, some care has
to be taken when a user wants to migrate an RDF document to OWL. When the
expressiveness of OWL DL or OWL Lite is deemed appropriate, some precautions have to be
taken to ensure that the original RDF document complies with the additional constraints
imposed by OWL DL and OWL Lite. Among others, every URI that is used as a class name
must be explicitly asserted to be of type owl:Class (and similarly for properties), every
individual must be asserted to belong to at least one class (even if only owl:Thing), the URI's
used for classes, properties and individuals must be mutually disjoint. The details of these
and other constraints on OWL DL and OWL Lite are explained in appendix E of the OWL
Reference.”

2. Language Synopsis [12]

This section provides a quick index to all the language features for OWL Lite, OWL DL, and
OWL Full.

In this document, italicized terms are terms in OWL. Prefixes of rdf: or rdfs: are used when
terms are already present in RDF or RDF Schema. Otherwise terms are introduced by OWL.
Thus, the term rdfs:subPropertyOf indicates that subPropertyOf is already in the rdfs
vocabulary (technically : the rdfs namespace). Also, the term Class is more precisely stated
as owl:Class and is a term introduced by OWL.

15
 OWL-Web Ontology Language

2.1 OWL Lite Synopsis

The list of OWL Lite language constructs is given below.

RDF Schema Features: (In)Equality: Property Characteristic

Class (Thing, Nothing) equivalentClass ObjectProperty
rdfs:subClassOf equivalentProperty DatatypePropert
rdf:Property sameAs inverseOf
rdfs:subPropertyOf differentFrom TransitiveProper
rdfs:domain AllDifferent SymmetricProper
rdfs:range FunctionalPrope
distinctMembers
Individual InverseFunctiona
Property Restrictions: Restricted Cardinality: Header Information:
Restriction minCardinality (only 0 or 1)  Ontology
onProperty maxCardinality (only 0 or 1)
imports
allValuesFrom
cardinality (only 0 or 1)
someValuesFrom
Class Intersection: Versioning: Annotation Properties:
intersectionOf versionInfo rdfs:label
Datatypes priorVersion rdfs:comment
xsd datatypes backwardCompatibleWith rdfs:seeAlso
incompatibleWith rdfs:isDefinedBy
DeprecatedClass AnnotationPrope

DeprecatedProperty OntologyPropert

1.1.1 2.2 OWL DL and Full Synopsis

The list of OWL DL and OWL Full language constructs that are in addition to or expand
those of OWL Lite is given below.

16
 OWL-Web Ontology Language

Class Axioms: Boolean Combinations of Class

oneOf, dataRange Expressions:
disjointWith unionOf
equivalentClass complementOf
(applied to class expressions)
intersectionOf
rdfs:subClassOf
(applied to class expressions)
Arbitrary Cardinality: Filler Information:
minCardinality hasValue
maxCardinality

cardinality

CHAPTER-2

 OWL-S: Semantic Markup for Web Services

17
OWL-Web Ontology Language

1.2 Abstract[1
7]

The Semantic Web should enable greater access not only to content but also to services on the
Web. Users and software agents should be able to discover, invoke, compose, and monitor Web
resources offering particular services and having particular properties, and should be able to do so
with a high degree of automation if desired. Powerful tools should be enabled by service
descriptions, across the Web service lifecycle. OWL-S (formerly DAML-S) is an ontology of
services that makes these functionalities possible. In this document we describe the overall
structure of the ontology and its three main parts: 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.

Following the layered approach to markup language development, the current version of OWL-S
builds on the Ontology Web Language (OWL) Recommendation produced by theWeb-Ontology
Working Group at the World Wide Web Consortium (W3C).

2.1 Introduction: Services on the Semantic Web

Efforts toward the creation of the Semantic Web are gaining momentum [1]. Soon it will be
possible to access Web resources by content rather than just by keywords. A significant force in
this movement is the development of a new generation of Web markup languages such as
OWL[16] and its predecessor DAML+OIL [7,9]. These languages enable the creation of
ontologies for any domain and the instantiation of these ontologies in the description of specific
Web sites. These languages are also amenable to efficient reasoning procedures and thus reasoning
applications can be built to automatically determine the logical consequences of the ontological
statements.

Among the most important Web resources are those that provide services. By ``service'' we mean
Web sites that do not merely provide static information but allow one to effect some action or
change in the world, such as the sale of a product or the control of a physical device. The Semantic

18
OWL-Web Ontology Language

Web should enable users to locate, select, employ, compose, and monitor Web-based services
automatically.

To make use of a Web service, a software agent needs a computer-interpretable description of the
service, and the means by which it is accessed. An important goal for Semantic Web markup
languages, then, is to establish a framework within which these descriptions are made and shared.
Web sites should be able to employ a standard ontology, consisting of a set of basic classes and
properties, for declaring and describing services, and the ontology structuring mechanisms of
OWL provide an appropriate, Web-compatible representation language framework within which to
do this.

2.2 Some Motivating Tasks [16]

We will be considering both simple, or ``atomic'' services, and complex or "composite" services.
Atomic services are ones where a single Web-accessible computer program, sensor, or device is
invoked by a request message, performs its task and perhaps produces a single response to the
requester. With atomic services there is no ongoing interaction between the user and the service.
For example, a service that returns a postal code or the longitude and latitude when given an
address would be in this category. In contrast, complex or 'composite' services are composed of
multiple more primitive services, and may require an extended interaction or conversation between
the requester and the set of services that are being utilized. One's interaction with
[Link] to buy a book is like this; the user searches for books by various criteria,
perhaps reads reviews, may or may not decide to buy, and gives credit card and mailing
information. OWL-S is meant to support both categories of services, but complex services have
motivated many of the ontology's elements. The following three task types will give the reader an
idea of the kinds of tasks we expect OWL-S to enable [17,18].

1. Automatic Web service discovery. Automatic Web service discovery is an automated

process for location of Web services that can provide a particular class of service
capabilities, while adhering to some client-specified constraints. For example, the user may
want to find a service that sells airline tickets between two given cities and accepts a

19
OWL-Web Ontology Language

particular credit card. Currently, this task must be performed by a human who might use a
search engine to find a service, read the Web page, and execute the service manually, to
determine if it satisfies the constraints. With OWL-S markup of services, the information
necessary for Web service discovery could be specified as computer-interpretable semantic
markup at the service Web sites, and a service registry or ontology-enhanced search engine
could be used to locate the services automatically. Alternatively, a server could proactively
advertise itself in OWL-S with a service registry, also called middle agent [4,25,15], so that
requesters can find it when they query the registry. Thus, OWL-S enables declarative
advertisements of service properties and capabilities that can be used for automatic service
discovery.
2. Automatic Web service invocation. Automatic Web service invocation is the automatic
invocation of an Web service by a computer program or agent, given only a declarative
description of that service, as opposed to when the agent has been pre-programmed to be
able to call that particular service. This is required,for example, so that a user can request
the purchase, from a site found by searching and then selected by that user, of an airline
ticket on a particular flight. Execution of a Web service can be thought of as a collection of
remote procedure calls. OWL-S markup of Web services provides a declarative, computer-
interpretable API that includes the semantics of the arguments to be specified when
executing these calls, and the semantics of that is returned in messages when the services
succeed or fail. A software agent should be able to interpret this markup to understand what
input is necessary to invoke the service, and what information will be returned. OWL-S, in
conjunction with domain ontologies specified in OWL, provides standard means of
specifying declaratively APIs for Web services that enable this kind of automated Web
service execution.
3. Automatic Web service composition and interoperation. This task involves the
automatic selection, composition, and interoperation of Web services to perform some
complex task, given a high-level description of an objective. For example, the user may
want to make all the travel arrangements for a trip to a conference. Currently, the user must
select the Web services, specify the composition manually, and make sure that any software
needed for the interoperation of services that must share information is custom-created.
With OWL-S markup of Web services, the information necessary to select and compose

20
OWL-Web Ontology Language

services will be encoded at the service Web sites. Software can be written to manipulate
these representations, together with a specification of the objectives of the task, to achieve
the task automatically. To support this, OWL-S provides declarative specifications of the
prerequisites and consequences of application of individual services , and a language for
describing service compositions and data flow interactions.

Any Web-accessible program/sensor/device that is declared as a service will be regarded as a

service. OWL-S does not preclude declaring simple, static Web pages to be services. But our
primary motivation in defining OWL-S has been to support more complex tasks of the kinds
described above.

2.3 An Upper Ontology for Services

Our structuring of the ontology of services is motivated by the need to provide three essential types
of knowledge about a service (shown in Figure 1), each characterized by the question it answers:

 What does the service provide for prospective clients? The answer to this question is given
in the "profile2," which is used to advertise the service. To capture this perspective, each
instance of the class Service presents a ServiceProfile.
 How is it used? The answer to this question is given in the "process model." This
perspective is captured by the ServiceModel class. Instances of the class Service use the
property describedBy to refer to the service's ServiceModel.
 How does one interact with it? The answer to this question is given in the "grounding." A
grounding provides the needed details about transport protocols. Instances of the class
Service have a supports property referring to a ServiceGrounding.

The class Service provides an organizational point of reference for a declared Web service; one
instance of Service will exist for each distinct published service. The properties presents,
describedBy, and supports are properties of Service. The classes ServiceProfile, ServiceModel, and
ServiceGrounding are the respective ranges of those properties. Each instance of Service will
present a ServiceProfile description, be describedBy a ServiceModel description, and support a
ServiceGrounding description. The details of profiles, models, and groundings may vary widely

21
OWL-Web Ontology Language

from one type of service to another--that is, from one instance of Service to another. But each of
these three service perspectives provides an essential type of information about the service, as we
explain below.

Generally speaking, the ServiceProfile provides the information needed for an agent to discover a
service, while the ServiceModel and ServiceGrounding, taken together, provide enough
information for an agent to make use of a service, once found.

Figure 1: Top level of the service ontology

The service profile tells "what the service does", in a way that is suitable for a service-seeking
agent (or matchmaking agent acting on behalf of a service-seeking agent) to determine whether the
service meets its needs. This form of representation includes a description of what is accomplished
by the service, limitations on service applicability and quality of service, and requirements that the
service requester must satisfy to use the service successfully.

The service model tells a client how to use the service, by detailing the semantic content of
requests, the conditions under which particular outcomes will occur, and, where necessary, the step
by step processes leading to those outcomes. That is, it describes how to ask for the service and
what happens when the service is carried out. For nontrivial services (those composed of several
steps over time), this description may be used by a service-seeking agent in at least four different
ways: (1) to perform a more in-depth analysis of whether the service meets its needs; (2) to
compose service descriptions from multiple services to perform a specific task; (3) during the

22
OWL-Web Ontology Language

course of the service enactment, to coordinate the activities of the different participants; and (4) to
monitor the execution of the service.

A service grounding ("grounding" for short) specifies the details of how an agent can access a
service. Typically a grounding will specify a communication protocol, message formats, and other
service-specific details such as port numbers used in contacting the service. In addition, the
grounding must specify, for each semantic type of input or output specified in the ServiceModel,
an unambiguous way of exchanging data elements of that type with the service (that is, the
serialization techniques employed).

The upper ontology for services specifies only two cardinality constraints: a service can be
described by at most one service model, and a grounding must be associated with exactly one
service. The upper ontology deliberately does not specify any minimum cardinality for the
properties presents or describedBy. (Although, in principle, a service needs all three properties to
be fully characterized, it is easy to imagine situations in which a partial characterization could be
useful.) Nor does the upper ontology specify any maximum cardinality for presents or supports. (It
will be extremely useful for some services to offer multiple profiles and/or multiple groundings.)

Finally, it must be noted that while we define one particular upper ontology for profiles, one for
service models, and one for groundings, nevertheless OWL-S allows for the construction of
alternative approaches in each case. Our intent here is not to prescribe a single approach in each of
the three areas, but rather to provide default approaches that will be useful for the majority of
cases. In the following three sections we discuss the resulting service profile, service model, and
service grounding in greater detail.

2.4 Service Profiles[1]

A transaction in a web services marketplace involves three parties: the service requesters, the
service provider, and infrastructure components [24,25]. The service requester, which may broadly
identify with the buyer, seeks a service to complete its work; the service provider, which can be
broadly identified with the seller, provides a service sought by the requester. In an open
environment such as the Internet, the requester may not know ahead of time of the existence of the

23
OWL-Web Ontology Language

provider, so the requester relies on infrastructure components that act like registries to find the
appropriate provider. For instance, a requester may need a news service that reports stock quotes
with no delay with respect to the market. The role of the registries is to match the request with the
offers of service providers to identify which of them is the best match. Within the OWL-S
framework, the Service Profile provides a way to describe the services offered by the providers,

[Link] Service Profile

The class ServiceProfile provides a superclass of every type of high-level description of the
service. ServiceProfile does not mandate any representation of services, but it mandates the basic
information to link any instance of profile with an instance of service.

There is a two-way relation between a service and a profile, so that a service can be related to a
profile and a profile to a service. These relations are expressed by the properties presents and
presentedBy.

presents
describes a relation between an instance of service and an instance of profile, it basically
says that the service is described by the profile.
presentedBy
is the inverse of presents; it specifies that a given profile describes a service.

[Link] Service Name, Contacts and Description

Some properties of the profile provide human-readable information that is unlikely to be

automatically processed. These properties include serviceName, textDescription and
contactInformation. A profile may have at most one service name and text description, but as many
items of contact information as the provider wants to offer.

serviceName
refers to the name of the service that is being offered. It can be used as an identifier of the
service.

24
OWL-Web Ontology Language

textDescription
provides a brief description of the service. It summarizes what the service offers, it
describes what the service requires to work, and it indicates any additional information that
the compiler of the profile wants to share with the receivers.
contactInformation
provides a mechanism of referring to humans or individuals responsible for the service (or
some aspect of the service). The range of this property is unspecified within OWL-S, but
can be restricted to some other ontology, such as FOAF, VCard, or the now depreciated
Actor class provided in previous versions of OWL-S.

The Profile ontology defines the following properties of the Profile class for pointing to IOPE's:

hasParameter
ranges over a Parameter instance of the Process ontology. Note that the Parameter class
models our intuition that Inputs and Outputs (which are kinds of Parameters) are both
involved in information transformation and therefore they are different from Preconditions
and Effects. As a consequence, we do not expect this class to be instantiated. It's role is
solely making domain knowledge explicit.
hasInput
ranges over instances of Inputs as defined in the Process Ontology.
hasOutput
ranges over instances of type Output, as defined in the Process ontology.
hasPrecondition
specifies one of the preconditions of the service and ranges over a Precondition instance
defined according to the schema in the Process ontology.
hasResult
specifies one of the results of the service, as defined by the Result class in the Process
ontology. It specifies under what conditions the outputs are generated. Furthermore, the
Result specifies what domain changes are produced during the execution of the service.

See Figure 2, which shows selected classes and properties of the Profile.

25
OWL-Web Ontology Language

Figure 2: Selected classes and properties of the Profile

[Link] Profile Attributes

CHAPTER-3

26
OWL-Web Ontology Language

2 M
od
eli
ng
Se
rv
ice
s
as
Pr
oc
es
se
s

Atomic and Simple Processes [5]

We are now ready to formalize the classes of processes: atomic, composite, and, not mentioned
before, ``simple.''

27
OWL-Web Ontology Language

<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>

See Figure 3, which shows selected classes and properties of the process model.

Figure 3: Top level of the process ontology

28
OWL-Web Ontology Language

Atomic processes correspond to the actions a service can perform by engaging it in a single
interaction; composite processes correspond to actions that require multi-step protocols and/or
multiple server actions; finally, simple processes provide an abstraction mechanism to provide
multiple views of the same process. Atomic processes are directly invocable (by passing them the
appropriate messages). Atomic processes have no subprocesses and execute in a single step, as far
as the service requester is concerned. That is, they take an input message, do something, and then
return their output message

<owl:Class rdf:ID="AtomicProcess">
<owl:subClassOf rdf:resource="#Process"/>
</owl:Class>

Simple processes are not invocable and are not associated with a grounding, but, like atomic
processes, they are conceived of as having single-step executions. Simple processes are used as
elements of abstraction; a simple process may be used either to provide a view of (a specialized
way of using) some atomic process, or a simplified representation of some composite process (for
purposes of planning and reasoning). In the former case, the simple process is realizedBy the atomic
process; in the latter case, the simple process expandsTo the composite process (see below).

Finally, for an atomic process, there are always only two participants, TheClient and TheServer:

<owl:Class rdf:about="#AtomicProcess">

Grounding a Service to a Concrete Realization

The grounding of a service specifies the details of how to access the service - details having mainly
to do with protocol and message formats, serialization, transport, and addressing. A grounding can
be thought of as a mapping from an abstract to a concrete specification of those service description
elements that are required for interacting with the service - in particular, for our purposes, the
inputs and outputs of atomic processes. Note that in OWL-S, both the ServiceProfile and the

29
OWL-Web Ontology Language

ServiceModel are thought of as abstract representations; only the ServiceGrounding deals with the
concrete level of specification.

6.1 Relationships between OWL-S and WSDL [10]

The approach described here allows a service developer, who is going to provide service
descriptions for use by potential clients, to take advantage of the complementary strengths of these
two specification languages. On the one hand (the abstract side of a service specification), the
developer benefits by making use of OWL-S' process model, and the expressiveness of OWL's
class typing mechanisms, relative to what XML Schema Definition (XSD) provides. On the other
hand (the concrete side), the developer benefits from the opportunity to reuse the extensive work
done in WSDL (and related languages such as SOAP), and software support for message
exchanges based on these declarations, as defined to date for various protocols and transport
mechanisms.

Figure 4: Mapping between OWL-S and WSDL

30
OWL-Web Ontology Language

We emphasize that an OWL-S/WSDL grounding involves a complementary use of the two

languages, in a way that is in accord with the intentions of the authors of WSDL. Both languages
are required for the full specification of a grounding, because the two languages do not cover the
same conceptual space. As indicated by Figure 4, the two languages do overlap in providing for the
specification of what WSDL calls ``abstract types'', which in turn are used to characterize the
inputs and outputs of services. WSDL, by default, specifies abstract types using XML Schema,
whereas OWL-S allows for the definition of abstract types as (description logic-based) OWL
classes 4. However, WSDL/XSD is unable to express the semantics of an OWL class. Similarly,
OWL-S has no means, as currently defined, to express the binding information that WSDL
captures. Thus, it is natural that a OWL-S/WSDL grounding uses OWL classes as the abstract
types of message parts declared in WSDL, and then relies on WSDL binding constructs to specify
the formatting of the messages.

31
OWL-Web Ontology Language

AN OWL-S/WSDL grounding is based upon the following three correspondences between OWL-
S and WSDL. Figure 4 shows the first two of these.

1. AN OWL-S atomic process corresponds to a WSDL (1.1) operation. Different types of

operations are related to OWL-S processes as follows:
o An atomic process with both inputs and outputs corresponds to a WSDL request-
response operation.
o An atomic process with inputs, but no outputs, corresponds to a WSDL one-way
operation.
o An atomic process with outputs, but no inputs, corresponds to a WSDL notification
operation.
o A composite process with both outputs and inputs, and with the sending of outputs
specified as coming before the reception of inputs, corresponds to WSDL's solicit-
response operation.5

Note that OWL-S grounding doesn't mandate a one-to-one correspondence between an

atomic process and a single WSDL operation (although that is the most normal case). To
accommodate the WSDL-supported practice of providing multiple definitions (within
different port types) of the same operation, OWL-S allows for a one-to-many
correspondence between an atomic process and multiple WSDL operations. It is also
possible, in these situations, to maintain a one-to-one correspondence, by using multiple
(differently named) atomic processes.

2. The set of inputs and the set of outputs of an OWL-S atomic process each correspond to
WSDL's concept of message. More precisely, OWL-S inputs correspond to the parts of an
input message of a WSDL operation, and OWL-S outputs correspond to the parts of an
output message of a WSDL operation.
3. The types (OWL classes) of the inputs and outputs of an OWL-S atomic process
correspond to WSDL's extensible notion of abstract type (and, as such, may be used in
WSDL specifications of message parts).

32
OWL-Web Ontology Language

To construct an OWL-S/WSDL grounding one must first identify, in WSDL, the messages and
operations by which an atomic process may be accessed, and then specify correspondences (1) -
(3).

AtomicProcess

The atomic processes are directly invocable (by passing them the appropriate messages). Atomic
processes have no subprocesses, and execute in a single step, from the perspective of the service
requester. That is, they take an input message, execute, and then return their output message -- and
the service requester has no visibility into the service's execution. For each atomic process, there
must be provided a grounding that enables a service requester to construct these messages, as
explained in Section 6.

<owl:Class rdf:ID="AtomicProcess">
<owl:subClassOf rdf:resource="#Process"/>
</owl:Class>

SimpleProcess

Simple processes are not invocable and are not associated with a grounding, but, like atomic
processes, they are conceived of as having single-step executions. Simple processes are used as
elements of abstraction; a simple process may be used either to provide a view of (a specialized
way of using) some atomic process, or a simplified representation of some composite process (for
purposes of planning and reasoning). In the former case, the simple process is realizedBy the
atomic process; in the latter case, the simple process expandsTo the composite process.

<owl:Class rdf:ID="SimpleProcess">
<rdfs:subClassOf rdf:resource="#Process"/>
</owl:Class>

<rdf:Property rdf:ID="realizedBy">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#AtomicProcess"/>
<owl:inverseOf rdf:resource="#realizes"/>
</rdf:Property>

<rdf:Property rdf:ID="expandsTo">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#CompositeProcess"/>
<owl:inverseOf rdf:resource="#collapsesTo"/>
</rdf:Property>

CompositeProcess

Composite processes are decomposable into other (non-composite or composite) processes; their
decomposition can be specified by using control constructs such as SEQUENCE and IF-THEN-ELSE,

33
OWL-Web Ontology Language

which are discussed below. Such a decomposition normally shows, among other things, how the
various inputs of the process are accepted by particular subprocesses, and how its various outputs
are returned by particular subprocesses.

<owl:Class rdf:ID="CompositeProcess">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Process"/>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#composedOf"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>

A process can often be viewed at different levels of granularity, either as a primitive,

undecomposable process or as a composite process. These are sometimes referred to as ``black
box'' and ``glass box'' views, respectively. Either perspective may be the more useful in some given
context. When a composite process is viewed as a black box, a simple process can be used to
represent this. In this case, the relationship between the simple and composite is represented using
the expandsTo property, and its inverse, the collapsesTo property. The declaration of expandsTo is
shown above, with SIMPLEPROCESS.

A COMPOSITEPROCESS must have a composedOf property by which is indicated the control

structure of the composite, using a CONTROLCONSTRUCT.

<rdf:Property rdf:ID="composedOf">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</rdf:Property>

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

Each control construct, in turn, is associated with an additional property called components to
indicate the ordering and conditional execution of the subprocesses (or control constructs) from
which it is composed. For instance, the control construct, SEQUENCE, has a components property
that ranges over a PROCESSCOMPONENTLIST (a list whose items are restricted to be
PROCESSCOMPONENTs, which are either processes or control constructs).

<rdf:Property rdf:ID="components">
<rdfs:comment>
Holds the specific arrangement of subprocesses.
</rdfs:comment>
<rdfs:domain rdf:resource="#ControlConstruct"/>
</rdf:Property>

<owl:Class rdf:ID="ProcessComponent">
<rdfs:comment>
A ProcessComponent is either a Process or a ControlConstruct.

34
OWL-Web Ontology Language

</rdfs:comment>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Process"/>
<owl:Class rdf:about="#ControlConstruct"/>
</owl:unionOf>
</owl:Class>

In the process upper ontology, we have included a minimal set of control constructs that can be
specialized to describe a variety of Web services. This minimal set consists of Sequence, Split,
Split + Join, Choice, Unordered, Condition, If-Then-Else, Iterate, Repeat-While, and Repeat-Until.

Fig:5-Top level of Process Ontology

Sequence
: A list of Processes to be done in order. We use a OWL restriction to restrict the
components of a Sequence to be a List of process components -- which may be either
processes (atomic, simple and/or composite) or control constructs.
<owl:Class rdf:ID="Sequence">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>

35
OWL-Web Ontology Language

<owl:onProperty rdf:resource="#components"/>
<owl:toClass rdf:resource="#ProcessComponentList"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

Split
: The components of a Split process are a bag of process components to be executed
concurrently. No further specification about waiting or synchronization is made at this
level.
<owl:Class rdf:ID="Split">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:toClass rdf:resource="#ProcessComponentBag"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

Split+Join
: Here the process consists of concurrent execution of a bunch of process components with
barrier synchronization. With SPLIT and SPLIT+JOIN, we can define processes that have
partial synchronization (e.g., split all and join some sub-bag).
Unordered
: Allows the process components (specified as a bag) to be executed in some unspecified
order, or concurrently. All components must be executed. As with Split+Join, completion of
all components is required. Note that, while the unordered construct itself gives no
constraints on the order of execution, nevertheless, in some cases, there may be constraints
associated with subcomponents, which must be respected.

Examples:

1. If all process components are atomic processes, any ordering is permitted. For
instance, (Unordered a b)could result in the execution of a followed by b, or b
followed by a.
2. Let a, b, c, and d be atomic processes, and X, Y, and Z be composite processes:
3. X = (Sequence a b)
4. Y = (Sequence c d)
5. Z = (Unordered X Y)

Z, then, translates to the following partial ordering:

{(a;b), (c;d)}

where ';' means ``executes before'', and the possible execution sequences (total
orders) include

36
OWL-Web Ontology Language

{(a;b;c;d), (a;c;b;d), (a;c;d;b), (a;c;d;b),

(c;d;a;b), (c;a;d;b), (c;a;b;d)}

Choice
: CHOICE is a control construct with additional properties chosen and chooseFrom. These
properties can be used both for process and execution control (e.g., choose from
chooseFrom and do chosen in sequence, or choose from chooseFrom and do chosen in
parallel) as well for constructing new subclasses like ``choose at least n from m'', ``choose
exactly n from m'', ``choose at most n from m'',5and so on.
If-Then-Else
: The IF-THEN-ELSE class is a control construct that has properties ifCondition, then and
else holding different aspects of the IF-THEN-ELSE. Its semantics is intended as ``Test If-
condition; if True do Then, if False do Else.'' (Note that the class CONDITION, which is a
placeholder for further work, will be defined as a class of logical expressions.)
<rdf:Property rdf:ID="ifCondition">
<rdfs:comment> The if condition of an if-then-else </rdfs:comment>
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range> rdf:resource ="#Condition" </rdfs:range>
</rdf:Property>

<rdf:Property rdf:ID="then">
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range rdf:resource="#ProcessComponent"/>
</rdf:Property>

<rdf:Property rdf:ID="else">
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range rdf:resource="#ProcessComponent"/>
</rdf:Property>

Iterate
: ITERATE is a control construct whose nextProcessComponent property has the same value
as the current process component. REPEAT is defined as a synonym of the ITERATE class.
The repeat/iterate process makes no assumption about how many iterations are made or
when to initiate, terminate, or resume. The initiation, termination or maintenance condition
could be specified with a whileCondition or an untilCondition as below.6
Repeat-Until

Version Information

37
OWL-Web Ontology Language

This version:
[Link]

Latest version:
[Link]

Previous version:
[Link]

Future Directions

38
OWL-Web Ontology Language

Change Log Since Last Call Release [4]

 Added owl:Nothing to OWL Lite.
 Added pointer to last call document under title
 Changed all links to owl-absyn to owl-semantics
 Incorporated Lee Lacy's grammatical comments from public-webont-comments dated April
21, 2003.
 Incorporated Lee Lacy's other comments: annotation properties, version properties, and
other missing tags in 2.2 (which got reorganised as a result)
 changed hasOffSpring example to hasDaughter (request of Morten Frederiksen)
 incorporated all Lasilla's comment, including replacing "machine readability" by "machine
interpretability" and various typo's.

Change Log Since Candidate Recommendation

 Added Change Log since candidate recommendation.
 Deleted Control Ms at the end of all lines.
 Incorporated Jeff Rafter's public webont comments.
 Updated Status, Document links, date of publication, etc. according to PR email from chair.

Change Log Since Proposed Recommendation

 Two broken links fixed - W3C icon was referenced by referring to local W3c expansion
src="OWL Web Ontology Language Overview_files/ as was gif for author. Added full
expansion to W3C icon ([Link] and email gif
([Link]
 Removed control Ms at the end of every line introduced with new version transfer.
 Added links to previous version in December 2003.

Conclusion

39
OWL-Web Ontology Language

This seminar provides an overview of the Web Ontology Language by providing a brief
introduction to why one might need a Web ontology language and how OWL fits in with related
W3C languages. It also provides a brief description of the three OWL sublanguages: OWL Lite,
OWL DL, and OWL Full along with a feature synopsis for each of the languages.

The Semantic Web should enable greater access not only to content but also to services on the
Web. Users and software agents should be able to discover, invoke, compose, and monitor Web
resources offering particular services and having particular properties

The Semantic Web is a vision for the future of the Web in which information is given explicit
meaning, making it easier for machines to automatically process and integrate information
available on the Web. The Semantic Web will build on XML's ability to define customized tagging
schemes and RDF's flexible approach to representing data. The first level above RDF required for
the Semantic Web is an ontology language what can formally describe the meaning of terminology
used in Web documents. If machines are expected to perform useful reasoning tasks on these
documents, the language must go beyond the basic semantics of RDF Schema.

Glossary

40
 OWL-Web Ontology Language

1. Ontology : An ontology defines the terms used to describe and represent an area of knowledge.
Ontologies are used by people, databases, and applications that need to share domain information
(a domain is just a specific subject area or area of knowledge, like medicine, tool manufacturing,
real estate, automobile repair, financial management, etc.). Ontologies include computer-usable
definitions of basic concepts in the domain and the relationships among them . They encode
knowledge in a domain and also knowledge that spans domains. In this way, they make that
knowledge reusable.

The word ontology has been used to describe artifacts with different degrees of structure. These
range from simple taxonomies (such as the Yahoo hierarchy), to metadata schemes (such as the
Dublin Core), to logical theories. The Semantic Web needs ontologies with a significant degree of
structure. These need to specify descriptions for the following kinds of concepts:

 Classes (general things) in the many domains of interest

 The relationships that can exist among things
 The properties (or attributes) those things may have

2. XML provides a surface syntax for structured documents, but imposes no semantic constraints on
the meaning of these documents.
3. XML Schema is a language for restricting the structure of XML documents and also extends
XML with datatypes.

4. RDF is a datamodel for objects ("resources") and relations between them, provides a simple
semantics for this datamodel, and these datamodels can be represented in an XML syntax.

5. RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a
semantics for generalization-hierarchies of such properties and classes.

41
OWL-Web Ontology Language

References
1. [Link]
2. T. Berners-Lee, J. Hendler, and O. Lassila.
The Semantic Web. Scientific American
3. [Link]
4. [Link]
5. [Link]
6. [Link]
7. [Link]
8. IEEE Intelligent Systems, 15(6):72-73, 2001.
9. [Link]
10. [Link]
11. [Link] .
12. [Link] .
13. [Link] .
14. [Link]
15. [Link]
16. [Link]
17. [Link] 2003.

42