WSMO logo

D2v1.1. Web Service Modeling Ontology (WSMO)

WSMO Working Draft 10 October 2004

This version:
http://www.wsmo.org/2004/d2/v1.1/20041010/
Latest version:
http://www.wsmo.org/2004/d2/v1.1/
Previous version:
http://www.wsmo.org/2004/d2/v1.1/20041008/
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

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) as a starting point, we refine and extend this framework, and develop an ontology and a description language.



Table of contents


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

In order to define WSMO, which is meant to be a meta-model for semantic web services, we make use of Meta Object Facility (MOF) [OMG, 2004], a specification that defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels. The meaning of the metamodeling constructs, marked as bold in the listings throughout this document, is given by the MOF specification ([OMG, 2004]). We make the following assumptions:

3. WSMO top level elements

WSMO defines three top level elements:

Listing 1. WSMO definition
Class WSMO
     hasOntologies type ontology
     hasServices type service
     hasMediators type mediator
Ontologies
Provide the terminology used by other WSMO elements. They are described in Section 4.
Services
Description of services that are requested, provided, and agreed by service requesters and service providers. They are described in Section 5.
Mediators
Deal with interoperability 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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasImportedOntology type ontology
      hasUsedMediator type ooMediator
      hasConcept type concept
      hasRelation type relation
      hasFunction type function
      hasInstance type instance
      hasAxiom type 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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasSuperConcept type concept
      hasAttribute type attribute
      hasDefinition type logicalExpression muliplicity = single-valued
Non functional properties
The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Super-concepts
There can be a finite number of concepts that serve as a superConcepts for some concept. Being a sub-concept of 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
   hasNonFunctionalProperty type nonFunctionalProperty   
   hasRange type concept  muliplicity = single-valued
Non functional properties
The non functional properties recommended 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

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
     hasNonFunctionalProperty type nonFunctionalProperty
     hasSuperRelations type relation
     hasParameters type parameter
     hasDefinition type logicalExpression muliplicity = single-valued
Non functional properties
The non functional properties recommended 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
     hasNonFunctionalProperty type nonFunctionalProperty           
     hasDomain type concept muliplicity = single-valued
Non functional properties
The non functional properties recommended 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:

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:

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 sub-Class relation
      hasRange type concept muliplicity = single-valued
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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasType type concept
      hasAttributeValues type attributeValue  
Non functional properties
The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Type
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
      hasAttribute type attribute muliplicity = single-valued  
      hasValue 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
      hasNonFunctionalProperty type nonFunctionalProperty 
      hasType type relation
      hasParameterValues type parameterValue
Non functional properties
The non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.
Type
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
      hasParameter type parameter muliplicity = single-valued 
      hasValue 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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasDefinition type logicalExpression
Non functional properties
The non functional properties recommended 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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasImportedOntology type ontology
      hasUsedMediator type {ooMediator, sdMediator}
      hasCapability type capability muliplicity = single-valued
      hasInterface type interface
Non functional properties
The non functional properties recommended 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. A service can use sdMediator to deal with process and protocol mediation.
Capability
A capability defines the service by means of its functionality.

Listing 14. Capability definition
Class capability
      hasNonFunctionalProperty type nonFunctionalProperty
      hasImportedOntology type ontology
      hasUsedMediator type ooMediator
      hasPrecondition type axiom 
      hasAssumption type axiom     
      hasPostcondition type axiom
      hasEffect type axiom
Non functional properties
The non functional properties recommended 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 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:

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
      hasNonFunctionalProperty type nonFunctionalProperty
      hasImportedOntology type ontology
      hasUsedMediator type ooMediator
      hasChoreography type choreography 
      hasOrchestration type orchestration
Non functional parameters
The non functional properties recommended 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
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. From a business-to-business perspective, the choreography can be split in two distinct choreographies:
  • execution choreography - defines the interaction protocol for accessing a service.
  • meta choreography - defines the interaction protocol for negotiating an agreed service and for monitoring the agreed service level agreement during the execution of a service.
Orchestration
Orchestration describes how the 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/or the behavior of a service that is required by its owner - the 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/or the behavior of a service that is provided by its owner - the 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 defined the owner of the provided service and the owner of the requested service.

Agreed services are a new element in WSMO 1.1 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:

The mediator is defined as follows:

Listing 16. Mediators definition
Class mediator 
      hasNonFunctionalProperty type nonFunctionalProperty
      hasImportedOntology type ontology
      hasSource type {ontology, service, mediator}
      hasTarget type {ontology, service, mediator}
      hasMediationService type {service, sdMediator}

Class ooMediator sub-Class mediator
      hasSource type {ontology, ooMediator}

Class sdMediator sub-Class mediator
      hasUsedMediator type ooMediator
      hasSource type {service, sdMediator}
      hasTarget type {service, sdMediator}
Non functional properties
The non functional properties recommended 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 recommended 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:

7.2 Basic vocabulary and terms

Let URI be the set of all valid uniform resource identifiers. This set will be used for the naming (or identifying, resp.) various entities in a WSMO description.

Definition 1. The vocabulary V of our language L(V) consists of the following symbols:

As usual, 0-ary function symbols are called constants. 0-ary predicate symbols correspond to propositional variables in classical propositional logic.

Definition 2. Given a vocabulary V, we can define the set of terms Term(V) (over vocabulary V) as follows:

As usual, the set of ground terms GroundTerm(V) is the subset of terms in Term(V) which do not contain any variables.

Terms can be used in general to describe computations (in some domain). One important additional interpretation of terms is that they denote objects in some universe and thus provide names for entities in some domain of discourse.

7.3 Logical expressions

We extend the previous definition (Definition 2) to the set of (complex) logical expressions (or formulae, resp.) L(V) (over vocabulary V) as follows:

Definition 3. A simple logical expression in L(V) (or atomic formula) is inductively defined by

The intuitive semantics for simple logical expressions (wrt. an interpretation) is as follows:

Definition 4. Definition 3 is extended to complex logical expressions in L(V) as follows

The intuitive semantics for complex logical expressions (wrt. to in interpretation) is as follows:

Notational conventions:

There is a precedence order defined for the logical connectives as follows, where op1 < op2 means that op2 binds stronger than op1: implies , equivalent,impliedBy< or, and < not.

The precedence order can be exploited when writing logical expressions in order to prevent from extensive use of parenthesis. In case that there are ambiguities in evaluating an expression, parenthesis must be used to resolve the ambiguities.

The terms O[ATT ofTypeSet (T)] and O[ATT hasValues {V}] (that means for the case n = 1 in the respective clauses above) can be written simpler by omitting the parenthesis.

A logical expression of the form false impliedBy L (commonly used in Logic Programming system for defining integrity constraints) can be written using the following syntactical shortcut: constraint L.

We allow the following syntactic composition of atomic formulas as a syntactic abbreviation for two separate atomic formulas: C1 subConceptOf C2 and C1[ATT op V] can be syntactically combined to C1[ATT op V] subConceptOf C2. Additionally, for the sake of backwards compatibility with F-Logic, we as well allow the following notation for the combination of the two atomic formulae: C1 subConceptOf C2 [ATT op V]. Both abbreviations stand for the set of the two single atomic formulae. The first abbreviation is considered to be the standard abbreviation for combining these two kinds of atomics formulae.

Furthermore, we allow path expressions as a syntactical shortcut for navigation related expressions: p.q stands for the element which can be reached by navigating from p via property q. The property q has to be a non-set-valued property (hasValue). For navigation over set-valued properties (hasValues), we use a different expression p..q. Such path expressions can be used like a term wherever a term is expected in a logical expression.

Note: Note that this definition for our language L(V) is extensible by extending the basic vocabulary V. In this way, the language for expressing logical expressions can be customized to the needs of some application domain.

Semantically, the various modeling elements of ontologies can be represented as follows: concepts can be represented as terms, relations as predicates with named arguments, functions as predicates with named arguments, instances as terms and axioms as logical expressions.

8. Non functional properties

Non functional properties are used in the definition of WSMO elements. Which non functional properties apply to which WSMO element is specified in the description of each WSMO element. We do not enforce restrictions on the range value type (and thus also omit the range restriction in the following listing) but in some cases we do provide additional recommendations in the textual description.

Non-functional properties are defined in the following way:

Listing 17. Non functional properties definition
Class nonFunctionalProperty
      hasAccuracy type accuracy
      hasContributer type dc:contributor 
      hasCoverage type dc:coverage 
      hasCreator type dc:creator 
      hasDate type dc:date 
      hasDescription type dc:description 
      hasFinancial type financial
      hasFormat type dc:format 
      hasIdentifier type dc:identifier 
      hasLanguage type dc:language 
      hasNetworkRelatedQoS type networkRelatedQoS
      hasOwner type owner
      hasPerformance type performance 
      hasPublisher type dc:publisher 
      hasRelation type dc:relation 
      hasReliability type reliability
      hasRights type dc:rights 
      hasRobustness type robustness     
      hasScalability type scalability
      hasSecurity type security       
      hasSource type dc:source 
      hasSubject type dc:subject 
      hastitle type dc:title 
      hasTransactional type transactional 
      hasTrust type trust
      hasType type dc:type 
      hasVersion type version 
Accuracy
It represents the error rate generated by the service. It can be measured by the numbers of errors generated in a certain time interval.
Contributor
An entity responsible for making contributions to the content of the element. Examples of dc:contributor include a person, an organization, or a service. The Dublin Core specification recommends, that typically, the name of a dc:contributor should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].
Coverage
The extent or scope of the content of the element. Typically, dc:coverage will include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity).
WSMO Recommendation: For more complex applications, consideration should be given to using an encoding scheme that supports appropriate specification of information, such as DCMI Period, DCMI Box or DCMI Point.
Creator
An entity primarily responsible for creating the content of the element. Examples of dc:creator include a person, an organization, or a service. The Dublin Core specification recommends, that typically, the name of a dc:creator should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].
Date
A date of an event in the life cycle of the element. Typically, dc:date will be associated with the creation or availability of the element.
WSMO Recommendation: We recommend to use the an encoding defined in the ISO Standard 8601:2000 [ISO8601, 2004] for date and time notation. A short introduction on the standard can be found here. This standard is also used by the the XML Schema Definition (YYYY-MM-DD) [Biron & Malhotra, 2001] and thus one is automatically compliant with XML Schema too.
Description
An account of the content of the element. Examples of dc:description include, but are not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
Financial
It represents the cost-related and charging-related properties of a service [O`Sullivan et al., 2002]. This property is a complex property, which includes charging styles (e.g. per request or delivery, per unit of measure or granularity etc.), aspects of settlement like the settlement model (transactional vs. rental) and a settlement contract, payment obligations and payment instruments.
Format
A physical or digital manifestation of the element. Typically, dc:format may include the media-type or dimensions of the element. Format may be used to identify the software, hardware, or other equipment needed to display or operate the element. Examples of dimensions include size and duration.
WSMO Recommendation: We recommend to use types defined in the list of Internet Media Types [IANA, 2002] by the IANA (Internet Assigned Numbers Authority)
Identifier
An unambiguous reference to the element within a given context. Recommended best practice is to identify the element by means of a string or number conforming to a formal identification system. In Dublin Core formal identification systems include but are not limited to the Uniform element Identifier (URI) (including the Uniform element Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).
WSMO Recommendation: We recommend to use URIs as Identifier, depending on the particular syntax the identity information of an element might already be given, however it might be repeated in dc:identifier in order to allow Dublin Core meta data aware applications the processing of that information.
Language
A language of the intellectual content of the element.
WSMO Recommendation: We recommend to use the language tags defined in the ISO Standard 639 [ISO639, 1988], e.g. "en-GB", in addition the logical language used to express the content should be mentioned, for example this can be OWL.
Network-related QoS
They represent the QoS mechanisms operating in the transport network which are independent of the service. They can be measured by network delay, delay variation and/or message loss.
Owner
A person or organization to which a particular WSMO element belongs.
Performance
It represents how fast a service request can be completed. According to [Rajesh & Arulazi, 2003] performance can be measured in terms of throughput, latency, execution time, and transaction time. The response time of a service can also be a measure of the performance. High quality services should provide higher throughput, lower latency, lower execution time, faster transaction time and faster response time.
Publisher
An entity responsible for making the element available. Examples of dc:publisher include a person, an organization, or a service. The Dublin Core specification recommends, that typically, the name of a dc:publisher should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific resource we recommend the use an instance of foaf:Agent as value type [Brickley & Miller, 2004].
Relation
A reference to a related element. Recommended best practice is to identify the referenced element by means of a string or number conforming to a formal identification system.
WSMO Recommendation: We recommend to use URIs as Identifier where possible. In particular, this property can be used to define namespaces that can be used in all child elements of the element to which this non functional property is assigned to.
Reliability
It represents the ability of a service to perform its functions (to maintain its service quality). It can be measured by the number of failures of the service in a certain time internal.
Rights
Information about rights held in and over the element. Typically, dc:rights will contain a rights management statement for the element, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions may be made about any rights held in or over the element.
Robustness
It represents the ability of the service to function correctly in the presence of incomplete or invalid inputs. It can be measured by the number of incomplete or invalid inputs for which the service still function correctly.
Scalability
It represents the ability of the service to process more requests in a certain time interval. It can be measured by the number of solved requests in a certain time interval.
Security
It represents the ability of a service to provide authentication (entities - users or other services - who can access service and data should be authenticated), authorization (entities should be authorized so that they only can access the protected services), confidentiality (data should be treated properly so that only authorized entities can access or modify the data), traceability/auditability (it should be possible to trace the history of a service when a request was serviced), data encryption (data should be encrypted), and non-repudiation (an entity cannot deny requesting a service or data after the fact).
Source
A reference to an element from which the present element is derived. The present element may be derived from the dc:source element in whole or in part. Recommended best practice is to identify the referenced element by means of a string or number conforming to a formal identification system.
WSMO Recommendation: We recommend to use URIs as Identifier where possible.
Subject
A topic of the content of the element. Typically, dc:subject will be expressed as keywords, key phrases or classification codes that describe a topic of the element. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Title
A name given to an element. Typically, dc:title will be a name by which the element is formally known.
Transactional
It represents the transactional properties of the service.
Trust
It represents the trust worthiness of the service.
Type
The nature or genre of the content of the element. The dc:type includes terms describing general categories, functions, genres, or aggregation levels for content.
WSMO Recommendation: We recommend to use an URI encoding to point to the namespace or document describing the type, e.g. for a domain ontology expressed in WSMO, one would use: http://www.wsmo.org/2004/d2/#ontologies.
Version
As many properties of an element might change in time, an identifier of the element at a certain moment in time is needed.
WSMO Recommendation: If applicable we recommend to use the revision numbers of a version control system. Such a system can be for example CVS (Concurrent Version System), that automatically keeps track of the different revisions of a document, an example CVS version Tag looks like: "$Revision: 1.26 $".

9. Conclusions and further directions

This document presented the Web Service Modeling Ontology (WSMO) for describing several aspects related to services on the web, by refining the Web Service Modeling Framework (WSMF). The definition of the missing elements (choreography and orchestration) will be provided in separate deliverables of the WSMO working group, and future versions of this document will contain refinements of the mediators.

References

[Arroyo & Stollberg, 2004] S. Arroyo and M. Stollberg (Eds.): WSMO Primer, WSMO Deliverable D3.1, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d3/d3.1/.

[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.

[Berners-Lee et al, 1998] T. Berners-Lee, R. Fielding, and L. Masinter: RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, IETF, August 1998, available at http://www.isi.edu/in-notes/rfc2396.txt.

[Biron & Malhotra, 2001] P. V. Biron and A. Malhotra: XML Schema Part 2: Datatypes, W3C Recommendation 02, 2001, avaliable at: http://www.w3.org/TR/xmlschema-2/.

[Bray et al., 1999] T. Bray, D. Hollander, and A. Layman (Eds.): Namespaces in XML, W3C Recommendation REC-xml-names-19990114, 1999, available at: http://www.w3.org/TR/REC-xml-names/.

[Brickley & Miller, 2004] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/.

[Dean et al., 2004] M. Dean, G. Schreiber, S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein: OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/2004/REC-owl-ref-20040210/.

[de Bruijn., 2004] J. de Bruijn: The WSML Family of Representation Languages, WSMO Deliverable D16, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d16/.

[Enderton, 1972] H.B. Enderton: A Mathematical Introduction to Logic, Academic Press, 1972.

[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.

[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications,Knowledge Acquisition, 5:199-220, 1993.

[Hayes, 2004] P. Hayes (ed.): RDF Semantics, W3C Recommendation 10 February 2004, 2004.

[IANA, 2002] Intenet Assigned Number Authority: MIME Media Types, available at: http://www.iana.org/assignments/media-types/, February 2002.

[ISO639, 1988] International Organization for Standardization (ISO): ISO 639:1988 (E/F). Code for the Representation of Names of Languages. First edition, 1988-04-01. Reference number: ISO 639:1988 (E/F). Geneva: International Organization for Standardization, 1988. iii + 17 pages.

[ISO8601, 2004] International Organization for Standardization (ISO): ISO 8601:2000. Representation of dates and times. Second edition, 2004-06-08. Reference number. Geneva: International Organization for Standardization, 2004. Available from http://www.iso.ch.

[Kifer et al., 1995] M. Kifer, G. Lausen, and J. Wu:Logical foundations of object-oriented and frame-based languages. Journal of the ACM, 42:741-843, July 1995.

[Kiryakov et. al., 2004] A. Kiryakov, D. Ognyanov, and V. Kirov: A framework for representing ontologies consisting of several thousand concepts definitions, Project Deliverable D2.2 of DIP, June 2004.

[Manoler & Miller, 2004] F. Manola and E. Miller: RDF Primer,W3C Working Draft 23 July 2004, available at http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.

[O`Sullivan et al., 2002] J. O`Sullivan, D. Edmond, and A. Ter Hofstede: What is a Service?: Towards Accurate Description of Non-Functional Properties, Distributed and ParallelDatabases, 12:117-133, 2002.

[OMG, 2004] The Object Management Group: Meta-Object Facility, 2004. Available at http://www.omg.org/technology/documents/formal/mof.htm.

[Pan & Horrocks, 2004] J. Z. Pan and I. Horrocks: OWL-E: Extending OWL with expressive datatype expressions. IMG Technical Report IMG/2004/KR-SW-01/v1.0, Victoria University of Manchester, 2004. Available from http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf.

[Parr & Quong, 1995] Parr, T.J. and R.W. Quong: ANTLR: A predicated-LL(k) parser generator. Software, Practice and Experience, 25(7), pp. 789-810, Jul 1995.

[Rajesh & Arulazi, 2003] S. Rajesh and D. Arulazi: Quality of Service for Web Services-Demystification, Limitations, and Best Practices, March 2003. (See http://www.developer.com/services/article.php/2027911.)

[Stollberg et al., 2004] M. Stollberg, H. Lausen, A. Polleres, and R. Lara (Eds.): WSMO Use Case Modeling and Testing, WSMO Deliverable D3.2, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d3/d3.2/

[Weibel et al., 1998] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.

[Yang & Kifer, 2003] G. Yang and M. Kifer: Reasoning about Anonymous Resources and Meta Statements on the Semantic Web J. Data Semantics I 2003: 69-97.

Acknowledgement

The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.

The editors would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.

Appendix A. Conceptual Elements of WSMO

ONLY WHEN THE MODEL IS STABLE THIS WILL BE COMPLETED.


[1] An instance can be an instance of several concepts by repeating the statement.

[2] A relation instance can be an instance of several relations by repeating the statement.

[3] One could argue that orchestration should not be part of a public interface because it refers to how a service is implemented. However, this is a short-term view that does not reflect the nature of fully open and flexible eCommerce. Here companies shrink to their core processes where they are really profitable in. All other processes are sourced out and consumed as eServices. They advertise their services in their capability and choreography description and they advertise their needs in the orchestration interfaces. This enables on-the-fly creation of virtual enterprises in reaction to demands from the market place. Even in the dinosaurian time of eCommerce where large companies still exist, orchestration may be an important aspect. The orchestration of a service may not be made public but may be visible to the different departments of a large organization that compete for delivering parts of the overall service. Notice that the actual business intelligence of a service provider is still hidden. It is his capability to provide a certain functionality with a chorography that is very different from the sub services and their orchestration. The ability for a certain type of process management (the overall functionality is decomposed differently in the choreography and the orchestration) is were it comes in as a Silver bullet in the process. How he manages the difference between the process decomposition at the choreography and the orchestration level is the business intelligence of the web service provider.


Valid XHTML 1.1!

webmaster

$Date: Sunday 10 October 2004 - 16:51:58$