Web Service Modeling Language (WSML)

In this document, we introduce the Web Service Modeling Language WSML which provides a formal syntax and semantics for the Web Service Modeling Ontology WSMO. WSML is based on different logical formalisms, namely, Description Logics, First-Order Logic and Logic Programming, which are useful for the modeling of Semantic Web services. WSML consists of a number of variants based on these different logical formalisms, namely WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. WSML-Core corresponds with the intersection of Description Logic and Horn Logic. The other WSML variants provide increasing expressiveness in the direction of Description Logics and Logic Programming. Finally, both paradigms are unified in WSML-Full, the most expressive WSML variant.

WSML is specified in terms of a normative human-readable syntax. Besides the human-readable syntax, WSML has an XML and an RDF syntax for exchange over the Web and for interoperation with RDF-based applications. Furthermore, we provide a mapping between WSML ontologies and OWL ontologies for interoperation with OWL ontologies through a common semantic subset of OWL and WSML.

Status of this Document

By publishing this document, W3C acknowledges that DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National University of Ireland, Galway, Ireland, BT, The Open University, and SAP AG have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

PART I: PRELUDE

1. Introduction

The Web Service Modeling Ontology WSMO proposes a conceptual model for the description of Ontologies, Semantic Web services, Goals, and Mediators, providing the conceptual grounding for Ontology and Web service descriptions. In this document we take the conceptual model of WSMO as a starting point for the specification of a family of Web service description and Ontology specification languages. The Web Service Modeling Language (WSML) aims at providing means to formally describe all the elements defined in WSMO. The different variants of WSML correspond with different levels of logical expressiveness and the use of different languages paradigms. More specifically, we take Description Logics, First-Order Logic and Logic Programming as starting points for the development of the WSML language variants. The WSML language variants are both syntactically and semantically layered. All WSML variants are specified in terms of a human-readable syntax with keywords similar to the elements of the WSMO conceptual model. Furthermore, we provide XML and RDF exchange syntaxes, as well as a mapping between WSML ontologies and OWL ontologies for interoperability with OWL-based applications.

Ontologies and Semantic Web services need formal languages for their specification in order to enable automated processing. As for ontology descriptions, the W3C recommendation for an ontology language OWL [OWL] has limitations both on a conceptual level and with respect to some of its formal properties [de Bruijn et al., 2005]. One proposal for the description of Semantic Web services is OWL-S [OWL-S]. However, it turns out that OWL-S has serious limitations on a conceptual level and also, the formal properties of the language are not entirely clear [Lara et al., 2005]. For example, OWL-S offers the choice between different languages for the specification of preconditions and effects. However, it is not entirely clear how these languages interact with OWL, which is used for the specification of inputs and output. These unresolved issues were the main motivation to provide an alternative, unified language for WSMO.

1.1 Structure of the Document

PART II: WSML VARIANTS

Chapter 2 describes the general WSML modeling elements, as well as syntax basics, such as the use of namespaces and the basic vocabulary of the languages. Further chapters define the restrictions imposed by the different WSML variants on this general syntax. Chapter 3 describes WSML-Core, which is the least expressive of the WSML variants. WSML-Core is based on the intersection of Description Logics and Logic Programming and can thus function as the basic interoperability layer between both paradigms. Chapter 4 presents WSML-DL, which is an extension of WSML-Core. WSML-DL is a full-blown Description Logic and offers similar expressive power to OWL-DL [OWLSemantics]. Chapter 5 describes WSML-Flight, which is an extension of WSML-Core in the direction of Logic Programming. WSML-Flight is a more powerful language and offers more expressive modeling constructs than WSML-Core. The extension described by WSML-Flight is disjoint from the extension described by WSML-DL. Chapter 6 describes WSML-Rule,which is a full-blown Logic Programming language; WSML-Rule allows the use of function symbols and does not require rule safety. It is an extension of WSML-Flight and thus it offers the same kind of conceptual modeling features. Chapter 7, presents WSML-Full which is a superset of both WSML-Rule and WSML-DL. WSML-Full can be seen as a notational variant of First-Order Logic with nonmonotonic extensions. Finally, Chapter 8 defines the WSML semantics.

PART III: THE WSML EXCHANGE SYNTAXES

The WSML variants are described in terms of their normative human-readable language in PART II. Although this syntax has been formally specified in the form of a grammar (see also Appendix A), there are limitations with respect to the exchange of the syntax over the Web. Therefore, Chapter 9 presents the XML exchange syntax for WSML, which is the preferred syntax for the exchange of WSML specifications between machines. Chapter 10 describes the RDF syntax of WSML, which can be used by RDF-based applications. Chapter 11, finally, describes a mapping between WSML and OWL ontologies in order to allow interoperation with OWL-based applications.

PART IV: FINALE

We conclude the document with describing efforts related to the WSML language in Chapter 12. These related efforts are mostly concerned with implementation of WSML-based tools and tools utilizing WSML for specific purposes.

Appendix Guide

Appendix A consists of the formal grammar shared by all WSML variants, as well as a complete integrated example WSML specification to which references are made in the various chapters of this document. Appendix B contains references to the XML Schemas, the XML Schema documentation and the XML version of the WSML example from Appendix A. These documents are all online resources. Appendix C describes the built-in predicates and datatypes of WSML, as well as a set of infix operators which correspond with particular built-in predicates. Appendix D contains a complete list of WSML keywords, as well as references to the sections in the document where these are described. Finally, Appendix E describes the relation between WSML and the WSMO conceptual model.

PART II: WSML VARIANTS

Figure 1 shows the different variants of WSML and the relationship between the variants. In the figure, an arrow stands for "extension in the direction of". The variants differ in the logical expressiveness they offer and in the underlying language paradigm. By offering these variants, we allow users to make the trade-off between the provided expressivity and the implied complexity on a per-application basis. As can be seen from the figure, the basic language WSML-Core is extended in two directions, namely, Description Logics (WSML-DL) and Logic Programming (WSML-Flight, WSML-Rule). WSML-Rule and WSML-DL are both extended to a full First-Order Logic with nonmonotonic extensions (WSML-Full), which unifies both paradigms.

As can be seen from Figure 2, WSML has two alternative layerings, namely, WSML-Core -> WSML-DL -> WSML-Full and WSML-Core -> WSML-Flight -> WSML-Rule -> WSML-Full. In both layerings, WSML-Core is the least expressive and WSML-Full is the most expressive language. The two layerings are to a certain extent disjoint in the sense that interoperation between the Description Logic variant (WSML-DL) on the one hand and the Logic Programming variants (WSML-Flight and WSML-Rule) on the other, is only possible through a common core (WSML-Core) or through a very expressive (undecidable) superset (WSML-Full). However, there are proposals which allow interoperation between the two while retaining decidability of the satisfiability problem, either by reducing the expressiveness of one of the two paradigms, thereby effectively adding the expressiveness of one of the two paradigms to the intersection (cf. [Levy &Rousset, 1998]) or by reducing the interface between the two paradigms and reason with both paradigms independently (cf. [Eiter et al., 2004]).[1]

The only languages currently specified in this document are WSML-Core, WSML-Flight and WSML-Rule. WSML-DL will correspond (semantically) with the Description Logic SHIQ(D_n), extended with more extensive datatype support. WSML-Full will be based on First-Order logic with specific extensions to accommodate the non-first order features of WSML-Rule.

In the descriptions in the subsequent chapters we use fragments of the WSML grammar (see Appendix A.1 for the full grammar) in order to show the syntax of the WSML elements. The grammar is specified using a dialect of Extended BNF which can be used directly in the SableCC compiler compiler [SableCC]. Terminals are delimited with single quotes, non-terminals are underlined and refer to the corresponding productions. Alternatives are separated using vertical bars '|'; optional elements are appended with a question mark '?'; elements that may occur zero or more times are appended with an asterisk '*'; elements that may occur one or more times are appended with a plus '+'. In the case of multiple references to the same non-terminal in a production, the non-terminals are disambiguated by using labels of the form '[label]:'. In order to keep the descriptions in this Part concise, we do not fully describe all non-terminals. Non-terminals are linked to the grammar in Appendix A.

Throughout the WSML examples in the following chapters, we use boldfaced text to distinguish WSML keywords.

2. WSML Syntax

In this chapter we introduce the WSML syntax. The general WSML syntax captures all features of all WSML variants and thus corresponds with the syntax for WSML-Full. Subsequent chapters will define restrictions on this syntax for the specification of specific WSML variants.

The WSML syntax consists of two major parts: the conceptual syntax and the logical expression syntax. The conceptual syntax is used for the modeling of ontologies, goals, web services and mediators; these are the elements of the WSMO conceptual model. Logical expressions are used to refine these definitions using a logical language.

This chapter is structured as follows. The WSML syntax basics, such as the use of namespaces, identifiers, etc., are described in Section 2.1. The elements in common between all WSML specifications are described in Section 2.2. WSML ontologies are described in Section 2.3. The elements shared between goals and web services, namely, capabilities and interfaces, are described in Section 2.4. Goals, mediators and web services are described in Sections 2.5, 2.6 and 2.7, respectively. Finally, the WSML logical expression syntax is specified in Section 2.8.

2.1 WSML Syntax Basics

The conceptual syntax for WSML has a frame-like style. The information about a class and its attributes, a relation and its parameters and an instance and its attribute values is specified in one large syntactic construct, instead of being divided into a number of atomic chunks. It is possible to spread the information about a particular class, relation, instance or axiom over several constructs, but we do not recommend this. In fact, in this respect, WSML is similar to OIL [Fensel et al., 2001], which also offers the possibility of either grouping descriptions together in frames or spreading the descriptions throughout the document. One important difference with OIL (and OWL) is that attributes are defined locally to a class and should in principle not be used outside of the context of that class and its subclasses.

Nonetheless, attribute names are global and it is possible to specify global behavior of attributes through logical expressions. However, we do not expect this to be necessary in the general case and we strongly advise against it.

It is often possible to specify a list of arguments, for example for attributes. Such argument lists in WSML are separated by commas and surrounded by curly brackets. Statements in WSML start with a keyword and can be spread over multiple lines.

A WSML specification is separated into two parts. The first part provides meta-information about the specification, which consists of such things as WSML variant identification, namespace references, non-functional properties (annotations), import of ontologies, references to mediators used and the type of the specification. This meta-information block is strictly ordered. The second part of the specification, consisting of elements such as concepts, attributes, relations (in the case of an ontology specification), capability, interfaces (in the case of a goal or web service specification), etc., is not ordered.

The remainder of this section explains the use of namespaces, identifiers and datatypes in WSML. Subsequent sections explain the different kinds of WSML specifications and the WSML logical expression syntax.

2.1.1 Namespaces in WSML

Namespaces were first introduced in XML [XMLNamespaces] for the purpose of qualifying names which originate from different XML documents. In XML, each qualified name consists of a tuple <namespace, localname>. RDF adopts the mechanism of namespaces from XML with the difference that qualified names are not treated as tuples, but rather as abbreviations for full URIs.

WSML adopts the namespace mechanism of RDF. A namespace can be seen as part of an IRI (see the next Section). The WSML keywords themselves belong to the namespace http://www.wsmo.org/wsml/wsml-syntax# (commonly abbreviated as 'wsml').

Namespaces can be used to syntactically distinguish elements of multiple WSML specifications and, more generally, resources on the Web. A namespace denotes a syntactical domain for naming resources.

Whenever a WSML specification has a specific identifier which corresponds to a Web address, it is good practice to have a relevant document on the location pointed to by the identifier. This can either be the WSML document itself or a natural language document related to the WSML document. Note that the identifier of an ontology does not have to coincide with the location of the ontology. It is good practice, however, to include a related document, possibly pointing to the WSML specification itself, at the location pointed to by the identifier.

2.1.2 Identifiers in WSML

Data values

WSML has direct support for different types of concrete data, namely, strings, integers and decimals, which correspond to the XML Schema [XMLSchemaDatatypes] primitive datatypes string, integer and decimal. These concrete values can then be used to construct more complex datatypes, corresponding to other XML Schema primitive and derived datatypes, using datatype constructor functions. See also Appendix C.

WSML uses datatype wrappers to construct data values based on XML Schema datatypes. The use of datatype wrappers gives more control over the structure of the data values than the lexical representation of XML. For example, the date: 3 February 2005, which can be written in XML as: '2005-02-03', is written in WSML as: _date(2005,2,3). The arguments of such a term can be either strings, decimals, integers or variables. No other arguments are allowed for such data terms. Each conforming WSML implementation is required to support at least the string, integer and decimal datatypes.

Datatype identifiers manifest themselves in WSML in two distinct ways, namely, as concept identifers and as datatype wrappers. A datatype wrapper is used as a datastructure for capturing the different components of data values. Datatype identifiers can also be used directly as concept identifiers. Note however that the domain of interpretation of any datatype is finite and that asserting membership of a datatype for a value which does not in fact belong to this datatype, leads to an inconsistency in the knowledge base.

The following are example attribute definitions which restrict the range of the attribute to a particular datatype:

Appendix C lists the built-in predicates which any conforming WSML application must be able to support, as well as the infix notation which serves as a shortcut for the built-ins.

Furthermore, WSML also allows shortcut syntax for IRI and sQName data values, as described below.

Internationalized Resource Identifiers

The IRI (Internationalized Resource Identifier) [IRI] mechanism provides a way to identify resources. IRIs may point to resources on the Web (in which case the IRI can start with 'http://'), but this is not necessary (e.g., books can be identified through IRIs starting with 'urn:isbn:'). The IRI proposed standard is a successor to the popular URI standard. In fact, every URI is an IRI.

An IRI can be abbreviated to an sQName. Note that the term 'QName' has been used, after its introduction in XML [XMLNamespaces], with different meanings. The meaning of the term 'QName' as defined in XML got blurred after the adoption of the term in RDF. In XML, QNames are simply used to qualify local names and thus every name is a tuple <namespace, localname>. In RDF, QNames have become abbreviations for URIs, which is different from the meaning in XML. WSML adopts a view similar to the RDF-like version of QNames, but due to its deviation from the original definition in XML we call them sQNames which is short for 'serialized QName'.

An sQName is equivalent to the IRI which is obtained by concatenating the namespace IRI (to which the prefix refers) with the local part of the sQName. Therefore, an sQName can be seen as an abbreviation for an IRI which enhances the legibility of the specification. If an sQName has no prefix, the namespace of the sQName is the default namespace of the document.

An sQName consists of two parts, namely, the namespace prefix and the local part. WSML allows two distinct ways to write sQNames. sQName can be seen as a datatype and thus it has an associated datatype wrapper, namely, _sqname (see also Appendix C), which has two arguments: namespace and localname. Because sQNames are very common in WSML specifications, WSML allows a short syntax for sQNames. An sQName can simply be written using a namespace prefix and a localname, separated by a hash ('#'): namespace_prefix#localname. It is also possible to omit the namespace prefix and the hash symbol. In this case, the name is defined in the default namespace.

IRI is a datatype in WSML and has the associated datatype wrapper _iri with one argument (the IRI). For convenience, WSML also allows a short form with the delimiters ' _" ' and ' " '. For convenience, an sQName does not require special delimiters. However, sQNames may not coincide with any WSML keywords. The characters '.' and '-' in an sQName need to be escaped using a '\':

Examples of sQNames in WSML (with corresponding full IRIs; dc stands for http://purl.org/dc/elements/1.1#, foaf stands for http://xmlns.com/foaf/0.1/ and xsd stands for http://www.w3.org/2001/XMLSchema#; we assume the default namespace http://example.org/#):

WSML defines the following two IRIs: http://www.wsmo.org/wsml/wsml-syntax#true and http://www.wsmo.org/wsml/wsml-syntax#false, which stand for universal truth and universal falsehood, respectively. Note that for convenience we typically use the abbreviated sQName form (where wsml stands for the default WSML namespace http://www.wsmo.org/wsml/wsml-syntax#): wsml#true, wsml#false. Additionally, WSML allows the keywords 'true' and 'false' in the human-readable syntax.

Please note that the IRI of a resource does not necessarily correspond to a document on the Web. Therefore, we distinguish between the identifier and the locator of a resource. The locator of a resource is an IRI which can be mapped to a location from which the (information about the) resource can be retrieved.

Anonymous Identifiers

An anonymous identifier represents an IRI which is meant to be globally unique. Global uniqueness is to be ensured by the system interpreting the WSML description (instead of the author of the specification). It can be used whenever the concrete identifier to be used to denote an object is not relevant, but when we require the identifier to be new (i.e., not used anywhere else in the WSML description).

Anonymous identifiers in WSML follow the naming convention for anonymous IDs presented in [Yang & Kifer, 2003]. Unnumbered anonymous IDs are denoted with ‘_#’. Each occurrence of ‘_#’ denotes a new anonymous ID and different occurrences of ‘_#’ are unrelated. Thus each occurrence of an unnumbered anonymous ID can be seen as a new unique identifier.

Numbered anonymous IDs are denoted with ‘_#n’ where n stands for an integer denoting the number of the anonymous ID. The use of numbered anonymous IDs is limited to logical expressions and can therefore not be used to denote entities in the conceptual syntax. Multiple occurrences of the same numbered anonymous ID within the same logical expression are interpreted as denoting the same object.

There are in total three occurrences of the unnumbered anonymous ID. All occurrences are unrelated. Thus, the second logical expression does not state that an object is a member of itself, but rather that some anonymous object is a member of some other anonymous object. The two occurrences of _#1 in the first logical expression denote the same object. Thus the value of attribute a is a member of b. The occurrence of _#1 in the second logical expression is, however, not related to the occurrence of _#1 in the first logical expression.

The use of an identifier in the specification of WSML elements is optional. If no identifier is specified, the following default rules apply:

If the same identifier is used for different definitions, it is interpreted differently, depending on the context. In a concept definition, an identifier is interpreted as a concept; in a relation definition this same identifier is interpreted as a relation. If, however, the same identifier is used in separate definitions, but with the same context, then the interpretation of the identifier has to conform to both definitions and thus the definitions are interpreted conjunctively. For example, if there are two concept definitions which are concerned with the same concept identifier, the resulting concept definition includes all attributes of the original definitions and if the same attribute is defined in both definitions, the range of the resulting attribute will be equivalent to the conjunction of the original attributes.

Note that the sets of identifiers for the top-level elements, namely ontology, goal, webService, ooMediator, ggMediator, wgMediator and wwMediator, are pairwise disjoint and also disjoint from all other identifiers.

2.1.3 Comments in WSML

A WSML file may at any place contain a comment. A single line comment starts with comment or // and ends with a line break. Comments can also range over multiple lines, in which they need to be delimited by /* and */.

It is recommended to use non-functional properties for any information related to the actual WSML descriptions; comments should be only used for meta-data about the WSML file itself. Comments are disregarded when parsing the WSML document.

2.2 WSML Elements

This section describes the elements in common between all types of WSML specifications and all WSML variants. The elements described in this section are used in Ontology, Goal, Mediator and Web service specifications. The elements specific to a type of specification are described in subsequent sections. Because all elements in this section are concerned with meta-information about the specification and thus do not depend on the logical formalism underlying the language, these elements are shared among all WSML variants.

In this section we only describe how each element should be used. The subsequent sections will describe how these elements fit in the specific WSML descriptions.

2.2.1 WSML Variant

Every WSML specification document may start with the wsmlVariant keyword, followed by an identifier for the WSML variant which is used in the document. Table 2.1 lists the WSML variants and the corresponding identifiers in the form of IRIs.

Table 2.1: WSML variant identifiers
WSML Variant	IRI
WSML-Core	http://www.wsmo.org/wsml/wsml-syntax/wsml-core
WSML-Flight	http://www.wsmo.org/wsml/wsml-syntax/wsml-flight
WSML-Rule	http://www.wsmo.org/wsml/wsml-syntax/wsml-rule
WSML-DL	http://www.wsmo.org/wsml/wsml-syntax/wsml-dl
WSML-Full	http://www.wsmo.org/wsml/wsml-syntax/wsml-full

The specification of the wsmlVariant is optional. In case no variant is specified, no guarantees can be made with respect to the specification and WSML-Full may be assumed.

The following illustrates the WSML variant reference for a WSML-Flight specification:

When the intended WSML variant is explicitly stated, tools can immediately recognize the intention of the author and return an exception if the specification does not conform to the syntactical restrictions imposed by the intended variant. This generally helps developers of WSML specifications to stay within desired limits of complexity and to communicate their desires to others.

2.2.2 Namespace References

At the top of a WSML document, below the identification of the WSML variant, there is an optional block of namespace references, which is preceded by the namespace keyword. The namespace keyword is followed by a number of namespace references. Each namespace reference, except for the default namespace, consists of the chosen prefix and the IRI which identifies the namespace. Note that, like any argument list in WSML, the list of namespace references is delimited with curly brackets ‘{’ ‘}’. In case only a default namespace is declared, the curly brackets are not required.

Two examples are given below, one with a number of namespace declarations and one with only a default namespace:

2.2.3 Header

Any WSML specification may have non-functional properties, may import ontologies and may use mediators:

Non-Functional Properties

Non-functional properties may be used for the WSML document as a whole but also for each element in the specification. Non-functional property blocks are delimited with the keywords nonFunctionalProperties and endNonFunctionalProperties or the short forms nfp and endnfp. Following the keyword is a list of attribute values, which consists of the attribute identifier, the keyword hasValue and the value for the attribute, which may be any identifier and can thus be an IRI, a data value, an anonymous identifier or a comma-separated list of the former, delimited with curly brackets. The recommended properties are the properties of the Dublin Core [DublinCore], but the list of properties is extensible and thus the user can choose to use properties coming from different sources. WSMO defines a number of properties which are not in the Dublin Core. These properties can be used in a WSML specification by referring to the WSML namespace (http://www.wsmo.org/wsml/wsml-syntax#). These properties are: wsml#version, wsml#accuracy, wsml#financial, wsml#networkRelatedQoS, wsml#performance, wsml#reliability, wsml#robustness, wsml#scalability, wsml#security, wsml#transactional, wsml#trust (here we assume that the prefix wsml has been defined as referring to the WSML namespace; see Section 2.1.1). For recommended usage of these properties see the WSMO document in this submission. Following the WSML convention, if a property has multiple values, these are separated by commas and the list of values is delimited by curly brackets.

Non-functional properties in WSML are not part of the logical language; programmatic access to these properties can be provided through an API.

Importing Ontologies

Ontologies may be imported in any WSML specification through the import ontologies block, identified by the keyword importsOntology. Following the keyword is a list of IRIs identifying the ontologies being imported. An importsOntology definition serves to merge ontologies, similar to the owl:import annotation property in OWL. This means the resulting ontology is the union of all axioms and definitions in the importing and imported ontologies. Please note that recursive import of ontologies is also supported. This means that if an imported ontology has any imported ontologies of its own, these ontologies are also imported.

If the imported ontology is of a different WSML variant than the importing specification, the resulting ontology is of the most expressive of the two variants. If the expressiveness of the variants is to some extent disjoint (e.g., when importing a WSML-DL ontology in a WSML-Rule specification), the resultant will be of the least common superset of the variants. In the case of WSML-DL and WSML-Rule, the least common superset is WSML-Full.

Using Mediators

Mediators are used to link different WSML elements (ontologies, goal, web services) and resolve heterogeneity between the elements. Mediators are described in more detail in Section 2.5. Here, we are only concerned with how mediators can be referenced from a WSML specification. Mediators are currently underspecified and thus this reference to the use of mediators can be seen as a placeholder.

The (optional) used mediators block is identified by the keywords usesMediator which is followed by one or more identifiers of WSML mediators. The types of mediators which can be used are constrained by the type of specification. An ontology allows for the use of different mediators than, for example, a goal or a web service. More details on the use of different mediators can be found in Section 2.5. The type of the mediator is reflected in the mediator specification itself and not in the reference to the mediator.

2.3 Ontology Specification in WSML

A WSML ontology specification is identified by the ontology keyword optionally followed by an IRI which serves as the identifier of the ontology. If no identifier is specified for the ontology, the locator of the ontology serves as identifier.

In this section we explain the ontology modeling elements in the WSML language. The modeling elements are based on the WSMO conceptual model of ontologies.

2.3.1 Concepts

A concept definition starts with the concept keyword, which is optionally followed by the identifier of the concept. This is optionally followed by a superconcept definition which consists of the keyword subConceptOf followed by one or more concept identifiers (as usual, if there is more than one, the list is comma-separated and delimited by curly brackets). This is followed by an optional nonFunctionalProperties block and zero or more attribute definitions.

Note that WSML allows inheritance of attribute definitions, which means that a concept inherits all attribute definitions of its superconcepts. If two superconcepts have an definitio for the same attribute a, but with a different range, these attribute definitions are interpreted conjunctively. This means that the resulting range of the attribute a in the subconcept is the conjunction (intersection) of the ranges of the attribute definitions in the superconcepts.

WSML allows creation of axioms in order to refine the definition already given in the conceptual syntax, i.e., the subconcept and attribute definitions. It is advised in the WSML specification to include the relation between the concept and the axioms related to the concept in the non-functional properties through the property dc#relation. In the example above we refer to an axiom with the identifier humanDefinition (see Section 2.3.4 for the axiom).

Different knowledge representation languages, such as Description Logics, allow for the specification of defined concepts (called "complete classes" in OWL). The definition of a defined concept is not only necessary, but also sufficient. A necessary definition, such as the concept specification in the example above, specifies implications of membership of the concept for all instances of this concept. The concept description above specifies that each instance of Human is also an instance of Primate and LegalAgent. Furthermore, all values for the attributes hasName, hasParent, hasWeight etc. must be of specific types. A necessary and sufficient definition also works the other way around, which means that if certain properties hold for the instance, the instance is inferred to be a member of this concept.

WSML supports defined concepts through the use of axioms (see Section 2.3.4). The logical expression contained in the axiom should reflect an equivalence relation between a class membership expression on one side and a conjunction of class membership expressions on the other side, each with the same variable. Thus, such a definition should be of the form:

For example, in order to define the class Human as the intersection of the classes Primate and LegalAgent, the following definition is used:

Attributes

WSML allows two kinds of attribute definitions, namely, constraining definitions with the keyword ofType and inferring definitions with the keyword impliesType. We expect that inferring attribute definitions will not be used very often if constraining definitions are allowed. However, several WSML variants, namely, WSML-Core and WSML-DL, do not allow constraining attribute definitions. In order to facilitate conceptual modeling in these language variants, we allow the use of impliesType in WSML.

An attribute definition of the form

A ofType
D

, where A is an attribute identifier and D is a concept identifier, is a constraint on the values for attribute A. If the value for the attribute A is not known to be of type D, the constraint is violated and the attribute value is inconsistent with respect to the ontology. This notion of constraints corresponds with the usual database-style constraints.

The keyword impliesType can be used for inferring the type of a particular attribute value. An attribute definition of the form A impliesType D, where A is an attribute identifier and D is a concept identifier, implies membership of the concept D for all values of the attribute A. Please note that if the range of the attribute is a datatype, the semantics of ofType and impliesType coincide, because datatypes have a known domain and thus values cannot be inferred to be of a certain datatype.

Data attributes in WSML can be distinguished from concept attributes through the meta-concept _datatype. Each datatype used in WSML is a member of this meta-concept.

Concept attributes (i.e., attributes which do not have a datatype as range) can be specified as being reflexive, transitive, symmetric, or being the inverse of another attribute, using the reflexive, transitive, symmetric and inverseOf keywords, respectively. Notice that these keywords do not enforce a constraint on the attribute, but are used to infer additional information about the attribute. The keyword inverseOf must be followed by an identifier of the attribute, enclosed in parentheses, of which this attribute is the inverse.

The cardinality constraints for a single attribute are specified by including two numbers between parentheses '(' ')', indicating the minimal and maximal cardinality, after the ofType (or impliesType) keyword. The first number indicates the minimal cardinality. The second number indicates the maximal cardinality, where '*' stands for unlimited maximal cardinality (and is not allowed for minimal cardinality). It is possible to write down just one number instead of two, which is interpreted as both a minimal and a maximal cardinality constraint. When the cardinality is omitted, then it is assumed that there are no constraints on the cardinality, which is equivalent to (0 *). Note that a maximal cardinality of 1 makes an attribute functional.

When an attribute is specified as being transitive, this means that if three individuals a, b and c are related via a transitive attribute att in such a way: a att b att c then c is also a value for the attribute att at a: a att c.

When an attribute is specified as being symmetric, this means that if an individual a has a symmetric attribute att with value b, then b also has attribute att with value a.

When an attribute is specified as being the inverse of another attribute, this means that if an individual a has an attribute att1 with value b and att1 is the inverse of a certain attribute att2, then it is inferred that b has an attribute att2 with value a.

2.3.2 Relations

A relation definition starts with the relation keyword, which is optionally followed by the identifier of the relation. WSML allows the specification of relations with arbitrary arity. The domain of the parameters can be optionally specified using the keyword impliesType or ofType. Note that parameters of a relation are strictly ordered. A relation definition is optionally completed by the keyword subRelationOf followed by one or more identifiers of superrelations. Finally an optional nonFunctionalProperties block can be specified.

Relations in WSML can have an arbitrary arity and values for the parameters can be constrained using parameter type definitions of the form ( ofType type-name ) and ( impliesType type-name). The definition of relations requires either the indication of the arity or of the parameter definitions. The usage of ofType and impliesType correspond with the usage in attribute definitions. Namely, parameter definitions with the ofType keyword are used to constrain the allowed parameter values, whereas parameter definitions with the impliesType keyword are used to infer concept membership of parameter values.

Below are two examples, one with parameter definitions and one with an arity definition:

As for concepts, the exact meaning of a relation can be defined using axioms. For example one could axiomatize the transitive closure for a property or further restrict the domain of one of the parameters. As with concepts, it is recommended that related axioms are indicated using the non-functional property dc#relation.

2.3.3 Instances

An instance definition starts with the instance keyword, (optionally) followed by the identifier of the instance, the memberOf keyword and the name of the concept to which the instance belongs. The memberOf keyword identifies the concept to which the instance belongs. This definition is followed by the attribute values associated with the instance. Each property filler consists of the property identifier, the keyword hasValue and the value(s) for the attribute.

Instances explicitly specified in an ontology are those which are shared together as part of the ontology. However, most instance data exists outside the ontology in private data stores. Access to these instances, as described in the WSMO document, is achieved by providing a link to an instance store. Instance stores contain large numbers of instances and they are linked to the ontology. We do not restrict the user in the way an instance store is linked to a WSML ontology. This would be done outside the ontology definition, since an ontology is shared and can thus be used in combination with different instance stores.

Besides specifying instances of concepts, it is also possible to specify instances of relations. Such a relation instance definition starts with the relationInstance keyword, (optionally) followed by the identifier of the relationInstance, the memberOf keyword and the name of the relation to which the instance belongs. This is followed by an optional nonFunctionalProperties block, followed by the values of the parameters associated with the instance.

Below is an example of an instance of a ternary relation (remember that the identifier is optional, see also Section 2.1.2):

2.3.4 Axioms

An axiom definition starts with the axiom keyword, followed by the name (identifier) of the axiom. This is followed by an optional nonFunctionalProperties block and a logical expression preceded by the definedBy keyword. The logical expression must be followed by either a blank or a new line. The language allowed for the logical expression is explained in Section 2.8.

WSML allows the specification of database-style constraints. Below is an example of a constraining axiom:

2.4 Capability and Interface Specification in WSML

The desired and provided functionality are described in WSML in the form of capabilities. The desired capability is part of a goal and the provided capability is part of a web service. The interaction style of both the requester and the provider is described in interfaces, as part of the goal and the web service, respectively.

2.4.1 Capabilities

A WSML goal or web service may only have one capability. The specification of a capability is optional.

A capability description starts with the capability keyword, (optionally) followed by the name (identifier) of the capability. This is followed by an optional nonFunctionalProperties block, an optional importsOntology block and an optional usesMediator block. The sharedVariables block is used to indicate the variables which are shared between the preconditions, postconditions, assumptions and effects of the capability, which are defined in the precondition, postcondition, assumption, and effect definitions, respectively. The number of such definitions is not restricted. Each of these definitions consists of the keyword, an optional identifier, an optional nonFunctionalProperties block and a logical expression preceded by the definedBy keyword, and thus has the same content as an axiom (see Section 2.3.4). The language allowed for the logical expression differs per WSML variant and is explained in the respective chapters.

2.4.2 Interface

A WSML goal may request multiple interfaces and a web service may offer multiple interfaces. The specification of an interface is optional.

An interface specification starts with the interface keyword, (optionally) followed by the name (identifier) of the interface. This is followed by an optional nonFunctionalProperties block, an optional importsOntology block and an optional usedMediator block and then by an optional choreography block consisting of the keyword choreography followed by the identifier of the choreography and an optional orchestration block consisting of the keyword orchestration followed by the identifier of the orchestration. Note that thus an interface can have at most one choreography and at most one orchestration. It is furthermore possible to reference interfaces which have been specified at a different location. For reasons of convenience, WSML allows the referencing of multiple interfaces using an argument list.

Below is an example of an interface and an example of references to multiple interfaces:

We do not define ways to specify the choreography and orchestration here. Instead, we refer the reader to the WSMO document in this submission.

2.5 Goal Specification in WSML

A WSML goal specification is identified by the goal keyword optionally followed by an IRI which serves as the identifier of the goal. If no identifier is specified for the goal, the locator of the goal serves as identifier.

The elements of a goal are the capability and the interfaces which are explained in the previous section.

2.6 Mediator Specification in WSML

WSML allows for the specification of four kinds of mediators, namely ontology mediators, mediators between web services, mediators between goals and mediators between web services and goals. These mediators are referred via the keywords ooMediator, wwMediator, ggMediator and wgMediator, respectively (cf. WSMO).

A WSML mediator specification is identified by the keyword indicating a particular kind of mediator (ooMediator, wwMediator, ggMediator, wgMediator), optionally followed by an IRI which serves as the identifier of the mediator. When no identifier is specified for the mediator, the locator of the mediator serves as identifier.

All types of mediators share the same syntax for the sources, targets and services used:

2.6.1 ooMediators

ooMediators are used to connect ontologies to other ontologies, web services, goals and mediators. ooMediators take care of resolving any heterogeneity which occurs.

The source of an ooMediator in WSML may only contain identifiers of ontologies and other ooMediators as source.

An ooMediator in WSML may only have one target. The target may be the identifier of an ontology, a goal, a web service or another mediator.

The keyword usesService is used to identify a goal which declaratively describes the mediation service, a web service which actually implements the mediation or a wwMediator which links to such a web service. The entity pointed to is given by an identifier

An ooMediator is used to import (parts of) ontologies and resolve heterogeneity. This concept of mediation between ontologies is more flexible than the importsOntology statement, which is used to import a WSML ontology into another WSML specification. The ontology import mechanism appends the definitions in the imported ontology to the importing specification.

In fact, importing ontologies can be seen as a simple form of mediation, in which no heterogeneity is resolved. However, usually there are mismatches and overlaps between the different ontologies which require mediation. Furthermore, if the imported ontology is specified using a WSML variant which has an undesirable expressiveness, a mediator could be used to weaken the definitions to the desired expressiveness.

2.6.2 wwMediators

wwMediators connect Web services, resolving any data, process and protocol heterogeneity between the two.

wwMediators in WSML may only have one source. The source may be the identifier of a web service or another wwMediator.

wwMediators in WSML may only have one target. The target may be the identifier of a web service or another wwMediator.

2.6.3 ggMediators

ggMediators connect different goals, enabling goals to refine more general goals and thus enabling reuse of goal definitions.

ggMediators in WSML may only have one source. The source may be the identifier of a goal or another ggMediator.

ggMediators in WSML may only have one target. The target may be the identifier of a goal or another ggMediator.

2.6.4 wgMediators

wgMediators connect goals and web services, resolving any data, process and protocol heterogeneity.

wgMediators in WSML may only have one source. The source may be the identifier of a web service or another wgMediator.

wgMediators in WSML may only have one target. The target may be the identifier of a goal or a ggMediator.

By externalizing the mediation services from the implementation of ontologies, goals and web services, WSML allows loose coupling of elements; the mediator is responsible for relating the different elements to each other and resolving conflicts and mismatches. For more details we refer to the WSMO document.

None of the elements in a mediator has any meaning in the logical language. In fact, the complexity of a mediator is hidden in the actual description of the mediator. Instead, the complexity is either in the implementation of the mediation service, in which case WSML does not support the description because WSML is only concerned with the interface description, or in the functional description of the web service or the goal which is used to specify the desired mediation service. As discussed in [Keller et al., 2004], these descriptions often need a very expressive language.

2.7 Web Service Specification in WSML

A WSML web service specification is identified by the webService keyword optionally followed by an IRI which serves as the identifier of the web service. If no identifier is specified for the web service, the locator of the web service specification serves as identifier.

The elements of a web service are capability and interface which are explained in Section 2.4.

2.8 Logical Expressions in WSML

Logical expressions occur within axioms and the capabilities which are specified in the descriptions of goals and Semantic Web services. In the following, we give a syntax specification for general logical expressions in WSML. The general logical expression syntax presented in this chapter encompasses all WSML variants and is thus equivalent to the WSML-Full logical expression syntax. In the subsequent chapters, we specify for each of the WSML variants the restrictions the variant imposes on the logical expression syntax.

In order to specify the WSML logical expressions, we introduce a new kind of identifier: variables.

Variables

Variable names start with an initial question mark, "?". Variables may occur in place of concepts, attributes, instances, relation arguments or attribute values. A variable may not, however, replace a WSML keyword. Furthermore, variables may only be used inside logical expressions.

The scope of a variable it always defined by its quantification. If a variable is not quantified inside a formula, the variable is implicitly universally quantified outside the formula, unless the formula is part of a capability description and the variable is explicitly mentioned in the sharedVariables block.

We start with the definition of the basic vocabulary for building logical expressions. Then, we define how the elements of the basic vocabulary can be composed in order to obtain admissible logical expressions. Definition 2.1 defines the notion of a vocabulary V of a WSML language L.

Definition 2.1. A vocabulary V of a WSML language L(V) consists of the following:

WSML allows the following logical connectives: and, or, implies, impliedBy, equivalent, neg, naf, forAll and exists and the following auxiliary symbols: '(', ')', '[', ']', ',', '=', '!=', ':=:', memberOf, hasValue, subConceptOf, ofType, and impliesType. Furthermore, WSML allows use of the symbol ':-' for Logic Programming rules and the use of the symbol '!-' for database-style constraints.

Definition 2.2. Given a vocabulary V, the set of terms Term(V) in WSML is defined as follows:

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

Based on the basic constructs of logical expressions, the terms, we can now define formulae. In WSML, we have atomic formulae and complex formulae. Each formula is terminated by a period.

Definition 2.3. Given a set of terms Term(V), the set of atomic formulae in L(V) is defined by:

Given the atomic formulae, we recursively define the set of formulae in L(V) in definition 2.4.

Note that WSML allows the symbols ->, <- and <-> as synonyms for implies, impliedBy, and equivalent, respectively.

The precedence of the operators is as follows: implies, equivalent, impliedBy < or, and < neg, naf. Here, op₁ < op₂ means that operator op₂ binds stronger than operator op₁. The precedence prevents extensive use of parenthesis and thus helps to achieve a better readability of logical expressions.

To enhance the readability of logical expressions it is possible to abbreviate a conjunction of several modules with the same subject as one compound molecule. E.g., the three molecules

The following are examples of WSML logical expressions (note that variables are implicitly universally quantified):

3. WSML-Core

As described in the introduction to this Part, there are several WSML language variants with different underlying logical formalisms. The two main logical formalisms exploited in the different WSML language variants are Description Logics [Baader et al., 2003] (exploited in WSML-DL) and Rule Languages [Lloyd, 1987] (exploited in WSML-Flight and WSML-Rule). WSML-Core, which is described in this chapter, marks the intersection of both formalisms. WSML-Full, which is the union of both paradigms, is described in Chapter 7.

WSML-Core is based on the Logic Programming subset of Description Logics described in [Grosof et al., 2003]. More specifically, WSML-Core is based on plain (function- and negation-free) Datalog, thus, the decidability and complexity results of Datalog apply to WSML-Core as well. The most important result is that Datalog is data complete for P, which means that query answering can be done in polynomial time.[2]

Many of the syntactical restrictions imposed by WSML-Core are a consequence of the limitation of WSML-Core to Description Logic Programs as defined in [Grosof et al., 2003].

This chapter is further structured as follows. We first introduce basics of the WSML-Core syntax, such as the use of namespaces, identifiers, etc. in Section 3.1. We describe the restrictions WSML-Core poses on the modeling of ontologies, goals, mediators and web services in sections 3.2, 3.3, 3.4 and 3.5, respectively. Finally, we describe the restrictions on logical expressions in WSML-Core in Section 3.6.

3.1 Basic WSML-Core Syntax

WSML-Core inherits the basics of the WSML syntax specified in Section 2.1. In this section we describe restrictions WSML-Core poses on the basic syntax.

WSML-Core restricts the use of identifiers. The vocabulary of WSML-Core is separated similarly to OWL DL.

Definition 3.1. A WSML-Core vocabulary V follows the following restrictions:

3.2 WSML-Core Ontologies

In this section we explain the restrictions on the WSML ontology modeling elements imposed by WSML-Core. The restrictions posed on the conceptual syntax for ontologies is necessary because of the restriction imposed on WSML-Core by the chosen underlying logical formalism (the intersection of Datalog and Description Logics), cf. [de Bruijn et al., 2004].

The grammar fragments shown in the following subsections only concern those parts of the grammar which are different from the general WSML grammar.

3.2.1 Concepts

WSML-Core poses a number of restrictions on attribute definitions. Most of these restrictions stem from the fact that it is not possible to express constraints in WSML-Core, other than for datatypes.

WSML-Core does not allow for the specification of the attribute features reflexive, transitive, symmetric and inverseOf. This restriction stems from the fact that reflexivity, transitivity, symmetricity and inversity of attributes are defined locally to a concept in WSML as opposed to Description Logics or OWL. You can however define global transitivity, symmetricity and inversity of attributes just like in DLs or OWL by defining respective axioms (cf. Definition 3.3 below).

Cardinality constraints are not allowed and thus it is not possible to specify functional properties.

It is not allowed to specify constraining attribute definitions, other than for datatype ranges. In other words, attribute definitions of the form: A ofType D are not allowed, unless D is a datatype identifier.

3.2.2 Relations

In WSML-Core, the arity of relations is restricted to two. The domain of the two parameters may be given using the keyword impliesType or ofType. However, the ofType keyword is only allowed in combination with a datatype and only the second parameter may have a datatype as its range.

Binary relations are in an ontological sense nothing more than attribute definitions. In most cases, it is thus highly recommended to define attributes on concepts instead of using binary relations.

3.2.3 Instances

WSML-Core does not impose restrictions on the specification of instances for concepts. Relation instances are only allowed for binary relations. Both values of the relation have to be specified and have to correspond to its signature. This includes the restriction that the first value may not be an data value.

3.2.4 Axioms

WSML-Core does not impose restrictions on the specification of axioms, apart from the fact that WSML-Core only allows the use of a restricted form of the WSML logical expression syntax. These restrictions are specified in the Section 3.6.

3.3 Goals in WSML-Core

Goals in WSML-Core follow the common WSML syntax. The logical expressions in the postconditions and effects are limited to WSML-Core logical expressions.

3.4 Mediators in WSML-Core

3.5 Web Services in WSML-Core

Web services in WSML-Core follow the common WSML syntax. The logical expressions in the assumptions, preconditions, effects and postconditions are limited to WSML-Core logical expressions.

3.6 WSML-Core Logical Expression Syntax

WSML-Core allows only a restricted form of logical expressions. There are two sources for these restrictions. Namely, the restriction of the language to a subset of Description Logics restricts the kind of formulas which can be written down to the two-variable fragment of first-order logic. Furthermore, it disallows the use of function symbols and restricts the arity of predicates to unary and binary and chaining variables over predicates. The restriction of the language to a subset of Datalog (without equality) disallows the use of the equality symbol, disjunction in the head of a rule and existentially quantified variables in the head of the rule.

Formulae in WSML Core logical expressions are, compared to Definitions 2.5 and 2.6 restricted to conjunctions of WSML-Core clauses. These WSML-Core clauses are defined in the following.

Let V be a WSML-Core vocabulary. Let further γ ∈ V_C, Γ be either an identifier in V_C or a list of identifiers in V_C, Δ be either an identifier in V_D or a list of identifiers in V_D, φ ∈ V_I, ψ be either an identifier in V_I or a list of identifiers in V_I, p,q ∈ V_RA, s,t ∈ V_RC, and Val be either a data value or a list of data values.

These are the only atomic clauses allowed in WSML Core, i.e., compared with general logical expressions, WSML core only allows ground facts.

Let Var₁, Var₂, ... be arbitrary WSML variables. We call molecules of the form Var_i memberOf Γ a-molecules, and molecules of the forms , Var_i[ p hasValue Var_k ] and Var_i[ p hasValue {Var_k1, Var_kl} ] b-molecules, respectively.

In the following, F stands for an lhs-formula, with the set of lhs-formulae defined as follows:

G,H stand for arbitrary WSML logical expressions formed by a-molecules and the operator and.

In the following, G,H stand for rhs-formulae, with the set of rhs-formulae defined as follows:

Here, the variable graph of a logical expression E is defined as the undirected graph having all WSML variables in E as nodes and an edge from Var₂ to Var₂ for every molecule Var₁[p hasValue Var₂], or p(Var₁,Var₁), respectively.

Note that wherever an a-molecule (or b-molecule, respectively) is allowed in a WSML-Core clause, compound molecules abbreviating conjunctions of a-molecules (or b-molecules, respectively), as mentioned in the end of Section 2.8 above, are also allowed.

4. WSML-DL

WSML-DL will be an extension of WSML-Core to a full-fledged description logic with an expressiveness similar to OWL DL. WSML-DL is both syntactically and semantically completely layered on top of WSML-Core. This means that every valid WSML-Core specification is also a valid WSML-DL specification. Furthermore, all consequences inferred from a WSML-Core specification are also valid consequences of the same specification in WSML-DL. Finally, if a WSML-DL specification falls inside the WSML-Core fragment then all consequences with respect to the WSML-DL semantics also hold with respect to the WSML-Core semantics.

WSML-DL extends WSML-Core to a full-fledged Description Logic with extensive datatype support based on OWL-E [Pan and Horrocks, 2004].

5. WSML-Flight

WSML-Flight is both syntactically and semantically completely layered on top of WSML-Core. This means that every valid WSML-Core specification is also a valid WSML-Flight specification. Furthermore, all consequences inferred from a WSML-Core specification are also valid consequences of the same specification in WSML-Flight. Finally, if a WSML-Flight specification falls inside the WSML-Core fragment then all consequences with respect to the WSML-Flight semantics also hold with respect to the WSML-Core semantics.

Default negation means that the negation of a fact is true, unless the fact is known to be true. Locally stratified negation means that the definition of a particular predicate does not negatively depend on itself.

This chapter is further structured as follows: we first introduce the basics of the WSML-Flight syntax in Section 5.1. We describe the restrictions WSML-Flight poses on the modeling of ontologies, goals, mediators and web services in sections 5.2, 5.3, 5.4 and 5.5, respectively. Finally, we describe the restrictions on logical expressions in WSML-Flight in Section 5.6.

5.1 Basic WSML-Flight Syntax

WSML-Flight adheres to the WSML syntax basics described in Section 2.1. The restrictions posed on this basic syntax by WSML-Core do not apply to WSML-Flight.

5.2 WSML-Flight Ontologies

Compared to WSML-Core, WSML-Flight does allow additional functionality for attribute definitions, relations, functions, and relation instances. In fact, the conceptual syntax for ontology modeling completely corresponds with the ontology modeling elements introduced in Section 2.3.

Note that for axioms, we only allow a restricted form of logical expressions, as defined in Section 5.6.

5.3 Goals in WSML-Flight

Goals in WSML-Flight follow the common WSML syntax. The logical expressions in the postconditions and effects are limited to WSML-Flight logical expressions.

5.4 Mediators in WSML-Flight

5.5 Web Services in WSML-Flight

Web services in WSML-Flight follow the common WSML syntax. The logical expressions in the assumptions, preconditions, effects and postconditions are limited to WSML-Flight logical expressions.

5.6 WSML-Flight Logical Expression Syntax

WSML-Flight is a rule language based on the Datalog subset of F-Logic, extended with locally stratified default negation, the inequality symbol '!=' and the unification operator '='. Furthermore, WSML-Flight allows monotonic Lloyd-Topor [Lloyd and Topor, 1984], which means that we allow classical implication and conjunction in the head of a rule and we allow disjunction in the body of a rule.

The head and the body of a rule are separated using the Logic Programming implication symbol ':-'. This additional symbol is required because negation-as-failure (naf) is not defined for classical implication (implies, impliedBy). WSML-Flight allows classical implication in the head of the rule. Consequently, every WSML-Core logical expression is a WSML-Flight rule with an empty body.

The syntax for logical expressions of WSML Flight is the same as described in Section 2.8 with the restrictions described in the following. We define the notion of a WSML-Flight vocabulary in Definition 5.1.

Definition 5.1. Any WSML vocabulary (see Definition 2.1) is a WSML-Flight vocabulary.

Definition 5.2 defines the set of WSML-Flight terms Term_Flight(V) for a given vocabulary V.

Definition 5.2. Given a vocabulary V, the set of terms Term_Flight(V) in WSML-Flight is defined as follows:

As usual, the set of ground terms GroundTerm_Flight(V) is the maximal subset of Term_Flight(V) which does not contain variables.

WSML-Flight does not allow the equality operator (:=:). Therefore, the set of admissible atomic formulae in WSML-Flight does not contain α :=: β for terms α, β.

Definition 5.3. Given a set of WSML-Flight terms Term_Flight(V), an atomic formula in L(V) is defined by:

Definition 5.4. Given a WSML-Flight vocabulary V, the set of formulae in L(V) is recursively defined as follows:

As with the general WSML logical expression syntax, <-, -> and <-> can be seen as synonyms of the keywords inplies, impliedBy and equivalent, respectively.

In order to check the safety condition for a WSML-Flight rule, the following transformations should be applied until no transformation rule is applicable:

Application of these transformation rules yields a set of WSML-Flight rules with only one atomic formula in the head and a conjunction of literals in the body.

The safety condition holds for a WSML-Flight rule if every variable which occurs in the rule occurs in a positive body literal which does not correspond to a built-in predicate. For example, the following rules are not safe and thus not allowed in WSML-Flight:

We require each WSML-Flight knowledge base to be locally stratified. Appendix A of [Kifer et al., 1995] explains local stratification for a frame-based logical language.

5.7 Differences between WSML-Core and WSML-Flight

The features added by WSML-Flight compared with WSML-Core are the following: Allows n-ary relations with arbitrary parameters, Constraining attribute definitions for the abstract domain, Cardinality constraints, (locally stratified) default negation in logical expressions, (in)equality in the logical language (in the body of the rule), Full-fledged rule language (based on the Datalog subset of F-Logic).

6. WSML-Rule

WSML-Rule is an extension of WSML-Flight in the direction of Logic Programming. WSML-Rule no longer requires safety of rules and allows the use of function symbols. The only differences between WSML-Rule and WSML-Flight are in the logical expression syntax.

WSML-Rule is both syntactically and semantically layered on top of WSML-Flight and thus each valid WSML-Flight specification is a valid WSML-Rule specification. Because the only differences between WSML-Flight and WSML-Rule are in the logical expression syntax, we do not explain the conceptual syntax for WSML-Rule.

Section 6.1 defines the logical expression syntax of WSML-Rule. Section 6.2 outlines the differences between WSML-Flight and WSML-Rule.

6.1 WSML-Rule Logical Expression Syntax

WSML-Rule is a simple extension of WSML-Flight. WSML-Rule allows the unrestricted use of function symbols and no longer requires the safety condition, i.e., variables which occur in the head are not required to occur in the body of the rule.

The syntax for logical expressions of WSML Rule is the same as described in Section 2.8 with the restrictions which are described in the following: we define the notion of a WSML-Rule vocabulary in Definition 6.1.

Definition 6.1. Any WSML vocabulary (see Definition 2.3) is a WSML-Rule vocabulary.

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

Definition 6.3. Given a set of WSML-Rule terms Term_Rule(V), an atomic formula in L(V) is defined by:

Definition 6.4. Given a WSML-Rule vocabulary V, the set of formulae in L(V) is recursively defined as follows:

As with the general WSML logical expression syntax, <-, -> and <-> can be seen as synonyms of the keywords inplies, impliedBy and equivalent, respectively.

We require each WSML-Rule knowledge base to be locally stratified. Appendix A of [Kifer et al., 1995] explains local stratification for a frame-based logical language.

6.2 Differences between WSML-Flight and WSML-Rule

7. WSML-Full

WSML-Full combines First-Order Logic with nonmonotonic negation in order to provide an expressive language which is able to capture all aspects of Ontology and Web service modeling. Furthermore, WSML-Full unifies the Description Logic and Logic Programming variants of WSML, namely, WSML-DL and WSML-Rule, in a principled way, under a common syntactic and semantic umbrella.

The goal of WSML-Full is to allow the full syntactic freedom of a First-Order logic and the full syntactic freedom of a Logic Programming language with default negation in a common semantic framework. The challenge for WSML-Full is to find an extension of First-Order Logic which can properly capture default negation. One (obvious) possible extension is Reiter's default logic [Reiter, 1987]. However, at the moment the semantics of WSML-Full is still an open research issue.

Note that both the conceptual and logical expression syntax for WSML-Full completely corresponds with the WSML syntax introduced in Chapter 2. Note also that the WSML-Full logical expression syntax is similar to the logical language specified in WSMO.

Compared with WSML-DL, WSML-Full adds full first-order modeling: n-ary predicates, function symbols and chaining variables over predicates. Furthermore, WSML-Full allows non-monotonic negation.

Compared with WSML-Rule, WSML-Full adds disjunction, classical negation, multiple model semantics, and the equality operator.

8. WSML Semantics

In the previous chapters we have defined the conceptual and logical expression syntax for different WSML variants. We have mentioned several characteristics of the semantics of different variants, but we have not defined the semantics itself. This chapter specifies the formal semantics for the WSML variants, in this version of the document of WSML-Core, WSML-Flight and WSML-Full. Specification of the semantics of WSML-DL and WSML-Full constitutes future work.

At this stage, the semantics of capability descriptions is not entirely clear. Therefore, we only define the semantics of ontology definitions.

In the following we provide first a mapping between the conceptual syntax for ontologies and the logical expression syntax for that part of the conceptual syntax which has a meaning in the logical language. We then provide a semantics for WSML-Core, WSML-Flight and WSML-Rule through mapping to existing logical formalisms. Finally, we will demonstrate that these languages are properly layered.

8.1 Mapping Conceptual Syntax to Logical Expression Syntax

In order to be able to specify the WSML semantics in a concise and understandable way, we first translate the conceptual syntax to the logical expression syntax.

Before we translate the conceptual syntax to the logical expression syntax, we perform the following pre-processing steps:

Table 8.1 contains the mapping between the WSML conceptual syntax for ontologies and the logical expression syntax through the mapping function τ (X and Y are meta-variables and are replaced with actual identifiers or variables during the translation itself; p_new is a newly introduced predicate). In the table, italic keywords refer to productions in the WSML grammar (see Appendix A) and boldfaced keywords refer to keywords in the WSML language.

8.2 Preprocessing steps

In order to make the definition of the WSML semantics more straightforward, we define a number of preprocessing steps to be applied to the WSML logical expressions. We identify the following preprocessing steps in order to obtain a suitable set of logical expressions which can be readily mapped to a logical formalism:

The resulting set of logical expressions does not contain any syntactical shortcuts and can be used directly for the definition of the semantics of the respective WSML variants.

8.3 WSML-Core Semantics

In order to define the semantics of WSML-Core, we first define the notion of a WSML-Core knowledge base in Definition 8.1.

Definition 8.1. We define a WSML-Core knowledge base KB as a collection of formulas written in the WSML logical expression language which are the result of application of the translation function τ of Table 8.1 and the preprocessing steps defined in Section 8.2 to a WSML-Core ontology.

We define the semantics of WSML-Core through a mapping to Horn logic using the mapping function π.

Table 8.2 presents the WSML-Core semantics through a direct mapping to function-free Horn logic. In the table, id# can be any identifier, dt# is a datatype identifier, X# can be either a variable or an identifier. Each occurrence of x and each occurrence of y represents a newly introduced variable.

Note that in the translation of typing constraints using ofType, we introduce a (built-in) datatype predicate in the head of the rule. However, rule engines typically do not allow built-in predicates in the head of a rule. For implementation in database/rule systems, this formula can be rewritten to the following constraint: ← id1(x) ∧ id2(x,y) ∧ not dt(y), with 'not' being default negation. It is the same for the use of impliesType with a datatype as range.

Each occurrence of an unnumbered anonymous ID is replaced with a new globally unique identifier. All occurrences of the same numbered anonymous ID in one formula are replaced with the same new globally unique identifier.

Application of the usual Lloyd-Topor transformations [Lloyd and Topor, 1984] yields actual Datalog rules. In particular, the following transformations are iteratively applied until no transformation is applicable:

Definition 8.2 (Satisfiability in WSML-Core) We say a WSML-Core knowledge base KB is satisfiable iff π(KB_A) is satisfiable under first-order semantics.

Definition 8.3 (Entailment in WSML-Core) We say a WSML-Core knowledge base KB_A entails a WSML-Core knowledge base KB_B, written as: KB_A |=_WSML KB_B iff π(KB_A) |= π(KB_B), where |= is the classical entailment relation.

8.4 WSML-Flight Semantics

In order to define the semantics of WSML-Flight, we first define the notion of a WSML-Flight knowledge base in Definition 8.4.

Definition 8.4. We define a WSML-Flight knowledge base KB as a collection of formulae written in the WSML logical expression language which are the result of application of the translation function τ of Table 8.1 and the preprocessing steps defined in Section 8.2 to a WSML-Flight ontology.

We define the semantics of WSML-Flight through a mapping to the Datalog fragment of F-Logic [Kifer et al., 1995] (extended with inequality and stratified default negation in the body of the rule) using the mapping function π.

Concepts, instances and attributes are interpreted as objects in F-Logic. We need a number of auxiliary rules in order to ensure the correct interpretation of the translated F-Logic statements (with not denoting default negation and a rule with an empty head denoting an integrity constraint):

The semantics of method signatures is captured through an integrity constraint on method signatures:

Now follows the semantics of WSML-Flight in Table 8.3. In the table, X# stands for either a variable or an identifier; '=' is the unification operator and '!=' is the built-in inequality symbol.

Rules with empty heads are integrity constraints. The first row in the table produces integrity constraints from the WSML logical expressions. Furthermore, there exists the integrity constraint which axiomatizes the semantics of ofType. All integrity constraints are part of the set of integrity constraints C.

We base the semantics of WSML-Flight on the perfect model semantics by Przymusinski [Przymusinski, 1989], which defines the semantics for locally stratified logic programs. Przymusinski shows that every stratified program has a unique perfect model. WSML-Flight only allows locally stratified negation.

Definition 8.5 (Satisfiability in WSML-Flight) Let KB be a WSML-Flight knowledge base and C be a set of constraints. KB is satisfiable iff π(KB) has a perfect model M_KB which does not violate any of the constraints in C. We say an integrity constraint is violated if some ground instantiation of the body of the constraint is true in the model M_KB.

We define the semantics of WSML-Flight with respect to the entailment of ground formulae. We say a formula is ground if it does not contain any variables.

Definition 8.6 (Entailment in WSML-Flight) We say a satisfiable WSML-Flight knowledge base KB entails a WSML-Flight ground formula F iff M_KB |= π(F), where M_KB is the perfect model of KB.

8.5 WSML-Rule Semantics

The semantics of WSML-Rule is defined in the same way as WSML-Flight. The only difference is that the semantics of WSML-Rule is not defined through a mapping to Datalog, but through a mapping to full Logic Programming (i.e., with function symbols and allowing unsafe rules) with inequality and (locally) stratified negation. However, the mapping looks exactly the same as Table 8.3. The only difference is that the meta-variables X# can also stand for a constructed term.

In order to define the semantics of WSML-Rule, we first define the notion of a WSML-Rule knowledge base in Definition 8.4.

Definition 8.7. We define a WSML-Rule knowledge base KB as a collection of formulae written in the WSML logical expression language which are the result of application of the translation function τ of Table 8.1 and the preprocessing steps defined in Section 8.2 to a WSML-Rule ontology.

We define the semantics of WSML-Rule through a mapping to the Horn fragment of F-Logic [Kifer et al., 1995] (extended with inequality and locally stratified default negation in the body of the rule) using the mapping function π.

The semantics of method signatures is captured through an integrity constraint on method signatures:

Now follows the semantics of WSML-Rule in Table 8.4. In the table, X# stands for either a variable, an identifier, or a constructed term; '=' is the unification operator and '!=' is the built-in inequality symbol.

Rules with empty heads are integrity constraints (in the database sense). The first row in the table produces integrity constraints from the WSML logical expressions. Furthermore, there exists the integrity constraint which axiomatizes the semantics of ofType. All integrity constraints are part of the set of integrity constraints C.

Application of the usual Lloyd-Topor transformations [Lloyd and Topor, 1984] yields actual Datalog rules (note that the syntactical restrictions on the WSML-Rule logical expression syntax prevent the use of disjunction in the head of any rule). In particular, the following transformations are iteratively applied until no transformation is applicable:

We base the semantics of WSML-Rule on the perfect model semantics by Przymusinski [Przymusinski, 1989], which defines the semantics for (locally) stratified logic programs. Przymusinski shows that every locally stratified program has a unique perfect model. WSML-Rule only allows locally stratified negation.

Definition 8.8 (Satisfiability in WSML-Rule) Let KB be a WSML-Rule knowledge base and C be a set of constraints. KB is satisfiable iff π(KB) has a perfect model M_KB which does not violate any of the constraints in C. We say an integrity constraint is violated if some ground instantiation of the constraint is true in the model M_KB.

We define the semantics of WSML-Rule with respect to the entailment of ground formulae. We say a formula is ground if it does not contain any variables.

Definition 8.9 (Entailment in WSML-Rule) We say a satisfiable WSML-Rule knowledge base KB entails a WSML-Rule ground formula F iff M_KB |= π(F), where M_KB is the perfect model of KB.

PART III: THE WSML EXCHANGE SYNTAXES

In the previous Part we have described the WSML family of languages in terms of their human-readable syntax. This syntax might not be suitable for exchange between automated agents. Therefore, we present three exchange syntaxes for WSML in order to enable automated interoperation.

9. XML Syntax for WSML

In this chapter, we explain the XML syntax for WSML. The XML syntax for WSML is based on the human-readable syntax for WSML presented in Chapter 2. The XML syntax for WSML captures all WSML variants. The user can specify the variant of a WSML/XML document through the 'variant' attribute of the <wsml> root element.

The complete XML Schema, including documentation, for the WSML/XML syntax can be found in Appendix B. Table 9.1 provides the transformations of the conceptual syntax, Table 9.2 presents the transformation of logical expressions, while in Table 9.3 a simple mapping example is given.

The basic namespace for WSML/XML is http://www.wsmo.org/wsml/wsml-syntax#. This is the namespace for all elements in WSML.

Before beginning the transformation process the following pre-processing steps need to be performed:

T(...) denotes a function which is recursively called to transform the first parameter (a fragment of WSML syntax) to the XML syntax.

In Table 9.1, all WSML keywords are marked bold. A,B,C stand for identifiers, D stands for a datatype identifier, DV_i stands for an integer value, DV_d stands for a decimal, and DV_s stands for a string data value. k,m,n are integer numbers. Productions in the grammar are underlined and linked to the production rules in Appendix A. Note that in the table we use the familiar sQName macro mechanism (see also Section 2.1.2) to abbreviate the IRIs of resources. The prefix 'xsd' stands for 'http://www.w3.org/2001/XMLSchema#'.

The logical expression syntax is explained in Table 9.2. In the table, A stands for identifiers and T₁,...,T_n stand for terms. V stands for a variable.

10. RDF Syntax for WSML

In this chapter an RDF syntax for WSML is introduced. The vocabulary used is an extension of the RDF Schema vocabulary defined in [RDFS]. The extension consists of WSML language components, as given in Table 10.1.

The remainder of this chapter presents a mapping between the human-readable syntax of WSML and the RDF/WSML-triple syntax for all WSML variants, where the knowledge is encoded in <subject><predicate><object>-triples. The big advantage of having such a syntax and reusing the RDFS-vocabulary as far as possible, is the fact that there are many existing RDF(S)-based tools available. These tools are optimized to handle triples and are thus able to understand parts of our specification and in a more general sense we can guarantee inter-operability with those. In RDF all triples are global, while in the conceptual syntax of WSML it is possible to append specific entities to higher-level entities, e.g., concepts to ontologies or attribute values to instances.

In order to maximize the reuse of RDFS vocabulary, several Dublin Core properties are translated to corresponding RDFS properties. Namely, dc#title is mapped to rdfs#label, dc#description is mapped to rdfs#comment, and dc#relation is mapped to rdfs#seeAlso.

Table 10.2 defines the mapping function T from WSML entities to RDF triples. Logical expressions are not completely translated to RDF. Instead, they are translated to the WSML/XML syntax and are specified as literals of type rdf#XMLLiteral. The transformation creates an RDF-graph based on above introduced RDF-triples. As definitions, i.e., top-level entities like ontologies, Web services, goals and mediators are disjoint constructs, their graphs are not inter-related. In other words the transformation defines one graph per definition. Note that in the table we use the familiar sQName macro mechanism (see also Section 2.1.2) to abbreviate IRIs. The prefix 'wsml' stands for 'http://www.wsmo.org/wsml/wsml-syntax#', 'rdf' stands for 'http://www.w3.org/1999/02/22-rdf-syntax-ns#', 'rdfs' stands for 'http://www.w3.org/2000/01/rdf-schema#', 'dc' stands for 'http://purl.org/dc/elements/1.1#', and 'xsd' stands for 'http://www.w3.org/2001/XMLSchema#'.

In Table 10.2, A,B,C,Z stand for identifiers, D stands for a datatype identifier, DV_i stands for an integer value, DV_d stands for a decimal, and DV_s stands for a string data value, and k,m,n are integer numbers.

The basic namespace for WSML/RDF is http://www.wsmo.org/wsml/wsml-syntax#. This is the namespace for all elements in WSML.

Before beginning the transformation process the following pre-processing steps need to be performed:

A simple example of a full translation from the human-readable syntax to the RDF triple notation is given in Table 10.3.

11. Mapping to OWL

The mapping to OWL presented here is applicable to ontologies and logical expressions only; note that logical expressions might occur in ontologies, as well as goal and web service capability descriptions. For a mapping of non-ontology constructs except logical expressions the RDF Syntax for WSML has to be used. Furthermore this version of the deliverable contains only a mapping of WSML-Core to OWL. Once WSML-DL has been specified, a mapping of WSML-DL to OWL will be defined. Other WSML variants will not be mapped directly to OWL, since their semantics are not compatible. If a mapping is desired first such an ontology has to be reduced to either WSML-DL or WSML-Core.

11.1 Mapping WSML-Core to OWL DL

In this section we define a mapping of WSML-Core to the OWL DL abstract syntax [OWLSemantics].

In order to simplify the translation we perform the following pre-processing steps:

Table 11.1 contains the mapping between the WSML Core and OWL DL abstract syntax through the mapping function τ. In the table, underlined words refer to productions rules in the WSML grammar (see Appendix A) and boldfaced words refer to keywords in the WSML language. X and Y are meta-variables and are replaced with actual identifiers or variables during the translation itself. Note that in the table we use the familiar sQName macro mechanism (see also Section 2.1.2) to abbreviate IRIs. The prefix 'wsml' stands for 'http://www.wsmo.org/wsml/wsml-syntax#', 'rdf' stands for 'http://www.w3.org/1999/02/22-rdf-syntax-ns#', 'rdfs' stands for 'http://www.w3.org/2000/01/rdf-schema#', 'dc' stands for 'http://purl.org/dc/elements/1.1#', 'xsd' stands for 'http://www.w3.org/2001/XMLSchema#', and 'owl' stands for 'http://www.w3.org/2002/07/owl#'.

11.2 Mapping OWL DL to WSML-Core

Table 11.2 shows the mapping between OWL DL (abstract syntax) and WSML-Core. The table shows for each construct supported by OWL DL (and being semantically within WSML-Core) the corresponding WSML-Core syntax in terms of logical expressions necessary to capture the construct.

The mapping is done by a recursive translation function τ. The symbol X denotes a meta variable that has to be substituted with the actual variable occurring during the translation. Note that only those ontologies within the expressivity of WSML Core, can be translated. If for an OWL DL ontology a mapping can not be found by applying τ the ontology is not within the expressivity of WSML Core.

In order to translate class axioms, the translation function τ takes a WSML logical expression from the translation of the left-hand side, τ_lhs, of a subclass relation (or partial/complete class descriptions, respectively) as the first argument, the right hand side of a subclass relationship as second argument, and a variable as third argument. This variable is used for relating classes through properties from the allValuesFrom and someValuesFrom restrictions. Whenever we pass such a value restriction during the translation, a new variable has to be introduced, i.e., x_new stands for a freshly introduced variable in every translation step.

We will now illustrate the translation described in Table 11.2 by an example:

Class(Chardonay partial Wine restriction(hasColor value White))

PART IV: FINALE

WSMO4J (http://wsmo4j.sourceforge.net/) will provide a data model in Java for WSML and will also provide (de-)serializers for the different WSML syntaxes. WSMO4J can be extended to connect with the specific reasoners to be used for WSML.

The WSML validator (http://dev1.deri.at:8080/wsml/) currently provides validation services for the WSML basic syntax this document.

WSMX provides the reference implementation for WSMO. WSMX makes use of pluggable reasoning services. WSMX is committed to using the WSML language developed in this deliverable.

Implementation of reasoning services for the different WSML variants is currently under investigation in WSML deliverable D16.2 [de Bruijn, 2004]. Future versions of that deliverable will provide reasoning implementations for the different WSML variants, based on existing reasoning implementations.

Converters will be developed to convert between the different syntaxes of WSML, namely, the human-readable syntax, the XML syntax and the RDF syntax. Furthermore, an importer/exporter for OWL will be created.

Acknowledgements

The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.

References

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

[de Bruijn et al., 2005] J. de Bruijn, A. Polleres, R. Lara and D. Fensel. OWL DL vs. OWL Flight: Conceptual Modeling and Reasoning for the Semantic Web. Fourteenth International World Wide Web Conference (WWW2005), 2005. To appear.

[Eiter et al., 2004] T. Eiter, T. Lukasiewicz, R. Schindlauer, and H. Tompits. Combining answer set programming with description logics for the semantic web. In Proc. of the International Conference of Knowledge Representation and Reasoning (KR04), 2004.

[Enderton, 2002] H. B. Enderton. A Mathematical Introduction to Logic (2nd edition). Academic Press, 2002

[Fensel et al., 2001] D. Fensel, F. van Harmelen, I. Horrocks, D.L. McGuinness, and P.F. Patel- Schneider: OIL: An Ontology Infrastructure for the Semantic Web. IEEE Intelligent Systems, 16:2, May 2001.

[Grosof et al., 2003] B. N. Grosof, I. Horrocks, R. Volz, and S. Decker. Description logic programs: Combining logic programs with description logic. In Proc. of the Twelfth International World Wide Web Conference (WWW 2003), pages 48-57. ACM, 2003.

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

[Levy &Rousset, 1998] A.Y. Levy and M.-C. Rousset. Combining horn rules and description logics in CARIN. Artificial Intelligence, 104:165-209, 1995.

[Lloyd, 1987] J. W. Lloyd. Foundations of Logic Programming (2nd edition). Springer-Verlag, 1987.

[Lloyd and Topor, 1984] John W. Lloyd and Rodney W. Topor. Making prolog more expressive. Journal of Logic Programming, 1(3):225{240, 1984.

[Mitra et al., 2000] P. Mitra, G. Wiederhold, and M.L. Kersten. A graph-oriented model for articulation of ontology interdependencies. In In Proceedings of Conference on Extending Database Technology (EDBT 2000), Konstanz, Germany, March 2000.

[OWLSemantics] P. F. Patel-Schneider, P. Hayes, and I. Horrocks: OWL web ontology language semantics and abstract syntax. Recommendation 10 February 2004, W3C. Available from http://www.w3.org/TR/owl-semantics/.

[Przymusinski, 1989] T. C. Przymusinski. On the declarative and procedural semantics of logic programs. Journal of Automated Reasoning>, 5(2):167-205, 1989.

[RDFS] D. Brickley and R. V. Guha. RDF vocabulary description language 1.0: RDF schema. W3C Recommendation 10 February 2004. Available from http://www.w3.org/TR/rdf-schema/.

[Reiter, 1987] Raymond Reiter. A logic for default reasoning. In Readings in Nonmonotonic Reasoning, pages 68-93. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1987.

[SWRL] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof and M. Dean: SWRL: A Semantic Web Rule Language Combining OWL and RuleML. W3C Member Submission 21 May 2004. Available from http://www.w3.org/submissions/2004/SUBM-SWRL-20040521/.

[XMLSchemaDatatypes] P.V. Biron and A. Malhorta. XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004.

[Yang & Kifer, 2003] G. Yang and M. Kifer. Reasoning about anonymous resources and meta statements on the semantic web. Journal on Data Semantics, 1:69-97, 2003.

Appendix A. Human-Readable Syntax

This appendix presents the complete grammar for the WSML language. The language use write this grammar is a variant of Extended Backus Nauer Form which can be interpreted by the SableCC compiler compiler [SableCC].

We present one WSML grammar for all WSML variants. The restrictions that each variants poses on the use of the syntax are described in the respective chapters in PART II of this deliverable.

A.1 BNF-Style Grammar

In this section we show the entire WSML grammar. The grammar is specified using a dialect of Extended BNF which can be used directly in the SableCC compiler compiler [SableCC]. Terminals are quoted, non-terminals are underlined and refer to the tokens and productions. Alternatives are separated using vertical bars '|', and are labeled, where the label is enclosed in curly brackets '{' '}'; optional elements are appended with a question mark '?'; elements that may occur zero or more times are appended with an asterisk '*'; elements that may occur one or more times are appended with a plus '+'.

The first part of the grammar file provides HELPERS which are used to write TOKENS. Broadly, a language has a collection of tokens (words, or the vocabulary) and rules, or PRODUCTIONS, for generating sentences using these tokens (grammar). A grammar describes an entire language using a finite set of productions of tokens or other productions; however this finite set of rules can easily allow an infinite range of valid sentences of the language they describe. Note, helpers cannot directly be used in productions. A last word concerning the IGNORED TOKENS: ignored tokens are ignored during the parsing process and are not taken into consideration when building the abstract syntax tree.

Helpers

all	=	[ 0x0 .. 0xffff ]
escape_char	=	'\'
basechar	=	[ 0x0041 .. 0x005A ] \| [ 0x0061 .. 0x007A ]
ideographic	=	[ 0x4E00 .. 0x9FA5 ] \| 0x3007 \| [ 0x3021 .. 0x3029 ]
letter	=	basechar \| ideographic
digit	=	[ 0x0030 .. 0x0039 ]
combiningchar	=	[ 0x0300 .. 0x0345 ] \| [ 0x0360 .. 0x0361 ] \| [ 0x0483 .. 0x0486 ]
extender	=	0x00B7 \| 0x02D0 \| 0x02D1 \| 0x0387 \| 0x0640 \| 0x0E46 \| 0x0EC6 \| 0x3005 \| [ 0x3031 .. 0x3035 ] \| [ 0x309D .. 0x309E ] \| [ 0x30FC .. 0x30FE ]
alphanum	=	digit \| letter
hexdigit	=	[ '0' .. '9' ] \| [ 'A' .. 'F' ]
not_escaped_namechar	=	letter \| digit \| '_' \| combiningchar \| extender
escaped_namechar	=	'.' \| '-' \| not_escaped_namechar
namechar	=	( escape_char escaped_namechar ) \| not_escaped_namechar
reserved	=	'/' \| '?' \| '#' \| '[' \| ']' \| ';' \| ':' \| '@' \| '&' \| '=' \| '+' \| '$' \| ','
mark	=	'-' \| '_' \| '.' \| '!' \| '~' \| '*' \| ''' \| '(' \| ')'
escaped	=	'%' hexdigit hexdigit
unreserved	=	letter \| digit \| mark
scheme	=	letter ( letter \| digit \| '+' \| '-' \| '.' )*
port	=	digit*
idomainlabel	=	alphanum ( ( alphanum \| '-' )* alphanum )?
dec_octet	=	digit \| ( [ 0x31 .. 0x39 ] digit ) \| ( '1' digit digit ) \| ( '2' [ 0x30 .. 0x34 ] digit ) \| ( '25' [ 0x30 .. 0x35 ] )
ipv4address	=	dec_octet '.' dec_octet '.' dec_octet '.' dec_octet
h4	=	hexdigit hexdigit? hexdigit? hexdigit?
ls32	=	( h4 ':' h4 ) \| ipv4address
ipv6address	=	( ( h4 ':' )* h4 )? '::' ( h4 ':' )* ls32 \| ( ( h4 ':' )* h4 )? '::' h4 \| ( ( h4 ':' )* h4 )? '::'
ipv6reference	=	'[' ipv6address ']'
ucschar	=	[ 0xA0 .. 0xD7FF ] \| [ 0xF900 .. 0xFDCF ] \| [ 0xFDF0 .. 0xFFEF ]
iunreserved	=	unreserved \| ucschar
ipchar	=	iunreserved \| escaped \| ';' \| ':' \| '@' \| '&' \| '=' \| '+' \| '$' \| ','
isegment	=	ipchar*
ipath_segments	=	isegment ( '/' isegment )*
iuserinfo	=	( iunreserved \| escaped \| ';' \| ':' \| '&' \| '=' \| '+' \| '$' \| ',' )*
iqualified	=	( '.' idomainlabel )* '.' ?
ihostname	=	idomainlabel iqualified
ihost	=	( ipv6reference \| ipv4address \| ihostname )?
iauthority	=	( iuserinfo '@' )? ihost ( ':' port )?
iabs_path	=	'/' ipath_segments
inet_path	=	'//' iauthority ( iabs_path )?
irel_path	=	ipath_segments
ihier_part	=	inet_path \| iabs_path \| irel_path
iprivate	=	[ 0xE000 .. 0xF8FF ]
iquery	=	( ipchar \| iprivate \| '/' \| '?' )*
ifragment	=	( ipchar \| '/' \| '?' )*
iri_f	=	scheme ':' ihier_part ( '?' iquery )? ( '#' ifragment )?
absolute_iri	=	scheme ':' ihier_part ( '?' iquery )?
relative_iri	=	ihier_part ( '?' iquery )? ( '#' ifragment )?
iric	=	reserved \| iunreserved \| escaped
iri_reference	=	iri_f \| relative_iri
tab	=	9
cr	=	13
lf	=	10
eol	=	cr lf \| cr \| lf
squote	=	'''
dquote	=	'"'
not_cr_lf	=	[ all - [ cr+ lf ] ]
escaped_char	=	escape_char all
not_escape_char_not_dquote	=	[ all - [ '"' + escape_char ] ]
string_content	=	escaped_char \| not_escape_char_not_dquote
long_comment_content	=	[ all - '/' ] \| [ all - '*' ] '/'
long_comment	=	'/' long_comment_content '*/'
begin_comment	=	'//' \| 'comment '
short_comment	=	begin_comment not_cr_lf* eol
comment	=	short_comment \| long_comment
blank	=	( ' ' \| tab \| eol )+
qmark	=	'?'
luridel	=	'_"'
ruridel	=	'"'

Tokens

t_blank	=	blank
t_comment	=	comment
comma	=	','
endpoint	=	'.' blank
lpar	=	'('
rpar	=	')'
lbracket	=	'['
rbracket	=	']'
lbrace	=	'{'
rbrace	=	'}'
hash	=	'#'
t_and	=	'and'
t_or	=	'or'
t_implies	=	'implies' \| '->'
t_implied_by	=	'impliedBy' \| '<-'
t_equivalent	=	'equivalent' \| '<->'
t_implied_by_lp	=	':-'
t_constraint	=	'!-'
t_not	=	'neg' \| 'naf'
t_exists	=	'exists'
t_forall	=	'forall'
t_univfalse	=	'false'
t_univtrue	=	'true'
gt	=	'>'
lt	=	'<'
gte	=	'>='
lte	=	'=<'
equal	=	'='
unequal	=	'!='
add_op	=	'+'
sub_op	=	'-'
star	=	'*'
div_op	=	'/'
t_assumption	=	'assumption'
t_axiom	=	'axiom'
t_capability	=	'capability'
t_choreography	=	'choreography'
t_concept	=	'concept'
t_definedby	=	'definedBy'
t_effect	=	'effect'
t_endnfp	=	'endNonFunctionalProperties' \| 'endnfp'
t_ggmediator	=	'ggMediator'
t_goal	=	'goal'
t_hasvalue	=	'hasValue'
t_impliestype	=	'impliesType'
t_importontology	=	'importsOntology'
t_instance	=	'instance'
t_interface	=	'interface'
t_inverseof	=	'inverseOf'
t_memberof	=	'memberOf'
t_namespace	=	'namespace'
t_nfp	=	'nonFunctionalProperties' \| 'nfp'
t_oftype	=	'ofType'
t_ontology	=	'ontology'
t_oomediator	=	'ooMediator'
t_orchestration	=	'orchestration'
t_postcondition	=	'postcondition'
t_precondition	=	'precondition'
t_reflexive	=	'reflexive'
t_relation	=	'relation'
t_relation_instance	=	'relationInstance'
t_sharedvariable	=	'sharedVariables'
t_source	=	'source'
t_subconcept	=	'subConceptOf'
t_subrelation	=	'subRelationOf'
t_symmetric	=	'symmetric'
t_target	=	'target'
t_transitive	=	'transitive'
t_usemediator	=	'usesMediator'
t_useservice	=	'usesService'
t_webservice	=	'webService'
t_wgmediator	=	'wgMediator'
t_wsmlvariant	=	'wsmlVariant'
t_wwmediator	=	'wwMediator'
variable	=	qmark alphanum+
anonymous	=	'_#'
nb_anonymous	=	'_#' digit+
pos_integer	=	digit+
pos_decimal	=	digit+ '.' digit+
string	=	dquote string_content* dquote
full_iri	=	luridel iri_reference ruridel
name	=	( letter \| '_' ) namechar*

Productions

wsml

wsmlvariant? namespace? definition*

wsmlvariant

t_wsmlvariant full_iri

namespace

t_namespace prefixdefinitionlist

prefixdefinitionlist

	{defaultns}	full_iri
\|	{prefixdefinitionlist}	lbrace prefixdefinition moreprefixdefinitions* rbrace

prefixdefinition

	{namespacedef}	name full_iri
\|	{default}	full_iri

moreprefixdefinitions

comma prefixdefinition

definition

	{goal}	goal
\|	{ontology}	ontology
\|	{webservice}	webservice
\|	{mediator}	mediator

	{nfp}	nfp
\|	{usesmediator}	usesmediator
\|	{importsontology}	importsontology

usesmediator

t_usemediator idlist

importsontology

t_importontology idlist

nfp

t_nfp attributevalue* t_endnfp

mediator

	{oomediator}	oomediator
\|	{ggmediator}	ggmediator
\|	{wgmediator}	wgmediator
\|	{wwmediator}	wwmediator

oomediator

t_oomediator id? nfp? importsontology? sources? target? use_service?

ggmediator

t_ggmediator id? header* sources? target? use_service?

wgmediator

t_wgmediator id? header* source? target? use_service?

wwmediator

t_wwmediator id? header* source? target? use_service?

t_source lbrace id moreids* rbrace

sources

	{single}	source
\|	{multiple}	msources

target

t_target id

goal

t_goal id? header* capability? interfaces*

webservice

t_webservice id? header* capability? interfaces*

capability

t_capability id? header* sharedvardef? pre_post_ass_or_eff*

sharedvardef

t_sharedvariable variablelist

pre_post_ass_or_eff

	{precondition}	t_precondition axiomdefinition
\|	{postcondition}	t_postcondition axiomdefinition
\|	{assumption}	t_assumption axiomdefinition
\|	{effect}	t_effect axiomdefinition

interfaces

	{single}	interface
\|	{multiple}	minterfaces

minterfaces

t_interface lbrace id moreids* rbrace

interface

t_interface id? header* choreography? orchestration?

t_ontology id? header* ontology_element*

ontology_element

	{concept}	concept
\|	{instance}	instance
\|	{relation}	relation
\|	{relationinstance}	relationinstance
\|	{axiom}	axiom

concept

t_concept id superconcept? nfp? attribute*

superconcept

t_subconcept idlist

att_type

	{open_world}	t_oftype
\|	{closed_world}	t_impliestype

attribute

id attributefeature* att_type cardinality? idlist nfp?

cardinality

lpar pos_integer cardinality_number? rpar

cardinality_number

	{finite_cardinality}	pos_integer
\|	{infinite_cardinality}	star

attributefeature

	{transitive}	t_transitive
\|	{symmetric}	t_symmetric
\|	{inverse}	t_inverseof lpar id rpar
\|	{reflexive}	t_reflexive

instance

t_instance id? memberof? nfp? attributevalue*

memberof

t_memberof idlist

attributevalue

id t_hasvalue valuelist

relation

t_relation id arity? paramtyping? superrelation? nfp?

paramtyping

lpar paramtype moreparamtype* rpar

t_relation_instance [name]: id? [relation]: id lpar value morevalues* rpar nfp?

axiom

t_axiom axiomdefinition

axiomdefinition

	{use_axiom}	id
\|	{nfp_axiom}	id? nfp
\|	{defined_axiom}	id? nfp? log_definition

log_definition

t_definedby log_expr+

log_expr

	{lp_rule}	[head]: expr t_implied_by_lp [body]: expr endpoint
\|	{constraint}	t_constraint expr endpoint
\|	{other_expression}	expr endpoint

expr

	{implication}	expr imply_op disjunction
\|	{disjunction}	disjunction

disjunction

	{conjunction}	conjunction
\|		disjunction t_or conjunction

conjunction

	{subexpr}	subexpr
\|		conjunction t_and subexpr

subexpr

	{negated}	t_not subexpr
\|	{simple}	simple
\|	{complex}	lpar expr rpar
\|	{quantified}	quantified

quantified

quantifier_key variablelist lpar expr rpar

simple

	{molecule}	molecule
\|	{comparison}	comparison
\|	{atom}	term

molecule

	{concept_molecule_preferred}	term attr_specification? cpt_op termlist
\|	{concept_molecule_nonpreferred}	term cpt_op termlist attr_specification
\|	{attribute_molecule}	term attr_specification

attr_specification

lbracket attr_rel_list rbracket

attr_rel_list

	{attr_relation}	attr_relation
\|		attr_rel_list comma attr_relation

attr_relation

	{attr_def}	term attr_def_op termlist
\|	{attr_val}	term t_hasvalue termlist

comparison

[left]: term comp_op [right]: term

functionsymbol

	{parametrized}	id lpar terms? rpar
\|	{math}	lpar mathexpr math_op term rpar

mathexpr

	{sub}	mathexpr math_op term
\|		term

comp_op

	{gt}	gt
\|	{lt}	lt
\|	{gte}	gte
\|	{lte}	lte
\|	{equal}	equal
\|	{unequal}	unequal

cpt_op

	{memberof}	t_memberof
\|	{subconceptof}	t_subconcept

quantifier_key

	{forall}	t_forall
\|	{exists}	t_exists

attr_def_op

	{oftype}	t_oftype
\|	{impliestype}	t_impliestype

imply_op

	{implies}	t_implies
\|	{impliedby}	t_implied_by
\|	{equivalent}	t_equivalent

math_op

	{add}	add_op
\|	{sub}	sub_op
\|	{mul}	star
\|	{div}	div_op

prefix

name hash

sqname

	{any}	prefix? name
\|	{relation}	prefix t_relation
\|	{source}	prefix t_source

iri

	{iri}	full_iri
\|	{sqname}	sqname

	{iri}	iri
\|	{anonymous}	anonymous
\|	{universal_truth}	t_univtrue
\|	{universal_falsehood}	t_univfalse

idlist

	{id}	id
\|	{idlist}	lbrace id moreids* rbrace

moreids

comma id

value

	{datatype}	functionsymbol
\|	{term}	id
\|	{numeric}	number
\|	{string}	string

valuelist

	{term}	value
\|	{valuelist}	lbrace value morevalues* rbrace

morevalues

comma value

term

	{data}	value
\|	{var}	variable
\|	{nb_anonymous}	nb_anonymous

terms

	{term}	term
\|		terms comma term

termlist

	{term}	term
\|		lbrace terms rbrace

variables

	{variable}	variable
\|		variables comma variable

variablelist

	{variable}	variable
\|	{variable_list}	lbrace variables rbrace

	{integer}	integer
\|	{decimal}	decimal

A.2 Example of the Human-Readable Syntax

Appendix B. Schemas for the XML Exchange Syntax

Userfriendly documentation for the schemas is available from the following locations:

Appendix C. Datatypes and Built-ins in WSML

This appendix contains a preliminary list of built-in functions and relations for datatypes in WSML. It also contains a translation of syntactic shortcuts to datatype predicates.

Appendix C.1 WSML Datatypes

WSML recommends the use of XML Schema datatypes as defined in [XMLSchemaDatatypes] for the representation of concrete values, such as strings and integers. WSML defines a number of built-in functions for the use of XML Schema datatypes.

WSML allows direct usage of the string, integer and decimal data values in the language. These values have a direct correspondence with values of the XML Schema datatypes string, integer, and decimal, respectively. Values of these most primitive datatypes can be used to construct values of more complex datatypes. Table C.1 lists datatypes allowed in WSML with the name of the datatype constructor, the name of the corresponding XML Schema datatype, a short description of the datatype (corresponding with the value space as defined in [XMLSchemaDatatypes]) and an example of the use of the datatype.

Table C.2 contains the shortcut syntax for the string, integer, decimal, IRI and sQName datatypes.

Appendix C.2 WSML Datatype Predicates

This section contains a list of datatype predicates suggested for use in WSML. These predicates correspond to functions in XQuery/XPath [XPathFunctions]. Notice that SWRL [SWRL] built-ins are also based on XQuery/XPath.

The current list is only based on the built-in support in the WSML language through the use of special symbols. A translation of the built-in symbols to datatype predicates is given in the next section. The symbol ‘range’ signifies the range of the function. Functions in XQuery have a defined range, whereas predicates only have a domain. Therefore, the first argument of a WSML datatype predicate which represents a function represents the range of the function. Comparators in XQuery are functions, which return a boolean value. These comparators are directly translated to predicates. If the XQuery function returns 'true', the arguments of the predicate are in the extension of the predicate. See Table C.3 for the complete list. In the evaluation of the predicates, the parameters 'A' and 'B' must be bound; the parameter 'range' does not need to be bound. A parameter is bound if it is substituted with a value. It is not bound if it is substituted with a variable. The variable is then used to convey some outcome of the function.

Each WSML implementation is required to either implement the complement of each of these built-ins or to provide a negation operator which can be used together with these predicates.

Appendix C.3 Translating Built-in Symbols to Datatype Predicates

In this section, we provide the translation of the built-in (function and predicate) symbols for datatype predicates to these datatype predicates.

We distinguish between built-in functions and built-in relations. Functions have a defined domain and range. Relations only have a domain and can in fact be seen as functions, which return a boolean, as in XPath/XQuery [XPathFunctions]. We first provide the translation of the built-in relations and then present the rewriting rules for the built-in functions.

We list the built-in functions and their translation to datatype predicates in Table C.5. In the table, ?x1 represents a unique newly introduced variable, which stands for the range of the function.

Function symbols in WSML are not as straightforward to translate to datatype predicates as are relations. However, if we see the predicate as a function, which has the range as its first argument, we can introduce a new variable for the return value of the function and replace an occurrence of the function symbol with the newly introduced variable and append the newly introduced predicate to the conjunction of which the top-level predicate is part.

Formulas containing nested built-in function symbols can be rewritten to datatype predicate conjunctions according to the following algorithm:

We present an example of the application of the algorithm to the following expression:

We first substitute the first occurrence of the function symbol '+' with a newly introduced variable ?x1 and append the predicate wsml#numericAdd(?x1, ?x, ?y) to the conjunction:

Now, we don't have any more built-in function symbols to substitute and we merely substitute the built-in relation '=' to obtain the final conjunction of datatype predicates:

Appendix D. WSML Keywords

This appendix lists all WSML keywords, along with the section of the deliverable where they have been described. Keywords are differentiated per WSML variant. Keywords common to all WSML variants are referred to under the column "Common element". The elements specific to a certain variant are listed under the specific variant. A '+' in the table indicates that the keyword included is inherited from the lower variant. Finally, a reference to a specific section indicates that the definition of the keyword can be found in this section.

Note that there are two layerings in WSML. Both layerings are complete syntactical and semantic (wrt. entailment of ground facts) layerings. The first layering is WSML-Core > WSML-Flight > WSML-Rule > WSML-Full, with WSML-Core being the lowest language in the layering and WSML-Full being the highest. This means, among other things, that every keyword of WSML-Core is a keyword of WSML-Flight, every keyword of WSML-Flight is a keyword of WSML-Rule, etc. The second layering is WSML-Core > WSML-DL > WSML-Full, which means that every WSML-Core keyword is a WSML-DL keyword, etc. Note that the second layering is a complete semantic layering, also with respect to entailment of non-ground formulae. For now we do not take WSML-DL into account in the table.

It can happen that the definition of a specific WSML element of a lower variant is expanded in a higher variant. For example, concept definitions in WSML-Flight are an extended version of concept definitions in WSML-Core.

Table D.2 lists the keywords allowed in logical expressions. The complete logical expression syntax is defined in Section 2.8. Besides the keywords in this list, WSML also allows for the use of a number of infix operators for built-in predicates, see also Appendix C

Appendix E. Relation to WSMO Conceptual Model

WSML aims at providing a complete language to describe all elements in the WSMO conceptual model as defined in the WSMO document. however, although most elements in WSMO have direct correspondences in WSML language constructs there are slight differences due to the fact that WSML is in principle a logical description language rather than a conceptual model.

Relations. The WSMO conceptual model defines relations as parts of ontologies. This concept also exists in WSML but there are slight differences. First, parameters in relations are not named in WSML. n-ary relations in a mathematical or logical sense are usually presented as a set of n-tuples which correspond to relations in WSML. Relations with named attributes in the sense of relational databases have a strong correspondence to this view of relations being "flat" concepts which can also be represented as sets of tuples. In WSML however, one would rather model relations with named parameters as concepts with corresponding attributes. This reflects the common correspondence between conceptual modeling and the relational data model. On the contrary, n-ary relations in WSML rather correspond to n-ary predicate symbols in a logical sense.

Functions. The WSMO conceptual model defines Functions as parts of ontologies. These are defined as a special type of relations with a distinct range parameter representing the function value. We can define such functional dependencies via axioms in WSML. For instance, the age of a person is uniquely determined by the birth date of a person. We can define the computation of this function and the respective functional dependency by two axioms as follows:

Value Ranges of Attributes. In the WSMO conceptual model, each attribute can only be assigned a single Range. Similarly relation parameters have a single Range. WSML makes a more fine-grained disctinction here, reflecting the different constraining and defining views of specifying the range of an attribute/parameter by the keywords a1 ofType range and a2 impliesType range. The former states that whenever the value of an attribute a1 is specified in an instance, it is checked whether this attribute is a member of the range class, corresponding to an integrity constraint, whereas the latter correxsponds to an axiom inferring membership of range for any value of the attribute a2. Furthermore, WSMO allows you to specify a list of ranges on the right-hand-side of ofType (and impliesType, resp.) which simply corresponds to specifying the range specification to the intersection of the given ranges.

Defined Concepts and Relations. In the WSMO conceptual model, concepts and relations can have a definition assigned by the hasDefinition attribute. This attribute then contains a logical expression defining the respective concept or relation. Since a concept or relation description in WSML boils down to a set of axioms itself semantically (as shown in Section 8), definitional axioms are not directly reflected in the WSML syntax. Rather, the user is expected to specify these definitions in separate axiom descriptions. Basically, the possibility of having a definition via axioms directly associated with the description of the respective concept or relation, can in WSML be expressed by using the dc:relation element of the non-functional properties of a concept or relation. Here you can explicitly refer to related axioms by their identifiers.

Choreography and Orchestration Interfaces. The language for defining complex interfaces of Web services is not yet defined within WSML.

Footnotes

[1]The work presented in [Levy &Rousset, 1998] might serve as a starting point to define a subset of WSML-Full which could be used to enable a higher degree of interoperation between Description Logics and Logic Programming (while retaining decidability, but possibly losing tractability) rather than through their common core described in WSML-Core. If we chose to minimize the interface between both paradigms, as described in [Eiter et al., 2004], it would be sufficient to add a simple syntactical construct to the Logic Programming language. This construct would stand for a query to the Description Logic knowledge base. Thus, the logic programming engine should have an interface to the Description Logic reasoner to issue queries and retrieve results.

[2]The complexity of query answering for a language with datatype predicates depends on the time required to evaluate these predicates. Therefore, when using datatypes, the complexity of query answering may grow beyond polynomial time in case evaluation of datatype predicates is beyond polynomial time.

[3]The only expressivity added by the logical expressions over the conceptual syntax is the complete class definition, and the use of individual values.

WSML Conceptual Syntax	WSML Logical Expression Syntax
τ(ontology)	τ(ontology_element₁) ... τ(ontology_element_n)
τ(concept id superconcept attribute₁ ... attribute_n)	τ(superconcept, id) τ(attribute₁, id) ... τ(attribute_n, id)
τ(subConceptOf idlist, X)	X subConceptOf idlist.
τ(attribute_id attributefeature impliesType cardinality range_idlist, X)	?x memberOf X *and ?x[attribute_id* hasValue ?y] implies ?y memberOf** range_idlist. τ(cardinality, X, attribute_id) τ(attributefeature, X, attribute_id)
τ(attribute_id attributefeature ofType cardinality range_idlist, X)	!- ?x memberOf X and ?x[attribute_id hasValue ?y] and naf ?y memberOf range_idlist. τ(cardinality, X, attribute_id) τ(attributefeature, X, attribute_id)
τ(transitive, X, Y)	?x memberOf X and ?y memberOf X and ?x[Y hasValue ?y] and ?y[Y hasValue ?z] implies ?x[Y hasValue ?z].
τ(symmetric, X, Y)	?x memberOf X and ?y memberOf X and ?x[Y hasValue ?y] implies ?y[Y hasValue ?x].
τ(reflexive, X, Y)	?x memberOf X implies ?x[Y hasValue ?x].
τ(inverseOf(att_id), X, Y)	?x memberOf X and ?x[Y hasValue ?y] implies ?y[att_id hasValue ?x]. ?y memberOf X and ?x[att_id hasValue ?y] implies ?y[Y hasValue ?x].
τ((n), X, Y)	τ((n n), X, Y)
τ((n m), X, Y)	τ((n *), X, Y) τ((0 m), X, Y)
τ((n *), X, Y)	p_new(?x) :- ?x memberOf X and ?x[Y hasValue ?y₁, ...,Y hasValue ?y_n] and ?y₁ != ?y₂ and ?y₁ != ?y₃ and ... and ?y_n-1 != ?y_n. !- ?x memberOf x and naf p_new(?x).
τ((0 m), X, Y)	!- ?x memberOf X and ?x[Y hasValue ?y₁, ...,Y hasValue ?y_m+1] and ?y₁ != ?y₂ and ?y₁ != ?y₃ and ... and ?y_m != ?y_m+1.
τ(relation id/arity superrelation)	τ(superrelation, id, arity)
τ(subRelationOf id, X, Y)	X(?x₁,...,?x_Y) implies id(?x₁,...,?x_Y).
τ(instance id memberof attributevalue₁ ... attributevalue_n)	τ(memberof, id) τ(attributevalue₁, id) τ(attributevalue_n, id)
τ(memberOf idlist, X)	X memberOf idlist.
τ(att_id hasValue valuelist, X)	X[att_id hasValue valuelist].
τ(axiom id log_expr)	log_expr

WSML	Horn logic
π(head impliedBy body.)	π(head) ← π(body)
π(lexpr or rexpr)	π(lexpr) ∨ π(rexpr)
π(lexpr and rexpr)	π(lexpr) ∧ π(rexpr)
π(X1 memberOf id2)	id2(X1)
π(id1 subConceptOf id2)	id2(x) ← id1(x)
π(X1[id2 hasValue X2])	id2(X1,X2)
π(id1[id2 impliesType id3])	id3(y) ← id1(x) ∧ id2(x,y)
π(id1[id2 ofType dt])	dt(y) ← id1(x) ∧ id2(x,y)
π(p(X₁,...,X_n))	p(X₁,...,X_n)

WSML	F-Logic
π(!- body.)	← π(body)
π(head :- body.)	π(head) ← π(body)
π(lexpr impliedBy rexpr.)	π(lexpr) ← π(rexpr)
π(lexpr or rexpr)	π(lexpr) ∨ π(rexpr)
π(lexpr and rexpr)	π(lexpr) ∧ π(rexpr)
π(X1 memberOf X2)	X1:X2
π(X1 subConceptOf X2)	X1::X2
π(X1[X2 hasValue X3])	X1[X2 → X3]
π(X1[X2 ofType X3])	X1[X2 ⇒ X3]
π(X1[X2 impliesType X3])	_impliestype(X1,X2,X3)
π(p(X₁,...,X_n))	p(X₁,...,X_n)
π(X₁ = X₂))	X₁ = X₂)
π(X₁ != X₂)))	X₁ != X₂)

WSML	F-Logic
π(!- body.)	← π(body)
π(head :- body.)	π(head) ← π(body)
π(lexpr impliedBy rexpr.)	π(lexpr) ← π(rexpr)
π(lexpr or rexpr)	π(lexpr) ∨ π(rexpr)
π(lexpr and rexpr)	π(lexpr) ∧ π(rexpr)
π(X1 memberOf X2)	X1:X2
π(X1 subConceptOf X2)	X1::X2
π(X1[X2 hasValue X3])	X1[X2 → X3]
π(X1[X2 ofType X3])	X1[X2 ⇒ X3]
π(X1[X2 impliesType X3])	_impliestype(X1,X2,X3)
π(p(X₁,...,X_n))	p(X₁,...,X_n)
π(X₁ = X₂))	X₁ = X₂)
π(X₁ != X₂)))	X₁ != X₂)

WSML syntax	XML Tree	Remarks
T ( wsmlVariant A definition₁ ... definition_n )	<wsml xmlns="http://www.wsmo.org/wsml/wsml-syntax#" variant="A"> T(definition₁) ... T(definition_n) </wsml>	definitions are Ontology, Goal, WebService and Mediators
T ( namespace { N, P₁ N₁, ..., P_n N_n } )		Because sQnames were resolved to full IRIs during pre-processing, there is no translation to RDF necessary for namespace definitions
T ( ontology A header₁ ... header_n ontology_element₁ ... ontology_element_n )	<ontology name="A"> T(header₁) ... T(header_n) T(ontology_element₁) ... T(ontology_element_n) </ontology>	An ontology_element represents all possible content of an ontology definition, i.e., concepts, relations, instances, ...
T ( concept C subConceptOf {B₁,...,B_n} nfp attribute₁ ... attribute_n )	<concept name="C"> T(nfp) <superConcept>B₁<superConcept> ... <superConcept>B_n<superConcept> T(attribute₁) ... T(attribute_n) </concept>
T ( A attributefeature₁ ... attributefeature_n ofType cardinality C nfp )	<attribute name="A" type="constraining"> <range>C</range> T(attributefeature₁) ... T(attributefeature_n) T(cardinality) T(nfp) </attribute>
T ( A attributefeature₁ ... attributefeature_n impliesType cardinality C nfp )	<attribute name="A" type="inferring"> <range>C</range> T(attributefeature₁) ... T(attributefeature_n) T(cardinality) T(nfp) </attribute>
T ( transitive )	<transitive/>
T ( symmetric )	<symmetric/>
T ( reflexive )	<reflexive/>
T ( inverseOf(A) )	<inverseOf>A</inverseOf>
T ( (minCard maxCard) )	<minCardinality>minCard</minCardinality> <maxCardinality>maxCard</maxCardinality>
T ( (card) )	<minCardinality>card</minCardinality> <maxCardinality>card</maxCardinality>
T ( instance A memberOf C₁,...,C_n nfp attributevalue₁ ... attributevalue_n )	<instance name="A"> <memberOf>C₁</memberOf> ... <memberOf>C_n</memberOf> T(nfp) T(attributevalue₁) ... T(attributevalue_n) </instance>
T ( A hasValue {value₁, ..., value_n} )	<attributeValue name="A"> T(value₁ ... T(value_n </attributeValue>	A value has always a datatype. There are four built-in datatypes: IRI, string, integer, decimal. In addition any arbitrary datatype can be defined by use of datatype wrappers. The next four transformations show how to handle these five cases.
T ( A )	<value type="xsd#anyURI"> A </value>
T ( DV_s )	<value type="xsd#string"> DV_s </value>
T ( DV_i )	<value type="xsd#integer"> DV_i </value>
T ( DV_d )	<value type="xsd#decimal"> DV_d </value>
T ( DV )	<value type="http://www.example.org/datatype#any"> <argument>DV.arg₁</argument> ... <argument>DV.arg_n</argument> </value>	A datatype wrapper is defined by the type and a number of arguments that define the value, e.g., _date(2005,12,12) for December 12, 2005 (and thus the value of type date has three arguments). In case there is just on argument, the element <argument> is optional and the value can be given as above for IRI, string, integer, decimal.
T ( relation A / n (paramtype₁,...,paramtype_m) subRelationOf {C₁,...,C_k} nfp )	<relation name="A" arity="n"> <parameters> T(paramtype₁>) ... T(paramtype_n) </parameters> <superRelation>C₁</superRelation> ... <superRelation>C_k</superRelation> T(nfp) </relation>	Note that the parameters of a relation are ordered and thus the order of the parameters elements in the XML representation important.
T ( ofType {C₁,...,C_n} )	<parameter type="constraining"> <range>C₁</range> ... <range>C_n</range> </parameter>
T ( impliesType {C₁,...,C_n} )	<parameter type="inferring"> <range>C₁</range> ... <range>C_n</range> </parameter>
T ( relationInstance A B (value₁,...,value_n) nfp )	<relationInstance name="A"> <memberOf>B</memberOf> T(value₁) ... T(value_n) T(nfp) </relationInstance>
T ( {value₁,...,value_n} )	<parameterValue> T(value₁) ... T(value_n) </parameterValue>	Note that the parameters of a relationInstance are ordered and thus the order of the value elements is important.
T ( axiom A axiomdefinition )	<axiom name="A"> T(axiomdefinition) </axiom>
T ( nfp definedBy log_expr )	T(nfp) <definedBy> T(log_expr) </definedBy>	The mapping of logical expressions is defined in Table 9.2.
T ( goal A header₁ ... header_n capability interface₁ ... interface_n )	<goal name="A"> T(header₁) ... T(header_n) T(capability) T(interface₁) ... T(interface_n) </goal>
T ( ooMediator A nfp importsontology source target use_service )	<ooMediator name="A"> T(nfp) T(importsontology) T(source) T(target) T(use_service) </ooMediator>
T ( ggMediator A header₁ ... header_n source target use_service )	<ggMediator name="A"> T(header₁) ... T(header_n) T(source) T(target) T(use_service) </ggMediator>
T ( wgMediator A header₁ ... header_n source target use_service )	<wgMediator name="A"> T(header₁) ... T(header_n) source target use_service </wgMediator>
T ( wwMediator A header₁ ... header_n source target use_service )	<wwMediator name="A"> T(header₁) ... T(header_n) T(source) T(target) T(use_service) </wwMediator>
T ( source { A₁,...,A_n } )	<source>A₁</source> ... <source>A_n</source>
T ( target A )	<target>A</target>
T ( usesService A )	<usesService>A</usesService>
T ( webService A header₁ ... header_n capability interface₁ ... interface_n )	<webService name="A"> T(header₁) ... T(header_n) T(capability) T(interface₁) ... T(interface_n) </webService>
T ( capability C header₁ ... header_n sharedvardef pre_post_ass_or_eff₁ ... pre_post_ass_or_eff_n )	<capability name="C"> T(header₁) ... T(header_n) T(sharedvardef) T(pre_post_ass_or_eff₁) ... T(pre_post_ass_or_eff_n) </capability>	pre_post_ass_or_eff unites the axiom definitions for precondition, assumption, postcondition and effect.
T ( sharedVariables {?v₁, ..., ?v_n} )	<sharedVariables> <variable name="?v₁"/> ... <variable name="?v_n"/> </sharedVariables>
T ( precondition B axiomdefinition )	<precondition name="B"> T(axiomdefinition) </precondition>
T ( assumption B axiomdefinition )	<assumption name="B"> T(axiomdefinition) </assumption>
T ( postcondition B axiomdefinition )	<postcondition name="B"> T(axiomdefinition) </postcondition>
T ( effect B axiomdefinition )	<effect name="B"> T(axiomdefinition) </effect>
T ( interface A header₁ ... header_n choreography orchestration )	<interface name="A"> T(header₁) ... T(header_n) T(choreography) T(orchestration) </interface>
T ( choreography C )	<choreography>C</choreography>
T ( orchestration A )	<orchestration>A</orchestration>
T ( nonFunctionalProperties attributevalue₁ ... attributevalue_n endNonFunctionalProperties )	<nonFunctionalProperties> T(attributevalue₁) ... T(attributevalue_n) </nonFunctionalProperties>
T ( nfp attributevalue₁ ... attributevalue_n endnfp )	<nonFunctionalProperties> T(attributevalue₁) ... T(attributevalue_n) </nonFunctionalProperties>
T ( importsOntology { A₁,...,A_n} )	<importsOntology>A₁</importsOntology> ... <importsOntology>A_n</importsOntology>
T ( usesMediator {B₁,...,B_n} )	<usesMediator>B₁</usesMediator> ... <usesMediator>B_n</usesMediator>

WSML syntax	XML Tree	Remarks
T ( A(term₁, ..., term_n) )	<term name="A"> T (term₁, arg) ... T (term_n, arg) </term>
T ( A(term₁, ..., term_n) , name)	<*name* name="A"> T (term₁, arg) ... T (term_n, arg) </*name*>
T ( V )	<term name="C"> </term>
T ( V , name)	<*name* name="V"> </*name*>
T ( A(term₁, ..., term_n) )	<atom name="A"> T(term₁, arg) ... T(term_n, arg) </atom>
T ( T₁[attr_relation₁, ..., attr_relation_n] subConceptOf T₂ )	<molecule> T(T₁) <isa type="subConceptOf"> T(T₂) </isa> T(attr_relation₁) ... T(attr_relation_n) </molecule>
T ( T₁[attr_relation₁, ..., attr_relation_n] memberOf T₂ )	<molecule> T(T₁) <isa type="memberOf"> T(T₂) </isa> T(attr_relation₁) ... T(attr_relation_n) </molecule>
T ( T [attr_relation₁, ..., attr_relation_n] )	<molecule> T(T) T(attr_relation₁) ... T(attr_relation_n) </molecule>
T ( T₀ ofType {T₁, ..., T_n} )	<attributeDefinition type="constraining"> T(T₀, name) T(T₁, type) ... T(T_n, type) </attributeDefinition>
T ( T₀ impliesType {T₁, ..., T_n} )	<attributeDefinition type="inferring"> T(T₀, name) T(T₁, type) ... T(T_n, type) </attributeDefinition>
T ( T₀ hasValue {T₁, ..., T_n} )	<attributeValue> T(T₀, name) T(T₁, value) ... T(T_n, value) </attributeValue>
T ( expr₁ and expr₂ )	<and> T(expr₁) T(expr₂) </and>
T ( expr₁ or expr₂ )	<or> T(expr₁) T(expr₂) </or>
T ( neg expr )	<neg> T(expr) </neg>
T ( naf expr )	<naf> T(expr) </naf>
T ( expr₁ implies expr₂ )	<implies> T(expr₁) T(expr₂) </implies>
T ( expr₁ impliedBy expr₂ )	<impliedBy> T(expr₁) T(expr₂) </impliedBy>
T ( expr₁ equivalent expr₂ )	<equivalent> T(expr₁) T(expr₂) </equivalent>
T ( forall ?v₁, ..., ?v_n ( expr ) )	<forall> <var>?v₁</var> ... <var>?v_n</var> T(expr) </forall>
T ( exists ?v₁, ..., ?v_n ( expr ) )	<exists> <var>?v₁</var> ... <var>?v_n</var> T(expr) </exists>
T ( !- expr )	<constraint> T(expr) </constraint>
T ( expr₁ :- expr₂ )	<impliedByLP> T(expr₁) T(expr₂) </impliedByLP>

WSML keyword		WSML keyword
wsml#variant	Used as predicate to indicate the WSML variant applied.	wsml#goal	Used to define a WSML goal.
wsml#ontology	Used to define a WSML ontology.	wsml#ooMediator	Used to define a WSML ooMediator
wsml#hasConcept	Used to type a WSML concept and to bind it to an ontology.	wsml#ggMediator	Used to define a WSML ggMediator
wsml#attribute	Used to define a WSML attribute	wsml#wgMediator	Used to define a WSML wgMediator
wsml#ofType	Used as predicate to define constraining attributes and parameters.	wsml#wwMediator	Used to define a WSML wwMediator
wsml#hasAttribute	Used as predicate to bind an attribute to a concept.	wsml#webService	Used to define a WSML webService
wsml#transitiveAttribute	Used to indicate the transitivity of an attribute.	wsml#useInterface	Used as predicate to bind an interface to a Web service.
wsml#symmetricAttribute	Used to indicate the symmetry of an attribute.	wsml#useCapability	Used as predicate to bind a capability to a Web service or goal.
wsml#reflexiveAttribute	Used to indicate the reflexivity of an attribute.	wsml#sharedVariables	Used as predicate to bind a shared variable to a capability.
wsml#inverseOf	Used to indicate the inverse relationship of two attributes.	wsml#precondition	Used to type a precondition and to bind it to a capability.
wsml#minCardinality	Used as predicate to defined the minimal cardinality of an attribute.	wsml#assumption	Used to type an assumption and to bind it to a capability.
wsml#maxCardinality	Used as predicate to defined the maximal cardinality of an attribute.	wsml#postcondition	Used to type a postcondition and to bind it to a capability.
wsml#hasInstance	Used to type an instance and to bind it to a concept.	wsml#effect	Used to type an effect and to bind it to a capability.
wsml#hasRelation	Used to type a relation and to bind it to an ontology.	wsml#choreography	Used to type a choreography and to bind it to an interface.
wsml#arity	Used to define the arity of a WSML relation.	wsml#orchestration	Used to type an orchestration and to bind it to an interface.
wsml#param	Used to type parameters of WSML relations.	wsml#nfp	Used to type non-functional properties.
wsml#subRelationOf	Used as predicate to define sub-relations.	wsml#importsOntology	Used to define the import of an external ontology.
wsml#hasRelationInstance	Used to type a relation instance and to bind it to an ontology.	wsml#usesMediator	Used to define the use of a mediator.
wsml#hasAxiom	Used to type an axiom and to bind it to an ontology.

WSML syntax	RDF Triples	Remarks
T ( wsmlVariant A definition₁ ... definition_n )	T(definition₁, A) ... T(definition_n, A)	definitions are Ontology, Goal, WebService and Mediators
namespace { N, P₁ N₁ ... P_n N_n }		Because sQnames were resolved to full IRIs during pre-processing, there is no translation to RDF necessary for namespace definitions
T ( ontology A header₁ ... header_n ontology_element₁ ... ontology_element_n , Z )	A rdf#type wsml#ontology A wsml#variant Z T(header₁, A) ... T(header_n, A) T(ontology_element₁, A) ... T(ontology_element_n, A)	An ontology_element represents possible content of an ontology definition, i.e., concepts, relations, instances, ...
T ( concept A subConceptOf {B₁,...,B_n} nfp attribute₁ ... attribute_n , Z )	Z wsml#hasConcept A T(nfp, A) A rdfs#subClassOf B₁ ... A rdfs#subClassOf B_n T(attribute₁, A) ... T(attribute_n, A)
T ( A attributefeature₁ ... attributefeature_n ofType cardinality C nfp , Z )	_:X wsml#attribute A T(attributefeature₁, _:X) ... T(attributefeature_n, _:X) _:X wsml#ofType C T(cardinality, _:X) T(nfp, _:X) Z wsml#hasAttribute _:X	The blank identifier_:X denotes a helper node to bind the attribute A to a defined owner: attributes are locally defined!
T ( A attributefeature₁ ... attributefeature_n impliesType cardinality C nfp , Z )	_:X wsml#attribute A T(attributefeature₁, _:X) ... T(attributefeature_n, _:X) _:X rdfs#range C T(cardinality, _:X) T(nfp, _:X) Z wsml#hasAttribute _:X
T ( transitive , Z )	Z rdf#type wsml#transitiveAttribute
T ( symmetric , Z )	Z rdf#type wsml#symmetricAttribute
T ( reflexive , Z )	Z rdf#type wsml#reflexiveAttribute
T ( inverseOf(A) , Z )	Z wsml#inverseOf A
T ( (m n) , Z )	Z wsml#minCardinality m Z wsml#maxCardinality n
T ( (card) , Z )	Z wsml#minCardinality card Z wsml#maxCardinality card
T ( instance A memberOf C₁,...,C_n nfp attributevalue₁ ... attributevalue_n , Z )	Z wsml#hasInstance A A rdf#type C₁ ... A rdf#type C_n T(nfp, A) T(attributevalue₁, A) ... T(attributevalue_n, A)	It is not required to associate an instance with an identifier. In that case the identifier J is replaced by a blank node identifier, e.g _:X. The same counts for all entities that do not require an ID: instance, relationInstance, but also goal, mediators, webService and capabilty and interface definitions.
T ( dc#title hasValue value , Z )	Z rdfs#label T(value)
T ( dc#description hasValue value , Z )	Z rdfs#comment T(value)
T ( dc#relation hasValue value , Z )	Z rdfs#seeAlso T(value)
T ( A hasValue value , Z )	Z A T(value)
T ( DV_s )	DV_s^^xsd#string	Strings are already enclosed with double quotes in WSML; these do not have to be added for the RDF literals.
T ( DV_i )	"DV_i"^^xsd#integer
T ( DV_d )	"DV_d"^^xsd#decimal
T ( D(a₁,...,a_n) )	T_serializer(D(a₁,...,a_n))^^T_datatypes(D)	T_serializer serializes the WSML representation of a data value to a string representation which can be readily used in RDF literals. This function is not yet defined. T_datatypes maps WSML datatypes to XML Schema datatypes, according to Table C.1 in Appendix C.
T ( A )	A	IRIs are directly used in RDF.
T ( relation A / n (B₁,...B_m) subRelationOf {C₁,...,C_k} nfp , Z )	Z wsml#hasRelation A A wsml#arity "n"^^xsd#integer A wsml#param _:X _:X rdf#type rdf#List _:X rdf#first _:X₁ T(B₁, _:X₁) _:X rdf#rest _:1 _:1 rdf#type rdf#List _:1 rdf#first _:X₂ ... _:m rdf#type rdf#List _:m rdf#first _:X_n T(B_m, _:X_n) R wsml#subRelationOf C₁ ... R wsml#subRelationOf C_k T(nfp, A)	The parameters of a relation are unnamed and thus ordered. The ordering in RDF is provided by use of the rdf#List.
T ( ofType C , Z )	Z wsml#ofType C
T ( impliesType C , Z )	Z rdfs#range C
T ( relationInstance A B (valuelist) nfp , Z)	Z wsml#hasRelationInstance A A rdf#type B T(valuelist, A) T(nfp, A)
T ( value₁,...,value_n , Z )	Z wsml#param _:X _:X rdf#type rdf#List _:X rdf#first T(value₁) _:X rdf#rest _:1 _:1 rdf#type rdf#List _:1 rdf#first T(value₂) _:1 rdf#rest _:2 ... _:m rdf#type rdf#List _:m rdf#first T(value_n)	The arguments of a relationinstance are unnamed and thus ordered. The ordering in RDF is provided by use of the rdf#List.
T ( axiom A axiomdefinition , Z )	Z wsml#hasAxiom A T(axiomdefinition, A)
T ( nfp definedBy log_expr )	T(nfp, A) A rdfs#isDefinedBy "T_XML(log_expr)"^^rdf#XMLLiteral	log_expr denotes a logical expression. The logical expressions are translated to literals of type rdf#XMLLiteral using the mapping function defined in Table 9.2
T ( goal A header₁ ... header_n capability interface₁ ... interface_n , Z)	A wsml#variant Z A rdf#type wsml#goal T(header₁, A) ... T(header_n, A) T(capability, A) T(interface₁, A) ... T(interface_n, A)
T ( ooMediator A nfp importsontology source target use_service , Z)	A wsml#variant Z A rdf#type wsml#ooMediator T(nfp, A) T(importsontology, A) T(source, A) T(target, A) T(use_service, A)
T ( ggMediator A nfp importsontology source target use_service , Z)	A wsml#variant Z A rdf#type wsml#ggMediator T(nfp, A) T(importsontology, A) T(source, A) T(target, A) T(use_service, A)
T ( wgMediator A nfp importsontology source target use_service , Z)	A wsml#variant Z A rdf#type wsml#wgMediator T(nfp, A) T(importsontology, A) T(source, A) T(target, A) T(use_service, A)
T ( wwMediator A nfp importsontology source target use_service , Z)	A wsml#variant Z A rdf#type wsml#wMediator T(nfp, A) T(importsontology, A) T(source, A) T(target, A) T(use_service, A)
T ( source { A₁,...,A_n } , Z)	Z wsml#source A₁ ... Z wsml#source A_n
T ( target A , Z)	Z wsml#target A
T ( usesService A , Z)	Z wsml#usesService A
T ( webService A header₁ ... header_n capability interface₁ ... interface_n , Z )	A wsml#variant Z A rdf#type wsml#webService T(header₁, A) ... T(header_n, A) T(capability, A) T(interface₁, A) ... T(interface_n, A)
T ( capability C header₁ ... header_n sharedvardef pre_post_ass_or_eff₁ ... pre_post_ass_or_eff_n , Z )	Z wsml#useCapabilty C T(header₁, C) ... T(header_n, C) T(sharedvardef, C) T(pre_post_ass_or_eff₁, C) ... T(pre_post_ass_or_eff_n, C)	pre_post_ass_or_eff reunites the axiom definitions for precondition, assumption, postcondition and effect.
T ( sharedVariables {?v₁, ..., ?v_n} , Z)	Z wsml#sharedVariables ?v₁ ... Z wsml#sharedVariables ?v_n	Please note that instead of simply using a triple per shared variable it is possible to apply the rdf#Bag container to better describe the group character of shared variables.
T ( precondition B axiomdefinition , Z)	Z wsml#precondition B T(axiomdefinition, B)
T ( assumption B axiomdefinition , Z)	Z wsml#assumption B T(axiomdefinition, B)
T ( postcondition B axiomdefinition , Z)	Z wsml#postcondition B T(axiomdefinition, B)
T ( effect B axiomdefinition , Z)	Z wsml#effect B T(axiomdefinition, B)
T ( interface A header₁ ... header_n choreography orchestration , Z )	Z wsml#useInterface A T(header₁, A) ... T(header_n, A) T(choreography, A) T(orchestration, A)
T ( choreography C , Z )	Z wsml#choreography C
T ( orchestration A , Z )	Z wsml#orchestration A
T ( nonFunctionalProperties attributevalue₁ ... attributevalue_n endNonFunctionalProperties , Z )	Z wsml#nfp _:P₁ T(attributevalue₁, _:P₁) ... Z wsml#nfp _:P_n T(attributevalue_n, _:P_n)
T ( nfp attributevalue₁ ... attributevalue_n endnfp , Z )	Z wsml#nfp _:P₁ T(attributevalue₁, _:P₁) ... Z wsml#nfp _:P_n T(attributevalue_n, _:P_n)
T ( importsOntology { A₁,...,A_n} , Z )	Z wsml#importsOntology A₁ ... Z wsml#importsOntology A_n
T ( usesMediator {B₁,...,B_n} , Z )	Z wsml#usesMediator B₁ ... Z wsml#usesMediator B_n

WSML-Core conceptual syntax	OWL DL Abstract syntax	Remarks
Mapping for ontologies
τ( ontology A header₁ ... header_n ontology_element₁ ... ontology_element_n )	Ontology(id τ(header₁) ... τ(header_n) τ(ontology_element₁) ... τ(ontology_element_n) )
τ(nonFunctionalProperties id₁ hasValue value₁ ... id_n hasValue value_n endNonFunctionalProperties )	annotation(id₁ τ(value₁)) ... annotation(id_n τ(value_n))	For non-functional properties on the ontology level "Annotation" instead of "annotation" has to be written.
τ(importsOntoloy idlist)	Annotation(owl#import id₁) ... Annotation(owl#import id_n)	An idlist can consist of n full IRIs (this remark holds for all idlists in this table.
τ(usesMediator idlist)	Annotation(wsml#usesMediator id₁) ... Annotation(wsml#usesMediator id_n)	OWL does not have the concept of a mediator. Therefore, the translation uses the wsml#usesMediator annotation.
Mapping for concepts
τ(concept id superconcept nfp att_id₁ att_type₁ range_id₁ ... att_id_n att_type_n range_id_n )	Class(id partial τ(nfp) τ(superconcept) restriction (att_id₁ allValuesFrom range_id₁)... restriction (att_id_n allValuesFrom range_id_n) ) [ObjectProperty\|DatatypeProperty] (att_id₁) ... [ObjectProperty\|DatatypeProperty] (att_id_n)	"DatatypeProperty" is chosen in case range_id_i refers to a datatype; otherwise, "ObjectProperty" is used.
τ(subConceptOf idlist)	id₁ ... id_n
Mapping for relations
τ(relation id arity paramtyping superrelation nfp)	[ObjectProperty\|DatatypeProperty] (id τ(nfp) τ(superrelation) τ(paramtyping) )	"DatatypeProperty" is chosen in case range_id refers to a datatype identifier; otherwise the relation is mapped to "ObjectProperty" (range_id refers to the second type of paramtyping).
τ(subRelationOf idlist)	super(id₁) .. super(id_n)
τ((att_type domain_id, att_type range_id))	domain(domain_id) range(range_id)
Mapping for instances
τ(instance id memberof nfp att_id₁ hasValue value₁ ... att_id_n hasValue value_n )	Individual(id τ(nfp) τ(memberof) value (att_id₁ τ(value₁)) ... value (att_id_n τ(value_n)) )
τ(memberOf idlist)	type(id₁)...type(id_n)
τ(datatype_id(x₁,...,x_n))	τ_serializer(datatype_id(x₁,...,x_n))^^τ_datatypes(datatype_id)	τ_serializer serializes the WSML representation of a data value to a string representation which can be readily used in OWL. This function is not yet defined. τ_datatypes maps WSML datatypes to XML Schema datatypes, according to Table C.1 in Appendix C.
τ(id)	id	In WSML and IRI is enclosed by `_"` and `"`, which are omitted in OWL abstract syntax.
τ(relationInstance relation_id memberof_id(value₁, value₂) nfp)	Individual(value₁ value (memberof_id τ(value₂)) )	If the relation instance has an identifier it will be omitted. The NFPs are disregarded as their semantics cannot be captured by OWL.
Mapping for axioms
τ(axiom id nfp log_expr)	τ(log_expr)
τ(conjunction)	intersectionOf( τ(molecule₁), ..., τ(molecule_n))
τ(id[att_id₁ att_type₁ range_id₁ ... att_id_n att_type_n range_id_n]superconcept)	Class(id partial τ(superconcept) restriction (att_id₁ allValuesFrom range_id₁)... restriction (att_id_n allValuesFrom range_id_n) )
τ(id[att_id₁ hasValue value₁ ... att_id_n hasValue value_n]memberof)	Individual(id τ(memberof) value (att_id₁ τ(value₁)) ... value (att_id_n τ(value_n)) )
τ(?x[att_id hasValue ?x] impliedBy ?x[att_id hasValue ?y] and ?y[att_id hasValue ?z])	ObjectProperty(att_id Transitive)
τ(?x[att_id hasValue ?y] impliedBy ?y[att_id hasValue ?x])	ObjectProperty(att_id Symmetric)
τ(?x[att_id hasValue ?y] impliedBy ?y[att_id2 hasValue ?x])	ObjectProperty(att_id InverseOf(att_id2))
τ(?x memberOf concept_id2 impliedBy ?x memberOf concept_id)	Class (concept_id partial concept_id2)
τ(?x memberOf concept_id equivalent ?x memberOf concept_id₁ and ... and ?x memberOf concept_id_n)	Class (concept_id complete concept_id₁ ... concept_id_n )
τ(att_id(?x,?y) impliedBy att_id2(?x,?y))	SubProperty (att_id att_id2)
τ(?x memberOf concept_id impliedBy att_id(?x,?y))	ObjectProperty(att_id domain(concept_id) )
τ(?y memberOf concept_id impliedBy att_id(?x,?y))	ObjectProperty(att_id range(att_id2) )
τ()		If τ is applied for a non-occurring production no translation has to be made

OWL DL Abstract syntax	WSML-Core syntax	Remarks
Class Axioms
Class(A partial C₁ ... C_n)	concept A nonFunctionalProperties dc#relation hasValue AxiomOfA endNonFunctionalProperties axiom AxiomOfA definedBy τ(?x_new memberOf A, C₁, ?x_new). ... τ(?x_new memberOf A, C_n, ?x_new).	If C_i is a named class the axiom definition for this i can be omitted and only conceptual syntax can be used by including C_i in the list of super concepts of A: concept A subConceptOf {C_i}
Class(A complete C₁ ... C_n)	concept A nonFunctionalProperties dc#relation hasValue AxiomOfA endNonFunctionalProperties axiom AxiomOfA definedBy τ(?x_new memberOf A, C₁, ?x_new). ... τ(?x_new memberOf A, C_n, ?x_new). τ(τ_lhs(C₁, ?x_new), A, ?x_new). τ(τ_lhs(C_n, ?x_new), A, ?x_new).	τ_lhs stands for a transformation function for left-hand side descriptions.
EquivalentClasses(C₁ ... C_n)	axiom _# definedBy τ(τ_lhs(C_i, ?x_new), C_j, ?x_new).	Conjunctively for all i ≠ j
SubClassOf(C₁ C₂)	axiom _# definedBy τ(τ_lhs(C₁, ?x_new), C₂, ?x_new)
Mapping of left hand side descriptions
τ_lhs(A,X)	X memberOf A
τ_lhs(intersectionOf(C₁ ... C_n), X)	τ_lhs(C₁, X) and ... and τ_lhs(C_n, X)
τ_lhs(unionOf(C₁ ... C_n), X)	τ_lhs(C₁, X) or ... or τ_lhs(C_n, X)
τ_lhs(restriction( R someValuesFrom C), X)	X[R hasValue ?x_new] and τ_lhs(C, x_new)
τ_lhs(restriction( R minCardinality(1)), X)	X[R hasValue x_new]
Mapping of right hand side descriptions
τ(WSMLExpr, intersectionOf(C₁ ... C_n), X)	τ(WSMLExpr, C₁, X) and ... and τ(WSMLExpr, C_n, X)
τ(X memberOf A₁, A₂, X)	A₁ subConceptOf A₂
τ(WSMLExpr, A, X)	WSMLExpr implies X memberOf A
τ(WSMLExpr, restriction( R allValuesFrom C), X)	τ(WSMLExpr and X[R hasValue ?x_new], C, ?x_new)
Property Axioms
ObjectProperty(R [super(R₁) ... super(R_n)] [domain(C₁) ... domain(C_n)] [range(D₁) ... range(D_n)] [inverseOf(R')] [Symmetric] [Transitive] )	relation R/2 subRelationOf {R₁, ..., R_n} nonFunctionalProperties dc#relation hasValue AxiomOfR endNonFunctionalProperties axiom AxiomOfR definedBy τ(?x[R hasValue ?y], C₁, ?x) and ... and τ(?x[R hasValue ?y], C_n, ?x). τ(?x[R hasValue ?y], D₁, ?x) and ... and τ(?x[R hasValue ?y], D_n, ?x). ?x[R hasValue ?y] implies ?y[R' hasValue ?x] and ?x[R' hasValue ?y] implies ?y[R hasValue ?x]. ?x[R hasValue ?y] implies ?y[R hasValue ?x]. ?x[R hasValue ?y] and ?y[R hasValue ?z]. implies ?x[R hasValue ?z].	All Specifications of the ObjectProperty except the identifier are optional. If both range and domain are given and consist only of named classes their translation can be abbreviated in the conceptual model: relation R( impliesType {C₁, ..., C_n} impliesType {D₁, ..., D_n})
SubProperty(R₁ R₂)	relation R₁/2 subRelationOf R₂
EquivalentProperties(R₁ ... R_n)	?x[R_i hasValue ?y] implies ?x[R_j hasValue ?y]	Conjunctively for all i ≠ j
Individuals
Individual (I [type (C₁) ... type(C_n)] [value (R₁ V₁) ... value (R_n V_n)] )	instance I memberOf {C₁,..., C_n} R₁ hasValue V₁ .... R_n hasValue V_n	All Specifications of the Individual except the identifier are optional.

WSML datatype constructor	XML Schema datatype	Description of the Datatype	Syntax
_string	string	A finite-length sequence of Unicode characters, where each occurrence of the double quote ‘"’ is escaped using the backslash symbol: ‘\"’ and the backslash is escaped using the backslash: ‘\\’.	_string("any-character*")
_decimal	decimal	That subset of natural numbers which can be represented with a finite sequence of decimal numerals.	_decimal("'-'?numeric+.numeric+")
_integer	integer	That subset of decimals which corresponds with natural numbers.	_integer("'-'?numeric+")
_float	float		_float("see XML Schema document")
_double	double		_double("see XML Schema document")
_iri	similar to anyURI	An IRI conforms to [IRI]. Every URI is an IRI.	_iri("iri-according-to-rfc3987")
_sqname	serialized QName	An sQName is a pair {namespace, localname}, where the localname us concatenated to the namespace to form an IRI. An sQName is actually equivalent to the IRI which results from concatenating the namespace and the localname.	_sqname("iri-according-to-rfc3987", "localname")
_boolean	boolean		_boolean("true-or-false")
_duration	duration		_duration(year, month, day, hour, minute, second)
_dateTime	dateTime		_dateTime(year, month, day, hour, minute, second, timezone-hour, timezone-minute) _dateTime(year, month, day, hour, minute, second)
_time	time		_time(hour, minute, second, timezone-hour, timezone-minute) _time(hour, minute, second)
_date	date		_date(year, month, day, timezone-hour, timezone-minute) _date(year, month, day)
_gyearmonth	gYearMonth		_gyearmonth(year, month)
_gyear	gYear		_gyear(year)
_gmonthday	gMonthDay		_gmonthday(month, day)
_gday	gDay		_gday(day)
_gmonth	gMonth		_gmonth(month)
_hexbinary	hexBinary		_hexbinary(hexadecimal-encoding)
_base64binary	base64Binary		_base64binary(hexadecimal-encoding)

WSML datatype constructor	Shortcut syntax	Example
_string	"any-character*"	"John Smith"
_decimal	'-'?numeric+.numeric+	4.2, 42.0
_integer	'-'?numeric+	42, -4
_iri	_"iri-according-to-rfc3987"	_"http://www.wsmo.org/wsml/wsml-syntax#"
_sqname	alphanumeric+'#'alphanumeric+	wsml#concept, xsd#integer

WSML datatype predicate	XQuery function	Datatype (A)	Datatype (B)	Return datatype
wsml#numericEqual(A,B)	op#numeric-equal(A,B)	numeric	numeric
wsml#numericGreaterThan(A,B)	op#numeric-greater-than(A,B)	numeric	numeric
wsml#numericLessThan(A,B)	op#numeric-less-than(A,B)	numeric	numeric
wsml#stringEqual(A,B)	op#numeric-equal(fn:compare(A, B), 1)	xsd#string	xsd#string
wsml#numericAdd(range,A,B)	op#numeric-add(A,B)	numeric	numeric	numeric
wsml#numericSubtract(range,A,B)	op#numeric-subtract(A,B)	numeric	numeric	numeric
wsml#numericMultiply(range,A,B)	op#numeric-multiply(A,B)	numeric	numeric	numeric
wsml#numericDivide(range,A,B)	op#numeric-divide(A,B)	numeric	numeric	numeric

Operator	Datatype (A)	Datatype (B)	Predicate
A = B	string	string	wsml#stringEqual(A,B)
A != B	xsd#string	xsd#string	wsml#stringInequal(A,B)
A = B	numeric	numeric	wsml#numericEqual(A,B)
A != B	numeric	numeric	wsml#numericInequal(A,B)
A < B	numeric	numeric	wsml#lessThan(A,B)
A =< B	numeric	numeric	wsml#lessEqual(A,B)
A > B	numeric	numeric	wsml#greaterThan(A,B)
A >= B	numeric	numeric	wsml#greaterEqual(A,B))

Operator	Datatype (A)	Datatype (B)	Predicate
A + B	numeric	numeric	wsml#numericAdd(?x1,A,B)
A - B	numeric	numeric	wsml#numericSubtract(?x1,A,B)
A * B	numeric	numeric	wsml#numericMultiply(?x1,A,B)
A / B	numeric	numeric	wsml#numericDivide(?x1,A,B)

Keyword	Section	Core	Flight	Rule	Full
wsmlVariant	2.2.1	+	+	+	+
namespace	2.2.2	+	+	+	+
nonFunctionalProperties	2.2.3	+	+	+	+
endNonFunctionalProperties	2.2.3	+	+	+	+
nfp	2.2.3	+	+	+	+
endnfp	2.2.3	+	+	+	+
importsOntology	2.2.3	+	+	+	+
usesMediator	2.2.3	+	+	+	+
ontology	2.3	+	+	+	+
concept	2.3.1	+	+	+	+
subConceptOf	2.3.1	+	+	+	+
ofType	2.3.1.1	+	+	+	+
impliesType	2.3.1.1	+	+	+	+
transitive	2.3.1.1	+	+	+	+
symmetric	2.3.1.1	+	+	+	+
inverseOf	2.3.1.1	+	+	+	+
reflexive	2.3.1.1		+	+	+
relation	2.3.2	+	+	+	+
subRelationOf	2.3.2	+	+	+	+
instance	2.3.3	+	+	+	+
memberOf	2.3.3	+	+	+	+
hasValue	2.3.3	+	+	+	+
relationInstance	2.3.3	+	+	+	+
axiom	2.3.4	+	+	+	+
definedBy	2.3.4	+	+	+	+
capability	2.4.1	+	+	+	+
sharedVariables	2.4.1	+	+	+	+
precondition	2.4.1	+	+	+	+
assumption	2.4.1	+	+	+	+
postcondition	2.4.1	+	+	+	+
effect	2.4.1	+	+	+	+
interface	2.4.2	+	+	+	+
choreography	2.4.2	+	+	+	+
orchestration	2.4.2	+	+	+	+
goal	2.5	+	+	+	+
ooMediator	2.6	+	+	+	+
ggMediator	2.6	+	+	+	+
wgMediator	2.6	+	+	+	+
wwMediator	2.6	+	+	+	+
source	2.6	+	+	+	+
target	2.6	+	+	+	+
usesService	2.6	+	+	+	+
webService	2.7	+	+	+	+

Keyword	WSML-Core	WSML-Flight	WSML-Rule	WSML-Full
true	+	+	+	+
false	+	+	+	+
memberOf	+	+	+	+
hasValue	+	+	+	+
subConceptOf	+	+	+	+
ofType	+	+	+	+
impliesType	+	+	+	+
and	+	+	+	+
or	+	+	+	+
implies	+	+	+	+
impliedBy	+	+	+	+
equivalent	+	+	+	+
neg	-	-	-	+
not	-	+	+	+
forall	+	+	+	+
exists	-	-	-	+