D2v1.1. Web Service Modeling Ontology (WSMO)

WSMO Working Draft 04 October 2004


This version:: http://www.wsmo.org/2004/d2/v1.1/20041004/
Latest version:: http://www.wsmo.org/2004/d2/v1.1/
Previous version:: http://www.wsmo.org/2004/d2/v1.1/20040927/
Editors:: Dumitru Roman
Holger Lausen
Uwe Keller
Co-Authors:: Christoph Bussler
Dieter Fensel; Michael Kifer; Eyal Oren
Chris Priest
Michael Stollberg

This document is also available in non-normative PDF version. The intent of the document is to be submitted to a standardization body.

Abstract

1. Introduction
2. Language for defining WSMO
3. WSMO top level elements
4. Ontologies
5. Service Descriptions
6. Mediators
7. Logical language for defining formal statements in WSMO
8. Non functional properties
9. Conclusions and further directions
References
Acknowledgement
Appendix A. Conceptual Elements of WSMO

1. Introduction

This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Having the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as a starting point, we refine and extend this framework, and develop a formal ontology and language. WSMF [Fensel & Bussler, 2002] consists of four different main elements for describing semantic web services: ontologies that provide the terminology used by other elements, goals that define the problems that should be solved by web services, web services descriptions that define various aspects of a web service, and mediators which bypass interpretability problems.

This document is organized as follows: Section 2 describes the language used for defining WSMO, then we define in the next Section the top level element of WSMO (Section 3), Ontologies in Section 4, service descriptions in Section 5, and mediators in Section 6. In Section 7 we define the syntax of the logical language that is used in WSMO. The semantics and computationally tractable subsets of this logical language are defined and discussed by the WSML working group. Section 8 describes the non functional properties used in the definition of different WSMO elements and Section 9 presents our conclusions and further directions.

For a brief tutorial on WSMO we refer to the WSMO Primer [Arroyo & Stollberg, 2004], for a non-trivial use case demonstrating how to use WSMO in a real-world setting we refer to the WSMO Use Case Modeling and Testing [Stollberg et al., 2004] and for the formal representation languages we refer to The WSML Family of Representation Languages [De Bruijn, 2004].

Besides the WSMO working group there are two more working groups related to the WSMO initiative: The WSML working group focusing on language issues and developing a adequate Web Service Modeling Language with various sublanguages as well the WSMX working group that is concerned with designing and building a reference implementation of an execution environment for WSMO.

Note: The Vocabulary defined by WSMO is fully extensible. It is based on URIs with optional fragment identifiers (URI references, or URIrefs) [Berners-Lee et al, 1998]. URI references are used for naming all kinds of things in WSMO. The target namespace of this document is wsmo:http://www.wsmo.org/2004/d2/. Furthermore this document uses the following namespace abbreviations: dc:http://purl.org/dc/elements/1.1#, xsd:http://www.w3.org/2001/XMLSchema# and foaf:http://xmlns.com/foaf/0.1/.

2. Language for defining WSMO

As WSMO is meant to be a meta-model for semantic web services, we use an "abstract language" [OMG, 2004] throughout this document to specify this meta-model. The constructs of this abstract language (the keywords marked with bold in the listings contained in this document), used for describing WSMO elements and their properties are presented below by giving an informal description and a mapping to the Meta Object Facility (MOF) [OMG, 2004] metamodeling constructs:

class
- used when a WSMO element is defined (e.g. class X: X is defined as a WSMO element).
- MOF mapping: class corresponds to the M3 level 'Class' MOF modelling construct.
subClass
- used when a WSMO element is defined to specify that it also has the properties of another WSMO element (e.g. class X subClass Y: WSMO element X has all the properties of WSMO element Y); all things followed by the declaration of an element (using class and optionally subClass) represent properties of this element.
- MOF mapping: subClass corresponds to the M3 level 'sub-Class' MOF modelling construct.
type
- used to specify the possible types of the single value a property may have; the set of types is marked by "{" and "}" and the types are separated by "," (e.g. X type{Y, Z}: X has a single value which can be either of type Y or Z).
- MOF mapping: type corresponds to the M3 level 'type' MOF modelling construct with the constraint that the M3 level 'attribute' MOF modelling construct to which the 'type' is applied has the "multiplicity" specification set to "single-valued".
typeSet
- used to specify the possible types of the multiple values a property may have; the set of types is marked by "{" and "}" and the types are separated by "," (e.g. X typeSet {Y, Z}: X might have multiple values which can be of type Y or Z).
- MOF mapping: typeSet corresponds to the M3 level 'type' MOF modelling construct with the constraint that the M3 level 'attribute' MOF modelling construct to which the 'type' is applied has the "multiplicity" specification set to "multi-valued".

This abstract language corresponds to the M3 layer (meta-meta-model layer) of MOF and WSMO corresponds to the M2 layer (meta-model layer) in MOF.

3. WSMO top level elements

WSMO defines three top level elements:

Listing 1. WSMO definition
class WSMO ontologies typeSet ontology serviceDescriptions typeSet service mediators typeSet mediator

Ontologies: Provide the terminology used by other WSMO elements. They are described in Section 4.
Service descriptions: Description of services that are requested, provided, and agreed by service requesters and service providers. They are described in Section 5.
Mediators: Deal with interpretability problems between different WSMO elements. They are described in Section 6.

4. Ontologies

In WSMO Ontologies are the key to link conceptual real world semantics defined and agreed upon by communities of users. An ontology is a formal explicit specification of a shared conceptualization [Gruber, 1993]. From this rather conceptual definition we want to extract the essential components which define an ontology. Ontologies define a common agreed upon terminology by providing concepts and relationships among the set of concepts. In order to capture semantic properties of relations and concepts, an ontology generally also provides a set of axioms, which means expressions in some logical framework. An ontology is defined as follows:

Listing 2. Ontology definition
class ontology nonFunctionalProperties type nonFunctionalProperties importedOntologies typeSet ontology usedMediators typeSet ooMediator concepts typeSet concept relations typeSet relation functions typeSet function instances typeSet instance axioms typeSet axiom

Listing 2. Ontology definition

class ontology
      nonFunctionalProperties type nonFunctionalProperties
      importedOntologies typeSet ontology
      usedMediators typeSet ooMediator
      concepts typeSet concept
      relations typeSet relation
      functions typeSet function
      instances typeSet instance
      axioms typeSet axiom

4.1 Non functional properties

The following non functional properties are available for characterizing ontologies: Contributor, Coverage, Creator, Date, Description, Format, Identifier, Language, Owner, Publisher, Relation, Rights, Source, Subject, Title, Type, Version.

4.2 Imported Ontologies

Building an ontology for some particular problem domain can be a rather cumbersome and complex task. One standard way to deal with the complexity is modularization. importedOntologies allow a modular approach for ontology design; this simplified statement can be used as long as no conflicts need to be resolved, otherwise an ooMediator needs to be used.

4.3 Used mediators

When importing ontologies, most likely some steps for aligning, merging and transforming imported ontologies have to be performed. For this reason and in line with the basic design principles underlying the WSMF, ontology mediators (ooMediator) are used when an alignment of the imported ontology is necessary. Mediators are described in Section 5 in more detail.

4.4 Concepts

Concepts constitute the basic elements of the agreed terminology for some problem domain. From a high level perspective, a concept – described by a concept definition – provides attributes with names and types. Furthermore, a concept can be a subconcept of several (possibly none) direct superconcepts as specified by the "isA"-relation.

Listing 3. Concept definition
class concept nonFunctionalProperties type nonFunctionalProperties subConceptOf typeSet concept attributes typeSet attribute definedBy type logicalExpression

Non functional properties

The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Superconcepts

There can be a finite number of concepts that serve as a superConcepts for some concept. Being a subConceptOf some other concept in particular means that a concept inherits the signature of this superconcept and the corresponding constraints. Furthermore, all instances of a concept are also instances of each of its superconcepts.

Attributes

Each concept provides a (possibly empty) set of attributes that represent named slots for data values for instances that have to be filled at the instance level. An attribute specifies a slot of a concept by fixing the name of the slot as well as a logical constraint on the possible values filling that slot. Hence, this logical expression can be interpreted as a typing constraint.

Listing 4. Attribute definition
class attribute nonFunctionalProperties type nonFunctionalProperties range type concept

Non functional properties: The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Range: A concept that serves as an integrity constraint on the values of the attribute.

Defined by

A logical expression (see Section 7) which can be used to define the semantics of the concept formally. More precisely, the logical expression defines (or restricts, resp.) the extension (i.e. the set of instances) of the concept. If C is the identifier denoting the concept then the logical expression takes one of the following forms

forAll ?x ( ?x memberOf C implies l-expr(?x) )
forAll ?x ( ?x memberOf C impliedBy l-expr(?x) )
forAll ?x ( ?x memberOf C equivalent l-expr(?x) )

where l-expr(?x) is a logical expression with precisely one free variable ?x.

In the first case, one gives a necessary condition for membership in the extension of the concept; in the second case, one gives a sufficient condition and in the third case, we have a sufficient and necessary condition for an object being an element of the extension of the concept.

4.5 Relations

Relations are used in order to model interdependencies between several concepts (respectively instances of these concepts).

Listing 5. Relation definition
class relation nonFunctionalProperties type nonFunctionalProperties superRelations typeSet relation parameters typeSet parameter definedBy type logicalExpression

Non functional properties

The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Superrelations

A finite set of relations of which the defined relation is declared as being a subrelation. Being a subrelation of some other relation in particular means that the relation inherits the signature of this superrelation and the corresponding constraints. Furthermore, the set of tuples belonging to the relation (the extension of the relation, resp.) is a subset of each of the extensions of the superrelations.

Parameters

The list of parameters.

Listing 6. Parameter definition
class parameter nonFunctionalProperties type nonFunctionalProperties domain type concept

Non functional properties: The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Domain: A concept constraining the possible values that the parameter can take.

Defined by

A logicalExpression (see Section 7) defining the set of instances (n-ary tuples, if n is the arity of the relation) of the relation. If the parameters are specified the relation is represented by a n-ary predicate symbol with named arguments (see Section 7) (where n is the number of parameters of the relation) where the identifier of the relation is used as the name of the predicate symbol. If R is the identifier denoting the relation and the parameters are specified then the logical expression takes one of the following forms:

forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] implies l-expr(?v1,...,?vn) )
forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] impliedBy l-expr(?v1,...,?vn) )
forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] equivalent l-expr(?v1,...,?vn) )

If the parameters are not specified the relation is represented by a predicate symbol (see Section 7) where the identifier of the relation is used as the name of the predicate symbol. If R is the identifier denoting the relation and the parameters are not specified then the logical expression takes one of the following forms:

forAll ?v1,...,?vn ( R(?v1,...,?vn) implies l-expr(?v1,...,?vn) )
forAll ?v1,...,?vn ( R(?v1,...,?vn) impliedBy l-expr(?v1,...,?vn) )
forAll ?v1,...,?vn ( R(?v1,...,?vn) equivalent l-expr(?v1,...,?vn) )

l-expr(?v1,...,?vn) is a logical expression with precisely ?v1,...,?vn as its free variables and p1,...,pn are the names of the parameters of the relation.

Using implies, one gives a necessary condition for instances ?v1,...,?vn to be related; using impliedBy, one gives a sufficient condition and using equivalent, we have a sufficient and necessary condition for instances ?v1,...,?vn being related.

4.6 Functions

A function is a special relation, with a unary range and a n-ary domain (parameters inherited from relation), where the range specifies the return value. In contrast to a function symbol, a function is not only a syntactical entity but has some semantics that allows to actually evaluate the function if one considers concrete input values for the parameters of the function. That means, that we actually can replace the (ground) function term in some expression by its concrete value. Function can be used for instance to represent and exploit built-in predicates of common datatypes. Their semantics can be captured externally by means of an oracle or it can be formalized by assigning a logical expression to the definedBy property inherited from relation.

Listing 7. Function definition
class function subClass relation range type concept

Range: A concept constraining the possible return values of the function.

The logical representation of a function is almost the same as for relations, whereby the result value of a function (resp. the value of a function term) has to be represented explicitly: the function is represented by an (n+1)-ary predicate symbol with named arguments (see Section 7) (where n is the number of arguments of the function) where the identifier of the function is used as the name of the predicate. In particular, the names of the parameters of the corresponding relation symbol are the names of the parameters of the function as well as one additional parameter range for denoting the value of the function term with the given parameter values. In Case the paramters are not specified the function is represented by an predicate symbol with ordered arguments and by convention the first argument specifies the value of the function term with given argument values.

If F is the identifier denoting the function and p1,...,pn is the set of parameters of the function then the logical expression for defining the semantics of the function (inherited from relation) can for example take the form

forAll ?v1,...,?vn,?res ( F[p1 hasValue ?v1,...,pn hasValue ?vn, result hasValue ?res] equivalent l-expr(?v1,...,?vn,?res) )

where l-expr(?v1,...,?vn,?res) is a logical expression with precisely ?v1,...,?vn,?res as its free variables and p1,...,pn are the names of the parameters of the function. Clearly, result may not be used as the name for a parameter of a function in order to prevent ambiguities.

4.7 Instances

Instances are either defined explicitly or by a link to an instance store, i.e., an external storage of instances and their values.

An explicit definition of instances of concepts is as follows:

Listing 8. Instance definition
class instance nonFunctionalProperties type nonFunctionalProperties instanceOf type concept attributeValues typeSet {URIRefernce, Literal, AnonymousId}

Non functional properties

The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Instance of

The concept to which the instance belongs to ([1]).

Attribute values

The attributeValues for the single attributes defined in the concept. For each attribute defined for the concept this instance is assigned to there can be a corresponding attribute value. These value have to be compatible with the corresponding type declaration in the concept definition.

Listing 9. Attribute value definition
class attributeValue attribute type attribute value type {URIRefernce, Literal, AnonymousId}

Attribute: The attribute this value refers to.
Value: An URI reference, literal or anonymous id representing the actual value of an instance for a specific attribute.

Instances of relations (with arity n) can be seen as n-tuples of instances of the concepts which are specified as the parameters of the relation. Thus we use the following definition for instances of relations:

Listing 10. Relation instance definition
class relationInstance nonFunctionalProperties type nonFunctionalProperties instanceOf type relation parameterValues typeSet parameterValue

Non functional properties

The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.

Instance of

The relation this instance belongs to ([2]).

Parameter values

A set of parameterValues specifying the single instances that are related according to this relation instance. The list of parameter values of the instance has to be compatible wrt. names and range constraints of that are specified in the corresponding relation.

Listing 11. Parameter value definition
class parameterValue parameter type parameter value type {URIRefernce, Literal, AnonymousId}

Parameter: The parameter this value refers to.
Value: An URI reference, literal or anonymous id representing the actual value of an instance for a specific attribute.

A detailed discussion and a concrete proposal on how to integrate large sets of instance data in an ontology model can be found in DIP Deliverable D2.2 [Kiryakov et. al., 2004]. Basically, the approach there is to integrate large sets of instances which are already existing on some storage devices by means of sending queries to external storage devices or oracles.

4.8 Axioms

An axiom is considered to be a logical expression together with its non functional properties.

Listing 12. Axiom definition
class axiom nonFunctionalProperties type nonFunctionalProperties definedBy type logicalExpression

Non functional properties: The nonFunctionalProperties that can be used are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Defined by: The actual statement captured by the axiom is defined by an formula in a logical language as described in Section 7.

5. Service Descriptions

WSMO provides service descriptions for describing requested, provided, and agreed services. In the following, we will describe the common elements of these descriptions as a general service description definition. Then, in Sections 5.1 to 5.3 the differences compared to the general service definition are highlighted.

A service description is defined as follows:

Listing 13. Service description definition
class service nonFunctionalProperties type wsNonFunctionalProperties importedOntologies typeSet ontology usedMediators typeSet ooMediator capability type capability interfaces typeSet interface

Listing 13. Service description definition

class service
      nonFunctionalProperties type wsNonFunctionalProperties
      importedOntologies typeSet ontology
      usedMediators typeSet ooMediator
      capability type capability
      interfaces typeSet interface

Non functional properties

The nonFunctionalProperties that can be used are: Accuracy, Contributor, Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security, Source, Subject, Title, Transactional, Trust, Type, Version.

Imported Ontologies

It is used to import ontologies as long as no conflicts are needed to be resolved.

Used mediators

A service can import ontologies using ontology mediators (ooMediators) when steps for aligning, merging and transforming imported ontologies are needed.

Capability

A capability defines the service by means of its functionality.

Listing 14. Capability definition
class capability nonFunctionalProperties type nonFunctionalProperties importedOntologies typeSet ontology usedMediators typeSet ooMediator preconditions typeSet axiom assumptions typeSet axiom postconditions typeSet axiom effects typeSet axiom

Listing 14. Capability definition

class capability
      nonFunctionalProperties type nonFunctionalProperties
      importedOntologies typeSet ontology
      usedMediators typeSet ooMediator
      preconditions typeSet axiom 
      assumptions typeSet axiom     
      postconditions typeSet axiom
      effects typeSet axiom

Non functional properties: The nonFunctionalProperties that can be used are: Accuracy, Contributor, Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security, Source, Subject, Title, Transactional, Trust, Type, Version.
Imported Ontologies: It is used to import ontologies as long as no conflicts are needed to be resolved.
Used mediators: A capability can import ontologies using ontology mediators (ooMediators) when steps for aligning, merging and transforming imported ontologies are needed.
PreConditions: PreConditions specify the information space of the service before its execution.
Assumptions: Assumptions describe the state of the world before the execution of the service.
PostConditions: PostConditions describe the the information space of the service after the execution of the service.
Effects: Effects describe the state of the world after the execution of the service.

Interfaces

An interface describes how the functionality of the service can be achieved (i.e. how the capability of a service can be fulfilled) by providing a twofold view on the operational competence of the service:

choreography decomposes a capability in terms of interaction with the service (service user's view)
orchestration decomposes a capability in terms of functionality required from other services (other service providers' view)

This distinction reflects the difference between communication and cooperation. The choreography defines how to communicate with the service in order to consume its functionality. The orchestration defines how the overall functionality is achieved by the cooperation of more elementary service providers [3].

An interface is defined by the following properties:

Listing 15. Interface definition
class interface nonFunctionalProperties type nonFunctionalProperties importedOntologies typeSet ontology usedMediators typeSet ooMediator choreography type choreography orchestration type orchestration

Listing 15. Interface definition

class interface
      nonFunctionalProperties type nonFunctionalProperties
      importedOntologies typeSet ontology
      usedMediators typeSet ooMediator
      choreography type choreography 
      orchestration type orchestration

Non functional parameters

Imported Ontologies

It is used to import ontologies as long as no conflicts are needed to be resolved.

Used mediators

An interface can import ontologies using ontology mediators (ooMediators) when steps for aligning, merging and transforming imported ontologies are needed.

Choreography

Choreography provides the necessary information to communicate with the service (i.e. how to access the service from the perspective of the service's user). From a business-to-business perspective, the choreography can be split in two distinct choreographies:

meta-choreography - consists of different types of choreographies, which are related to, and can influence the execution of a service. Negotiation, re-negotiation and monitoring choreographies are examples of such meta-choreographies:
- negotiation choreography - consists of a protocol for message interactions which, on successful termination, will result in the agreement of a service between two parties, i.e. an agreed service. Web Services technologies can be used as grounding technologies for negotiation choreographies.
- monitoring choreography - consists of a protocol for message interactions which monitors the execution of an agreed service; depending on the execution of the agreed service, the monitoring choreography may generate new re-negotiation choreographies, which in turn may generate new executions. Web Services technologies can be used as grounding technologies for monitoring choreographies.
execution choreography - consists of a protocol for message interactions about an agreement, which has been agreed using (re-)negotiation choreographies. Web Services technologies can be used as grounding technologies for execution choreographies.

Orchestration

Orchestration describes how the service works from the provider's perspective (i.e. how a service makes use of other services in order to achieve its capability).

5.1 Requested Services

A requested service is a service description representing the functionality and the behaviour of a service that is required by a service requester (the owner of the requested service description), having the following features:

PreConditions in the capability of the service description specify the information space that can not be fulfilled by the service requester when the service would start to execute.
Assumptions in the capability of the service description describe the state of the world that can not be fulfilled by the service requester when the service would start to execute.
The ownerin the non functional properties of the service description is a service requester.

Requested service descriptions replace the goal descriptions of WSMO 1.0.

5.2 Provided Services

A provided service is a service description representing the functionality and the behaviour of a service that is provided by a service provider (the owner of the provided service description), having the following features:

PreConditions in the capability of the service description describe what the provided service expects for enabling it to provide its value.
Assumptions in the capability of the service description describe the expectation of the provided service on the state of the world when starting an execution of the service.
The ownerin the non functional properties of the service description is a service provider.

Provided service descriptions replace the web service descriptions of WSMO 1.0.

5.3 Agreed Services

An agreed service is defined as an agreement between a service provider and a service requester on the service that is going to be provided. An agreed service is a service description, having explicitly defined the owner of the provided service and the owner of the requested service.

Agreed services are a new element in WSMO as compared to WSMO 1.0.

6. Mediators

In this section, we introduce the notion of mediators and define the elements that are used in the description of a mediator.

We distinguish two different types of mediators :

ooMediators - mediators that import ontologies and resolve possible representation mismatches between ontologies.
sdMediators - mediators that link provided services to requested services; the link can be seen at two different levels:
- service capability level - the functionality of the requested service can be partially or totally fulfilled by the provided service.
- service interface level - the focus is on the behavior and protocol mediation between the requested service and provided service.

The mediator is defined as follows:

Listing 16. Mediators definition
class mediator nonFunctionalProperties type nonFunctionalProperties importedOntologies typeSet ontology source typeSet {ontology, service, mediator} target type {ontology, service, mediator} mediationService type service class ooMediator subClass mediator source typeSet {ontology, ooMediator} class sdMediator subClass mediator usedMediators typeSet ooMediator source typeSet {service, sdMediator} target type {service, sdMediator}

Listing 16. Mediators definition

class mediator 
      nonFunctionalProperties type nonFunctionalProperties
      importedOntologies typeSet ontology
      source typeSet {ontology, service, mediator}
      target type {ontology, service, mediator}
      mediationService type service

class ooMediator subClass mediator
      source typeSet {ontology, ooMediator}

class sdMediator subClass mediator
      usedMediators typeSet ooMediator
      source typeSet {service, sdMediator}
      target type {service, sdMediator}

Non functional properties: The nonFunctionalProperties that can be used are: Accuracy, Contributor, Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security, Source, Subject, Title, Transactional, Trust, Type, Version.
Imported Ontologies: It is used to import ontologies as long as no conflicts are needed to be resolved.
Source: The source components define entities that are the sources of the mediator.
Target: The target component defines the entity that is the targets of the mediator.
Mediation Service: The mediationService points to a service that actually implements the mediation.
Used Mediators: sdMediators use a set of ooMediators in order to map between different vocabularies used in the description of service capabilities and align different heterogeneous ontologies.

7. Logical language for defining formal statements in WSMO

As the major component of axiom, logical expressions are used almost everywhere in the WSMO model to capture specific nuances of meaning of modeling elements or their constituent parts in a formal and unambiguous way. In the following, we give a definition of the syntax of the formal language that is used for specifying logicalExpressions. The semantics of this language will be defined formally by the WSML working group in a separate document.

Section 7.1 introduces the identifiers that can be used for the basic vocabulary of WSMO. Sections 7.2 gives the definition of the basic vocabulary and the set of terms for building logical expression. Then we define in Section 7.3 the most basic formulas (atomic formulae, resp.) which allows us to eventually define the set of logical expressions.

7.1 Identifiers

There are for different identifier within WSMO:

URI references
WSMO is based on the idea of identifying things using web identifiers (called Uniform Resource Identifiers). Everything in WSMO is by default denoted by a URI, except when itself classifies it as Literal, Variable or Anonymous Id. Using URIs does not limit WSMO to make statements about things that are not accessible on the web, like with the uri: "urn:isbn:0-520-02356-0" that identifies a certain book. URIs can be expressed as follows: full URIs: e.g. http://www.wsmo.org/2004/d2/ or qualified Names (QNames) that are resolved using namespace declarations. For more details on QNames, we refer to [Bray et al., 1999].
Literals
Literals are used to identify values such as numbers by means of a lexical representation. Anything represented by a literal could also be represented by a URI, but it is often more convenient or intuitive to use literals. Literals are either plain literals or typed literals. A Literal can be typed to a data type (e.g. to xsd:integer). Formally, such a data type is defined by [Hayes, 2004]:
- a non-empty set of character strings called the lexical space of d; e.g. {"true", "1", "false", "0"}
- a non-empty set called the value space of d; e.g. {true, false};
- a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d; e.g. {"true", "1"}->{true}; {"false", "0"}->{false}.
Furthermore the data type may introduce facets on its value space, such as ordering and therefore define the axiomatization for the relations <, > and function symbols like + or -. These special relations and functions are called data type predicates and are defined more in detail in the WSML Family of Representation Languages [De Bruijn, 2004].
Anonymous Ids
Anonymous Ids can be numbered (_#1, _#2, ...) or unnumbered (_#). They represent Identifier. The same numbered Anonymous Id represents the same Identifier within the same scope (logicalExpression), otherwise Anonymous Ids represent different Identifiers [Yang & Kifer, 2003]. Anonymous Ids can be used to denote objects that exists, but don't need a specific identifier (e.g. if someone wants to say that a Person John has an address _# which itself has a street name "hitchhikerstreet" and a street number "42", then the object of the address itself does not need a particular URI, but since it must exist as connecting object between John and "hitchhikersstreet", "42" we can denote it with an Anonymous Id).The concept of anonymous IDs is similar to blank nodes in RDF [Hayes, 2004], however there are some differences. Blank Nodes are essentially existential quantified variables, where the quantifier has the scope of one document. RDF defines different strategies for the union of two documents (merge and union), whereas the scope of one anonymous ID is a logical expression and the semantics of anonymous ids do not require different strategies for a union of two documents respectively two logical expressions. Furthermore Anonymous IDs are not existentially quantified variables, but constants. This allows two flavors of entailment: Strict and Relaxed, where the relaxed entailment is equivalent to the behavior of blank nodes and the strict entailment allows an easier treatment wrt. implementation.
Variable names
Variable names are strings that start with a question mark '?', followed by any positive number of symbols in {a-z, A-Z, 0-9, _, -}, i.e. ?var or ?lastValue_Of.

7.2 Basic vocabulary and terms

7.3 Logical expressions

Listing 17. Non functional properties definition
class nonFunctionalProperties accuracy dc:contributor dc:coverage dc:creator dc:date dc:description financial dc:format dc:identifier dc:language networkRelatedQoS owner performance dc:publisher dc:relation reliability dc:rights robustness scalability security dc:source dc:subject dc:title transactional trust dc:type version

D2v1.1. Web Service Modeling Ontology (WSMO)

WSMO Working Draft 04 October 2004

Abstract

Table of contents