Docstoc

describing the semantics of web

Document Sample
describing the semantics of web Powered By Docstoc
					     IST-2103 STP Artemis                   21/07/2013




Artemis Deliverable D3.1.1.2: Review of the
State-of-the-Art – Semantic Web and Web
Service Semantics


                               07-April-2004




     D3.1.1.2-v1.2                     Page 1 of 55
IST-2103 STP Artemis                                                                      21/07/2013



Document Name:                   Artemis Deliverable D3.1.1.2: Review of the State-of-the-Art-
                                 Semantic Web and Web Service Semantics

Project Number:                  IST-2103 STP Artemis

Project Name:                    A Semantic Web Service-based P2P Infrastructure for the
                                 Interoperability of Medical Information systems

Project Dates:                   Project Start Date: January 1, 2004
                                 Project End Date: June 30, 2006
                                 Project Duration: 30 months

Responsible Partner:             METU-SRDC

Partners Contributing:           ALTEC

Document Author/s:               METU-SRDC, ALTEC

Document Editors:                Artemis Consortium

Document Reference               D3.1.1.2-v1.2
Number:
Due Date:                        April 1, 2004
Delivery Date:                   April 7, 2004
Circulation:                     Public


Short Description: This document presents a survey of Semantic Web Initiative of W3C, Web
Service Semantics and Ontology Mapping



Artemis Consortium Contacts:

Organisation     Name             Phone               Fax                 E-Mail
METU-SRDC        Asuman Dogac     +90 312 2105598     +90 312 2101004     asuman@srdc.metu.edu.tr
OFFIS            Marco Eichelberg +49 441 9722 147    +49 441 9722 102    eichelberg@offis.de
SEBT             Leslie Finlay    +44 28 90565261     +44 28 90565806     leslie.finlay@sebt.n-i.nhs.uk
ALTEC            Adamantios       +30 2310 595659     +30 2310 595630     akou@altec.gr
                 Koumpis
Tepe             Bulent Kunac     +90 312 2919100     +90 312 2662998     bkunac@tepeteknoloji.com.tr
Technology
IT Innovation    Mike Boniface    +44 23 8076 0834    +44 23 8076 0833    mjb@it-
                                                                          innovation.soton.ac.uk




D3.1.1.2-v1.2                                                                       Page 2 of 55
IST-2103 STP Artemis                                            21/07/2013


Document History:

Version   Date         Changes                     From         Review

1.0       05.03.2004   Initial draft               METU-SRDC    All partners

1.1       29.03.2004   Formatted                   METU-SRDC    All partners

1.2       02.04.2004   METU added ALTEC Comments   METU-        All Partners
                                                   SRDC/ALTEC




D3.1.1.2-v1.2                                              Page 3 of 55
IST-2103 STP Artemis                                                                                                    21/07/2013




Table of contents

Artemis Deliverable D3.1.1.2: Review of the State-of-the-Art – Semantic Web and Web
Service Semantics ................................................................................................................1
1 ABSTRACT ................................................................................................................5
2 DESCRIBING THE SEMANTICS OF WEB ..........................................................5
  2.1      Introduction..........................................................................................................5
  2.2      Ontology ..............................................................................................................7
  2.3      Ontology Representation Languages .................................................................10
     2.3.1      First generation Ontology languages .........................................................10
     2.3.2      XML based ontology languages ................................................................10
     2.3.3      Ontologies languages comparison .............................................................11
  2.4      Resource Description Framework (RDF) ..........................................................13
     2.4.1      Statements about Statements .....................................................................16
     2.4.2      RDF Schema ..............................................................................................17
     2.4.3      RDF Tools..................................................................................................18
     2.4.4      RDF Syntax and Schema Summary...........................................................19
     2.4.5      Dublin Core................................................................................................20
  2.5      Web Ontology Language, OWL ........................................................................21
     2.5.1      The Motivation of the Need for Web Ontology Language........................22
     2.5.2      OWL Language Basics ..............................................................................23
     2.5.3      OWL Lite Features ....................................................................................24
     2.5.4      Incremental Language Description of OWL DL and OWL FULL ...........27
3 DESCRIBING THE SEMANTICS OF WEB SERVICES...................................27
  3.1      Introduction........................................................................................................27
  3.2      OWL-S...............................................................................................................30
     3.2.1      OWL-S Service Profile ..............................................................................31
     3.2.2      OWL-S Service Model ..............................................................................32
     3.2.3      OWL-S Service Grounding .......................................................................33
  3.3      Exploiting Service Semantics in Registries through Ontology Languages .......34
4 ONTOLOGY MAPPING .........................................................................................36
  4.1      Introduction........................................................................................................36
  4.2      Discovery ...........................................................................................................38
  4.3      Representation ...................................................................................................40
     4.3.1      RDFT .........................................................................................................41
     4.3.2      Knowledge Management Tool...................................................................41
     4.3.3      MAFRA .....................................................................................................42
  4.4      Execution ...........................................................................................................43
  4.5      MAFRA Architecture ........................................................................................43
     4.5.1      Horizontal Dimension of MAFRA ............................................................44
     4.5.2      Vertical Dimension of MAFRA ................................................................45
  4.6      Example Mapping With MAFRA......................................................................45
5 REFERENCES ........................................................................................................51




D3.1.1.2-v1.2                                                                                                   Page 4 of 55
IST-2103 STP Artemis                                                                       21/07/2013




1   ABSTRACT
This document presents a survey of Semantic Web initiative of World Wide Web Consortium,
and Web Service Semantics. The Semantic Web is an extension of the current web in which
information is given well-defined meaning, better enabling computers and people to work in
cooperation. One of the most important initiatives for describing the semantic of Web resources is
the Resource Description Framework (RDF) developed by the World Wide Web Consortium. On
top of RDF, World Wide Web Consortium has proposed OWL, Web Ontology Language, for
facilitating greater machine interpretability of Web content incorporating lessons learned from the
design and application of DAML+OIL. This document presents a survey of the aims of the
Semantic Web initiative together with these Ontology Languages.

When looking towards the future of Web services, it is predicted that a breakthrough will come
when the software agents start using the Web services rather than the users who need to browse,
discover and compose the services. Providing the semantic of Web services gives the software
agents the capability to discover and compose Web services. By observing that the Semantic Web
should enable greater access not only to content of the Web but also to services on the Web, a
semantic markup language for web services, OWL-S (previously DAML-S), has been developed
based on OWL.

Ontologies are widely used in Semantic Web. For each domain, that would be nice to have an
ontology which whole world agreed upon, However, the distributed development of ontologies
has led to a number of ontologies covering the same or overlapping domains. Ontology mapping
is a solution to interoperate applications using ontologies which are covering the same or
overlapping domains. Mapping is to define functional relationships between the ontologies, and
translating the instance of one ontology to another at runtime.

In this document a survey of the studies on defining the Semantics of Web Services, and
Ontology Mapping will be presented. The information presented in both Semantic Web and Web
Service Semantics chapter are mainly based on the book of one of the editors, namely “B2B e-
Commerce Technology: Frameworks, Standards and Emerging Issues" (in preparation)
by Asuman Dogac and Ibrahim Cingil” [DogacBook].

2   DESCRIBING THE SEMANTICS OF WEB

    2.1   Introduction
The World Wide Web is originally built for human consumption. Although everything on the
Web is machine-readable, they are not machine-understandable. Considering the volume of
information available on the Web, it is not possible to deal with it manually. This lack of means
for applications to automatically process and meaningfully share information on the Web,
constitutes one of the main barriers to the so called “Semantic Web” [Berners-Lee et al., 2001].

In order to fully exploit the opportunities brought by Web, metadata (semantic representation) of
the resources need to be made explicit to make it automatically processable. Metadata can be
defined as “structured data about data”. For example, library card catalogs represent a well-
established type of metadata that help discovering resources like books and journals in the
libraries.



D3.1.1.2-v1.2                                                                        Page 5 of 55
IST-2103 STP Artemis                                                                          21/07/2013

If Web sites publish their metadata then search engines or software agents can easily extract and
aggregate information from different sites. The agents can use this information to provide
meaningful information to the users or as input data to other programs. For any piece of data to be
automatically processable, first it has to have a well defined format.

A well-defined metadata description language gives the ability to automatically process the
description to obtain the metadata. However to interpret the metadata automatically through a
program or a software agent, its meaning (semantics) must also be known. Meaning of data is
given through domain specific ontologies. An ontology is a schema for a domain, in other words,
it is the explicit formal specification of the terms in the domain and relations among them.

There have been serious efforts in defining the languages to describe the semantic of Web
resources. We can divide these efforts as the first generation ontology languages and the XML
based ontology languages. The first generation ontology languages include KIF [Genesereth
1992], Loom [MacGregor 1991], OCML [Motta 1999], FLogic [Kifer 1995], and SHOE [Luke
2000] which will be presented in the following section 2.3.1.

One of the most important initiatives for describing the semantic of Web resources among the
XML based ontology languages is the Resource Description Framework (RDF) developed by the
World Wide Web Consortium [W3C]. RDF fixes the syntax and structure of describing metadata
through RDF Syntax [RDF Syntax,1999 ] and it allows meaning to be defined and associated
with data through RDF Schema [RDF Schema,1999 ], which gives facilities to define domain
specific ontologies.

Although Resource Description Framework provides good building blocks for defining a
Semantic Web Markup Language, it lacks expressive power. For example, it is not possible to
restrict the range of properties locally to a class definition, necessary and sufficient conditions for
class membership, equivalence and disjointness of classes. The only constraints expressible in
RDF are the domain/range constraints on properties.

On the other hand, the next-generation Web, which is called the “Semantic Web” [Berners-Lee et
al.,2001] aims at providing access to structured collections of information and sets of inference
rules that the computers an use to conduct automated reasoning. The challenge of the “Semantic
Web” is to provide a language that expresses both data and rules for reasoning about the data and
that allows rules from any existing knowledge-representation system to be exported onto the
Web.

Recently, there have been several efforts that build upon RDF with more artificial intelligence
inspired knowledge representation languages. An important initiative is by [DARPA] which
created DARPA Agent Markup Language [DAML, 2000]. DAML is an ontology and inference
language based on RDF. The DAML group later joined efforts with the Ontology Inference Layer
[OIL], another initiative providing more sophisticated classification, using constructs from frame-
based AI. The result is [DAML+OIL, 2001], a language for expressing far more sophisticated
classifications and properties of resources than RDF Schema. DAML+OIL also adds facilities for
data typing based on the type definitions provided in the W3C XML Schema Definition
Language [XML Schema,1999 ].

By observing that the Semantic Web should enable greater access not only to content but also to
services on the Web, a semantic markup for web services, based on DAML+OIL, has also been
defined in [DAML-S, 2001]. Recently, World Wide Web Consortium [W3C] has proposed OWL,
Web Ontology Language, [OWL, 2003] for facilitating greater machine interpretability of Web


D3.1.1.2-v1.2                                                                           Page 6 of 55
IST-2103 STP Artemis                                                                        21/07/2013

content. It should be noted that OWL is a revision of the DAML+OIL web ontology language
incorporating lessons learned from the design and application of DAML+OIL.

In this chapter we aim to provide insight to RDF and OWL but also present the other initiatives
shortly. We first explain the ontology concept and then give explanatory information about the
existing ontology languages. Lastly we provide details in RDF and an important RDFschema,
namely Dublin Core [DC, 1998]. We then describe OWL through simple examples. These
examples are useful to give a flavor of these efforts, but a framework is necessary to describe how
the pieces are put together to demonstrate the real use of RDF and OWL. We provide this in
Chapter 3 which develops a comprehensive framework for describing the semantics of Web
services.

    2.2   Ontology
The word ontology comes from the Greek “ontos” for “being” and “logos” for “word”. It is a
relatively new term in the long history of philosophy, introduced by the 19th century German
philosophers to distinguish the study of being as such from the study of various kinds of beings in
the natural sciences [Sowa, 1999].

The subject of ontology is the study of the categories of things that exist or may exist in some
domain. The product of such a study, called an ontology, is a catalog of the types of things that
are assumed to exist in a domain of interest. In other words, an ontology is an explicit
specification of a conceptualization. It provides a formal specification of the terms in a domain
and relations among them. A conceptualization is an abstract, simplified view of the world that
we wish to represent for some purpose. A typical ontology has a taxonomy and a set of inference
rules. Using ontologies, tomorrow’s applications can be more “intelligent”, in the sense that they
will come closer to the human conceptual level than they are today.

An ontology is generally composed of the following items:
    a formal explicit description of concepts in a domain of discourse (i.e. classes which are
       also called concepts),
    properties of each concept describing various features and attributes of the concept (i.e.
       slots which are also called roles or properties) and,
    restrictions on slots (i.e. facets which are also called role restrictions).

An ontology together with a set of individual instances of classes constitutes a knowledge base.
The knowledge included in an ontology can be shared because the use of this knowledge is
consensual, that is, it has been accepted by a group, not by a single individual.

In practical terms, developing an ontology includes [Noy and McGuinness]:
     defining classes in the ontology,
     arranging the classes in a taxonomic (subclass-superclass) hierarchy,
     defining properties (i.e. slots) and describing allowed values (facets) for these slots,
     filling in the values for slots for instances.




D3.1.1.2-v1.2                                                                         Page 7 of 55
IST-2103 STP Artemis                                                                          21/07/2013



                                      Person
                                        name
                                        SSID


               Patient                                      Healthcare
                                                             Provider
                                                              position
                ongoing
               Problems                                     department




                                           Physician                             Nurse
                                               specialty



        Figure 1 An example of a simplified Ontology describing the players in Medical Domain



Classes describe concepts in the domain. For example, a class of students may represent all
students. Specific students are instances of this class. A class can have subclasses that represent
concepts that are more specific than the superclass. For example, as shown in Figure 1 we can
divide the players in Healthcare domain into “patient” and “provider” classes. Slots describe
properties of classes and instances. For example, a “person” class may have properties such as
“name”, “SSID” and these slots are attached to the “person” class. Note that a slot should be
attached at the most general class that can have that property. For example, the “name” property
should be attached to “person”, not to its subclass, say “patient”. On the other hand, an
“ongoingProblems” property should be attached to “patient” class, not to the “person” class, since
it only exists for patients, not for Healthcare Provider.

Slots can have different facets describing the value type, allowed values, the number of the values
(cardinality), and other features of the values the slot can take. A value-type facet describes what
types of values can fill in the slot. The common value types are as follows:

        String is a value type which is used for slots such as “John” as the name of a patient.
        Number (sometimes more specific value types of Float and Integer are used) describes
         slots with numeric values.
        Boolean slots are simple yes-no flags.
        Enumerated slots specify a list of specific allowed values for the slot.
        Instance-type slots allow slot values to be instances of other classes. For example, the
         “ongoingProblems” property of the class “patient” could be another class “Problems”.
         Allowed classes for slots of type Instance are often called the range of a slot. For
         example, the class Problems is the range of the “ongoingProblems” slot. The classes to
         which a slot is attached are called the domain of that slot. The Patient class is the domain
         of the “ongoingProblems” slot. The basic rules for determining a domain and a range of a
         slot are similar: When defining a domain or a range for a slot, the most general classes or
         class should be the domain or the range for the slots. It is not advisable, unless essential,
         to specify the range of the slot as THING, which is the most general class in an ontology.



D3.1.1.2-v1.2                                                                          Page 8 of 55
IST-2103 STP Artemis                                                                       21/07/2013

Some systems let the user to define multiple inheritances, and still others require disjoint sub
classes to be defined.

Inference rules in ontologies supply further power. An ontology may express a rule ``If person B
is the parent of person C, and if the parent of B is A, then person A is an ancestor of person C".
Then, an inference engine, such as Prolog [Colmeraurer and Kanoui, 1973], [Colmeraurer and
Roussel, 1993], [GNU Prolog] or JESS [Jess], can run on the instances of a given ontology to
determine, say, the ancestors of people.

Ontologies are usually expressed in a logic-based language, so that detailed, accurate, consistent,
sound, and meaningful distinctions can be made among the classes, properties, and relations.
Inference engines than can perform automated reasoning using the ontologies, and thus provide
advanced services to intelligent applications such as: conceptual/semantic search and retrieval,
software agents, decision support, speech and natural language understanding, knowledge
management, intelligent databases, and electronic commerce.

Ontologies figure prominently in the emerging Semantic Web as a way of representing the
semantics of documents and enabling the semantics to be used by web applications and intelligent
agents. Ontologies can prove very useful for a community as a way of structuring and defining
the meaning of the metadata terms that are currently being collected and standardized. Using
ontologies, tomorrow's applications can be "intelligent," in the sense that they can more
accurately work at the human conceptual level [OWL, 2004].

There are libraries of reusable ontologies on the Web and in the literature such as the Ontolingua
ontology library [OntoLingua, 1997], or the DAML ontology library [DAML Ontology]. There
are also a number of publicly available commercial ontologies such as [UNSPSC] and
[RosettaNet].

It also worths noting a software tool, [Chimaera, 2000], which supports users in creating and
maintaining distributed ontologies on the Web. Two major functions it provides are helping users
to merge multiple ontologies together and diagnosing individual or multiple ontologies. It
supports users in such tasks as loading knowledge bases in different formats, reorganizing
taxonomies, resolving name conflicts, browsing ontologies, and editing terms.

Another ontology tool is Protégé, [Protege, 2000] which allows the user to construct a domain
ontology, customize knowledge-acquisition forms and enter domain knowledge.

[Noy and McGuinness] gives an excellent tutorial on how to develop ontologies.

In order for ontologies to have the maximum impact, they need to be widely shared. In order to
minimize the intellectual effort involved in developing an ontology they need to be re-used. In the
best of all possible worlds they need to be composed and mapped to each other. There is a
considerable amount of research in Ontology Mapping which will br further elaborated in section
4.




D3.1.1.2-v1.2                                                                        Page 9 of 55
IST-2103 STP Artemis                                                                        21/07/2013


    2.3   Ontology Representation Languages

2.3.1 First generation Ontology languages
KIF [Genesereth 1992] is a language based on first order logic created in 1992 as an interchange
format for diverse KR systems. Ontolingua [Gruber 1993], which builds on KIF, was developed
in 1992 by the KSL at Stanford University. It combines the KR paradigms of frames and first
order predicate calculus (KIF). It is the most expressive of all the languages that have been used
for representing ontologies, allowing the representation of concepts, taxonomies of concepts, n-
ary relations, functions, axioms, instances and procedures. Its high expressiveness led to
difficulties in building reasoning mechanisms for it. Hence, no reasoning support is provided with
the language.

Loom [MacGregor 1991] was developed simultaneously with Ontolingua at the Information
Science Institute (ISI) at the University of South California. Initially, it was not meant for
implementing ontologies, but for general KBs. Loom is based on DLs and production rules, and
provides automatic classifications of concepts. The following ontology components can be
represented with this language: concepts, concept taxonomies, n-ary relations, functions, axioms
and production rules.

OCML [Motta 1999] was developed later, in 1993, at the KMI at the Open University. It was
created as a kind of ‘‘operational Ontolingua’’. In fact, most of the definitions that can be
expressed in OCML are similar to the corresponding definitions in Ontolingua, and some
additional components can be defined: deductive and production rules, and operational definitions
for functions. OCML was built for developing executable ontologies and models in problem
solving methods.

FLogic [Kifer 1995] was developed in 1995 at the Karlsruhe University. FLogic (Frame Logic)
combines frames and first order logic, allowing representing concepts, concept taxonomies,
binary relations, functions, instances, axioms and deductive rules. FLogic is the only of the
previous languages that do not have Lisp-like syntax. Its inference engine, Ontobroker [Decker
1999] , can be used for constraint checking and deducting new information.

In Spring 1997, the High Performance Knowledge Base program (HPKB) started. This research
program was sponsored by DARPA, and its objective was to solve many of the problems that
usually appear when dealing with large KBs (concerning efficiency, content creation, and
integration of the content available in different systems, etc.). One of the results of this program
was the development of the OKBC (Open Knowledge Base Connectivity) protocol . This
protocol allows accessing KBs stored in different knowledge representation systems (KRSs). Of
the systems presented before, Ontolingua and LOOM are OKBC compliant.

SHOE [Luke 2000] was built in 1996 as an extension of HTML, in the University of Maryland. It
uses tags different from those of the HTML specification, thus it allows the insertion of
ontologies in HTML documents. SHOE combines frames and rules. SHOE just allows
representing concepts, their taxonomies, n-ary relations, instances and deduction rules, which are
used by its inference engine to obtain new knowledge.

2.3.2 XML based ontology languages
XOL [Karp 1999] was developed by the AI center of SRI international, in 1999, as a XMLization
of a small subset of primitives from the OKBC protocol, called OKBC-Lite. It is a very restricted
language where only concepts, concept taxonomies and binary relations can be specified. No


D3.1.1.2-v1.2                                                                       Page 10 of 55
IST-2103 STP Artemis                                                                       21/07/2013

inference mechanisms are attached to it, as it was mainly designed for the exchange of ontologies
in the biomedical domain.

RDF [Lassila 1999] was developed by the W3C (the World Wide Web Consortium) as a
semantic-network based language to describe Web resources. RDF Schema was built by the W3C
as an extension to RDF with frame-based primitives. The combination of both RDF and RDF
Schema is normally known as RDF(S). RDF(S) is not very expressive, just allowing the
representation of concepts, concept taxonomies and binary relations. Some inference engines
have been created for this language, mainly for constraint checking.

These languages have established the foundations of the Semantic Web. In this context, three
more languages have been developed as extensions to RDF(S): OIL, DAML+OIL and OWL.

OIL [Horrocks 2000] was developed in the framework of the European IST project On-To-
Knowledge. It adds frame-based KR primitives to RDF(S), and its formal semantics is based on
DLs. The FaCT classifier is used to perform automatic classifications of concepts.

DAML-ONT specification was released some time later in the context of the DARPA initiative
DAML (DARPA Agent Markup Language). On December 2000, it was upgraded to DAML+OIL
[40], which was created by a joint committee from the US and the EU in the context of the
DARPA project DAML. DAML+OIL also adds DL-based KR primitives to RDF(S). Both OIL
and DAML+OIL allow representing concepts, taxonomies, binary relations, functions and
instances. Many efforts are being put to provide reasoning mechanisms for DAML+OIL.

Finally, in 2001, the W3C formed a working group called Web-Ontology (WebOnt) Working
Group. 7 The aim of this group was to make a new ontology markup language for the Semantic
Web, called OWL (Web Ontology Language). They have already defined a list of main use cases
for the Semantic Web, have taken DAML+OIL features as the main input for developing OWL
and have proposed the first specification of this language.


2.3.3 Ontologies languages comparison
As a conclusion of this section Table 1 presents some important features for the formalization of
ontologies. The table present which of this languages support this feature (with the symbol “+”)
or not (with the symbol “-”). Also in cases that a language supports a feature but not directly we
use the symbol “(+)”


                 Onto-   OCML      LOOM      Flogic   XOL    SHOE     RDF(S)    OIL    DAML      OWL
                 ligua
Concepts
General Issues
Metaclasses      +       +         +         +        +      -        +         -      -         -
Partitions       +       (+)       +         (+)      -      -        -         +      +         +
Documentation    +       +         +         (+)      +      +        +         +      +         +
Attributes
Template         +       +         +         +        +      +        +         +      +         +
Class      own   +       +         +         +        +      -        -         +      +         +
Attributes
Local Scope      +       +         +         +        +      +        +         +      +         +
Global Scope     (+)     (+)       +         -        +      -        +         +      +         +


D3.1.1.2-v1.2                                                                       Page 11 of 55
IST-2103 STP Artemis                                                                        21/07/2013


Facets
Default     slot   -        +         +       +        +      -       -          -      -        -
value
Type               +        +         +       +        +      +       +          +      +        +
Constraint
Cardinality        +        +         +       (+)      +      -       -          +      +        +
Slot Docum.        +        +         +       -        +      +       +          +      +        +
Taxonomies
Subclass of        +        +         +       +        +      +       +          +      +        +
Exhaustive         +        (+)       +       (+)      -      -       -          +      +        +
subclass
partitions
Disjoint           +        (+)       +       (+)      -      -       -          +      +        +
decompositions
Not subClass       (+)      -         (+)     -        -      -       -          +      +        +
of
Relation      &
Functions
n-ary relations    +        +         +       (+)      (+)    +       (+)        (+)    (+)      (+)
and functions
Type constr.       +        +         +       +        +      +       +          +      +        +
Integrity          +        +         +       +        -      -       -          -      -        -
constr.
Operational        -        +         +       +        -      -       -          -      -        -
def.
Axioms
First      order   +        +         +       +        -      (+)     -          (+)    (+)      (+)
logic
Second order       +        -         -       -        -      -       -          -      -        -
logic
Named axioms       +        +         -       -        -      -       -          -      -        -
Embedded           +        +         +       -        -      -       -          -      -        -
axioms
Instances
Instances     of   +        +         +       +        +      +       +          +      +        +
concepts
Facts              +        +         +       +        +      +       +          +      +        +
Claims             -        -         -       -        -      +       (+)        (+)    (+)      (+)
                       Table 1 Comparison of Ontology Representation Languages


Concepts, organized in taxonomies, binary relations and instances are the only components that
can be represented in all of the presented languages. However, some differences exist in the
primitives available in each language for representing concept taxonomies. In this sense,
Ontolingua, LOOM, OCML, OIL, DAML+OIL and OWL are more expressive, since they allow
creating exhaustive and disjoint subclass partitions of a concept.

In Ontolingua and SHOE, arbitrary n-ary relations can be created. In the rest of languages, these
relations must be represented by their decomposition into binary relations.




D3.1.1.2-v1.2                                                                        Page 12 of 55
IST-2103 STP Artemis                                                                       21/07/2013

Functions can be defined easily in Ontolingua, LOOM, OCML, OIL, DAML+OIL and OWL. In
FLogic they can be created by defining a relation and an additional axiom that restricts the
number of values that it can have.

Formal axioms are the most powerful means of representing knowledge in ontologies, and they
are usually used to represent those pieces of knowledge that cannot be represented with other
primitives of the language. Formal axioms can be defined in Ontolingua, LOOM, OCML and
FLogic.

Finally, rules can only be defined in LOOM and OCML, and procedures can only be defined in
Ontolingua (although they cannot be executed), LOOM and OCML.

Concerning the inference mechanisms attached to each language, they are diverse. Except for the
OIL inference engine (FaCT), inference engines are used to deduce new knowledge from the
ontology or check inconsistencies with its formal axioms. In LOOM and OIL, the inference
engine also performs automatic concept classifications.

In summary, KR paradigms underlying all the languages are diverse: frames, DLs, first (and
second) order predicate calculus, conceptual graphs, semantic networks, production rules,
deductive rules, etc. In many cases, they are based on combinations of several formalisms.

Additionally, there is a tight interdependence between expressiveness and reasoning in all the
languages, in the sense that the expressive power of a language must be sometimes limited to
ensure a good reasoning service.

    2.4    Resource Description Framework (RDF)
The Resource Description Framework [RDF Syntax, 1999], [RDF Schema, 1999] provides a
general-purpose language for representing information in the World Wide Web. It is particularly
intended for representing metadata about Web resources, and it provides a common framework
for expressing this information in such a way that it can be exchanged between applications
without loss of meaning.

The basic RDF data model expressing the syntax and structure consists of three object types:
resources which are the things being described by RDF, properties which are specific aspects,
attributes or relations describing a resource and statements that assign a value to a property of a
resource.

<?xml version = "1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/rdf-syntax-ns#"
xmlns:dc="http://dublincore.org/documents/dces/">
<rdf:Description about = "http://www.srdc.metu.edu.tr/eCatalog">
<dc:Creator>ABC Company</dc:Creator>
<dc:Date>April 23, 2002</dc:Date>
</rdf:Description>
</rdf:RDF>
                               Figure 2 An Example RDF Description


A resource can be any object that is uniquely identifiable by an Uniform Resource Identifier
[URI]. For example, “http://www.srdc.metu.edu.tr/eCatalog” is a resource in Figure 2.



D3.1.1.2-v1.2                                                                      Page 13 of 55
IST-2103 STP Artemis                                                                       21/07/2013

Values may be atomic in nature or can be other resources, which in turn may have their own
properties. A value can just be a string, for example “ABC Company” or it can be another
resource, for example “http://www.srdc.metu.edu.tr/Privacy”. A collection of these properties that
refers to the same resource is called a description. The RDF data model provides an abstract,
conceptual framework; a concrete syntax is also required and XML is used for this purpose.

Consider, for example, the description given in Figure 2 which states that the “ABC Company”
is the creator of the indicated electronic catalog. In this RDF description, a resource, namely,
“http://www.srdc.metu.edu.tr/eCatalog” is being described by giving a value, “ABC Company” to
its “dc:Creator” property. Notice that rdf:RDF tag marks the beginning and end of the description
document. rdf:Description tag envelopes the description of the resource. dc:Creator is a property
of this resource. The resource “http://www.srdc.metu.edu.tr/eCatalog”, its property dc:Creator
and the value “ABC Company” constitutes an RDF statement.



                         http://www.srdc.metu.edu.tr/eCatalog

                      dc:Creator                                 dc:Date
              ABC Company                                     April 23, 2002



            Figure 3 Graph representation of the example RDF Description in Figure 2
In fact, RDF models descriptions and statements in terms of a directed graph consisting of nodes
and arcs. The nodes describe resources, and properties represented by directed arcs that connect
subject nodes to object nodes. A property arc is interpreted as an attribute, relationship or
predicate of the resource, with a value given by the object node. Figure 3 shows the graph
representation of the sample RDF description given in Figure 2.

The namespace URI in a namespace declaration, like xmlns:rdf=``http://www.w3.org/1999/rdf-
syntax-ns" in the example of Figure 2, is a globally unique identifier for a particular schema, and
it indicates that rdf:Description tag is defined in this schema.

The <rdf:RDF> tag tells us that this is an RDF description, that is, we (or a software program) is
informed that an RDF statement will follow with a well-defined syntax. However to understand
the meaning of this description we need to know what “dc:Creator” means. For the dc:Creator
element, its meaning may be intuitive, but the meaning of the dc:Date is not clear: it could be the
date publishing the catalog, or the date of catalog expiry or something else.

Therefore meaning in RDF is expressed through a reference to an application-specific schema,
which defines the terms that will be used in RDF statements and gives specific meanings to them.
That is, RDF does not stipulate semantics for each resource description community, but rather
provides the ability for these communities to define metadata elements as needed. Individual
resource description communities define the semantics, or meaning of metadata that addresses
their particular needs using RDF Schema Specification mechanisms [Miller, 1998a]. The XML
namespace mechanism [Namespaces in XML] serves to identify RDF Schemas. The “dc” in the
example refers to a well-known schema, namely Dublin Core [DC,1998 ] which will be discussed
in Section 2.4.5.


D3.1.1.2-v1.2                                                                      Page 14 of 55
IST-2103 STP Artemis                                                                           21/07/2013



Once the meanings of the attributes are known, this description becomes machine processable.
Any program (having a prior knowledge of the syntax and semantics of RDF, in this case) can
parse the description, extract meta-data, interpret it and use it for its purposes. Note however that
even when an application knows only the RDF Syntax and has no understanding of a particular
schema will still be able to parse the description into the property-type and corresponding values
and will still be able to deduce that a resource is being described with a certain property and a
property value.

There could be any number of statements in a description and any number of descriptions about
different resources in an RDF document. The description element may have one of the following
two attributes: “about” and “ID” to identify the resource being described. The “about” attribute
names an existing resource to which the description applies. If the resource does not yet exist
(i.e., does not yet have a resource identifier) then the “ID” attribute provides an identifier for the
resource to be described. In other words, the “ID” attribute signals the creation of a new resource
and the “about” attribute refers to an existing resource.

       <?xml version = "1.0"?>
       <rdf:RDF xmlns:rdf="http://www.w3.org/1999/rdf-syntax-ns#"
       xmlns:cs="http://www.srdc.metu.edu.tr/Catalog_Schema#">
       <rdf:Description about="http://www.srdc.metu.edu.tr/eCatalog/Components/C1">
       <cs:made_Up_Of>
       <rdf:Bag>
       <rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P1"/>
       <rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P2"/>
       <rdf:Alternative>
       <rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P3"/>
       <rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P4"/>
       </rdf:Alternative>
       </rdf:Bag>
       </cs:made_Up_Of>
       <cs:Creator>Delphi Company</cs:Creator>
       </rdf:Description>
       </rdf:RDF>

               Figure 4 An example RDF Description illustrating the use of Containers


Frequently it is necessary to refer to a collection of resources. In this respect, RDF Syntax
provides the container facilities consisting of Bag, Sequence, and Alternative container objects. A
Sequence and a Bag represent sets; whereas Alternative represents an element. More precisely, a
Sequence is an ordered list of resources or literals whereas in a Bag, order is not important. An
Alternative is a list of resources or literals that represents alternatives for a single element. Figure
4 demonstrates the use of containers. In this example, the component C1 is made up of parts P1,
P2 and P3, and part P4 is a substitute for P3, and the meaning of “cs:made_Up_Of” tag is given in
the schema provided at “http://www.srdc.metu.edu.tr/Catalog_Schema#”.

RDF also provides to enumerate the members of a class. An enumeration defines a class by
giving an explicit list of its members. As an example:

<rdfs:Class rdf:ID="ProductAvailability"/>
<ProductAvailability rdf:ID="InStock"/>



D3.1.1.2-v1.2                                                                            Page 15 of 55
IST-2103 STP Artemis                                                                          21/07/2013


<ProductAvailability rdf:ID="OutOfStock"/>
<ProductAvailability rdf:ID="SpecialOrder"/>

Basically, this is just the definition of the instances of the class in the schema. However, exactly
for this reason the enumeration in RDF is not closed, that is anyone can add items to the
enumeration without a restriction. Usually a tight control is needed over the items in an
enumeration, meaning that RDF lacks ways of expressing such a restriction.

2.4.1 Statements about Statements

In addition to making statements about Web resources, RDF can be used for making statements
about other RDF statements; in other words, RDF allows a form of reification. In order to make a
statement about another statement, that is, to express a belief about a statement to be true or false,
it is necessary to model the original statement as a reified statement.

To model reified statements, RDF defines the following properties:
    subject: The subject property identifies the resource being described by the modeled
      statement; the value of this property is the resource about which the original statement
      was made.
    predicate: The predicate property identifies the original property in the modeled
      statement; that is, the value of the predicate property is a resource representing the
      specific property in the original statement.
    object: The object property identifies the property value in the modeled statement; that is,
      the value of the object property is the object in the original statement.
    type: The value of the type property describes the type of the new resource. All reified
      statements are instances of RDF:Statement; that is, they have a type property whose
      object is RDF:Statement.

A new resource with the above four properties represents the original statement and can both be
used as the object of other statements and have additional statements made about it. The resource
with these four properties is not a replacement for the original statement; it is a model of the
statement. A statement and its corresponding reified statement exist independently in an RDF
graph and either may be present without the other.

Consider, for example, the resource described in Figure 4. To express the fact that the Web Site
Administrator of this resource believes that the “Creator” of this resource is “Delphi Company”,
we need to make a statement as shown in Figure 5.

<?xml version = "1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cs="http://www.srdc.metu.edu.tr/Catalog_Schema">
<rdf:Description>
<rdf:subject rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/Components/" />
<rdf:predicate rdf:resource="http://www.srdc.metu.edu.tr/Catalog_Schema/Creator" />
<rdf:object>Delphi Company</rdf:object>
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<cs:attributedTo>Web Site Administrator</cs:attributedTo>
</rdf:Description>
</rdf:RDF>




D3.1.1.2-v1.2                                                                         Page 16 of 55
IST-2103 STP Artemis                                                                        21/07/2013

                  Figure 5 An example of “making Statements about Statements”

2.4.2    RDF Schema

The declaration of properties and their corresponding semantics are defined in the context of RDF
as a schema. [RDF Schema,1999 ] defines a Schema Specification Language for this purpose and
provides a basic type system for use in RDF Models. It defines resources and properties such as
“Class” and “subClassOf” that are used in specifying application-specific schemas.

To be more specific the RDF Schema mechanism defines the following core classes:
     rdfs:Resource: This class is the top class, i.e., all resources are considered to be instances
       of this class.
     rdf:Property: This class represents the subset of RDF resources that are properties.
     rdfs:Class: The class rdfs:Class represents the subset of RDF resources that are classes.
       An RDF schema is organized into a collection of classes.

The RDF Schema mechanism also defines the following core properties:

       rdf:type: This property indicates which class a resource belongs to. Resources may be
        instances of one or more classes by multiple inheritance. Note that when a schema
        defines a new class, the resource representing that class must have an rdf:type property
        whose value is the resource rdfs:Class. The resource known as rdfs:Class is itself a
        resource of rdf:type rdfs:Class.

       rdfs:subClassOf: Classes are often organized in a hierarchy and rdfs:subClassOf property
        is defined to express subclass relationship among classes.
       rdfs:subPropertyOf: This core property specifies that one property is a specialization of
        another.

Property names must be associated with a schema. This can be done by qualifying the element
names with namespace prefixes to unambiguously connect the property definition with the
corresponding RDF schema.

The class hierarchy mechanism provided by RDF is very helpful in defining ontologies which are
much needed in e-commerce applications. The example provided in Figure 6 defines such a class
hierarchy where “Product” is the subclass of the top level class “resource”, and
“Physical_Product” is a subclass of “Product”.

<?xml version = "1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#">
<rdf:Description rdf:ID="Product">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:comment>All kinds of trade Products</rdfs:comment>
<rdfs:label>Product</rdfs:label>
</rdf:Description>
<rdf:Description rdf:ID="Physical_Product">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Product"/>
<rdfs:comment>All kinds of physical products</rdfs:comment>



D3.1.1.2-v1.2                                                                       Page 17 of 55
IST-2103 STP Artemis                                                                        21/07/2013


<rdfs:label>PhysicalProduct</rdfs:label>
</rdf:Description>
</rdf:RDF>

            Figure 6 An example description illustrating the use of SubClassOf Property


An RDF schema can declare constraints associated with classes and properties. In particular, the
concepts of domain and range are used in RDF schemas to make statements about the context in
which certain properties make sense. Range property expresses the fact that the value of a
property should be a resource of a designated class. Assume, for example, we would like to define
user profiles to deliver personalized information to the users on the Web. For this purpose we
define a property called “interested.in”, whose domain is the “user” class, and whose range is the
“subject” class. The definition of this property is provided in Figure 7. A domain constraint
applying to the “interested.in” property expresses that this property may only be used for the
resource class “User” and the range constraint expresses that the value of this attribute must be an
instance of the class “Subject”.

<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#"
<rdf:Description rdf:ID="User">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:label>User</rdfs:label>
<rdfs:comment>Web users</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Subject">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:label>Subject</rdfs:label>
<rdfs:comment>Subject areas</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="interested.in">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-syntax#Property"/>
<rdfs:label>List of subject that a user has been interested</rdfs:label>
<rdfs:domain rdf:resource="#User">
<rdfs:range rdf:resource="#Subject">
<rdfs:comment>This property indicates the subjects that
are of interest to a user </rdfs:comment>
</rdf:Description>
</rdf:RDF>

    Figure 7 An example RDF description illustrating the use of Domain and Range Constraints

2.4.3 RDF Tools

Some of the tools available for processing RDF documents are as follows:

       [RDF API ]defines interfaces for parsing and accessing RDF as sets of statements.
       The Frodo RDFS Visualization tool [Frodo RdfsViz ] provides a visualization service for
        ontologies represented in RDF Schema. It uses the Java RDF API implementation [RDF
        API ], the Xerces XML parser [Xerces ] and the Graphviz graph drawing program


D3.1.1.2-v1.2                                                                       Page 18 of 55
IST-2103 STP Artemis                                                                         21/07/2013

        [Graphviz ]. Additionally, the Frodo RDF-to-Java tool [Frodo RDF2JAVA ] allows RDF
        files to be imported into Java, and Java objects to be exported to RDF files.
       The Karlsruhe Ontology tool suite [KAON ] builds on RDF and provides specialized
        tools for the engineering, discovery, management, and presentation of ontologies and
        metadata. It also provides a mapping tool for ontologies, MAFRA [Maedeche, 2002],
        which will be presented in Section 4.
       [rdfDB ] is intended to be a simple, scalable, open-source database for RDF.
       The ICS-FORTH RDF Suite [Alexaki et al.,2001 ],[ICS-Forth RDF Suite ] software
        tools provide:
             o A Validating RDF Parser supporting semantic validation of both resource
                  descriptions and schemas.
             o An RDF Schema Specific DataBase which uses schema knowledge to
                  automatically generate
             o An Object-Relational representation of RDF metadata and load resource
                  descriptions.
             o A Declarative RDF Query Language for uniformly querying RDF schemas and
                  resource descriptions.
       [Jena ] is a Java API which can be used to create and manipulate RDF graphs. Jena has
        object classes to represent graphs, resources, properties and literals.
       [Redland ] is a library that provides a high-level interface for RDF allowing the RDF
        graph to be parsed from XML, stored, queried and manipulated.
       [Wilbur ] is Nokia Research Center's toolkit for RDF and DAML (and XML), written in
        Common Lisp. Wilbur offers an API for manipulating RDF data (graphs, nodes, etc.) as
        well as parsing functionality. It also provides a simple HTTP client API for accessing
        remote URLs. Wilbur additionally provides a frame system API on top of the RDF data
        API, including a simple query language.
       [IsaViz ] is a visual environment for browsing and authoring RDF models represented as
        graphs.
       [Xpetal] converts Unified Modeling Language [UML] models in Rational Rose [Rational
        Rose ] files to RDF models, HTML reports and XML schemata. Another converter that
        supports automatic translation from UML/XMI to RDFS/RDF/XML is available from
        [UML-RDF ].
       [Sesame] is an RDF Schema-based Repository and Querying facility developed within
        the scope of On-To-Knowledge [On-To-Knowledge ] project.
       Closed World Machine [CWM,2000 ] is a forward chaining reasoner which can be used
        for querying, checking, transforming and filtering information. Its core language is RDF
        which is extended to include rules.


2.4.4 RDF Syntax and Schema Summary

The basic building block in RDF Syntax is an object-attribute-value triple. Any object can play
the role of a value, and thus it is possible to chain the resources. RDF also allows any RDF
statement to be the object or value of a triple, which means resources can be nested as well as
chained [Decker et al.,2000]. Finally, it is possible to indicate that a given object is of a certain
type through rdf:type property.

RDF schema lets developers define a particular vocabulary for RDF data. In other words, the
RDF schema mechanism provides a basic type system for RDF models. This type system uses




D3.1.1.2-v1.2                                                                        Page 19 of 55
IST-2103 STP Artemis                                                                         21/07/2013

some predefined terms, such as Class, subClassOf, subPropertyOf, for defining application
specific schema.

RDF objects can be defined as instances of one or more classes using the type property. The
subClassOf property allows organizing classes in a class hierarchy and subPropertyOf does the
same for properties. Constraints on properties can be specified using domain and range
constructs.

2.4.5 Dublin Core

The RDF Schema specification provides a machine-understandable system for defining
“schemas” for descriptive vocabularies like the Dublin Core [DC,1998]. The DC standard
comprises fifteen elements, the semantics of which have been established through consensus by
an international, cross-disciplinary group of professionals from libraries, computer science, text
encoding, the museum community, and other related fields. The Dublin Core is believed to be
broadly applicable to describing Web resources to enable their discovery. The DC elements and a
brief description of their semantics are given in Table 2, and Figure 8 demonstrates an example
resource described through Dublin Core.

<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax"
xmlns:rds="http://www.w3.org/TR/PR-rdf-schema#"
xmlns:dc="http://purl.org/DC/#"
<rdf:Description about="http://www.srdc.metu.edu.tr/bookstore/catalog.xml">
<dc:Title>METU Virtual Bookstore</dc:Title>
<dc:Subject>electronic catalog, Web, book, business, religion,
history, civilizations, geography, military, armies, weapons,
war, economy, science fiction, romance </dc:Subject>
<dc:Type>Text.Serial.Book</dc:Type>
<dc:Format>text/xml</dc:Format>
<dc:Identifier>"http://www.srdc.metu.edu.tr/bookstore/catalog.rdf"
</dc:Identifier>
<dc:Date>2001-11-05</dc:Date>
<dc:Creator>METU Bookstore</dc:Creator>
<dc:Publisher>METU Bookstore</dc:Publisher>
<dc:Language>
<rdf:Alt>
<rdf:li>Turkish</rdf:li>
<rdf:li>English</rdf:li>
<rdf:li>Chinese</rdf:li>
</rdf:Alt>
</dc:Language>
<dc:Description>This resource contains the electronic catalog of
METU Bookstore in XML </dc:Description>
<dc:Coverage>Global</dc:Coverage>
<rdf:Description>
</rdf:RDF>

              Figure 8 An example resource description using Dublin Core element set


Each element in the DC set is optional and may be repeated. Each element also has a limited set
of qualifiers, attributes that may be used to further refine (not extend) the meaning of the element.


D3.1.1.2-v1.2                                                                        Page 20 of 55
IST-2103 STP Artemis                                                                          21/07/2013

The Dublin Core Metadata Initiative (DCMI) has defined standard ways to “qualify” elements
with various types of qualifiers. A set of recommended qualifiers conforming to DCMI “best
practice” is available, with a formal registry in process [Hillmann,2001 ].

Element                                         Description

Title                                           The title of the resource

Subject                                         Simple keywords or terms taken from a list of
                                                subject headings
Description                                     A description or an abstract
Creator                                         The person or organization primarily responsible for
                                                the intellectual content of the resource

Publisher                                       The publisher

Contributor                                     A secondary contributor to the intellectual content
                                                of the resource

Date                                            A date associated with the relation or availability of
                                                the resource

Type                                            The genre of the resource (home page, thesis,
                                                article, journal, dataset, etc.)

Format                                          Typically a MIME type (e.g. text/html)

Identifier                                      A URL,ISBN,ISSN,URN or other identifier

Source                                          The resource from which the current resource was
                                                derived

Language                                        The language of the resource

Relation                                        An identifier of a second resource and its
                                                relationship to the current resource
Coverage                                        The temporal or spatial characteristics of the
                                                resource

Rights                                          A simple rights statement about the resource


                               Table 2 The Dublin Core elements


    2.5       Web Ontology Language, OWL
The OWL Web Ontology Language is designed for use by applications that need to process the
content of information instead of just presenting information to humans. OWL can be used to
explicitly represent the meaning of terms in vocabularies and the relationships between those
terms as an ontology. OWL facilitates greater machine interpretability of Web content than that
supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along
with a formal semantics. OWL is a revision of the DAML+OIL web ontology language
incorporating lessons learned from the design and application of DAML+OIL [OWL, 2003].


D3.1.1.2-v1.2                                                                        Page 21 of 55
IST-2103 STP Artemis                                                                      21/07/2013


2.5.1 The Motivation of the Need for Web Ontology Language

In [OWL, 2004] W3C has expressed the need for a Web Ontology language on top of the existing
XML, and RDF. These can be summarized as follows: “Ontologies are critical for applications
that want to search across or merge information from diverse communities. Although XML DTDs
and XML Schemas are sufficient for exchanging data between parties who have agreed to
definitions beforehand, their lack of semantics prevent machines from reliably performing this
task given new XML vocabularies. The same term may be used with (sometimes subtle) different
meaning in different contexts, and different terms may be used for items that have the same
meaning. RDF and RDF Schema begin to approach this problem by allowing simple semantics to
be associated with identifiers. With RDF Schema, one can define classes that may have multiple
subclasses and super classes, and can define properties, which may have sub properties, domains,
and ranges. In this sense, RDF Schema is a simple ontology language. However, in order to
achieve interoperation between numerous, autonomously developed and managed schemas, richer
semantics are needed. For example, RDF Schema cannot specify that the Person and Car classes
are disjoint, or that a string quartet has exactly four musicians as members.”

In summary 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.
      XML Schema is a language for restricting the structure of XML documents.
      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.
      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

A number of use cases have been identified where Web Ontology Language can be used in
[OWL, 2004]. These can be summarized as follows:

      Web Portals: A web portal is a web site that provides information content on a common
       topic, for example a specific city or domain of interest. Portals usually provide a simple
       index of subject areas, however this does not provide the community with sufficient
       ability to search for the content that its members require. Ontologies can be designed to
       organize the contents in the Web Portals in order to facilitate their discovery both by the
       humans and software agents.
      Multimedia Collections: Ontologies can be used to provide semantic annotations for
       collections of images, audio, or other non-textual objects. It is even more difficult for
       machines to extract meaningful semantics from multimedia than it is to extract semantics
       from natural language text. Thus, these types of resources are typically indexed by
       captions or metatags. However, since different people can describe these non-textual
       objects in different ways, it is important that the search facilities go beyond simple
       keyword matching. Ideally, the ontologies would capture additional knowledge about the
       domain that can be used to improve retrieval of images.


D3.1.1.2-v1.2                                                                     Page 22 of 55
IST-2103 STP Artemis                                                                       21/07/2013

      Corporate Web Site Management: Large corporations typically have numerous web
       pages concerning things like press releases, product offerings and case studies, corporate
       procedures, internal product briefings and comparisons, white papers, and process
       descriptions. Ontologies can be used to index these documents and provide better means
       of retrieval. Although many large organizations have a taxonomy for organizing their
       information, this is often insufficient. A single ontology is often limiting because the
       constituent categories are likely constrained to those representing one view and one
       granularity of a domain; the ability to simultaneously work with multiple ontologies
       would increase the richness of description. Furthermore, the ability to search on values
       for different parameters is often more useful than a keyword search with taxonomies.
      Design Documentation: Ontologies can be used to build an information model which
       allows the exploration of the information space in terms of the items which are
       represented, the associations between the items, the properties of the items, and the links
       to documentation which describes and defines them (i.e., the external justification for the
       existence of the item in the model). This can be necessary for a large body of engineering
       documentation, such as that used by the aerospace industry. Through such an ontology
       the interrelationships of each document can be stored and managed.
      Agents and Services: OWL can provide agents with the capability to understand and
       integrate diverse information resources and services. A specific example is that of a
       social activities planner, which can take the preferences of a user (such as what kinds of
       films they like, what kind of food they like to eat, etc.) and use this information to plan
       the user's activities for an evening. The task of planning these activities will depend upon
       the richness of the service environment being offered and the needs of the user. Defining
       the services through ontologies will facilitate the service determination / matching
       process. These functionalities can also be provided using other services. For example
       ratings and review services may also be consulted to find closer matches to user
       preferences.
      Web services and Ubiquitous Computing: Ubiquitous computing is an emerging
       paradigm of personal computing, characterized by the shift from dedicated computing
       machinery to pervasive computing capabilities embedded in our everyday environments.
       A key technology of true ad hoc networks is service discovery, functionality by which
       "services" (both the functions offered by various devices such as cell phones, printers,
       sensors, etc. and the services provided as Web services) can be described, advertised, and
       discovered by others. Hence there is a need for a Web Ontology Language to describe the
       characteristics and the functionalities of the services. The exploitation of OWL for Web
       Service Discovery and Composition will further be elaborated in Chapter 3.

2.5.2 OWL Language Basics

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

      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.
      OWL DL supports those users who want the maximum expressiveness while retaining
       computational completeness (all conclusions are guaranteed to be computed) 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



D3.1.1.2-v1.2                                                                      Page 23 of 55
IST-2103 STP Artemis                                                                          21/07/2013

        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.

In this document we will be presenting the features of OWL Lite and state the features of OWL
DL and OWL Full incrementally over OWL Lite.

2.5.3 OWL Lite Features

In OWL Lite, as in RDF, it is possible to define Classes and class/subclass hierarchies in your
domain, and properties of these classes using RDF constructs such as Class, rdfs:subClassOf,
rdfs:Property, rdfs:subPropertyOf, rdfs:subPropertyOf:, rdfs:domain, rdfs:range.

In order for ontologies to have the maximum impact, they need to be widely shared. In order to
minimize the intellectual effort involved in developing an ontology they need to be re-used. In the
best of all possible worlds they need to be composed. To tie together a set of component
ontologies as part of a third it is frequently useful to be able to indicate that a particular class or
property in one ontology is equivalent to a class or property in a second ontology. For stating the
equality/inequality relationships between the Ontology components the following constructs are
available in OWL Lite:

       equivalentClass : Two classes may be stated to be equivalent.
       equivalentProperty: Two properties may be stated to be equivalent
       sameAs: Two individuals may be stated to be the same.
       differentFrom: An individual may be stated to be different from other individuals
       allDifferent: A number of individuals may be stated to be mutually distinct in one
        allDifferent statement.

In OWL Lite it is possible to specify property characteristics, which provides a powerful
mechanism for enhanced reasoning about a property. The following special identifiers can be
used to to provide information concerning properties and their values [OWL Guide] :

       inverseOf: One property may be stated to be the inverse of another property. For example
        if hasPatient is the inverse of hasDoctor and Gokce hasDoctor Dr. Alp, then a reasoner
        can deduce that Dr. Alp hasPatient Gokce.
       TransitiveProperty: Properties may be stated to be transitive. For example, if the part of
        relation is stated to be transitive, and if CardiologyDepartment is a partOf Hospital A
        (i.e., (CardiologyDepartment, Hospital A) is an instance of the property partOf) and
        ElectroCardioLab is partOf CardiologyDepartment (i.e., (ElectroCardioLab,
        CardiologyDepartment) is an instance of the property partOf), then a reasoner can deduce
        that ElectroCardioLab is a partOf Hospital A. OWL Lite (and OWL DL) impose the side
        condition that transitive properties (and their superproperties) cannot have a
        maxCardinality 1 restriction.
       SymmetricProperty: Properties may be stated to be symmetric. For example, roomMate
        may be stated to be a symmetric property. Then a reasoner that is given that Gokce is the
        roomMate of Yildiray can deduce that Yildiray is a roomMate of Gokce.


D3.1.1.2-v1.2                                                                          Page 24 of 55
IST-2103 STP Artemis                                                                         21/07/2013

      FunctionalProperty : Properties may be stated to have a unique value. If a property is a
       FunctionalProperty, then it has no more than one value for each individual (it may have
       no values for an individual). For example, hasInsuranceId may be stated to be a
       FunctionalProperty. From this a reasoner may deduce that no patient may have more than
       one PatientId for an Insurance Company. This does not imply that every Patient must
       have at least one insurance id from an insurance company however
      InverseFunctionalProperty: Properties may be stated to be inverse functional. If a
       property is inverse functional then the inverse of the property is functional. Thus the
       inverse of the property has at most one value for each individual. For example,
       hasPatientId (a unique identifier for the patients of a unique hospital) may be stated to be
       inverse functional (or unambiguous). The inverse of this property (which may be referred
       to as isThePatientIdFor) has at most one value for any patient (for a unique hospital).
       Thus any one patient's patientID is the only value for their isThePatientIdFor property.
       From this a reasoner can deduce that no two different individual instances of Patient have
       the identical patientId in a unique hospital. Also, a reasoner can deduce that if two
       instances of Patient in a unique hospital have the same patientID, then those two
       instances refer to the same individual.

   In addition to designating property characteristics, it is possible to further constrain the range
   of a property in specific contexts in a variety of ways. OWL Lite allows restrictions to be
   placed on how properties can be used by instances of a class. The following two restrictions
   limit which values can be used while the cardinality restrictions limit how many values can
   be used.

      allValuesFrom: The restriction allValuesFrom is stated on a property with respect to a
       class. It means that this property on this particular class has a local range restriction
       associated with it. For example, we may have defined the hasPrimaryDoctor property of a
       Patient with a range of Doctor class. Then we may define a subClass of Patient, namely
       CardiologyPatient for specifying the patients of the Cardiology Department in the
       hospital; and we may define a restriction on the hasPrimaryDoctor (which has been
       inherited to CardiologyPatient from the PatientClass) to have all values from Cardiologist
       Class (Cardiologist is a subClass of Doctor Class). This means that if an individual
       CardiologyPatient Gokce is related by the property hasPrimary to the individual Dr.Alp,
       then from this a reasoner can deduce that Dr.Alp is an instance of the class Cardiologist.
      someValuesFrom: The restriction someValuesFrom is stated on a property with respect
       to a class. A particular class may have a restriction on a property that at least one value
       for that property is of a certain type. For example, the class MedicalInformaticsPaper may
       have a someValuesFrom restriction on the hasKeyword property that states that some
       value for the hasKeyword property should be an instance of the class
       MedicalInformaticsTopic. This allows for the option of having multiple keywords and as
       long as one or more is an instance of the class MedicalInformaticsTopic, then the paper
       would be consistent with the someValuesFrom restriction.

   OWL Lite includes a limited form of cardinality restrictions. OWL Lite cardinality
   restrictions are limited because they only allow statements concerning cardinalities of value 0
   or 1 (they do not allow arbitrary values for cardinality, as is the case in OWL DL and OWL
   Full). This permits the user to indicate 'at least one', 'no more than one', and 'exactly one'.

      minCardinality: Cardinality is stated on a property with respect to a particular class. If a
       minCardinality of 1 is stated on a property with respect to a class, then any instance of



D3.1.1.2-v1.2                                                                        Page 25 of 55
IST-2103 STP Artemis                                                                       21/07/2013

       that class will be related to at least one individual by that property. This restriction is
       another way of saying that the property is required to have a value for all instances of the
       class.
      maxCardinality: Cardinality is stated on a property with respect to a particular class. If a
       maxCardinality of 1 is stated on a property with respect to a class, then any instance of
       that class will be related to at most one individual by that property. A maxCardinality 1
       restriction is sometimes called a functional or unique property.
      cardinality: Cardinality is provided as a convenience when it is useful to state that a
       property on a class has both minCardinality 0 and maxCardinality 0 or both
       minCardinality 1 and maxCardinality 1.

   OWL provides additional constructors with which to form classes. These constructors can be
   used to create so-called class expressions. OWL Lite contains an intersection constructor but
   limits its usage.

      intersectionOf: OWL Lite allows intersections of named classes and restrictions. For
       example, the class InsuredPatient can be described as the intersectionOf Patient and
       InsuredPerson (which could be defined as person that have a minimum cardinality of 1 on
       the hasInsurance property). From this a reasoner may deduce that any particular
       InsuredPatient has at least one Insurance.

In OWL properties are categorized according to whether they relate individuals to individuals
(object properties) or individuals to datatypes (datatype properties). Datatype properties may
range over RDF literals or simple types defined in accordance with XML Schema datatypes
[XSD].

OWL uses most of the built-in XML Schema datatypes. References to these datatypes are by
means of the URI reference for the datatype, http://www.w3.org/2001/XMLSchema. The
following datatypes are recommended for use with OWL:

xsd:string                  xsd:normalizedString          xsd:boolean
xsd:decimal                 xsd:float                     xsd:double
xsd:integer                 xsd:nonNegativeInteger        xsd:positiveInteger
xsd:nonPositiveInteger      xsd:negativeInteger
xsd:long                    xsd:int                       xsd:short                 xsd:byte
xsd:unsignedLong            xsd:unsignedInt               xsd:unsignedShort         xsd:unsignedByte
xsd:hexBinary               xsd:base64Binary
xsd:dateTime                xsd:time                      xsd:date                  xsd:gYearMonth
xsd:gYear                   xsd:gMonthDay                 xsd:gDay                  xsd:gMonth
xsd:anyURI                  xsd:token                     xsd:language
xsd:NMTOKEN                 xsd:Name                      xsd:NCName
                         Table 3 Recommended XML Schema Data types

The datatypes presented in Table 3, plus rdfs:Literal, form the built-in OWL datatypes. Other
built-in XML Schema datatypes may be used in OWL Full.




D3.1.1.2-v1.2                                                                      Page 26 of 55
IST-2103 STP Artemis                                                                        21/07/2013


2.5.4 Incremental Language Description of OWL DL and OWL FULL
Both OWL DL and OWL Full use the same vocabulary although OWL DL is subject to some
restrictions. Roughly, OWL DL requires type separation (a class can not also be an individual or
property, a property can not also be an individual or class). This implies that restrictions cannot
be applied to the language elements of OWL itself (something that is allowed in OWL Full).
Furthermore, OWL DL requires that properties are either ObjectProperties or DatatypeProperties:
DatatypeProperties are relations between instances of classes and RDF literals and XML Schema
datatypes, while ObjectProperties are relations between instances of two classes. We describe the
OWL DL and OWL Full vocabulary that extends the constructions of OWL Lite below.
      oneOf: (enumerated classes): Classes can be described by enumeration of the individuals
         that make up the class. The members of the class are exactly the set of enumerated
         individuals; no more, no less. For example, the class of organisationType for a healtcare
         institution can be described by simply enumerating the individuals hospital, outpatient
         clinic, emergency department, diagnostic department, laboratory service, day care
         service, nursing home, physician’s office, rehabilitation center, residential facility as
         proposed by CEN, ENV13606, Electronic healthcare record communication, DomainTem
         List [ENV13606].
      hasValue: (property values): A property can be required to have a certain individual as a
         value (also sometimes referred to as property values). For example, instances of the class
         of TurkishCitizens can be characterized as those people that have Turkey as a value of
         their nationality. (The nationality value, Turkey, is an instance of the class of
         Nationalities).
      disjointWith: OWL Full allows the statement that classes are disjoint. For example, Man
         and Woman can be stated to be disjoint classes. From this disjointWith statement, a
         reasoner can deduce an inconsistency when an individual is stated to be an instance of
         both and similarly a reasoner can deduce that if A is an instance of Man, then A is not an
         instance of Woman.
      unionOf, complementOf, intersectionOf (Boolean combinations): OWL DL allows
         arbitrary Boolean combinations of classes and restrictions: unionOf, complementOf, and
         intersectionOf. For example, using unionOf, we can state that a class contains things that
         are either USCitizens or EUCitizens. Using complementOf, we could state that children
         are not SeniorCitizens. (i.e. the class Children is a subclass of the complement of
         SeniorCitizens). Citizenship of the European Union could be described as the union of
         the citizenship of all member states.
      minCardinality, maxCardinality, cardinality (full cardinality): While in OWL Lite,
         cardinalities are restricted to at least, at most or exactly 1 or 0, full OWL allows
         cardinality statements for arbitrary non-negative integers.
      complex classes : In many constructs, OWL Lite restricts the syntax to single class names
         (e.g. in subClassOf or equivalentClass statements). OWL Full extends this restriction to
         allow arbitrarily complex class descriptions, consisting of enumerated classes, property
         restrictions, and Boolean combinations. Also, OWL Full allows classes to be used as
         instances (and OWL DL and OWL Lite do not).


3   DESCRIBING THE SEMANTICS OF WEB SERVICES

    3.1   Introduction
Web services, also called e-services, are self-contained, self-describing, modular applications that
can be published, located, and invoked across the Web. Web services perform functions that can
be anything from simple requests to complicated business processes. Once a Web service is


D3.1.1.2-v1.2                                                                       Page 27 of 55
IST-2103 STP Artemis                                                                          21/07/2013

deployed, other applications (and other Web services) can discover and invoke the deployed
service [IBM ’s Tutorial ].

Web Services in contrast to Web sites that merely provide static information, cause some action
or change in the world, such as the sale of a product or the control of a physical device. Web
services can be mixed and matched with other Web services to create business processes and
value chains. There seems to be a consensus that the future of e-business collaboration will be
through Web services.

Recently, there have been a number of initiatives related with web service discovery and
composition lead by IT companies and consortiums like [eSpeak] from HP, [UDDI,2001a] from
IBM and Microsoft, and [ebXML,1999 ] from United Nations/CEFACT and [OASIS,1998]. HP
has developed a platform, called eFlow [Casati and Shan,2001a][Casati and Shan,2001b], for
specifying, enacting, and monitoring composite Web services. Furthermore most of the
application servers available in the market now provide support for Web Service based solutions,
for example BEA Web Logic provides a set of graphical tools for development, search, and
composing of the Web Services with the tool titled “BEA WebLogic Workshop”
[BEAWebLogic].

Well accepted standards like Web Services Description Language [WSDL] and Simple Object
Access Protocol [SOAP] make it possible to dynamically invoke Web services. That is, when the
semantic of the service to be used is known, its WSDL description can be accessed by a program
which uses the information in the WSDL description like the interface, binding and operations to
dynamically access the service. However to be able to exploit the Web services to their full
potential, their semantic information should be available. In this way, not only humans can query
the service registries to discover and compose services, but more importantly, this also opens up
the way for software agents to automatically exploit Web services on behalf of users since formal
semantic descriptions are machine processable. [Dogac, 2004]

A number of taxonomies, such as North American Industrial Classification Scheme [NAICS],
Universal Standard Products and Services Classification [UNSPC] and ISO 3166 [ISO3166] are
being used to discover services in service registries like UDDI or ebXML. Although the terms
“taxonomy” and “ontology” are sometimes used interchangeably there is a critical difference. A
taxonomy indicates only class/subclass relationship whereas an ontology describes a domain
completely. The mechanisms that ontology languages provide include their formal specification
(which allows them to be queried) and their ability to define properties of classes. Through
properties very accurate descriptions of services can be defined and services can be related to
other services or resources. [Dogac, 2002]

To motivate the reader on the need for Web service semantics we first give an example where we
demonstrate the inefficiencies that may be faced in a service registery which does not contain
service semantics.

Consider UDDI registries, currently there are no mechanisms to describe the metadata of services
in UDDI. Assume that a business user in Ankara wishes to buy second hand IBM desktop
computers for the cheapest price that s/he can get, for over a period of time (that is, s/he wishes to
establish a long term business relationship). The user also wishes to find services for possible
products that may add value to the desktop, for example, a scanner. There is a need for the
purchases to be delivered, and therefore complementary services like “delivery” are also
necessary.



D3.1.1.2-v1.2                                                                         Page 28 of 55
IST-2103 STP Artemis                                                                         21/07/2013

This business user can find a standard products and services code (like [UNSPSC]) for desktops
and the geography code for Ankara, and search for businesses in a UDDI registry. However there
are a number of problems in this process:

       First, the user has to go through all the businesses found to check their services. These
        services could be anything related with desktops, not only the services that sell desktops.
        Therefore the user has to go through all the services found to distinguish the ones that
        “sell”desktops. With the projected near-term population of several hundred thousand to
        million distinct entities in a UDDI registry, it is unlikely that even this result set will be
        manageable.

       Second, it is not possible in UDDI to enforce a relationship between the service names
        and their functionality. Note that Web service description languages like [WSDL] only
        provide the signature of the operations of the service, that is, the name, parameters and
        the types of parameters of the service.Trying to discover services by name may not be
        always very meaningful since a service name could be anything and in any language. So
        it is not easy to figure out which of the services in the UDDI registry indeed realize the
        “sell” functionality.

       Third, among the services discovered that sell desktops there is no hint on which of these
        services actually sell “IBM” desktops, since UDDI does not provide a mechanism to
        discover services on the basis of product instances. In other words, although it is possible
        to find the services according to the category of the products, it is not possible to find
        services by giving specific product information like their brand names.

       Notice that the user in the example above is looking for a service that has a property: the
        service should deal with “second hand” products. There is no way to find such services
        since it is not possible to define properties for the services in UDDI.

       Products may have attributes that cannot be defined in product taxonomies like UNSPSC.
        For example given an anchor product, say a desktop, there could be a number of products
        that add value to this product, say a scanner or a printer, and the user may wish to find the
        services related with these products as in the case of our example.

       Since there is no mechanism to define relationships among service types, it is hard to
        identify complementary services. Continuing with our example, the user cannot locate a
        complementary “delivery” service for the reason stated.

These limitations are not inherent in the UDDI specification, but rather stem basically from the
lack of semantic descriptions of the Web services. Currently, describing the semantic of Web in
general [Berners-Lee et al.,2001 ], and semantic of Web services in particular are very active
research areas. There are a number of efforts for describing the semantics of Web services such as
[McIlraith et al., 2001a], [McIlraith et al., 2001b] and [Denker et al., 2001].

W3C has an important initiative in this respect, namely OWL-S, previously DAML-S, Service
Specification [OWL-S], [DAML-S, 2001]. OWL-S is an OWL-based Web service ontology,
which supplies Web service providers with a core set of markup language, constructs for
describing the properties and capabilities of their Web services in unambiguous, computer-
interpretable form. OWL-S will be presented in Section 3.2.




D3.1.1.2-v1.2                                                                         Page 29 of 55
IST-2103 STP Artemis                                                                     21/07/2013

This upper ontology provided by OWL-S need to be extended for specific application domains.
Defining domain specific ontologies in this way, that is by grounding them in upper ontologies
makes them more consistent and it becomes easier to integrate them within distributed
heterogeneous systems. However, there are certain functionalities that are common to all e-
businesses that need to be defined before providing domain specific ontologies:

        Discovering services with complementary functionality: A user may wish to discover
         complementary services. For example, a “Sell” service can complement a “Delivery”
         service. To facilitate their discovery, a standard property, for example an “addOn”
         property, should be defined to describe such complementary services.

        Finding services according to the properties of services or products:Given an anchor
         product, a customer may be interested in products that add value to this product. As an
         example, a customer willing to buy a “computer”, may also need complementary
         products such as a “scanner” or a “ups”, and may therefore be interested in finding
         services providing these products. This necessitates using product ontologies in
         conjunction with the service ontologies. Also services themseves may have properties;
         for example a “sell” service may be dealing with only “second hand” products; or a
         “payment” service may have properties such as “Credit Card Payment”. Since such
         properties are common to most of the services; it would be more meaningful to define
         them at the upper levels of the ontology, rather than requiring each domain to specify
         these common properties by themselves.

        Relating the services with electronic catalogs: For example a user may not only wish to
         rent a car but a specific model like “Chevrolet Model 1956”. Unless the instances of a
         “Car_Rental_Service” provide a standard way to access electronic catalogs, providing the
         user what he wants in an automated way may become impossible.



   3.2     OWL-S

OWL-S (formerly DAML-S) is "an OWL Web service ontology which supplies Web service
providers with a core set of markup language constructs for describing the properties and
capabilities of their Web services in unambiguous, computer-interpretable form. OWL-S markup
of Web services aims to facilitate the automation of Web service tasks including automated Web
service discovery, execution, interoperation, composition and execution monitoring [OWL-S].

OWL-S classifies the Web Services in to two categories as:
     “primitive” in the sense that they invoke only a single Web-accessible computer program,
        sensor, or device that does not rely upon another Web service, and there is no ongoing
        interaction between the user and the service, beyond a simple response.
     “complex” that are composed of multiple primitive services, often requiring an
        interaction or conversation between the user and the services, so that the user can make
        choices and provide information conditionally.
OWL-S is meant to support both categories of services, in order to facilitate the following
functionalities:
1. Automatic Web service discovery involves the automatic location of Web services that
    provide a particular service and that adhere to requested constraints.
2. Automatic Web service invocation involves the automatic execution of an identified Web
    service by a computer program or a software agent.


D3.1.1.2-v1.2                                                                     Page 30 of 55
IST-2103 STP Artemis                                                                        21/07/2013

3. Automatic Web service composition and interoperation involves the automatic selection,
   composition and interoperation of Web services to perform some tasks, given a high-level
   description of an objective.
4. Automatic Web service execution monitoring: Individual services and, even more,
   compositions of services, will often require some time to execute completely. Users may
   want to know during this period what the status of their request is, or their plans may have
   changed requiring alterations in the actions the software agent takes.

However, only the first two functionalities are for giving semantics to Web Services. Therefore in
this document we focus OWL-S from the semantics of Web Services point of view. The
composition functionality is elaborated in the document including the Web Service composition
(Deliverable 3.1.1 Web Service Technologies State of Art).

OWL-S provides an upper ontology for Service definition (Figure 9). The top level class in this
ontology is the “Service” class.

Service class has the following three properties:
     presents: The range of this property is ServiceProfile class. That is, the class Service
        presents a ServiceProfile to specify what the service provides for its users as well as what
        the service requires from its users.
     describedBy: The range of this property is ServiceModel class. That is, the class Service
        is describedBy a ServiceModel to specify how it works.
     supports: The range of this property is ServiceGrounding. That is, the class Service
        supports a ServiceGrounding to specify how it is used.


        Product             provides                 Service
                            presents                                    supports

                                                 describedBy
                    ServiceProfile                                       ServiceGrounding

                                                 ServiceModel
            What the                                                            How to
            service does                                                        access it
                                                     How it works



                           Figure 9 OWL-S Top Level Service Ontology

3.2.1 OWL-S Service Profile

The service profile tells “what the service does”; that is, it gives the types of information needed
by a service-seeking agent (or matchmaking agent acting on behalf of a service-seeking agent) to
determine whether the service meets its needs. In addition to representing the capabilities of a
service, the profile can be used to express the needs of the service-seeking agent, so that a
matchmaker has a convenient dual-purpose representation upon which to base its operations.


D3.1.1.2-v1.2                                                                       Page 31 of 55
IST-2103 STP Artemis                                                                         21/07/2013

The class ServiceProfile provides a superclass of every type of high-level description of the
service. The information that can be represented in a ServiceProfile can be summarized as
follows:

       Some properties of the profile provide human-readable information that is unlikely to be
        automatically processed. These properties include serviceName, textDescription and
        contactInformation.
       An essential component of the profile is the specification of what functionality the service
        provides and the specification of the conditions that must be satisfied for a successful
        result. In addition, the profile specifies what conditions result from the service, including
        the expected and unexpected results of the service activity. The OWL-S Profile represents
        two aspects of the functionality of the service: the information transformation
        (represented by inputs and outputs) and the state change produced by the execution of the
        service (represented by preconditions and effects). These are represented with the
        hasParameter, hasInput, hasOutput, hasPrecondition and hasEffect properties.
       Additional attributes of the service such as the quality the service is guaranteeing, can be
        represented using the serviceParameter property.
       Within the ServiceProfile, it is possible to specify the possible classification of the
        service using the serviceCategory property. As a range of the property, the taxonomy, its
        code and value can be specified.

3.2.2 OWL-S Service Model
The service model tells “how the service works”; that is, it describes 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 course of the service
enactment, to coordinate the activities of the different participants; and (4) to monitor the
execution of the service. These details can be provided using the ProcessModel which has been
defined as a subclass of ServiceModel.




D3.1.1.2-v1.2                                                                        Page 32 of 55
IST-2103 STP Artemis                                                                        21/07/2013




                          Figure 10 OWL-S Top Level Process Ontology



The Top level class in this ontology, the Process Class, has related properties hasParameter,
hasInput, hasOutput, hasPrecondition, and hasEffect, which range over classes Parameter, Input,
ConditionalOutput, Precondition, and ConditionalEffect, respectively. The “Process” Class is
classified in to three categories: Atomic, Simple, Composite Processes.

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. 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. Composite processes are decomposable into other (non-
composite or composite) processes; their decomposition can be specified by using control
constructs such as Sequence, Split, Split+Join, Unordered, Choice, If-Then-Else, Iterate, and
Repeat-Until.


3.2.3 OWL-S Service Grounding

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



D3.1.1.2-v1.2                                                                       Page 33 of 55
IST-2103 STP Artemis                                                                       21/07/2013

ServiceProfile and the ServiceModel are thought of as abstract representations; only the
ServiceGrounding deals with the concrete level of specification. The central function of an OWL-
S grounding is to show how the (abstract) inputs and outputs of an atomic process are to be
realized concretely as messages, which carry those inputs and outputs in some specific
transmittable format.

Since there exists a significant body of work in the area of concrete message specification, which
is already well along in terms of industry adoption, namely Web Services Description Language
[WSDL], OWL-S has chosen to use WSDL as a basis for OWL-S Service Grounding.

    3.3    Exploiting Service Semantics in Registries through Ontology
           Languages



                                          HealthCareServices
PatientAdministration                                                               ObservationReporting
                        PatientCare            PatientReferral         Scheduling

    PatientReferralRequest
                                          PatientInfoRequest                  CancelPatientReferral

          InsuranceInformation                ClinicalInformation           DemographicData

                                      GetClinicalInformation



                          patientID                  clinicalInformation


               Figure 11 An example Functionality Ontology in the Healthcare Domain
Once a domain specific service ontology becomes available based on OWL-S such as the one
presented in Figure 11, there are a number of issues to be addressed before it can be used to find
the service instances from the service registries:
     Where to store the ontology so that it could be accessible from service registries. For
        example, in UDDI registries there is no mechanism to store the ontology. Therefore
        generic ontology descriptions can be stored by the standard bodies who define them. And
        the server, where the service is defined, can host the semantic description of the service
        instance. This facilitates the maintenance of the service descriptions. However there are
        times, when it is necessary to query all the individual service descriptions. Therefore a
        combined schema per industry domain containing all the semantic descriptions of the
        services pertaining to this domain may be necessary to facilitate global querying. ebXML
        registry, on the other hand, allows metadata to be stored in the registry. This is achieved
        through a “classification" mechanism, called ClassificationScheme which helps to
        classify the objects in the registry. Classification Scheme defines a hierarchy of
        ClassificationNodes.
     How to relate the generic ontology classes with the service instances advertised in
        registries. The mechanism to relate semantics with services advertised in the UDDI
        registries are the tModel keys and the category bags of registry entries. tModels provide


D3.1.1.2-v1.2                                                                       Page 34 of 55
IST-2103 STP Artemis                                                                      21/07/2013

       the ability to describe compliance with taxonomies, ontologies or controlled vocabularies.
       Therefore if tModel keys are assigned to the nodes of the ontology and if the services put
       the corresponding tModel keys in their category bags, it is possible to locate services
       conforming to the semantic given in a particular node of this ontology. This issue is
       elaborated in [Dogac 2002TES].

       An ebXML registry [ebXML, 1999], on the other hand, allows defining semantics
       basically through two mechanisms: First, it allows properties of registry objects to be
       defined through “slots” and, secondly, metadata can be stored in the registry through a
       “ClassificationScheme”. Furthermore, “Classification ”objects explicitly link the services
       advertised with the nodes of a “ClassificationScheme ”.This information can then be used
       to discover the services by exploiting the ebXML query mechanisms.


<rim:ClassificationScheme id=’HL7’ isInternal=’true’ nodeType=’uniqueCode’>
       <rim:Name> <rim:LocalizedString calue=’WebService’/></rim:Name>
       <rim:Description>
                <rim:LocalizedString value=’This is a sample HL7 WebServiceSchema’/>
       </rim:Description>
</rimClassificationScheme>

<rim:ClassificationNode id=’PatientReferralServices’ parent=’HL7’>
       <rim:Name> <rim:LocalizedString calue=’PatientReferralServices’/> </rim:Name>
       <rim:Description/>
</rimClassificationNode>

<rim:ClassificationNode id=’PatientInformationRequest’ parent=’PatientReferralServices’>
       <rim:Name> <rim:LocalizedString calue=’PatientInformationRequest’/> </rim:Name>
       <rim:Description/>
</rimClassificationNode>

<rim:ClassificationNode id=’ClinicalInformation’ parent=’PatientInformationRequest’>
       <rim:Name> <rim:LocalizedString calue=’ClinicalInformation’/> </rim:Name>
       <rim:Description/>
</rimClassificationNode>

<rim:ClassificationNode id=’GetClinicalInformation’ parent=’ClinicalInformationRequest’>
       <rim:Name> <rim:LocalizedString calue=’GetClinicalInformation’/> </rim:Name>
       <rim:Description/>
       <Slot name=’PatientId’ slotType=’StringList’>
       <Slot name=’ClinicalInformation’ slotType=’StringList’>
</rimClassificationNode>

                         Figure 12 Defining Ontology Classes in ebXML



       Consider for example the service Functionality Ontology given in Figure 11. Such a
       hierarchy can be stored in an ebXML registry through the piece of code as shown in
       Figure 12, and then the registry objects can be related with the nodes in the hierarchy. In
       this way it is possible to give meaning to the services. In other words, by relating a


D3.1.1.2-v1.2                                                                     Page 35 of 55
IST-2103 STP Artemis                                                                        21/07/2013

          service with a node in the classification hierarchy, we make the service an explicit
          member of this node and the service inherits the well-defined meaning associated with
          this node as well as the generic properties defined for this node. As an example, assume
          that there is a service instance in the ebXML registry, namely,
          “MyGetClinicalInfoService ”. When we associate “MyGetClinicalInfoService” with the
          “GetPatientClinicalInformation ” node through a “SubmitObjectsRequest ”as shown in
          Figure 13, its meaning becomes clear; that this service is providing patient clinical
          information. Furthermore “MyGetClinicalInfoService” service inherits properties of the
          “GetPatientClinicalInformation ”service such as “patientID” and “clinicalInformation”
          [Dogac, 2004].

<SubmitObjectsRequest>
      <rim:LeafRegistryObjectList>
              <Service id="MyGetClinicalInfoService">
                      <Name> <LocalizedString lang="TR"
                               value=" MyGetClinicalInfoService""/></Name>
                      <Slot name=’PatientID’>
                               <valueList><value>PID</Value></ValueList>
                      </Slot>
                      <Slot name=’ClinicalInformation’>
                               <valueList><value>CI</Value></ValueList>
                      </Slot>
                      <ServiceBinding accessURI="http://.../ MyGetClinicalInfoService">
                      <SpesificationLink spesificationObject="wsdl" /> </ServiceBinding>
              </Service>
              <Classification classificationNode="GetClinicalInformation"
                               ClassifiedObject=" MyGetClinicalInfoService""/>
              <ExtrinsicObject id="wsdl" mimeType="text/xml" />
      </rim:LeafRegistryObject>
</SubmitObjectsRequest>


                    Figure 13 Relating a Service Instance with the Ontology Class

4   ONTOLOGY MAPPING

    4.1     Introduction
Ontologies are knowledge bodies that provide a formal representation of a shared
conceptualization of a particular domain. They are widely used in the Semantic Web where they
provide semantics of annotations in Web pages and have become increasingly common on Web.
They are also widely used for the applications specific for any domain since they are powerful in
describing the semantics of a domain. Because of the widely usage of the Web and the number of
people contributing to the web, ontologies are developed in a distributed fashion. This distributed
nature of ontology development has led to a large number of different ontologies covering the
same or overlapping domains. As the number of these overlapping ontologies that are made
publicly available and accessible on the Web increases, the number of applications that use some
of these ontologies also increase proportionally. At this point ontologies lose their property which
is to define a domain uniquely between applications.




D3.1.1.2-v1.2                                                                       Page 36 of 55
IST-2103 STP Artemis                                                                      21/07/2013

The first solution for this problem is to group and define one and only one ontology for the
specified domains which is expected to be agreed by the whole world. Unfortunately this solution
is far away from the reality and does not seem to be possible because of the distributed nature of
the web and the number of people using it.

Other solutions to this problem can be the merging, alignment or mapping of the ontologies that
cover the overlapping domains.

Ontology mapping is a collection of functions assigning the entities used in one ontology to the
entities of the other. But two ontologies may be related in a more general fashion, namely by
means of relations instead of functions. Ontology alignment and merging are the tasks of
establishing a collection of binary relations between the vocabularies of two ontologies. Both
ontology merging and alignment aims to have a single ontology from the participated ontologies.
Merging the ontologies, create a single coherent ontology, where aligning the ontologies
establishes links between them and allows the aligned ontologies to reuse information from one
another.

In merging, a single ontology that is a merged version of the original ontologies is created. The
new ontology is used instead of the previous two source ontologies. In other words we lose the
two source ontologies For example, the Unified Medical Language System (UMLS) is a large
merged ontology that reconciles differences in terminology from various machine-readable
biomedical information sources.

In alignment, the two original ontologies persist, with links established between them. The
original ontologies are made consistent and coherent with one another but kept separately.
Alignment usually is performed when the ontologies cover domains that are complementary to
each other.

As an illustration of the possible processes that establish correspondence between different
ontologies, we consider the ontologies that natural languages embody. A researcher trying to find
common ground between two such languages may perform one of several tasks. He may create a
mapping between the two languages to be used in, say, a machine-translation system. Differences
in the ontologies underlying the two languages often do not allow simple one-to-one
correspondence, so a mapping must account for these differences. Alternatively, Esperanto
language (an international language that was constructed from words in different European
languages) was created through merging: All the languages and their underlying ontologies were
combined to create a single language. Aligning languages (ontologies) is a third task. Consider
how we learn a new domain language that has an extensive vocabulary, such as the language of
medicine. The new ontology (the vocabulary of the medical domain) needs to be linked in our
minds to the knowledge that we already have (our existing ontology of the world). The creation of
these links is alignment. Figure 14 illustrates the three methods.




D3.1.1.2-v1.2                                                                     Page 37 of 55
IST-2103 STP Artemis                                                                     21/07/2013




                       Figure 14 Mapping/Merging/Alignment Illustrations


In this report one of the solutions for the overlapping ontologies, ontology mapping will be
presented. Merging and alignment is out of scope of this document. More information on merging
and alignment can be found in PROMPT [Noy, 2000], Chimaera [McGuinness, 2000], FCA-
Merge [Maedche, 2001], and SMART [Noy, 1999].

As mentioned before, ontology mapping is to define collection of functional relations between
two overlapping ontologies. The aim of the mapping is to be able to transform one instance of an
ontology to an instance of another ontology. Mapping is a directional process. Therefore the
ontologies participating in the mapping process are differentiated. Mapping is done from source
ontology to target ontology. Transformation gets an instance of the source ontology and creates
an instance of the target ontology.

Ontology mapping is not a totally new issue which came into the play with the semantic web.
Another issue from old days which somehow resembles the ontology mapping is the integration
of distributed databases, and dataware houses, which is named as schema matching. Therefore
through out the document some aspects of schema matching will also be presented with its
techniques that are also applied to ontology mapping. Detailed information on schema matching
has been given in [Rahm, 2001].

The remainder of the document is as follows. First the mapping process will be presented in its
three steps, namely discovery, representation and execution. In the later section one of the
ontology mapping tools, MAFRA will be presented and lastly an example mapping process with
MAFRA will be given.

4.2       Discovery

Discovery phase represents the (semi)automatic discovery of the related ontology entities and the
functional relationship between them. There are various solutions in this area. Natural language
processing and artificial intelligence is widely used to solve discovery problems.


D3.1.1.2-v1.2                                                                     Page 38 of 55
IST-2103 STP Artemis                                                                         21/07/2013



Approaches used in schema matching are widely used in the discovery phase of ontology
mapping. Schema matching includes the mapping between the elements of two schemas that
correspond to each other semantically. It requires a particular representation of these two schemas
such as: Entity Relationship (ER) model, Object Oriented (OO) model, XML, Directed graphs.

The result of the matching is called the “match result”. However it is not possible to determine
matches fully automatically since most schemas have semantics that affect the matching criteria
but is not formally expressed or documented. Therefore this process is accomplished semi-
automatically. After the processing schemas, matcher returns “match candidates”, which user
accepts, rejects or updates. The mappings are categorized as “Partial map” or “Full map”. Partial
map does not guarantee that the source schema will be completely transformed into the target
schema. Generally partial mapping is achieved with semi-automatic schema matching.

In [Rahm, 2001], the schema matching approaches are classified as below.

       Instance vs. Schema: Instance based approaches use learning algorithms on the instances
        of the schema and extracts the similarity based on the gained knowledge (frequent
        occurrence of a word in a column of a table). Schema based approach consider only the
        schema.
       Element vs. Structure: Element based approaches tries to find the functional relations
        between only the atomic individual schema elements such as attributes while structure
        based approaches tries to match for combination of elements.
       Language vs. Constraint: Language based approaches uses textual names and
        descriptions. Calculate the similarity according to the name of the elements or structures.
        Constraint based approaches uses the constraints on the schema elements to measure the
        similarity. For example, these constraints can be the type of an attribute and matcher can
        conclude a high similarity if the type of two attributes are ‘date’.
       Matching Cardinality: Overall match result may relate one or more elements of one
        schema to one or more elements of other schema. (1:1, 1:n, m:n)

A specific example tool where the discovery is performed via artificial intelligence and linguistic
approaches is GLUE [Doan, 2002]. GLUE uses learning strategy as described in the instance
based approaches. However it uses a multi-learning strategy, because there are many different
types of information a learner can glean from the training instances in order to make predictions.
It can exploit the frequencies of words in the text value of instances, the instance names, the value
formats, or the characteristics of value distributions. To cope with this diversity, the authors
developed two learners, a content learner and a name learner. The former uses a text classification
method, called Naive Bayes learning. The name learner is similar to the content learner but uses
the full name of the instance instead of its content. They then developed a meta-learner that
combines the predictions of the two learners. It assigns to each one of them a learner weight that
indicates how much it trusts its predictions. The authors also used a technique; relaxation
labeling, that assigns labels to nodes of a graph, given a set of constraints. The authors applied
this technique to map two ontologies' taxonomies, O1 to O2, by regarding concepts (nodes) in O2
as labels, and recasting the problem as finding the best label assignment to concepts (nodes) in
O1, given all knowledge they have about the domain and the two taxonomies. That knowledge
can include domain-independent constraints like `two nodes match if nodes in their neighborhood
also match where neighborhood is defined to be the children, the parents or both as well as
domain-dependent constraints.




D3.1.1.2-v1.2                                                                        Page 39 of 55
IST-2103 STP Artemis                                                                       21/07/2013

Another powerful method for the similarity measuring and extraction is Similarity Flooding
[Melnik, 2002]. It is based on the following idea. First, the authors convert the models to be
matched into directed labeled graphs. These graphs are used in an iterative fix point computation
whose results tell us what nodes in one graph are similar to nodes in the second graph. For
computing the similarities, they rely on the intuition that elements of two distinct models are
similar when their adjacent elements are similar. In other words, a part of the similarity of two
elements propagates to their respective neighbors. This approach is similar to relaxation labeling
which is used in GLUE. Algorithm continuously processes the graph and tries to increase the
similarity value of each edge in the graph until a fix point is reached. Then they apply thresholds
and filters to come up with the matching candidates to the user.


4.3       Representation

Representation is the phase where the manually or semi-automatically found mappings are
represented in a formal language. This language should be capable of describing the relations and
functions between ontology entities and, the constraints of these functions.

There are some important work on representing the mappings of the ontologies such as RDFT
[Omelayenko, 2002], Knowledge Management Tool [Crubezy, 2003], and MAFRA [Maedche,
2002]. All these approaches use a mediator component to define the mapping relations between
ontologies. They categorize the types of mapping relations that can be expressed in any situation
that requires mapping knowledge from one ontology to another. Such categorization allows to
conceptualize mapping relations in a better way and to design appropriate tool support for their
definition and interpretation. The categorization of the components is done via another ontology.
This special ontology is named as the ‘mediator ontology’ that is shown in Figure 15. The
mentioned work on the representation of the mapping is elaborated below.




                                  Figure 15 Mediating Ontology




D3.1.1.2-v1.2                                                                      Page 40 of 55
IST-2103 STP Artemis                                                                    21/07/2013


4.3.1 RDFT

RDFT is based on the CWM (Common Warehouse Modeling) architecture to define the mapping
ontology and focuses mainly on the relations between the ontology entities. It does not define
functions or constraints on these relations. Other approaches define the components to provide
mapping between only ontology entities (classes and properties), where as RDFT provides
components for mapping between ontology entities; and also between ontology entities and xml
schema elements. Several types of bridges are defined in RDFT:

      Event2Event bridges link different events, specify temporal event generation conditions,
       and link the events to the messages transmitted with them. They connect instances of the
       meta-class mediator:Event.
      RDFbridges: Class2Class and Property2Property bridges between RDF Schema classes
       and properties.
            Class2Class bridges contain SourceClass and TargetClass properties pointing to
               rdfs:Class instances.
            Property2Property bridges contain SourceProperty and TargetProperty properties
               pointing to rdf:Property instances. Again, only one-to-many and many-to-one
               bridges are allowed in RDFT. In RDF Schema properties are defined as first-
               class objects together with classes, and they capture most of domain knowledge.
               Classes mostly specify aggregation of properties, and thus we do not include
               class-to-property and property-to-class bridges in RDFT.
      XMLBridges: Tag2Class and Tag2Property bridges link source XML DTD tags and
       target RDF Schema classes and properties. Class2Tag and Property2Tag bridges connect
       RDF Schema classes and properties, and the elements of the target DTD. These are
       constructed from SourceTag and TargetTag properties in addition to the Source/Target-
       Class/Property properties mentioned above.


4.3.2 Knowledge Management Tool

In [Crubezy, 2003] a small, generic mapping ontology that provides a structure for defining
mapping relations between a source and a target ontology is proposed, in terms of conceptual
alignment, of instance migration and of slot value computation. The mediating ontology is shown
in Figure 16. To configure two components to work together in a system, a developer instantiates
mapping ontology with the set of mapping relations that links the ontologies of the source and
target components. The developer thus creates a mapping knowledge base that contains rules to
compute the target instances from source instance knowledge. It supports one-to-one, one-to-
many, many-to-one and many-to-many mappings.




D3.1.1.2-v1.2                                                                    Page 41 of 55
IST-2103 STP Artemis                                                                       21/07/2013




                   Figure 16 Knowledge Management Tool Mediating Ontology


Instance-level mappings can express many-to-one, or many-to-many, aggregation relations
between source and target concepts, as well as one-to-many concept-decomposition relations.
Slot-level mappings also can express aggregation and decomposition operations, and include
lexical, numerical and functional transformations of slot values. It is important to note that the
core knowledge that is needed to create target instances out of source instances resides in the set
of slot-level transformation operations attached to an instance-level mapping relation. This is
realized as the operations that change the format and resolution of the source slot values to
compute the required values of target slots.

Unfortunately, no implementation of the Knowledge Management Tool exists. Just the ideas are
presented in the related paper [Crubezy, 2003]. While this document was being prepared, Ms.
Monica Crubezy, who is the author of the paper, informed us about the fact that the tool is being

4.3.3 MAFRA

The last approach presented for representation is MAFRA (Mapping Framework) which is also
used to define and execute an example mapping for this report. MAFRA uses the mediating
component which is an ontology as in other two mentioned. The mediating ontology in MAFRA
is called as “Semantic Bridging Ontology” since it defines the semantic bridges used to define
relations in MAFRA.

A role of a semantic bridge is to encapsulate all necessary information to transform instances of
one source ontology entity to instances of one target ontology entity.

The nature of semantic bridges may be understood by considering different dimensions, each
describing one particular aspect of a semantic bridge. Authors categorized the semantic bridges.
The important aspect used in this categorization is the structure of RDFS. Mainly the bridges are
divided into two as “Property Bridges” and the “Concept Bridges” since RDFS defined two
ontology entities: concepts and properties. This logic is also used in the previous two approaches.
With respect to this categorization, the authors identified following five dimensions of semantic
bridges:

       Entity dimension: Semantic bridges may relate the three ontology entities, namely
        concepts (modeling classes of objects from the real world), relations (modeling
        relationships between objects in the real world), and attributes (modeling simple
        properties of objects in the real world)




D3.1.1.2-v1.2                                                                      Page 42 of 55
IST-2103 STP Artemis                                                                        21/07/2013

         Cardinality dimension: This dimension determines the number of ontology entities at
          both sides of the semantic bridge, ranging from 1:1 to m:n.
         Structural dimension: This dimension reflects the way how elementary bridges may be
          combined into more complex bridges. Three different relations may hold between
          bridges. Specialization allows a bridge to reuse definitions from another bridge and
          provide additional abstraction is a variation of the type of the super-classes. When this
          attribute is set, the specified bridge should not be executed independently, but only as
          super-class of another. Composition relation between to bridges specifies that a bridge is
          composed of other bridges. Alternatives relation between bridges specifies a set of
          mutually exclusive bridges.
         Constraint dimension: The constraint dimension permits to control the execution of a
          semantic bridge. It reflects relevant constraints applied during the execution phase to
          instances from the source ontology. Constraints act as conditions that must hold in order
          the transformation procedures is applied onto the instances of the source ontology, e.g.
          the bridge evaluate only if the value of the source instance matches a certain pattern.
         Transformation dimension: This dimension reflects how instances of the source
          ontology are transformed during the mapping process. Transformations assume different
          complexity and variety depending on the ontologies being bridged.

A specification of all available semantic bridges, organized in taxonomy, is a Semantic Bridging
Ontology (SBO). To actually relate the source and target ontology, the mapping process creates
an instance of SBO containing semantic bridge instances, each encapsulating all necessary
information to transform instances of one source entity to instances of the target entity.



    4.4     Execution

Execution step is where transformation takes place. Usually the component for this task is called
as the “transformation engine”. At this step, the similarities between ontologies have already been
found and represented with a formal language. The engine is provided with the mapping
representation, the source and target ontologies and the source instance. The output of the engine
is the target instance.

    4.5     MAFRA Architecture
After presented the general view to the ontology mapping, MAFRA (Mapping Framework) will
be explained and an example on how to use MAFRA and achieve ontology mapping will be
given.

MAFRA identifies the phases commonly found in any ontology mapping process through the
horizontal components (i.e. Lift & Normalization, Similarity Measuring, Semantic Bridging,
Execution and Post-processing). Simultaneously, it identifies and organizes a set of modules that
are not part of the process, but represent crucial functionalities existing in any system, providing
(automatic) support along the entire ontology mapping process. The framework suggests a cyclic,
iterative and interactive operation, promoting the continuous improvement and recycling of the
mapping. The horizontal and vertical dimensions are shown in the following figure.




D3.1.1.2-v1.2                                                                       Page 43 of 55
IST-2103 STP Artemis                                                                        21/07/2013




                                 Figure 17 MAFRA Architecture


Whereas, the architecture represented in above figure is proposed in the publication related to
MAFRA, only the three components are implemented in the tool. These are the two top horizontal
components, and one vertical component; namely: Semantic Bridging, Execution and GUI.
Therefore MAFRA do not support semi-automatic similarity discovery. Another weakness of
MAFRA is the fact that it supports only the ontologies defined in RDFS. It does not support the
new ontology representation languages such as DAML or OWL. It also show some anomalies
when one of the ontologies used, which is represented in RDFS, is designed with an ontology
editor other than KAON [KAON]. Even not implemented, the basic idea behind the components
has importance for the properties that a mapping tool should have. The below definitions of the
components are directly taken from the paper presenting MAFRA [Maedche, 2002].


4.5.1 Horizontal Dimension of MAFRA

      Lift & Normalization focuses on coping with language and lexical heterogeneity
       between source and target ontology. Language lift focuses on minimizing syntactical and
       structural representation heterogeneity, while lexical normalization focuses on
       minimizing ontology contents lexical heterogeneity. Lexical normalization is responsible
       for the normalization of abbreviations and acronyms. It acquires special relevance in the
       Similarity Measuring.
      Similarity Measuring is responsible from the discovery of the similarities. It aims to
       acquire, infer and establish similarities measures between source ontology entities and
       target ontology entities. Similarities might be explicitly defined by domain expert, or
       semi-automatically acquired through complementary mechanisms.
      Semantic Bridging phase establishes the semantic relations between set of source and
       target entities and defines the transformation function relating the sets. Again, the process
       associated with this phase may be manual or semi-automatic. In manual approach, the
       prior phase is not mandatory, and similarities are implicit in domain expert knowledge.
       The resulting of this phase is an ontology mapping document.
      Execution phase transforms instances from the source ontology into target ontology
       instances by evaluating the ontology mapping document defined in previous phase. In
       general two distinct modes of operation are possible, namely offline (static, one-time
       transformation) and online (dynamic, continuous mapping between source and the target)
       execution depending on operation environment and requirements.
      Post-processing takes the results of the execution module to check and improve the
       quality of the transformation results. The most challenging task of post-processing is
       establishing object identity - recognizing that two (or more) instances represent the same


D3.1.1.2-v1.2                                                                       Page 44 of 55
IST-2103 STP Artemis                                                                          21/07/2013

          real-world object, and recognize that two (or more) similar entities represent two different
          objects.


4.5.2 Vertical Dimension of MAFRA

         Evolution. The evolution module focuses on maintenance of ontology mapping
          document, which is due to at least two reasons: synchronize with the changes in the
          source and target ontologies, and changes in domain or application requirements.
         Cooperative Consensus Building. Semantic clashes easily arise between heterogeneous
          and autonomous entities populating the Semantic Web. Additionally, due to ontology
          mapping evolution, choosing the correct ontology mapping (version) may arise
          difficulties. Though the automatic agreements are hard to achieve, the cooperative
          consensus-building module assists and promotes negotiation between the two knowledge
          communities involved in the process
         Domain Constraints and Background Knowledge. The quality of similarity
          computation and semantic bridging may be dramatically improved by introducing
          background knowledge and domain constraints, e.g. by using glossaries to help identify
          synonyms or by using lexical ontologies, such as WordNet or domain-specific thesauri, to
          identify similar concepts.
         Graphical User Interface. Mapping is a difficult and time-consuming process, which is
          not less difficult than building an ontology itself. Graphical user interface arises as a
          fundamental tool in the system, allowing and promoting better ontology mappings.



    4.6     Example Mapping With MAFRA
In order to design an example mapping, two partial health care ontologies are used. These two
partial ontologies are designed with background knowledge of two healthcare standards, namely
HL7 [HL7] and ENV-13606 [ENV 13606]. The aim of the example is to transform instances of
‘AdverseReaction’ (ENV) partial ontology shown in Figure 18 into ‘AL1’ (HL7) partial
ontology shown in Figure 19 . Both ontologies represent allergies of a patient and its properties.




                                 Figure 18 ENV-13606 based ontology


ENV based ontology consists of only one concept, named ‘AdverseReaction’. This node has three
attributes which are ‘reactionName’, ‘reaction’ and ‘substance’. As can be understood from the
names of the attributes, ‘reaction’ is the action of the human body against the ‘substance’. And
‘reactionName’ is the name of this action in Health domain. HL7 based ontology consists of three
concepts. ‘AL1’ is the top concept representing the allergy properties. In this ontology,
‘allergyReaction’ is equivalent to ‘reactionName’ attribute in the previous ontology.
‘allergyCode’ is a value from a taxonomy, which may be specific to medical institute.
‘allergyType’ attribute represents both the substance and reaction, which is the action of the body


D3.1.1.2-v1.2                                                                         Page 45 of 55
IST-2103 STP Artemis                                                                       21/07/2013

to the substance. Lastly ‘hasSeverity’ property of AL1, relates the concept with one of the two
concepts: ‘LowSeverity’ and “High Severity’. The name of the reaction specifies which concept
to relate.




                                  Figure 19 HL7 based ontology



After designing the ontologies, instance of the source ontology is designed using KAON. The
designed ontologies and the instance are just for illustration. Therefore they are very simple, and
even may not be totally meaningful in the domain of Healthcare. Figure 20 shows the instance of
source ontology which is AdverseReaction. It is expected to construct an AL1 instance from the
source instance.




                            Figure 20 Allergy State Ontology Instances


The automatic or semi-automatic similarity measuring and discovery is not the goal of this
examples, since such functionality already hasn’t been implemented in MAFRA. What is trying
to be shown is how to design a mapping with MAFRA manually and see the result of the
execution once the mapping is defined. Expected outcome of the example, after the definition and
execution of the mapping, is shown in Figure 21. It is planned to get the values of ‘reaction’ and
‘substance’ attributes of AdverseReaction, concatenate and assign to ‘allergyType’ attribute of
AL1. This is shown with orange lines in Figure 21. Moreover the ‘reactionName’ attribute of
AdverseReaction will directly be copied to ‘allergyReaction’ attribute of AL1, which is shown
with brown line. With help of a lookup table which is a hash table, where there is a value for each
of the entries, the ‘allergyCode’ attribute of AL1. ‘reactionName’ of AdverseReaction attribute is
used to lookup the hash table, and get the value for ‘allergyCode.




D3.1.1.2-v1.2                                                                      Page 46 of 55
IST-2103 STP Artemis                                                                          21/07/2013




                                Figure 21 Expected Mapping Result


Lastly ‘hasSeverity’ property of AL1 will be initialized. In order to do that again ‘reactionName’
attribute of AdverseReaction is used. It is possible to define a process such as in Figure 22. This
process is shown with purple line in Figure 21.




                             Figure 22 initialize a new concept instance


MAFRA tool provides a easy to use GUI. Within tool it is possible first to define one-to-one
“Concept Bridges” between ontology nodes. However any node can participate in multiple
Concept Bridges. This way many-to-many mapping are supported. After defining a Concept
Bridge, it is possible to add Property Bridges to Concept Bridges using “hasBridge” property of
Concept Bridge (which is defined in Semantic Bridge Ontology). It is also possible to define
constraint on the bridges which will be used to decide if the bridge will be executed or not. The
constraints mentioned help us to define processes as in Figure 22, in other words to control if
some condition holds or not.

During execution step, for each of the Concept Bridge, the related target ontology node instance
is created if constraints are calculated to true. After traversing all the Concept Bridges, the
Property Bridges are executed and the attributes of created instances are set. This functionality is
shown in Figure 23. For a definition shown in the top part of the figure, is executed as follows:
First ‘instance B’, is constructed with a null attribute. After all Concept Bridges are executed, the
Property Bridge is executed and ‘pB’ attribute of the instance is set.




D3.1.1.2-v1.2                                                                         Page 47 of 55
IST-2103 STP Artemis                                                                       21/07/2013




                            Figure 23 Execution of bridges in MAFRA


In order to facilitate the transformation, Property Bridges are supported with “Services” which are
external functions. Example to these functions may be copying an attribute, splitting a string into
pieces according to some regular expressions. In Figure 24 a Property Bridge that relates
‘reactionName’ attribute of AdverseReaction to ‘allergyReaction’ attribute of AL1 is presented.
The service that this Property Bridge uses is “Copy Attribute”.




                                     Figure 24 Copy Attribute


The mapping process gets more and more complex with the number of attributes and concepts to
initialize on the target ontology side. Even for this small mapping the complexity of mapping is
shown in Figure 27.

After the design is finished, the execution is performed and the results are as expected. Once the
Allergy State instance represented in RDF, as shown in Figure 25 is provided to the tool the
output is shown in Figure 26 is automatically created. From the result it can be seen, every
expectation mentioned in the beginning is achieved. All of the attributes of AL1 instance are set,
instance of the concept ‘HighSeverity’ is created (be careful not the ‘LowSeverity’), and the
‘hasSeverity’ property of AL1 is related with this instance which may be seen from the id’s
assigned. The ‘hasSeverity’ property has the value of the id assigned to ‘HighSeverity’ instance
(i-1074761652135-1753614546)



D3.1.1.2-v1.2                                                                       Page 48 of 55
IST-2103 STP Artemis                                                  21/07/2013




                        Figure 25 Allergy State Instance RDF




                       Figure 26 Created Allergy Instance RDF




D3.1.1.2-v1.2                                                   Page 49 of 55
                IST-2103 STP Artemis                                                    21/07/2013




            Figure 27 Snapshot of Example Mapping Definition in MAFRA


D3.1.1.2-v1.2                                                           Page 50 of 55
IST-2103 STP Artemis                                                                       21/07/2013


5   REFERENCES
[Alexaki et al.,2001 ] S. Alexaki, V. Christophides, G. Karvounarakis, D. Plexousakis, and K.
Tolle. The ICS-FORTH RDFSuite:Managing Voluminous RDF Description Bases,Proc.
of the Second International Work hop on the Semantic Web (SemWeb2001),May 2001.
[BEAWebLogic] BEA WebLogic Workshop,
http://h71028.www7.hp.com/enterprise/cache/3922-0-0-225-121.aspx
[Berners-Lee et al.,2001 ] T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web,
Scientific American ,May 2001.
[Casati and Shan,2001a ] F. Casati and M-C. Shan. Definition, Execution, Analysis and
Optimization of Composite E-Services, IEEE Data Engineering Bulletin ,24(1):29 –34.
[Casati and Shan,2001b ] F. Casati and M-C. Shan. Dynamic and Adaptive Composition of E-
Services, Information Systems, to appear.
[Chimaera,2000 ]Chimaera, http://www.ksl.stanford.edu/software/chimaera/
[Colmeraurer and Kanoui,1973 ]Colmeraurer,A.,Kanoui,H.,Roussel,P.and Pasero,R.
Un systme de communication homme-machine en francais. Technical Report, Group de
Recherce en Intelligence Artifielle,Univ.d ’Aix-Marseille, 1973.
[Colmeraurer and Roussel,1993 ] Colmeraurer, A. and Roussel, P. The Birth of Prolog. HOPL II
Preprints, SIGPLAN Notices,1993,28:37 –52.
[Crubezy, 2003] Crubézy, M., Pincus, Z. and Musen, M.A. (2003). Mediating Knowledge
between Application Components. In: Proceedings of the Semantic Integration Workshop of the
Second International Semantic Web Conference (ISWC-03), Sanibel Island, Florida.
[CWM,2000 ]CWM:Closed World Machine,http://www.w3.org/2000/10/swap/doc/wm.html.
[DAML Ontology ]DAML Ontology Library,http://www.daml.org/ontologies/.
[DAML-S,2001 ]DAML Services Coalition (A. Ankolekar, M. Burstein, J. Hobbs, O. Lassila,
D. Martin, S. McIlraith, S. Narayanan, M. Paolucci, T. Payne, K. Sycara, H. Zeng), DAML-S:
Semantic Markup for Web Services, In Proceeding of the International Semantic Web Working
Symposium (SWWS), July 2001.
[DC, 1998] Dublin Core: The Metadata Element Set,http://dublincore.org,1998.
[Decker 1999] S. Decker, M. Erdmann, D. Fensel, R. Studer, Ontobroker “Ontology based access
to distributed and semi-structured information”, Semantic Issues in Multimedia Systems (DS8),
Kluwer Academic Publisher, Boston,1999, pages 351–369
[Decker et al., 2000]S. Decker, S. Melnik, F. Van Harmelen, D. Fensel, M. Klein, J. Broekstra,
M. Erdmann, I .Horrocks. The Semantic Web: The Roles of XML and RDF, IEEE



D3.1.1.2-v1.2                                                                Page 51 of 55
IST-2103 STP Artemis                                                                     21/07/2013

[Denker et al.,2001 ]G. Denker, J. R. Hobbs, S. Narayan, R. Waldinger. Accessing Information
and Services on DAML-Enabled Web, Semantic Web Workshop, 2001.
[Doan, 2002] A. Doan, J. Madhavan, P. Domingos, and A. Halevy. Learning to map between
ontologies on the semantic web. In Proceedings of the 11th International World Wide Web
Conference (WWW 2002), Hawaii, USA, May 2002.
[DogacBook] Asuman Dogac and Ibrahim Cingil, “B2B e-Commerce Technology: Frameworks,
Standards and Emerging Issues" (in preparation)
[Dogac, 2002] Dogac, A., Laleci, G. B., Kabak, Y., Cingil, I., “Exploiting Web Service
Semantics: Taxonomies vs. Ontologies”, IEEE Data Engineering Bulletin, Vol. 25, No. 4,
December 2002, http://www.research.microsoft.com/research/db/debull/issues-list.htm.
[Dogac 2002TES] Dogac, A., Cingil, I., Laleci, G. B., Kabak, Y., "Improving the Functionality of
UDDI Registries through Web Service Semantics", 3rd VLDB Workshop on Technologies for E-
Services (TES-02), Hong Kong, China, August 23-24, 2002.
[Dogac, 2004] Dogac, A., Kabak, Y., Laleci, G., "Enriching ebXML Registries with OWL
Ontologies for Efficient Service Discovery", 14th International Workshop on Research Issues on
Data Engineering, Boston, USA , March 28-29, 2004. Internet Computing, 2000, 4(5):63 –74
[ebXML, 1999] ebXML, http://www.ebxml.org/.
[ENV 13606] CEN TC/251 (European Standardization of Health Informatics) ENV 3606,
Electronic Health Record Communication,http://www.centc251.org/
[eSpeak] e-Speak,http://www.e-speak.hp.com/.
[Frodo RdfsViz ]Frodo RDFSVisualization Tool, http://www.dfki.uni-kl.de/frodo/RDFSViz/.
[Frodo RDF2JAVA ]Frodo RDF-to-Java Tool,http://www.dfki.uni-kl.de/frodo/rdf2java/.
[Genesereth 1992] M. Genesereth, R. Fikes, “Knowledge interchange format”, Technical Report
Logic-92-1, Computer Science Department, Stanford University, 1992.
[GNU Prolog] The GNU Prolog web site,http://gnu-prolog.inria.fr/.
[Graphviz]Graphviz -open source graph drawing software,
http://www.research.att.com/sw/tools/graphviz/.
[Gruber, 1993] Tom Gruber. A translation approach to portable ontology specifications.
Knowledge Acquisition, pages 199–220, 1993.
[Hillmann, 2001] D. Hillmann. Using Dublin Core,
http://dublincore.org/documents/2001/04/12/usageguide/#coreelements
[HL7] Health Level 7 (HL7), http://www.hl7.org
[Horrocks 2000] I. Horrocks, D. Fensel, F. Harmelen, S. Decker, M. Erdmann, M. Klein “OIL in
a Nutshell”, ECAI00 Workshop on Application of Ontologies and PSMs, Berlin, 2000.


D3.1.1.2-v1.2                                                                Page 52 of 55
IST-2103 STP Artemis                                                                        21/07/2013

[IBM’s Tutorial]IBM’s tutorial on Web Services,
http://www.ibm.com/software/solutions/webservices/.
[ICS-Forth RDF Suite]The ICS-FORTH RDF Suite, http://www.ics.forth.gr/proj/isst/RDF/.
[IsaViz ]IsaViz,http://www.daml.org/tools/#IsaViz
[ISO 3166 ]ISO 3166/MA:Maintenance agency –ISO ’s focal point for country codes,
http://www.iso.org/iso/en/prods-services/iso3166ma/index.html.
[Jena] JENA: A Resource Description Framework (RDF) Application Programming Interface
(API), http://www.hpl.hp.com/semweb/doc/tutorial/RDF_API .
[Jess]JESS: the Rule Engine for the Java Platform, http://herzberg.ca.sandia.gov/jess/.
[KAON ]Karlsruhe Ontology (KAON)tool suite,http://kaon.semanticweb.org/.
[Karp 1999] R. Karp, V. Chaudhri, J. Thomere, XOL “An XML-Based Ontology Exchange
Language”, technical report, 1999.
[Kifer 1995] M. Kifer, G. Lausen, J. Wu, “Logical foundations of object-oriented and frame-
based languages”, Journal of the ACM 42, 1995, pages 741–843.
[Lassila 1999] O. Lassila, R. Swick, Resource description framework (RDF) model and syntax
specification, W3C Recommendation (1999).
[Luke 2000] S. Luke, J. Heflin “SHOE 1.01. proposed specification”, SHOE Project technical
report, University of Maryland,2000.
[MacGregor 1991] R. MacGregor, “Inside the LOOM clasifier”, SIGART bulletin 2, 1991, pages
70–76.
[Maedche, 2001] G. Stumme and A. Maedche. (FCA-Merge) Ontology Merging for Federated
Ontologies on the Semantic Web. In Proceedings of the International Workshop for Foundations
of Models for Information Integration (FMII-2001), Viterbo, Italy, September 2001.
[Maedche, 2002] Maedche, A., Motik, D., Silva, N., Volz, R., “MAFRA-A MApping
FRAmework for Distributed Ontologies”, In Proc. of the 13th European Conf. on Knowledge
Engineering and Knowledge Management EKAW-2002, Madrid, Spain, 2002.
[McGuinness, 2000]McGuinness, D.L., Fikes, R., Rice, J. and Wilder, S. (2000). An
Environment for Merging and Testing Large Ontologies. In: Proceedings of the Seventh
International Conference on Principles of Knowledge Representation and Reasoning (KR2000),
Breckenridge, Colorado.
[McIlraith et al., 2001a] S. A. McIlraith, T. C. Son, and H. Zeng. Semantic Web Services,
IEEE Intelligent Computing, March/April 2001.
[McIlraith et al., 2001b] S. A. McIlraith, T. C. Son, H. Zeng. Mobilizing the Semantic Web
with DAML-Enabled Web Services, Semantic Web Workshop, 2001.


D3.1.1.2-v1.2                                                                  Page 53 of 55
IST-2103 STP Artemis                                                                      21/07/2013

[Melnik, 2002] Melnik, Sergey; Garcia-Molina, Hector; Rahm, Erhard. Similarity Flooding: A
Versatile Graph Matching Algorithm and its Application to Schema Matching, Proc. 18th ICDE
Conf., 2002
[Miller, 1998a] E. Miller. An Introduction to the Resource Description framework, D-Lib
Magazine, May 1998, (also available at http://www.dlib.org/dlib/may98/miller/05miller.html).
[NAICS]NAICS: North American Industrial Classification Scheme Codes, http://www.-
naics.com
[Motta 1999] Motta E. Reusable Components for Knowledge Modelling. IOS Press, Amsterdam,
The Netherlands. ISBN: 1 58603 003 5, 1999
[Namespaces in XML ]Namespaces in XML,http://www.w3.org/TR/REC-xml-names/.
[Noy and McGuinness] N. F. Noy and D. L. McGuinness. Ontology Development 101: A
Guide to Creating Your First Ontology, available from http://derpi.tuwien.ac.at/andrei/daml.htm
[Noy, 1999] N.F. Noy and M. Musen. SMART: Automated Support for Ontology Merging and
Alignment. In Proceedings of the 12th Workshop on Knowledge Acquisition, Modelling and
Management (KAW'99), Ban®, Canada, October 1999.
[Noy, 2000] N. F. Noy & M. A. Musen. “PROMPT: Algorithm and Tool for Automated
Ontology Merging and Alignment” In the Proceedings of the Seventeenth National Conference
on Artificial Intelligence (AAAI-2000), Austin, TX. Available as SMI technical report SMI-
2000-0831 (2000)
[OASIS, 1998]OASIS: Organization for the Advancement of Structured Information Stan-
dards,1998,http://www.oasis-open.org/cover/siteIndex.html.
[Omelayenko, 2002]B. Omelayenko. Integrating Vocabularies: Discovering and Representing
Vocabulary Maps. In Proceedings of the First International Semantic Web Conference (ISWC-
2002), Sardinia, Italy, June 9-12, 2002., 2002.
[On-To-Knowledge ]On-To-Knowledge (IST-1999-10132):Content-driven Knowledge
Management through Evolving Ontologies,http://www.ontoknowledge.org/.
[OntoLingua,1997 ] Ontolingua Ontology Library,
http://www.ksl.stanford.edu/software/ontolingua/.
[OWL, 2003] OWL Web Ontology Language Overview,W3C Proposed Recommendation 15
December 2003, http://www.w3.org/TR/2003/PR-owl-features-20031215/.
[OWL, 2004] OWL Web Ontology Language, Use Cases and Requirements, W3C
Recommendation 10 February 2004, http://www.w3.org/TR/2004/REC-webont-req-20040210/
[OWL Guide] OWL Web Ontology Language Guide, W3C Recommendation 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-guide-20040210/.


D3.1.1.2-v1.2                                                                Page 54 of 55
IST-2103 STP Artemis                                                                     21/07/2013

[OWL-S] OWL-S 1.0 Release, http://www.daml.org/services/owl-s/1.0/
[Protege, 2000] The Protégé Project, Stanford Medical Informatics, 2000,
http://protege.stanford.edu/index.shtml.
[Rahm, 2001]Rahm, E., Bernstein, P.A, “A survey of approaches automatic schema matching”,
VLDB J. 10:4 (2001), pp. 334:350
[Redland]Redland RDF Application Framework, http://www.redland.opensource.ac.uk/.
[RDF API]RDF API, http://www-db.stanford.edu/melnik/rdf/api.html#overview.
[rdfDB] rdfDB: An RDF Database, http://www.guha.om/rdfdb/.
[RDF Schema, 1999]RDF Schema: Resource Description Framework Schema Specification,
W3C Proposed Recommendation,1999,http://www.w3.org/TR/PR-rdf-schema.
[RDF Syntax, 1999] RDF Syntax: Resource Description Framework Model and Syntax
Specifcation, W3C Recommendation,1999,http://www.w3.org/TR/REC-rdf-syntax.
[Rational Rose]Rational Rose, http://www.rational.om/products/rose/index.jsp
[RosettaNet ] RosettaNet,http://www.rosettanet.org/.
[Sesame ]Sesame,http://sesame.aidministrator.nl/.
[SOAP] SOAP: Simple Object Access Protocol,http://www.w3.org/TR/SOAP/.
[Sowa, 1999] J. F. Sowa. Knowledge Representation: Logical, Philosophical, and Computational
Foundations, Brooks Cole Publishing Co., Pacific Grove, CA, 1999.
[UDDI, 2001a]UDDI: Universal Description, Discovery and Integration, 2001,
http://www.uddi.org/.
[UML ]UML:Unified Modelling Langugage,http://www.omg.org/uml/.
[UML-RDF]Representing UML in RDF, http://www-db.stanford.edu/melnik/rdf/uml/.
[UNSPSC] UNSPSC: Universal Standard Products and Services Classification,
http://eccma.org/unspsc/.
[URI] Uniform Resource Identifier,http://www.w3.org/Addressing/.
[W3C ]W3C: World Wide Web Consortium,http://www.w3.org/.
[Wilbur ]Wilbur RDF Toolkit,http://wilbur-rdf.sourceforge.net/.
[WSDL]WSDL: Web Service Description Language,http://www.w3.org/TR/wsdl.
[Xerces ]Xerces Java Parser,http://xml.apa he.org/xerces-j/index.html
[Xpetal ]Xpetal,http://www.langdale.com.au/styler/xpetal/
[XSD] XML Schema Datatypes, http://www.w3.org/TR/xmlschema-2/s




D3.1.1.2-v1.2                                                                  Page 55 of 55

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:7/21/2013
language:English
pages:55
jny jhtw jny jhtw
About