D16.1v0.3 WSML Language Reference

For printing and off-line reading, this document is also available in non-normative PDF version.

Abstract

WSML is a language for modeling Web services, ontologies, and related aspects, and is based on the Web Service Modeling Ontology WSMO. The formal grounding of the language is based on a number of logical formalisms, namely, Description Logics, First-Order Logic and Logic Programming. Besides providing its own language for modeling ontologies, it allows the import and use of RDF Schema and OWL ontologies for Web service description.

This document provides a reference of the features of the WSML language. It is intended for users who want to model web services and ontologies using WSML, and implementers who want to build tools based on the WSML language.

Please note that the current version of the WSML specification (that is WSML v0.3) is not backward compatible to the previous version of WSML (that is WSML v0.21). For details please refer to the changelog.

PART I: PRELUDE

1. Introduction

The Web Service Modeling Ontology WSMO [Roman et al. 2006] 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. The WSML Abstract Syntax and Semantics [de Bruijn, 2007] closely follows the conceptual model of WSMO version 1.3 in presenting the abstract syntax as well as the semantics of WSML, and only diverges where necessary. That document also features a mapping from the abstract to the surface syntax of WSML. The latter is defined the WSML Language Reference, i.e. in this document. It provides a specification of all WSML variants in terms of a human-readable syntax with keywords similar to the elements of the WSMO conceptual model. To increase the interoperability of WSML, exchange syntaxes to XML and RDFS have been developed (based on [de Bruijn, 2007]) in the following documents: WSML/XML in [Toma, 2008] and WSML/RDF in [de Bruijn, 2006]. Furthermore a mapping from WSML-DL to OWL DL and vice versa has been developed (based as well on [de Bruijn, 2007]) in the following document: [Steinmetz, 2008]. This mapping can be seen as guide for people that are interested in conversions between WSML and OWL.

The WSML Language Reference takes the abstract syntax of WSML as a basis 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.

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 [Dean & Schreiber, 2004] 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, 2004]. 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.

Please note that the current version of the WSML specification (that is WSML v0.3) is not backward compatible to the previous version of WSML (that is WSML v0.21) with respect to the following items:

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 [Patel-Schneider et al., 2004]. 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. Finally, 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.

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 [de Bruijn, 2007], as well as 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 three syntaxes for WSML were developed, namely XML, RDF and OWL. The XML exchange syntax for WSML, defined in [Toma, 2008], is the preferred syntax for the exchange of WSML specifications between machines. The RDF syntax of WSML, defined in [de Bruijn, 2006], can be used by RDF-based applications and finally a mapping between WSML and OWL ontologies is discussed in [de Bruijn, 2007] and in [Steinmetz, 2008] in order to allow interoperation with OWL-based applications. This section provides pointers to external documents containing these syntaxes.

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 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 C contains a complete list of WSML keywords, as well as references to the sections in the document where these are described. Finally, Appendix D contains the changelog.

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.

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 belong to the WSML prologue and 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

A WSML specification contains all information about a class and its attributes, a relation and its parameters and an instance and its attribute values 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 WSML, 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. In case one needs to model a property which is independent of the concept definition, this property is most likely a relation rather than an attribute and thus should be modeled as a relation.

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, 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, and finally the use of MIME types for WSML specifications. 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 [XML-NAMESPACES-1.1] for the purpose of qualifying names which originate from different XML documents. In XML, each qualified name consists of a tuple <namespace, localname>. RDF [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).

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

An identifier in WSML is either a data value, an IRI [Duerst & Suignard, 2005] or an anonymous ID. Additionally a new kind of identifiers has been introduced, namely variables. They might only be used (a) in the conceptual syntax in the nonFunctionalProperty definition or in the sharedVariables block, or (b) in the logical expression syntax.

Note that the sets of identifiers of the following items are disjoint: ontology, goal, Web service, ooMediator, ggMediator, wgMediator, wwMediator, capability, interface, choreography, orchestration, state signature, grounding identifier, variant identifier, datatype wrapper identifier, built-in predicate identifier.

Data values

WSML has direct support for different types of concrete data, namely, strings, integers and decimals, which correspond to the XML Schema [Biron & Malhotra, 2004] 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.

To construct data values, WSML uses datatype wrappers. Datatype wrappers are IRIs used to define data types based on the XML Schema datatypes. Each datatype wrapper has a name and a set of arguments. The name of a datatype wrapper corresponds to the IRI of the datatype. The use of such datatype wrappers gives more control over the structure of the data values than the lexical representation of XML. For example, the date: 3rd of February, 2005, which can be written in XML as: '2005-02-03', is written in WSML as: xsd#date(2005,2,3).

The arguments of a datatype wrapper can be strings, integers, decimals 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.

The WSML surface syntax allows, but discourages, to use a shortcut syntax for the datatype wrappers, e.g. _integer is short for xsd#integer (which is the Compact URI corresponding to the IRI http://www.w3.org/2001/XMLSchema#integer); a shortcut syntax is a legacy feature.

Datatype identifiers manifest themselves in WSML in two distinct ways, namely, as concept identifiers and as datatype wrappers. A datatype wrapper is used as a data structure 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.

A data value identifier can be either a simple datavalue, i.e. an integer, a decimal or a string, or it can be a constructed datavalue, where a constructeddatavalue corresponds to a datatype wrapper.

Internationalized Resource Identifiers

The IRI (Internationalized Resource Identifier) [Duerst & Suignard, 2005] 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 a Compact URI. Such a Compact URI is similar to the qualified Name 'QName' in XML. After its introduction in XML [Bray et al., 2004], the term 'QName' has been used 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 'Compact URIs'.

A Compact URI consists of two parts, namely, the namespace prefix and the local part. A Compact URI is written using a namespace prefix and a localname, separated by a hash ('#'): namespace_prefix#localname.

A Compact URI is equivalent to the IRI which is obtained by concatenating the namespace IRI (to which the prefix refers) with the local part of the Compact URI. Therefore, a Compact URI can be seen as an abbreviation for an IRI which enhances the legibility of the specification. If a Compact URI has no prefix, the namespace of the Compact URI is the default namespace of the document, except for attribute identifiers. The namespace of an attribute identifier with no prefix is the namespace of the concept type or the instance definition within which it appears. Note: In case the default namespace is not defined or a prefix used in a Compact URI cannot be resolved, the WSML specification is not well formed.

IRIs are Unicode strings which are valid absolute IRIs according to [Duerst & Suignard, 2005] delimited with the symbols ' _" ' and ' " '. For convenience, a Compact URI does not require special delimiters. Any Compact URI contains a namespace prefix. Namespace prefixes may not coincide with any WSML keywords. The characters '.' and '-' in a Compact URI need to be escaped using the backslash (‘\’) character.

Examples of Compact URIs 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/#):

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.

The use of an identifier in the specification of the WSML elements ontology, goal, Web service, mediator, capability, interface, choreography and orchestration is optional. If no identifier is specified and if the element is not contained within another element (as e.g. a capability contained in a goal), the following rule applies: the identifier is assumed to be the same as the locator of the specification, i.e. the location where the specification was found. If an element is contained within another element, it does not need to have an identifier. The fact that the set of identifiers of those items need to be disjoint, as described in the beginning of this section, makes that there may not be two such top level elements without an identifier in a single file (e.g. a Web service and an ontology without an identifier), as they would otherwise get the same identifier.

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 unnumbered anonymous IDs. 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.

Please note that anonymous identifiers are disallowed for the following elements:

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 attached to the same concept identifier, the resulting concept definition includes all attributes of the original definitions. Also if the same attribute is defined in both concept definitions, the range of the resulting attribute will be equivalent to the conjunction of the ranges of the original attributes.

Variables

Variables are a new kind of identifiers which are used in defining WSML logical expressions (see Section Section 2.8).

Variable names start with an initial question mark, "?". Variables may only occur in place of concepts, attributes, instances, relation arguments or attribute values. A variable may not, for example, replace a WSML keyword however.

Variables may only be used (a) inside of logical expressions, and (b) as values in a non-functional property definition (see Section Section 2.4.3) or in the sharedVariables block within capability definitions (see Section Section 2.4.1).

The scope of a variable is 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.

Invalidity of identifiers

Note that whenever in place of an identifier a symbol is used which is not a valid identifier, the document is not a valid WSML document. Examples include Compact URIs with undefined namespace prefixes and invalid data values.

2.1.3 Comments in WSML

A WSML file may at any place contain a comment. A single line comment starts with // 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 annotations 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.1.4 WSML MIME type

When accessing resources over the Web, the MIME type indicates the type of the resource. For example, plain text documents have the MIME type text/plain and XML documents have the MIME type application/xml.

When exchanging WSML documents written in the normative syntax, it is necessary to use the appropriate MIME type so that automated agents can detect the type of content. The MIME type to be used for WSML documents is:
application/x-wsml

WSML/XML documents should have the MIME type: application/x-wsml+xml
WSML/RDF documents in the XML serialization of RDF should have the usual MIME type: application/rdf+xml

2.2 WSML Prologue

This section describes the prologue of a WSML specification, that is all those elements that are 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

The WSML header consists of items that any WSML specification may have: annotations, import ontologies and use mediators:

Annotations

Annotations can be used for the WSML document as a whole or specific for each element in the specification. Annotations blocks are delimited with the keywords annotations and endAnnotations. 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 unnumbered anonymous identifier or a comma-separated list of the former, delimited with curly brackets. The recommended properties are the properties of the Dublin Core Metadata Element Set [Weibel et al. 1998], but the list of properties is extensible and thus the user can choose to use properties coming from different sources. WSMO [Roman et al., 2006] 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 and wsml#owner, (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 annotations see [Roman et al., 2006]. 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.

Annotations in WSML are not part of the logical language, that is of the conceptual or the logical expression syntax in WSML; programmatic access to these properties can be provided through an API.

The current version of WSML is not backward compatible with respect to the syntax used to specify annotations descriptions. In the previous versions (versions before d16.1v0.3_20061110) annotation descriptions were implemented as nonFunctionalProperties or nfp constructs. The current versions use the annotations construct. A translation tool from the old syntax to the new syntax to convert documents is available at http://tools.deri.org/wsml/nfptranslator/.

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.

WSML does not only allow the import of WSML ontologies: the imported ontologies may be WSML ontologies, RDFS graphs, or OWL ontologies (both OWL DL and OWL Full are supported). The variant of every imported ontology should be lower than or equal to the variant of the importing description. RDFS ontologies are conformant to WSML Flight or WSML Rule. If an OWL DL ontology is in the DLP subset, i.e. it is equivalent to a set of equality-free Horn formulas, it has the WSML-Core variant. If not, it has the variant WSML-DL or WSML-Full. An OWL Full ontology is in the WSML-Full variant.

If the imported ontology is of a higher 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 Ontologies 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 [Roman et al., 2006].

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 annotations 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 a definition 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 annotations 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. 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. WSML supports defined concepts through the use of axioms (see Section 2.3.4). The axiom definition below 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.

As mentioned above axioms can be used to define concepts. 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

As already described in Section 2.1, WSML Syntax Basics,, attributes in WSML 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. In case one needs to model a property which is independent of the concept definition, this property is most likely a relation rather than an attribute and thus should be modeled as a relation.

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 using the keyword ofType, 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.

Please note that WSML allows instances which are not members of a particular concept. This makes that the attribute range does not need to contain a concept identifier or datatype as value. Attributes can thus be written in all WSML variants by using an empty idlist, e.g. 'a ofType { }'.

Attributes which do not have a datatype 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. Attributes can also be specified as being a subAttribute of another attribute, using the keyword subAttributeOf. Notice that these keywords do not enforce a constraint on the attribute, but are used to infer additional information about the attribute. The keywords inverseOf and subAttributeOf must be followed by an identifier of the attribute, enclosed in parentheses, of which this attribute is the inverse, respectively the subAttribute of.

WSML allows the specification of cardinality and range constraints which are defined like integrity constraints in databases, i.e., in the case of violation of a constraint, a given ontology is inconsistent. This additional feature allows to check the integrity of a closed set of data, implicitly leading the modeler to express a local closed world view on her/his published data.

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. In the same time att2 is the inverse of att1 which means that the following can be inferred: a has an attribute att1 with value b. The inverseOf relationship is a symmetric relationship between attributes. This means that if att1 is the inverse of att2, then att2 is the inverse of att1.

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

2.3.2 Instances

An instance definition starts with the instance keyword, optionally followed by the identifier of the instance and optionally by 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. Attribute values can be IRIs, unnumbered anonymous identifiers and datavalues.

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 [Roman et al., 2006], 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.

WSML allows instances which are not members of a particular concept. This can be written in all WSML variants like, e.g.

2.3.3 Relations

Relations in WSML can be used in order to model interdependencies between several concepts (respectively instances of these concepts). 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 annotations 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 annotation dc#relation.

2.3.4 RelationInstances

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, and the name of the relation to which the instance belongs. This is followed by the values of the parameters associated with the instance and by an optional annotations block. The parameter values can be IRIs, unnumbered anonymous identifiers and datavalues.

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.5 Axioms

The usage of axioms in WSML allows for example to refine the definition already given in the conceptual syntax. This can concern for example subconcept and attribute definitions (see also Section 2.3.1.).

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

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

2.4 Capabilities, Interfaces and Non-functional Properties in WSML

The desired and provided functionality of services 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. Finally, other aspects of services or goals which are neither functional nor behavioral are captured in non-functional properties.

2.4.1 Capabilities

A capability constitutes a formal description of the functionality requested from or provided by a Web service. WSML supports two ways of defining capabilities: create a complex capability description consisting of annotations, imported ontologies, used mediators, non-functional properties, shared variables, assumptions, preconditions, effects and postconditions, or refer to one concept (using an IRI) which is presumably defined in an ontology imported by the goal or Web service.

Concerning the complex capability descriptions, the preconditions describe conditions on the input of the service, the postconditions describe the relation between the input and the output of the service, the assumptions describe what must hold (but cannot be checked beforehand) of the state of the world for the Web service to be able to execute successfully, and the effects describe real-world effects of the execution of the Web service which are not reflected in the output.

A WSML goal or Web service may only have one capability. The specification of a capability is optional. Please note that all ontologies that are imported within a goal or Web service specification are implicitly imported in all the contained (complex) capabilities as well.

A WSML capability may be a stand-alone entity which may be defined outside a WSML goal or Web service definition. If a WSML capability is a stand-alone entity then it cannot be written in the same file as goal, Web service and mediator descriptions. A capability written in a file underneath a goal or Web service belongs to that goal or Web service. A capability that is written in a file in a way that makes it impossible to see to which Web service or goal it belongs to, causes a parse error.

A complex capability description starts with the capability keyword, (optionally) followed by the name (identifier) of the capability. This is followed by an optional annotations block, an optional importsOntology block, an optional usesMediator block and one or more optional

 
nonFunctionalProperty

statements. The (optional) 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 annotations 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.

A simple capability description starts with the


capability

keyword, followed by an IRI depicting a concept within an external ontology, describing the functionality of the goal or Web service. Such a capability should not define any annotations; they should be written in the referred ontology.

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. Please note that all ontologies that are imported within a goal or Web service specification are implicitly imported in all the contained capabilities as well.

A WSML interface may be a stand-alone entity which may be defined outside a WSML goal or Web service definition. If a WSML interface is a stand-alone entity then it cannot be written in the same file as goal, Web service and mediator descriptions. An interface written in a file underneath a goal or Web service belongs to that goal or Web service. An interface that is written in a file in a way that makes it impossible to see to which Web service or goal it belongs to, causes a parse error.

An interface specification starts with the interface keyword, (optionally) followed by the name (identifier) of the interface. This is followed by an optional annotations block, an optional importsOntology block, an optional usedMediator block, one or more optional

 
nonFunctionalProperty

statements and then by an optional choreography block and an optional orchestration block. Note that 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.

Currently only a syntax for choreographies is defined in WSML. A choreography specification starts with the choreography keyword, (optionally) followed by the name (identifier) of the choreography. This is followed by an optional annotations block, an optional importsOntology block and an optional usesMediator block. Following these elements are the optional blocks of stateSignature and transitions containers. An orchestration simply starts with the orchestration keyword followed by an optional identifier. This element is yet to be better defined.

A state signature in a choreography description starts with the stateSignature keyword followed by an optional identifier, an optional block of annotations, an optional importsOntology statement and an optional usesMediator statement. Finally, the state signature defines an optional set of mode containers. Each mode container is defined by a mandatory mode name (static, in, out, shared or controlled) and a list of entries. Each entry may take a default form (which relates to a concept), an explicit concept definition or an explicit relation definition. The default form is defined by an IRI followed by an optional block of grounding IRIs. An explicit concept mode entry is defined by the keyword concept followed by an IRI followed by an optional block of grounding IRIs. The same applies for a relation mode entry except that instead of the keyword concept, relation is used . The grounding information is defined by the withGrounding keyword followed by a list of IRIs. Note that we refrain from defining the state since such an element is comprised of the ground facts defined in the imported ontologies.

Following the state signature block is the transition rules container. This is defined by the transitionRules keyword followed by an optional identifier, an optional annotations block and a set of rule elements. A rule can take the form of an if-then, a choose, a for-all, a set of piped-rules (for non-determinism) or an update-rule. An if-then rule is defined by the if keyword, a WSML Logical Expression (condition), a then keyword, a non-empty set of rule elements and ending with the endIf keyword. A for-all rule is defined by the forall keyword, a list of variable elements, a with keyword, a WSML Logical Expression (condition), a do keyword, a set of non-empty rule elements and ending with the endForall keyword. Similarly, a choose rule is defined by the choose keyword, a list of variable elements, a with keyword, a WSML Logical Expression (condition), a do keyword, a set of non-empty rule elements and ends with the endChoose keyword. A piped rule is either a normal rule element or defined recursively by a rule followed by a pipe or followed by another set of piped rules.

An update rule is defined by a modifier keyword (add, delete or update), an open parenthesis, a fact and a closing parenthesis. A fact can take the form of a preferred molecule, a non-preferred molecule or a fact molecule. The first form, the preferred molecule, is defined by a term, an optional attribute fact, a memberOf keyword, a term list and an optional fact update. An attribute fact is defined by an open square bracket, an attribute fact list and a closing square bracket. An attribute fact list can take the form of an attribute relation or a list of attribute relations (defined recursively) delimited by a comma. An attribute relation is defined by a term, a hasValue keyword, a term list and an optional fact update. A fact update is defined by an arrow of the form => followed by a term list. The non-preferred form of a fact is defined by a term, a memberOf keyword, a term list, an optional fact update and an attribute fact. A fact molecule is defined by a term and an attribute fact. A fact can also be related to a relation. Such a fact is defined by the '@' symbol (which clearly identifies that the modifier deals with an update of a relation) an identifier, an open parenthesis, a list of term updates (depending on the number of arguments of the relation) and a closing parenthesis. The list of term updates is defined as a single term update or a term update followed by a comma followed by another term update. A term update is defined as a term, or as a term followed by the update symbol => and another new term.

The syntax presented before, known more commonly as the WSML Abstract State Machine (ASM) syntax, is the only syntax for choreographies that may be embedded within a WSML description. Should other formalisms and syntaxes be desired these choreographies should be referenced by IRIs. As no orchestration syntax has so far been specified by the WSML group it is currently not possible to embed an orchestration within a WSML description, however, same as choreographies, they may be referenced by IRIs.

Below is an example of an interface, an example of references to multiple interfaces and an example of an interface with a defined choreography:

2.4.3 Non-functional Properties

Non-functional properties are those properties which strictly belong to a Web service, goal, capability, interface or mediator and which are not functional and behavioral. A WSML Web service, goal, capability, interface or mediator may specify multiple non-functional properties. The specification of a non-functional property is optional.

Non-functional properties start with the keyword


nonFunctionalProperty

or its short form nfp. Following the keyword is an attribute value, which consists of the attribute identifier, the keyword hasValue and the value for the attribute, which may be an identifier, a data value or a variable symbol (or a set of such symbols). This is followed by an optional annotations block.

In case the value of the attribute in the name-value pair is an identifier, this value may be an IRI, a data value, an anonymous identifier or a comma-separated list of the former, delimited with curly brackets. In case it is a variable symbol, an axiom definition block in which the variable symbol is used should follow. Such an axiom definition block consists of the keyword


definedBy

, followed by one or more logical expressions, each followed by either a blank or a new line character (please note that an axiom definition block as defined for non-functional properties is not equal to an axiom as defined in Section Section 2.3.4.. The keyword axiom is omitted here.). The language allowed for the logical expression differs per WSML variant. The logical expressions are restricted to rule bodies for the Core, Flight and Rule variants, and to descriptions (i.e. tree-shaped formulas) for the DL variant. If the axiom definition block is missing or the variable symbol is not used in it, then implementations should issue a warning to the user.

2.5 Goals 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 have been explained in the previous section.

Please note that all ontologies that are imported within a goal specification are implicitly imported in all the contained capabilities and interfaces as well.

2.6 Mediators 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. [Roman et al., 2006]).

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. ooMediators can have more than one 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 iri.

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 have multiple sources. A source may be an 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 [Roman et al., 2006].

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., 2005], these descriptions often need a very expressive language.

2.7 Web Services 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.

Please note that all ontologies that are imported within a Web service specification are implicitly imported in all the contained capabilities and interfaces as well.

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.

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:

Object constructors are those elements of V that can be either functional symbols, datatype wrappers, data values, or anonymous identifiers.

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. WSML also allows the use of true and false as predicates with the standard pre-defined meaning.

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. A logical expression is a formula 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 molecules 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):

WSML keywords are allowed in the WSML logical expression syntax. Additionally, WSML allows the keywords 'true' and 'false' in the human-readable syntax.

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 WSML-Core Syntax Basics

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 syntax basics.

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:

The arguments of a datatype wrapper in WSML-Core can only be strings, integers or decimals. No other arguments, also not variables, are allowed for such data terms.

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. [Grosof et al., 2003].

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, inverseOf and subAttributeOf. This restriction stems from the fact that reflexivity, transitivity, symmetricity and inverse 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.

One may not 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

3.2.3 Instances

In WSML-Core, allowed attribute values are restricted to strings, numbers, ids, or a lists of such values. Constructed data values are not allowed.

WSML-Core does not allow the specification of relation instances, as the use of relations is disallowed.

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 'assumptions', 'preconditions', 'effects' and 'postconditions' of a capability and 'definition' of a non-functional property 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' of a capability and 'definiton' of a non-functional property 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.

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.

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 (i.e., a formula allowed in the antecedent, or left-hand side, of an implication), with the set of lhs-formulae defined as follows:

In the following, G,H stand for rhs-formulae (i.e., formulae allowed in the consequent, or right-hand side, of an implication), 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 between Var₁ and Var₂ for every molecule Var₁[p hasValue Var₂].

Note that wherever an a-molecule (or b-molecule) 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, are also allowed.

4. WSML-DL

WSML-DL is an extension of WSML-Core to a full-fledged description logic with an expressiveness similar to OWL DL, namely SHIQ(D). 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.

Same as OWL, WSML-DL does not adhere to the Unique Name Assumption (UNA). This means that having two different names does not mean that these refer to two different individuals.

All restrictions on the general conceptual modeling syntax of WSML, introduced in Chapter 2, imposed by WSML-Core, also holds for WSML-DL. The difference between WSML-Core and WSML-DL lies in the logical expression syntax. The logical expression syntax of WSML-DL is less restrictive than the logical expression syntax of WSML-Core. The remainder of this chapter defines the logical expression syntax allowed in WSML-DL.

4.1. WSML-DL Logical Expression Syntax

WSML-DL allows only a restricted form of logical expressions, as an extension of the WSML-Core logical expression syntax. The source of the restrictions on WSML-DL is the fact that the language is restricted to the SHIQ(D) subset of First-Order logic [Borgida, 1996]. This subset is close to the two-variable fragment of First-Order Logic (the only description that needs more than two variables is the description of transitive roles); it disallows the use of function symbols, restricts the arity of predicates to unary and binary and prohibits chaining variables over predicates.

Currently the WSML-DL logical expression syntax is specified in first-order logic style. The resulting language is not very user-centric, so that it is hard to use the full expressivity that Description Logics provide to WSML-DL. This is why we will propose a new DL-based alternative, non-normative, surface syntax in the next release of this deliverable.

Definition 4.2. The set of atomic formulae, also called molecules in L(V) is defined as follows:

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.

Similar to most definitions of Description Logics, we distinguish between descriptions and formulae.

The variable graph of a description F is defined as the undirected graph having all WSML variables in F as nodes and an edge between Var₁ and Var₂ for every molecule Var₁[p hasValue Var₂].

In the following, F₁, F₂ stand for WSML-DL descriptions with connected, acyclic variable graphs; furthermore, the variable graphs of F₁ and F₂ can be seen as trees which share the same root node. G stands for a WSML-DL formula.

Definition 4.4. The set of WSML-DL formulae in L(V) is defined as follows:

Note that the top level implication, inverse implication or equivalence is not needed. If it is omitted, a formula F is implicitly implied by true:
true implies F.

All variables that are not explicitly quantified are implicitly universally quantified. This entails the possibility to embed WSML-DL formulae in an outer universal quantification.

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

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.

Section 5.1 defines the restrictions on logical expressions in WSML-Flight. Section 5.2 outlines the differences between WSML-Core and WSML-Flight.

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

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 implies, 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. For more details on local stratification please refer to [de Bruijn, 2007].

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

5.2. 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 implies, impliedBy and equivalent, respectively.

There may only be one distance between two locations, and the distance between locations A and B is the same as the distance between B and A:

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 non-monotonic extensions of First-Order Logic are notoriously hard to deal with. In fact, many (if not all) such extensions are not even semi-decidable (i.e., even if the formula is consistent, the algorithm still might not terminate).

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 D2 v1.2 [Roman et al., 2006].

7.1. Differences between WSML-DL and WSML-Full

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

7.2. Differences between WSML-Rule and WSML-Full

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

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 two exchange syntaxes for WSML in order to enable automated interoperation and one WSML/OWL mapping that can be used for conversions from WSML to OWL and vice versa.

The WSML/OWL mapping is discussed in [de Bruijn, 2007] and in [Steinmetz, 2008]. This mapping can be seen as guide for people that are interested in conversions between WSML and OWL.

Appendix A. Human-Readable Syntax

This appendix presents the complete grammar for the WSML language. The language used to 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 variant 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 )?
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	=	'"'

States

default
in_ws_or_goal

Tokens

	t_blank	=	blank
	t_comment	=	comment
	at	=	'@'
	arrow	=	'=>'
	comma	=	','
	t_pipe	=	'\|'
	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_annotations	=	'annotations'
	t_endannotations	=	'endAnnotations'
	t_assumption	=	'assumption'
	t_axiom	=	'axiom'
{ in_ws_or_goal }
	t_innercapability	=	'capability'
	t_capability	=	'capability'
	t_choreography	=	'choreography'
	t_statesignature	=	'stateSignature'
	t_static	=	'static'
	t_in	=	'in'
	t_out	=	'out'
	t_shared	=	'shared'
	t_controlled	=	'controlled'
	t_withgrounding	=	'withGrounding'
	t_transitionrules	=	'transitionRules'
	t_if	=	'if'
	t_then	=	'then'
	t_endif	=	'endIf'
	t_with	=	'with'
	t_endforall	=	'endForall'
	t_choose	=	'choose'
	t_endchoose	=	'endChoose'
	t_do	=	'do'
	t_add	=	'add'
	t_delete	=	'delete'
	t_update	=	'update'
	t_concept	=	'concept'
	t_definedby	=	'definedBy'
	t_effect	=	'effect'
{ in_ws_or_goal -> default , default }
	t_ggmediator	=	'ggMediator'
{ default -> in_ws_or_goal , in_ws_or_goal }
	t_goal	=	'goal'
	t_hasvalue	=	'hasValue'
	t_impliestype	=	'impliesType'
	t_importontology	=	'importsOntology'
	t_instance	=	'instance'
{ in_ws_or_goal }
	t_innerinterface	=	'interface'
	t_interface	=	'interface'
	t_inverseof	=	'inverseOf'
	t_subattributeof	=	'subAttributeOf'
	t_memberof	=	'memberOf'
	t_namespace	=	'namespace'
	t_nfp	=	'nonFunctionalProperty' \| 'nfp'
	t_oftype	=	'ofType'
{ in_ws_or_goal -> default , default }
	t_ontology	=	'ontology'
{ in_ws_or_goal -> default , default }
	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'
{ default -> in_ws_or_goal , in_ws_or_goal }
	t_webservice	=	'webService'
{ in_ws_or_goal -> default , default }
	t_wgmediator	=	'wgMediator'
	t_wsmlvariant	=	'wsmlVariant'
{ in_ws_or_goal -> default , default }
	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_f 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
\|	{capability}	capability
\|	{interface}	interface

	{annotations}	annotations
\|	{usesmediator}	usesmediator
\|	{importsontology}	importsontology

usesmediator

t_usemediator irilist

importsontology

t_importontology irilist

annotations

t_annotations annotationvalue* t_endannotations

mediator

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

oomediator

t_oomediator iri annotations* importsontology? nfp* sources? target? use_service?

ggmediator

t_ggmediator iri header* nfp* source? target? use_service?

wgmediator

t_wgmediator iri header* nfp* sources? target? use_service?

wwmediator

t_wwmediator iri header* nfp* source? target? use_service?

t_source lbrace iri? moreiris* rbrace

sources

	{single}	source
\|	{multiple}	msources

target

t_target iri?

goal

t_goal iri header* nfp* innercapability? innerinterfaces*

webservice

t_webservice iri header* nfp* innercapability? innerinterfaces*

innercapability

t_innercapability iri header* nfp* sharedvardef? pre_post_ass_or_eff*

capability

t_capability iri header* nfp* 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

innerinterfaces

	{single}	innerinterface
\|	{multiple}	minnerinterfaces

minnerinterfaces

t_innerinterface lbrace iri moreiris* rbrace

interface

t_interface iri header* nfp* choreography? orchestration?

innerinterface

t_innerinterface iri header* nfp* choreography? orchestration?

choreography

t_choreography iri header* statesignature? transitions?

statesignature

t_statesignature id? header* mode*

mode

	{grounded_mode}	grounded_mode
\|	{ungrounded_mode}	ungrounded_mode

grounded_mode

	{in}	t_in grounded_mode_entry_list
\|	{out}	t_out grounded_mode_entry_list
\|	{shared}	t_shared grounded_mode_entry_list

ungrounded_mode

	{static}	t_static ungrounded_mode_entry_list
\|	{controlled}	t_controlled ungrounded_mode_entry_list

grounded_mode_entry_list

	{mode_entry}	grounded_mode_entry
\|	{mode_entry_list}	grounded_mode_entry comma grounded_mode_entry_list

ungrounded_mode_entry_list

	{mode_entry}	ungrounded_mode_entry
\|	{mode_entry_list}	ungrounded_mode_entry comma ungrounded_mode_entry_list

grounded_mode_entry

	{default}	iri grounding
\|	{concept}	t_concept iri grounding
\|	{relation}	t_relation iri grounding

ungrounded_mode_entry

	{default}	iri
\|	{concept}	t_concept iri
\|	{relation}	t_relation iri

grounding

t_withgrounding irilist

transitions

t_transitionrules id? annotations? rule*

rule

	{if}	t_if condition t_then rule+ t_endif piped_rule?
\|	{forall}	t_forall variables t_with condition t_do rule+ t_endforall piped_rule?
\|	{choose}	t_choose variables t_with condition t_do rule+ t_endchoose piped_rule?
\|	{undate}	updaterule

{restricted_le}

{piped_rule}

modifier lpar fact rpar

modifier

	{add}	t_add
\|	{delete}	t_delete
\|	{update}	t_update

fact

	{fact_preferred}	term attr_fact? t_memberof termlist fact_update?
\|	{fact_nonpreferred}	term t_memberof termlist fact_update? attr_fact
\|	{fact_molecule}	term attr_fact
\|	{fact_relation}	at id lpar term_updates rpar

fact_update

arrow termlist

attr_fact

lbracket attr_fact_list rbracket

attr_fact_list

	{attr_relation}	term t_hasvalue termlist fact_update?
\|		attr_fact_list comma term t_hasvalue termlist fact_update?

term_updates

	{one_param}	term_update
\|	{more_params}	term_update comma term_updates

term_update

	{single}	term
\|	{move}	[oldterm]: term arrow [newterm]: term

{new_term}

t_nfp annotations? attributevaluenfp log_definition_nfp?

attributevaluenfp

id t_hasvalue valuenfp

valuenfp

	{anyid}	anyid
\|	{var}	variable

ontology

t_ontology iri header* ontology_element*

ontology_element

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

concept

t_concept id superconcept? annotations? attribute*

superconcept

t_subconcept idlist

att_type

	{open_world}	t_oftype
\|	{closed_world}	t_impliestype

attribute

id attributefeature* att_type cardinality? idlist annotations?

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
\|	{sub_attribute_of}	t_subattributeof lpar id rpar
\|	{reflexive}	t_reflexive

instance

t_instance id? memberof? annotations? attributevalue*

memberof

t_memberof idlist

annotationvalue

id t_hasvalue anyidlist

attributevalue

id t_hasvalue anyidlist

relation

t_relation id arity? paramtyping? superrelation? annotations?

paramtyping

lpar paramtype moreparamtype* rpar

t_relation_instance [name]: id? [relation]: id lpar anyid moreanyids* rpar annotations?

axiom

t_axiom axiomdefinition

axiomdefinition

	{use_axiom}	id
\|	{annotations_axiom}	id? annotations
\|	{defined_axiom}	id? annotations? log_definition

log_definition

t_definedby log_expr+

log_definition_nfp

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 variables lpar expr rpar

simple

	{molecule}	molecule
\|	{comparison}	comparison
\|	{atom}	term
\|	{universal_truth}	t_univtrue
\|	{universal_falsehood}	t_univfalse

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

arith_val

		mult_val
\|	{addition}	arith_val arith_op mult_val
\|	{semisimple1_addition}	term arith_op mult_val
\|	{semisimple2_addition}	arith_val arith_op term
\|	{simple_addition}	[a]: term arith_op [b]: term

mult_val

		[a]: term mul_op [b]: term
\|	{multiplication}	mult_val mul_op term

math_op

	{arith}	arith_op
\|	{mult}	mul_op

arith_op

	{add}	add_op
\|	{sub}	sub_op

mul_op

	{mul}	star
\|	{div}	div_op

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

prefix

name hash

compacturi

	{any}	prefix? name
\|	{localkeyword}	prefix anykeyword

anykeyword

	{and}	t_and
\|	{or}	t_or
\|	{implies}	t_implies
\|	{implied_by}	t_implied_by
\|	{equivalent}	t_equivalent
\|	{implied_by_lp}	t_implied_by_lp
\|	{constraint}	t_constraint
\|	{not}	t_not
\|	{exists}	t_exists
\|	{forall}	t_forall
\|	{univfalse}	t_univfalse
\|	{univtrue}	t_univtrue
\|	{annotations}	t_annotations
\|	{assumption}	t_assumption
\|	{axiom}	t_axiom
\|	{capability}	t_capability
\|	{innercapability}	t_innercapability
\|	{choreography}	t_choreography
\|	{concept}	t_concept
\|	{definedby}	t_definedby
\|	{effect}	t_effect
\|	{end_annotations}	t_endannotations
\|	{ggmediator}	t_ggmediator
\|	{goal}	t_goal
\|	{hasvalue}	t_hasvalue
\|	{impliestype}	t_impliestype
\|	{importontology}	t_importontology
\|	{instance}	t_instance
\|	{interface}	t_interface
\|	{innerinterface}	t_innerinterface
\|	{inverseof}	t_inverseof
\|	{memberof}	t_memberof
\|	{namespace}	t_namespace
\|	{nfp}	t_nfp
\|	{oftype}	t_oftype
\|	{ontology}	t_ontology
\|	{oomediator}	t_oomediator
\|	{orchestration}	t_orchestration
\|	{postcondition}	t_postcondition
\|	{precondition}	t_precondition
\|	{reflexive}	t_reflexive
\|	{relation}	t_relation
\|	{relation_instance}	t_relation_instance
\|	{sharedvariable}	t_sharedvariable
\|	{source}	t_source
\|	{subconcept}	t_subconcept
\|	{subrelation}	t_subrelation
\|	{symmetric}	t_symmetric
\|	{target}	t_target
\|	{transitive}	t_transitive
\|	{usemediator}	t_usemediator
\|	{useservice}	t_useservice
\|	{webservice}	t_webservice
\|	{wgmediator}	t_wgmediator
\|	{wsmlvariant}	t_wsmlvariant
\|	{wwmediator}	t_wwmediator

iri

	{iri}	full_iri
\|	{compacturi}	compacturi

	{iri}	iri
\|	{anonymous}	anonymous

irilist

	{iri}	iri
\|	{irilist}	lbrace iri moreiris* rbrace

moreiris

comma iri

idlist

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

comma id

	{datavalue}	datavalue
\|	{term}	id

anyidlist

	{anyid}	anyid
\|	{anyidlist}	lbrace anyid moreanyids* rbrace

value

	{datatype}	functionsymbol
\|	{term}	id
\|	{numorstring}	numberorstring

numberorstring

	{numeric}	number
\|	{string}	string

datavalue

	{numorstring}	numberorstring
\|	{constructeddatavalue}	constructeddatavalue

numberorstrings

numberorstring morenumberorstrings*

morenumberorstrings

comma numberorstring

constructeddatavalue

iri lpar numberorstrings rpar

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. 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 B.1. WSML Datatypes

WSML recommends the use of XML Schema datatypes as defined in [Biron & Malhotra, 2004] 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 requires all compliant implementations to implement at least the string, decimal, and integer data types.

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 B.1 lists the datatypes recommended by WSML with the shortcut 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 [Biron & Malhotra, 2004]) and an example of the use of the datatype. The full name of the datatype constructor is the IRI http://www.w3.org/2001/XMLSchema#datatype, where datatype is the name of the XML schema datatype, depicted in Table B.1. The datatype rdf#XMLLiteral is defined in [Klyne & Carroll, 2004].

Table B.2 contains the shortcut syntax for the string, integer, and decimal datatypes.

Appendix B.2. WSML Built-in Predicates

This section contains a list of built-in predicates suggested for use in WSML. These predicates largely correspond to functions and comparators in XQuery/XPath [Malhotra et al., 2004]. Notice that SWRL [Horrocks et al., 2004] 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 B.3 for the complete list. In case the built-in predicate has an equivalent function in XQuery, this is indicated in the table. The types 'wsml#equal', 'wsml#inequal' and 'wsml#strongEqual' refer to the unification operator, inequality and user-defined inequality, respectively.

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, with the following exceptions:

Appendix B.3. Translating Built-in Symbols to Predicates

In this section, we provide the translation of the built-in (function and predicate) symbols to 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 [Malhotra et al., 2004]. 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 B.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 C. 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 C.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 B

Appendix D. Changelog

In the following we will outline changes corresponding to the development of WSML v0.21 to WSML v0.3 and this document as a whole, including:

D.1. Non backward compatible items in WSML v0.3

The following list describes all items in the language that make that WSML v0.3 is not backward compatible to all previous versions of WSML

D.2. Changes in the language (WSML v0.3) since version 0.21

D.3. Changes in this document since the previous version (March 17, 2008)

D.4. Issues List

For a list of the issues to be addressed in this version of D16.1, see the WSML Issues List.

References

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

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

[Borgida, 1996] A. Borgida. On the Relative Expressiveness of Description Logics and Predicate Logics. Journal of Artificial Intelligence, 82 (1-2): 353-367, 1996.

[Bray et al., 2004] T. Bray, D. Hollander, A. Layman, R. Tobin, Editors. Namespaces in XML 1.1. W3C Recommendation 04 February 2004. http://www.w3.org/TR/xml-names11/.

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

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

[van Gelder et al., 1991] A. van Gelder, K. Ross, and J. S. Schlipf. The well-founded semantics for general logic programs. Journal of the ACM, 38(3):620-650, 1991.

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

[Keller et al., 2005] U. Keller, R. Lara, H. Lausen, A. Polleres, and D. Fensel: Automatic location of services. In Proceedings of the 2nd European Semantic Web Conference (ESWC2005), pp. 1-16. Springer-Verlag, 2005.

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

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

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

[Scicluna et al., 2005] J. Scicluna, A. Polleres, D. Roman, and C. Feier (eds.): Ontology-based Choreography and Orchestration of WSMO Services, WSMO deliverable D14 version 0.2. available from http://www.wsmo.org/TR/d14/v0.2/.

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

[Yang & Kifer, 2002] G. Yang and M. Kifer. Well-Founded Optimism: Inheritance in Frame-Based Knowledge Bases. In First International Conference on Ontologies, Databases and Applications of Semantics (ODBASE), Irvine, California, 2002.

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

Acknowledgements

The work is funded by the European Commission under the projects ASG, DIP, enIRaF, InfraWebs, Knowledge Web, Musing, Salero, SEKT, Seemp, SemanticGOV, Super, SWING and TripCom; by Science Foundation Ireland under the DERI-Lion Grant No.SFI/02/CE1/I13 ; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects Grisino, RW², SemNetMan, SeNSE and TSC.

The editors would like to thank to all the members of the WSML working group for their advice and input into this document. We would especially like to thank Douglas Foxvog and Eyal Oren for their work on deliverables superseded by this deliverable.

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.

Datatype	Description of the Datatype	Syntax	Datatype constructor shortcut syntax
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: ‘\\’.	xsd#string("any-character*")	_string
decimal	That subset of natural numbers which can be represented with a finite sequence of decimal numerals.	xsd#decimal("'-'?numeric+.numeric+")	_decimal
integer	That subset of decimals which corresponds with natural numbers.	xsd#integer("'-'?numeric+")	_integer
float		xsd#float("see XML Schema document")	_float
double		xsd#double("see XML Schema document")	_double
boolean		xsd#boolean("true-or-false")	_boolean
dateTime		xsd#dateTime(integer_year, integer_month, integer_day, integer_hour, integer_minute, decimal_second, integer_timezone-hour, integer_timezone-minute) xsd#dateTime(integer_year, integer_month, integer_day, integer_hour, integer_minute, decimal_second)	_dateTime
time		xsd#time(integer_hour, integer_minute, decimal_second, integer_timezone-hour, integer_timezone-minute) xsd#time(integer_hour, integer_minute, decimal_second)	_time
date		xsd#date(integer_year, integer_month, integer_day, integer_timezone-hour, integer_timezone-minute) xsd#date(integer_year, integer_month, integer_day)	_date
gYearMonth		xsd#gYearMonth(integer_year, integer_month)	_gyearmonth
gYear		xsd#gYear(integer_year)	_gyear
gMonthDay		xsd#gMonthDay(integer_month, integer_day)	_gmonthday
gDay		xsd#gDay(integer_day)	_gday
gMonth		xsd#gMonth(integer_month)	_gmonth
hexBinary		xsd#hexBinary("hexadecimal-encoding")	_hexbinary
base64Binary		xsd#base64Binary("base64-encoding")	_base64binary
XMLLiteral	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: ‘\\’, such that removing escaping yields a string in the lexical space of the rdf:XMLLiteral, specified in [Klyne & Carroll, 2004].	rdf#XMLLiteral(""-escaped XML content")

Datatype constructor	Shortcut syntax	Example
xsd#string	"any-Unicode-character*"	"John Smith"
xsd#decimal	'-'?numeric+.numeric+	4.2, 42.0
xsd#integer	'-'?numeric+	42, -4

WSML built-in predicate	XQuery function	Type (A)	Type (B)	Return type
wsml#equal		abstract	abstract
wsml#inequal		abstract	abstract
wsml#numericEqual(A,B)	op#numeric-equal(A,B)	numeric	numeric
wsml#numericInequal(A,B)	op#boolean-equal( op#numeric-equal(A,B),"false")	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#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
wsml#stringEqual(A,B)	fn#codepoint-equal(A, B)	string	string
wsml#stringInequal(A,B)	op#boolean-equal( fn:codepoint-equal(A, B), "false")	string	string
wsml#dateEqual(A,B)	op#date-equal(A, B)	date	date
wsml#dateInequal(A,B)	op#boolean-equal( op:date-equal(A, B), "false")	date	date
wsml#dateGreaterThan(A,B)	op#date-greater-than(A, B)	date	date
wsml#dateLessThan(A,B)	op#date-less-than(A, B)	date	date
wsml#timeEqual(A,B)	op:date-equal(A, B)	time	time
wsml#timeInequal(A,B)	op#boolean-equal( op:time-equal(A, B), "false")	time	time
wsml#timeGreaterThan(A,B)	op#time-greater-than(A, B)	time	time
wsml#timeLessThan(A,B)	op#time-less-than(A, B)	time	time
wsml#dateTimeEqual(A,B)	op#dateTime-equal(A, B)	dateTime	dateTime
wsml#dateTimeInequal(A,B)	op#boolean-equal( op:dateTime-equal(A, B), "false")	dateTime	dateTime
wsml#dateTimeGreaterThan(A,B)	op#dateTime-greater-than(A, B)	dateTime	dateTime
wsml#dateTimeLessThan(A,B)	op#dateTime-less-than(A, B)	dateTime	dateTime
wsml#gyearmonthEqual(A,B)	op#gYearMonth-equal(A, B)	gYearMonth	gYearMonth
wsml#gyearEqual(A,B)	op#gYear-equal(A, B)	gYear	gYear
wsml#gmonthdayEqual(A,B)	op#gMonthDay-equal(A, B)	gMonthDay	gMonthDay
wsml#gmonthEqual(A,B)	op#gMonth-equal(A, B)	gMonth	gMonth
wsml#gdayEqual(A,B)	op#gDay-equal(A, B)	gDay	gDay
wsml#durationEqual(A,B)	op#duration-equal(A, B)	duration	duration
wsml#dayTimeDurationGreaterThan(A,B)	op#dayTimeDuration-greater-than(A, B)	dayTime	dayTime
wsml#dayTimeDurationLessThan(A,B)	op#dayTimeDuration-less-than(A, B)	dayTimeDuration	dayTimeDuration
wsml#yearMonthDurationGreaterThan(A,B)	op#yearMonthDuration-greater-than(A, B)	yearMonthDuration	yearMonthDuration
wsml#yearMonthDurationLessThan(A,B)	op#yearMonthDuration-less-than(A, B)	yearMonthDuration	yearMonthDuration

Operator	Type (A)	Type (B)	Predicate
A = B	abstract	abstract	wsml#equal(A,B)
A != B	abstract	abstract	wsml#inequal(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))
A = B	string	string	wsml#stringEqual(A,B)
A != B	string	string	wsml#stringInequal(A,B)
A = B	date	date	wsml#dateEqual(A,B)
A != B	date	date	wsml#dateInequal(A,B)
A = B	time	time	wsml#timeEqual(A,B)
A != B	time	time	wsml#timeInequal(A,B)
A = B	dateTime	dateTime	wsml#dateTimeEqual(A,B)
A != B	dateTime	dateTime	wsml#dateTimeInequal(A,B)
A = B	gYearMonth	gYearMonth	wsml#gyearmonthEqual(A,B)
A = B	gYear	gYear	wsml#gyearEqual(A,B)
A = B	gMonthDay	gMonthDay	wsml#gmonthdayEqual(A,B)
A = B	gMonth	gMonth	wsml#gmonthEqual(A,B)
A = B	gDay	gDay	wsml#gdayEqual(A,B)
A = B	duration	duration	wsml#durationEqual(A,B)
A = B	dayTimeDuration	dayTimeDuration	wsml#dayTimeDurationEqual(A,B)
A = B	yearMonthDuration	yearMonthDuration	wsml#yearMonthDurationEqual(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
wsmlVariant	2.2.1
namespace	2.2.2
annotations	2.2.3
endAnnotations	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
subAttributeOf	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
nonFunctionalProperty	2.4.3
nfp	2.4.3
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-DL	WSML-Flight	WSML-Rule	WSML-Full
true	+	+	+	+	+
false	+	+	+	+	+
memberOf	+	+	+	+	+
hasValue	+	+	+	+	+
subConceptOf	+	+	+	+	+
ofType	+	+	+	+	+
impliesType	+	+	+	+	+
and	+	+	+	+	+
or	+	+	+	+	+
implies	+	+	+	+	+
impliedBy	+	+	+	+	+
equivalent	+	+	+	+	+
neg	-	+	-	-	+
naf	-	-	+	+	+
forall	+	+	+	+	+
exists	-	+	-	-	+

D16.1v0.3 WSML Language Reference

Abstract

Table of Contents

PART I: PRELUDE

1. Introduction

1.1. Structure of the Document

PART II: WSML VARIANTS

PART III: THE WSML EXCHANGE SYNTAXES

Appendix Guide

PART II: WSML VARIANTS

Data values

Internationalized Resource Identifiers

Anonymous Identifiers

Variables

Invalidity of identifiers

PART III: THE WSML EXCHANGE SYNTAXES

Helpers

States

Tokens

Ignored Tokens

Productions

D.1. Non backward compatible items in WSML v0.3

D.2. Changes in the language (WSML v0.3) since version 0.21

D.3. Changes in this document since the previous version (March 17, 2008)

D.4. Issues List

References

Acknowledgements

Footnotes