WSML Working Draft 02 November 2007
For printing and off-line reading, this document is also available in non-normative PDF version. Note that the documentation for the WSML XML syntax is not included in this PDF. Instead, it is included in the following three PDF documents: XMLSchemaWSML, XMLSchemaID, and XMLSchemaExpr.
Copyright © 2007 DERI ®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
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 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 WSML specification is not backward compatible with respect to the syntax used to specify annotations descriptions. For more details please see Section 2.2.3
PART III: THE WSML EXCHANGE SYNTAXES
Appendix A. Human-Readable Syntax
The Web Service Modeling Ontology WSMO [Roman et al. 2005] proposes a conceptual model for the description of Ontologies, Semantic Web services, Goals, and Mediators, providing the conceptual grounding for Ontology and Web service descriptions. In this document we take the conceptual model of WSMO as a starting point for the specification of a family of Web Service description and Ontology specification languages. The Web Service Modeling Language (WSML) aims at providing means to formally describe all the elements defined in WSMO. The different variants of WSML correspond with different levels of logical expressiveness and the use of different languages paradigms. More specifically, we take Description Logics, First-Order Logic and Logic Programming as starting points for the development of the WSML language variants. The WSML language variants are both syntactically and semantically layered. All WSML variants are specified in terms of a human-readable syntax with keywords similar to the elements of the WSMO conceptual model. Furthermore, we provide XML and RDF [RDF] exchange syntaxes, as well as a mapping between WSML ontologies and OWL ontologies for interoperability with OWL-based applications.
Ontologies and Semantic Web services need formal languages for their specification in order to enable automated processing. As for ontology descriptions, the W3C recommendation for an ontology language OWL [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.
The remainder of this document is structured as follows:
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.
The WSML variants are described in terms of their normative human-readable language in PART II. Although this syntax has been formally specified in the form of a grammar (see also Appendix A), there are limitations with respect to the exchange of the syntax over the Web. Therefore three syntaxes for WSML were developed, namely XML, RDF and OWL. The XML exchange syntax for WSML is the preferred syntax for the exchange of WSML specifications between machines. The RDF syntax of WSML can be used by RDF-based applications and finally a mapping between WSML and OWL ontologies in order to allow interoperation with OWL-based applications. This section provides pointers to external documents containing these syntaxes.
This document contains a number of appendices:
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.
Please note that the current version of WSML specification is not backward compatible with respect to the syntax used to specify annotations descriptions. For more details please see Section 2.2.3
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.
Figure 1. WSML Space
Figure 2. WSML Layering
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(Dn), 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.
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.
A WSML document has the following structure:
| wsml | = |
|
||||||||||||||||||
| definition | = |
|
This chapter is structured as follows. The WSML syntax basics, such as the use of namespaces, identifiers, etc., are described in Section 2.1. The elements in common between all WSML specifications are described in Section 2.2. WSML ontologies are described in Section 2.3. The elements shared between goals and web services, namely, capabilities and interfaces, are described in Section 2.4. Goals, mediators and web services are described in Sections 2.5, 2.6 and 2.7, respectively. Finally, the WSML logical expression syntax is specified in Section 2.8.
The conceptual syntax for WSML has a frame-like style. The information about a class and its attributes, a relation and its parameters and an instance and its attribute values is specified in one large syntactic construct, instead of being divided into a number of atomic chunks. It is possible to spread the information about a particular class, relation, instance or axiom over several constructs, but we do not recommend this. In fact, in this respect, WSML is similar to OIL [Fensel et al., 2001], which also offers the possibility of either grouping descriptions together in frames or spreading the descriptions throughout the document. One important difference with OIL (and OWL) is that attributes are defined locally to a class and should in principle not be used outside of the context of that class and its subclasses.
Nonetheless, attribute names are global and it is possible to specify global behavior of attributes through logical expressions. However, we do not expect this to be necessary in the general case and we strongly advise against it.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.
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). The WSML keywords themselves belong to the the namespace http://www.wsmo.org/wsml/wsml-syntax# (commonly abbreviated as 'wsml').
Namespaces can be used to syntactically distinguish elements of multiple WSML specifications and, more generally, resources on the Web. A namespace denotes a syntactical domain for naming resources.
Whenever a WSML specification has a specific identifier which corresponds to a Web address, it is good practice to have a relevant document on the location pointed to by the identifier. This can either be the WSML document itself or a natural language document related to the WSML document. Note that the identifier of an ontology does not have to coincide with the location of the ontology. It is good practice, however, to include a related document, possibly pointing to the WSML specification itself, at the location pointed to by the identifier.
An identifier in WSML is either a data value, an IRI [Duerst & Suignard, 2005] or an anonymous ID. Additionally a new kind of identifiers have been introduced, namely variables which might be used in the conceptual syntax only in nonFunctionalProperties block definition or in the sharedVariables block.
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.
WSML uses datatype wrappers to construct data values based on XML Schema datatypes. The use of datatype wrappers gives more control over the structure of the data values than the lexical representation of XML. For example, the date: 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 such a term can be either strings, decimals, integers, IRIs or variables. No other arguments are allowed for such data terms. Each conforming WSML implementation is required to support at least the string, integer and decimal datatypes.
Datatype 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 arguments of a datatype wrapper can be strings, integers, decimals or variables. 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 sQName 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.
Examples of data values:
xsd#date(2005,3,12)
xsd#boolean("true")The following are example attribute definitions which restrict the range of the attribute to a particular datatype:
age ofType xsd#integer
hasChildren ofType xsd#booleanWSML allows the following syntactical shortcuts for particular datatypes:
integer is a shortcut for
xsd#integer("integer"). For example, 4 is
a shortcut for xsd#integer("4")decimal is a
shortcut for xsd#decimal("decimal"). For example,
4.2 is a shortcut for
xsd#decimal("4.2").| integer | = |
|
|||
| decimal | = |
|
|||
| string | = | '"' string_content* '"' | |||
| string_content | = | escaped_char | not_escape_char_not_dquote |
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 an integer, a decimal, a string or a constructeddatavalue, where a constructeddatavalue corresponds to a datatype wrapper.
| datavalue | = |
|
|||||||||||||
| datavaluelist | = |
|
|||||||||||||
| constructeddatavalue | = |
|
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 an sQName. Note that the term 'QName' has been used, after its introduction in XML [Bray et al., 2004], with different meanings. The meaning of the term 'QName' as defined in XML got blurred after the adoption of the term in RDF. In XML, QNames are simply used to qualify local names and thus every name is a tuple <namespace, localname>. In RDF, QNames have become abbreviations for URIs, which is different from the meaning in XML. WSML adopts a view similar to the RDF-like version of QNames, but due to its deviation from the original definition in XML we call them sQNames which is short for 'serialized QName'.
An sQName consists of two parts, namely, the namespace prefix and the
local part. An sQName is written using a namespace prefix and a localname,
separated by a hash ('#'):
namespace_prefix#localname.
An sQName is equivalent to the IRI which is obtained by concatenating the namespace IRI (to which the prefix refers) with the local part of the sQName. Therefore, an sQName can be seen as an abbreviation for an IRI which enhances the legibility of the specification. If an sQName has no prefix, the namespace of the sQName is the default namespace of the document, except for attribute identifiers. The namespace of an attribute identifier with no prefix is the namespace of the concept type of the instance to which it appears. Note: In case the default namespace is not defined or a prefix used in a sQName can not 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, an sQName does not require special delimiters. Any sQName contains a namespace prefix. Namespace prefixes may not not coincide with any WSML keywords. The characters '.' and '-' in an sQName need to be escaped using the backslash (‘\’) character.
| full_iri | = |
|
|||||||
| sQName | = |
|
|||||||
| iri | = |
|
Examples of full IRIs in WSML:
_"http://example.org/PersonOntology#Human"
_"http://www.uibk.ac.at/"Examples of sQNames in WSML (with corresponding full IRIs; dc stands for http://purl.org/dc/elements/1.1#, foaf stands for http://xmlns.com/foaf/0.1/ and xsd stands for http://www.w3.org/2001/XMLSchema#; we assume the default namespace http://example.org/#):
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.
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.
| anonymous | = | '_#' | |
| nb_anonymous | = | '_#' digit+ |
Take as an example the following logical expressions:
_#[a hasValue _#1] and _#1 memberOf b.
_#1[a hasValue _#] and _# memberOf _#.There are in total three occurrences of the unnumbered anonymous ID. All occurrences are unrelated. Thus, the second logical expression does not state that an object is a member of itself, but rather that some anonymous object is a member of some other anonymous object. The two occurrences of _#1 in the first logical expression denote the same object. Thus the value of attribute a is a member of b. The occurrence of _#1 in the second logical expression is, however, not related to the occurrence of _#1 in the first logical expression.
The use of an identifier in the specification of the WSML elements ontology, goal, web service, mediator, capability, interface, import ontologies, used mediators, sources and targets of mediators, services used by mediators, choreography, orchestration is optional. If no identifier is specified, the following rule apply: the identifier is assumed to be the same as the locator of the specification, i.e., the location where the specification was found.
| id | = |
|
|||||||||
| anyid | = |
|
|||||||||
| idlist | = |
|
If the same identifier is used for different definitions, it is interpreted differently, depending on the context. In a concept definition, an identifier is interpreted as a concept; in a relation definition this same identifier is interpreted as a relation. If, however, the same identifier is used in separate definitions, but with the same context, then the interpretation of the identifier has to conform to both definitions and thus the definitions are interpreted conjunctively. For example, if there are two concept definitions which are concerned with the same concept identifier, the resulting concept definition includes all attributes of the original definitions and if the same attribute is defined in both definitions, the range of the resulting attribute will be equivalent to the conjunction of the original attributes.
Note that anonymous identifiers are disallowed for the top-level elements, namely ontology, goal, webService, ooMediator, ggMediator, wgMediator and wwMediator. Anonymous identifiers are as well disallowed for capability, interface, import ontologies, used mediators, sources of mediators, targets of mediators, services used by mediators, choreography and orchestration
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 sQNames with undefined namespace prefixes and invalid data values.
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 occur in place of concepts, attributes, instances, relation arguments or attribute values. A variable may not, however, replace a WSML keyword. Furthermore, variables may only be used inside logical expressions.
The scope of a variable 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.
| variable | = | '?' alphanum+ |
Examples of variables are: ?x, ?y1, ?myVariable
Variables might be used either in nonFunctionalProperties block definition (see Section Section 2.4.3) or in the sharedVariables block from in the capability definition (see Section Section 2.4.1).
A WSML file may at any place contain a comment. A single line comment
starts with comment or // and ends with a line break. Comments can also range
over multiple lines, in which they need to be delimited by /* and */.
| comment | = | short_comment | long_comment |
| short_comment | = | ('//' | 'comment ') not_cr_lf* eol |
| long_comment | = | '/*' long_comment_content* '*/' |
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.
Examples:
/* Illustrating a multi line
* comment
*/
// a one-line comment
comment another one-line commentWhen 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
This section describes the elements in common between all types of WSML specifications and all WSML variants. The elements described in this section are used in Ontology, Goal, Mediator and Web service specifications. The elements specific to a type of specification are described in subsequent sections. Because all elements in this section are concerned with meta-information about the specification and thus do not depend on the logical formalism underlying the language, these elements are shared among all WSML variants.
In this section we only describe how each element should be used. The subsequent sections will describe how these elements fit in the specific WSML descriptions.
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.
| 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.
| wsmlvariant | = |
|
The following illustrates the WSML variant reference for a WSML-Flight specification:
wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight" 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.
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.
| namespace | = |
|
||||||
| prefixdefinitionlist | = |
|
||||||
| prefixdefinition | = |
|
Two examples are given below, one with a number of namespace declarations and one with only a default namespace:
namespace {_"http://www.example.org/ontologies/example#",
dc _"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml-syntax#",
loc _"http://www.wsmo.org/ontologies/location#",
oo _"http://example.org/ooMediator#"}
namespace _"http://www.example.org/ontologies/example#"Any WSML specification may have annotations, may import ontologies and may use mediators:
| header | = |
|
Annotations may be used for the WSML document as a whole but also 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 anonymous identifier or a
comma-separated list of the former, delimited with curly brackets. The
recommended properties are the properties of the Dublin Core [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., 2005] 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.,
2005]. 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 | = |
|
Example:
annotations
dc#title hasValue "WSML example ontology"
dc#subject hasValue "family"
dc#description hasValue "fragments of a family ontology to provide WSML examples"
dc#contributor hasValue { _"http://homepage.uibk.ac.at/~c703240/foaf.rdf",
_"http://homepage.uibk.ac.at/~csaa5569/",
_"http://homepage.uibk.ac.at/~c703239/foaf.rdf",
_"http://homepage.uibk.ac.at/homepage/~c703319/foaf.rdf" }
dc#date hasValue _date("2004-11-22")
dc#format hasValue "text/html"
dc#language hasValue "en-US"
dc#rights hasValue _"http://www.deri.org/privacy.html"
wsml#version hasValue "$Revision: 1.220 $"
endAnnotationsAnnotations in WSML are not part of the logical language; 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) annotations descriptions were introduced by nonFunctionalProperties or nfp construct. The current versions use the annotations construct. A translation tool from the old syntax to the new syntax used to specify annotations is available at http://tools.deri.org/wsml/nfptranslator/.
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.
| importsontology | = |
|
Example:
importsOntology {_"http://www.wsmo.org/ontologies/location",
_"http://xmlns.com/foaf/0.1"}If the imported ontology is of a different WSML variant than the importing specification, the resulting ontology is of the most expressive of the two variants. If the expressiveness of the variants is to some extent disjoint (e.g., when importing a WSML-DL ontology in a WSML-Rule specification), the resultant will be of the least common superset of the variants. In the case of WSML-DL and WSML-Rule, the least common superset is WSML-Full.
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.
| usesmediator | = |
|
Eexample:
usesMediator _"http://example.org/ooMediator"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.
Example:
ontology familyAn ontology specification document in WSML consists of:
| ontology | = |
|
|||||||||||||||
| ontology_element | = |
|
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., 2005].
A concept definition starts with the concept
keyword, which is 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.
| concept | = |
|
|||
| superconcept | = |
|
Example:
concept Human subConceptOf {Primate, LegalAgent}
annotations
dc#description hasValue "concept of a human being"
dc#relation hasValue humanDefinition
endAnnotations
hasName ofType foaf#name
hasParent impliesType Human
hasChild impliesType Human
hasAncestor impliesType Human
hasRelative impliesType Human
hasWeight ofType _float
hasWeightInKG ofType _float
hasBirthdate ofType _date
hasObit ofType _date
hasBirthplace ofType loc#location
isMarriedTo impliesType Human
hasCitizenship ofType oo#countryWSML 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 (called "complete
classes" in OWL). The definition of a defined concept is not only necessary,
but also sufficient. A necessary definition, such as the concept
specification in the example above, specifies implications of membership of
the concept for all instances of this concept. 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:
?x memberOf A equivalent ?x memberOf B1 and ... and ?x memberOf BnWith A and B1,...,Bn concept identifiers.
For example, in order to define the class Human as the
intersection of the classes Primate and LegalAgent,
the following definition is used:
axiom humanDefinition
definedBy
?x memberOf Human equivalent ?x memberOf Primate and ?x memberOf LegalAgent.Two important features of attribute modeling which set WSML apart from OWL are cardinality constraints and attribute range constraints. OWL offers cardinality and range restrictions on attributes which serve to create additional (monotonic) inferences such as existence or equality of objects or membership in a certain class. For many users these restrictions show unintuitive behavior from the viewpoint of classical rule languages and databases [de Bruijn et al., 2005]: Means to actually check the data in your knowledge base with respect to integrity constraints are missing in OWL. 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 the modeler to express a local a closed world view on her/his published data.
WSML allows two kinds of attribute definitions, namely, constraining definitions with the keyword ofType and inferring definitions with the keyword impliesType. We expect that inferring attribute definitions will not be used very often if constraining definitions are allowed. However, several WSML variants, namely, WSML-Core and WSML-DL, do not allow constraining attribute definitions. In order to facilitate conceptual modeling in these language variants, we allow the use of impliesType in WSML.
An attribute definition of the form A ofType
D, where A is an attribute identifier
and D is a concept identifier, is a constraint on the
values for attribute A. If the value for the attribute A is
not known to be of type D, the constraint is violated and the
attribute value is inconsistent with respect to the ontology. This notion of
constraints corresponds with the usual database-style constraints.
The keyword impliesType can be used for inferring the type of a
particular attribute value. An attribute definition of the form
A impliesType D, where
A is an attribute identifier and
D is a concept identifier, implies membership of the
concept D for all values of the attribute A.
Please note that if the range of the attribute is a datatype, the semantics
of ofType and impliesType coincide, because datatypes have a
known domain and thus values cannot be inferred to be of a certain
datatype.
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 sub-attribute of.
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 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.
Below is an example of a concept definition with attribute definitions:
concept Human
annotations
dc#description hasValue "concept of a human being"
endAnnotations
hasName ofType foaf#name
hasParent inverseOf(hasChild) impliesType Human
hasChild inverseOf(hasRelative) impliesType Human
hasAncestor transitive impliesType Human
hasRelative symmetric impliesType Human
hasWeight ofType (1) _float
hasWeightInKG ofType (1) _float
hasBirthdate ofType (1) _date
hasObit ofType (0 1) _date
hasBirthplace ofType (1) loc#location
isMarriedTo symmetric impliesType (0 1) Human
hasCitizenship ofType oo#countryA relation definition starts with the relation keyword, which is 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.
| relation | = |
|
|||
| arity | = |
|
|||
| paramtyping | = |
|
|||
| paramtype | = |
|
|||
| moreparamtype | = |
|
|||
| superrelation | = |
|
Below are two examples, one with parameter definitions and one with an arity definition:
relation distance (ofType City, ofType City, impliesType _decimal) subRelationOf measurement
relation distance/3As 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.
An instance definition starts with the instance keyword, followed by the
identifier of the instance, the memberOf keyword
and the name of the concept to which the instance belongs. The memberOf keyword identifies the concept to which the
instance belongs. This definition is followed by the attribute values
associated with the instance. Each property filler consists of the property
identifier, the keyword hasValue and the
value(s) for the attribute.
| instance | = |
|
|||
| memberof | = |
|
|||
| attributevalue | = |
|
Example:
instance Mary memberOf {Parent, Woman}
annotations
dc#description hasValue "Mary is parent of the twins Paul and Susan"
endAnnotations
hasName hasValue "Maria Smith"
hasBirthdate hasValue _date(1949,9,12)
hasChild hasValue {Paul, Susan}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., 2005], 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 by using an empty idlist, e.g. 'a ofType { }'
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 an optional annotations block, followed by the values of the
parameters associated with the instance.
| relationinstance | = |
|
Below is an example of an instance of a ternary relation (remember that the identifier is optional, see also Section 2.1.2):
relationInstance distance(Innsbruck, Munich, 234)An axiom definition starts with the axiom
keyword, followed by the name (identifier) of the axiom. This is followed by
an optional annotations block and a logical
expression preceded by the definedBy keyword.
The logical expression must be followed by either a blank or a new line. The
language allowed for the logical expression is explained in Section 2.8.
| axiom | = |
|
||||||
| axiomdefinition | = |
|
||||||
| log_definition | = |
|
Example of a defining axiom:
axiom humanDefinition
definedBy
?x memberOf Human equivalent
?x memberOf Animal and
?x memberOf LegalAgent.WSML allows the specification of database-style constraints. Below is an example of a constraining axiom:
axiom humanBMIConstraint
definedBy
!- naf bodyMassIndex(bmi hasValue ?b, length hasValue ?l, weight hasValue ?w)
and ?x memberOf Human and
?x[length hasValue ?l,
weight hasValue ?w,
bmi hasValue ?b].The desired and provided functionality are described in WSML in the form of capabilities. The desired capability is part of a goal and the provided capability is part of a web service. The interaction style of both the requester and the provider is described in interfaces, as part of the goal and the web service, respectively. Finnaly, other aspects of services or goals which are neither functional nor behavioural are captured in non-functional properties.
A capability constitutes a formal description of the functionality requested from or provided by a web service. 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 succesfully, 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.
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 can not 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 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 and an optional usesMediator block. The sharedVariables block
is used to indicate the variables which are shared between the preconditions,
postconditions, assumptions and effects of the capability, which are defined
in the precondition, postcondition, assumption, and
effect definitions, respectively. The number of such definitions is
not restricted. Each of these definitions consists of the keyword, an
optional identifier, an optional 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.
| capability | = |
|
||||||||||||
| sharedvardef | = |
|
||||||||||||
| pre_post_ass_or_eff | = |
|
Below is an example of a capability specified in WSML:
capability
sharedVariables ?child
precondition
annotations
dc#description hasValue "The input has to be boy or a girl
with birthdate in the past and be born in Germany."
endAnnotations
definedBy
?child memberOf Child
and ?child[hasBirthdate hasValue ?birthdate]
and ?child[hasBirthplace hasValue ?location]
and ?location[locatedIn hasValue oo#de]
or (?child[hasParent hasValue ?parent] and
?parent[hasCitizenship hasValue oo#de] ) .
effect
annotations
dc#description hasValue "After the registration the child
is a German citizen"
endAnnotations
definedBy
?child memberOf Child
and ?child[hasCitizenship hasValue oo#de].A WSML goal may request multiple interfaces and a web service may offer multiple interfaces. The specification of an interface is optional.
A WSML interface may be a stand-alone entity which may be defined outside a WSML goal or web service definition.
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 can not 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 and an optional usedMediator block and then by an optional
choreography block and an optional orchestration block. Note that thus an interface can have at most one
choreography and at most one orchestration. It is furthermore possible to
reference interfaces which have been specified at a different location. For
reasons of convenience, WSML allows the referencing of multiple interfaces
using an argument list.
Currently only a syntax for choreographies in WSML is defined. A choreography
specification starts with the annotations block, an optional importsOntology block and an optional usedMediator block. Following these elements are
the optional blocks of stateSignature and transitions containers. An orchestration simply starts with
the
| interfaces | = |
|
||||||
| minterfaces | = |
|
||||||
| interface | = |
|
||||||
| choreography | = |
|
||||||
| orchestration | = |
|
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 definined in the imported ontologies.
| statesignature | = |
|
|||||||||||||||
| mode | = |
|
|||||||||||||||
| mode_entry_list | = |
|
|||||||||||||||
| mode_id | = |
|
|||||||||||||||
| mode_entry | = |
|
|||||||||||||||
| grounding | = |
|
|||||||||||||||
| grounding_info | = |
|