WSML Final Draft 20 March 2005
Please have a look at the erratum to this document.
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 © 2005 DERI ®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
We introduce the Web Service Modeling Language WSML which provides a formal syntax and semantics for the Web Service Modeling Ontology WSMO. WSML is based on different logical formalisms, namely, Description Logics, First-Order Logic and Logic Programming, which are useful for the modeling of Semantic Web services.
WSML consists of a number of variants based on these different logical formalisms, namely WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full.
WSML-Core corresponds with the intersection of Description Logic and Horn Logic (without function symbols and without equality), extended with datatype support in order to be useful in practical applications. WSML-Core is fully compliant with a subset of OWL.
WSML-Core is extended, both in the direction of Description Logics and in the direction of Logic Programming, to WSML-DL and WSML-Flight.
WSML-DL extends WSML-Core to an expressive Description Logic, namely, SHIQ, thereby covering that part of OWL which is efficiently implementable.
WSML-Flight extends WSML-Core in the direction of Logic Programming. WSML-Flight has a rich set of modeling primitives for modeling different aspects of attributes, such as value constraints and integrity constraints. Furthermore, WSML-Flight incorporates a fully-fledged rule language, while still allowing efficient decidable reasoning. To be more precise, WSML-Flight allows to write down any Datalog rule, extended with inequality and (locally) stratified negation.
WSML-Rule extends WSML-Flight to a fully-fledged Logic Programming language, including function symbols. WSML-Rule no longer restricts the use of variables in logical expressions.
The final WSML variant unifies the Description Logic and Logic Programming paradigms.
WSML-Full unifies all WSML variants under a common First-Order umbrella with non-monotonic extensions which allow to capture nonmonotonic negation of WSML-Rule.
All WSML variants are described in terms of a normative human-readable syntax. Besides the human-readable syntax we provide an XML and an RDF syntax for exchange between machines. Furthermore, we provide a mapping between WSML ontologies and OWL for basic inter-operation with OWL ontologies through a common semantic subset of OWL and WSML.
This deliverable supersedes a number of now obsolete WSML deliverables. References to these now obsolete deliverables can be found at: http://www.wsmo.org/TR/d16/
PART III: THE WSML EXCHANGE SYNTAXES
Appendix A. Human-Readable Syntax
Appendix B. Schemas for the XML Exchange Syntax
Appendix E. Relation to WSMO Conceptual Model
The Web Service Modeling Ontology WSMO [Roman et al. 2004] proposes a conceptual model for the description of Ontologies, Semantic Web services, Goals, and Mediators, providing the conceptual grounding for Ontology and Web service descriptions. In this document we take the conceptual model of WSMO as a starting point for the specification of a family of Web Service description and Ontology specification languages. The Web Service Modeling Language (WSML) aims at providing means to formally describe all the elements defined in WSMO. The different variants of WSML correspond with different levels of logical expressiveness and the use of different languages paradigms. More specifically, we take Description Logics, First-Order Logic and Logic Programming as starting points for the development of the WSML language variants. The WSML language variants are both syntactically and semantically layered. All WSML variants are specified in terms of a human-readable syntax with keywords similar to the elements of the WSMO conceptual model. Furthermore, we provide XML and RDF exchange syntaxes, as well as a mapping between WSML ontologies and OWL ontologies for interoperability with OWL-based applications.
Ontologies and Semantic Web services need formal languages for their specification in order to enable automated processing. As for ontology descriptions, the W3C recommendation for an ontology language OWL [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. Chapter 7, presents WSML-Full which is a superset of both WSML-Rule and WSML-DL. WSML-Full can be seen as a notational variant of First-Order Logic with nonmonotonic extensions. Finally, Chapter 8 defines the WSML semantics.
The WSML variants are described in terms of their normative human-readable language in PART II. Although this syntax has been formally specified in the form of a grammar (see also Appendix A), there are limitations with respect to the exchange of the syntax over the Web. Therefore, Chapter 9 presents the XML exchange syntax for WSML, which is the preferred syntax for the exchange of WSML specifications between machines. Chapter 10 describes the RDF syntax of WSML, which can be used by RDF-based applications. Chapter 11, finally, describes a mapping between WSML and OWL ontologies in order to allow interoperation with OWL-based applications.
We conclude the document with describing efforts related to the WSML language in Chapter 12. These related efforts are mostly concerned with implementation of WSML-based tools and tools utilizing WSML for specific purposes.
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 contains references to the XML Schemas, the XML Schema documentation and the XML version of the WSML example from Appendix A. These documents are all online resources. Appendix C describes the built-in predicates and datatypes of WSML, as well as a set of infix operators which correspond with particular built-in predicates. Appendix D contains a complete list of WSML keywords, as well as references to the sections in the document where these are described. Appendix E describes the relation between WSML and the WSMO conceptual model. Finally, Appendix F contains the changelog which documents the changes between the current and previous version of this document.
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.
It is often possible to specify a list of arguments, for example for attributes. Such argument lists in WSML are separated by commas and surrounded by curly brackets. Statements in WSML start with a keyword and can be spread over multiple lines.
A WSML specification is separated into two parts. The first part provides meta-information about the specification, which consists of such things as WSML variant identification, namespace references, non-functional properties (annotations), import of ontologies, references to mediators used and the type of the specification. This meta-information block is strictly ordered. The second part of the specification, consisting of elements such as concepts, attributes, relations (in the case of an ontology specification), capability, interfaces (in the case of a goal or web service specification), etc., is not ordered.
The remainder of this section explains the use of namespaces, identifiers and datatypes in WSML. Subsequent sections explain the different kinds of WSML specifications and the WSML logical expression syntax.
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 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.
WSML has direct support for different types of concrete data, namely, strings, integers and decimals, which correspond to the XML Schema [Biron & Malhorta, 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: _date(2005,2,3). The arguments of such a term can be either strings, decimals, integers or variables. No other arguments are allowed for such data terms. Each conforming WSML implementation is required to support at least the string, integer and decimal datatypes.
Datatype identifiers manifest themselves in WSML in two distinct ways, namely, as concept identifers and as datatype wrappers. A datatype wrapper is used as a datastructure for capturing the different components of data values. Datatype identifiers can also be used directly as concept identifiers. Note however that the domain of interpretation of any datatype is finite and that asserting membership of a datatype for a value which does not in fact belong to this datatype, leads to an inconsistency in the knowledge base.
Examples of data values:
_date(2005,3,12)
_sqname("http://www.wsml.org/wsml/wsml-syntax#", "goal")
_boolean("true")
The following are example attribute definitions which restrict the range of the attribute to a particular datatype:
age ofType _integer
location ofType _iri
hasChildren ofType _boolean
WSML allows the following syntactical shortcuts for particular datatypes:
integer is a shortcut for
_integer("integer"). For example, 4
is a shortcut for _integer("4")decimal is a shortcut for
_decimal("decimal"). For example, 4.2
is a shortcut for _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.
Furthermore, WSML also allows shortcut syntax for IRI and sQName data values, as described below.
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 is equivalent to the IRI which is obtained by concatenating the namespace IRI (to which the prefix refers) with the local part of the sQName. Therefore, an sQName can be seen as an abbreviation for an IRI which enhances the legibility of the specification. If an sQName has no prefix, the namespace of the sQName is the default namespace of the document.
An sQName consists of two parts, namely, the
namespace prefix and the local part. WSML allows two distinct ways to write sQNames. sQName can be seen as a datatype and thus it has an associated datatype wrapper, namely, _sqname (see also Appendix C), which has two arguments: namespace and localname. Because sQNames are very common in WSML specifications, WSML allows a short syntax for sQNames. An sQName can simply be written using a namespace prefix and a localname, separated by a hash ('#'): namespace_prefix#localname. It is also possible to omit the namespace prefix and the hash symbol. In this case, the name is defined in the default namespace.
IRI is a datatype in WSML and has the associated datatype wrapper _iri with one argument (the IRI). For convenience, WSML also allows a short form with the delimiters ' _" ' and ' " '.
For convenience, an sQName does not require special delimiters.
However, sQNames may not coincide with any WSML keywords.
The characters '.' and '-' in an sQName need to be escaped using 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/#):
WSML defines the following two IRIs: http://www.wsmo.org/wsml/wsml-syntax#true and http://www.wsmo.org/wsml/wsml-syntax#false, which stand for universal truth and universal falsehood, respectively. Note that for convenience we typically use the abbreviated sQName form (where wsml stands for the default WSML namespace http://www.wsmo.org/wsml/wsml-syntax#): wsml#true, wsml#false. Additionally, WSML allows the keywords 'true' and 'false' in the human-readable syntax.
Please note that the IRI of a resource does not necessarily correspond to a document on the Web. Therefore, we distinguish between the identifier and the locator of a resource. The locator of a resource is an IRI which can be mapped to a location from which the (information about the) resource can be retrieved.
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 WSML elements is optional. If no identifier is specified, the following default rules apply:
| id | = |
|
||||||||||||
| 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 the sets of identifiers for the top-level elements, namely ontology, goal, webService, ooMediator, ggMediator, wgMediator and wwMediator, are pairwise disjoint and also disjoint from all other identifiers.
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 non-functional properties for any information related to the actual WSML descriptions; comments should be only used for meta-data about the WSML file itself. Comments are disregarded when parsing the WSML document.
Examples:
/* Illustrating a multi line
* comment
*/
// a one-line comment
comment another one-line comment
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/",
xsd _"http://www.w3.org/2001/XMLSchema#",
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 non-functional properties, may import ontologies and may use mediators:
| header | = |
|
Non-functional properties may be used for the WSML document as a whole but
also for each element in the specification. Non-functional property blocks
are delimited with the keywords nonFunctionalProperties and endNonFunctionalProperties or the short forms nfp and endnfp. Following the keyword is a list of attribute
values, which consists of the attribute identifier, the keyword
hasValue and the value for the attribute, which may be any identifier
and can thus be an IRI, a data value, an anonymous identifier or a comma-separated list of the former, delimited with curly brackets. The recommended
properties are the properties of the Dublin Core [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., 2004]
defines a number of properties which are not in the Dublin Core. These
properties can be used in a WSML specification by referring to the WSML
namespace (http://www.wsmo.org/wsml/wsml-syntax#). These properties are:
wsml#version, wsml#accuracy, wsml#financial, wsml#networkRelatedQoS, wsml#performance, wsml#reliability, wsml#robustness, wsml#scalability, wsml#security, wsml#transactional, wsml#trust (here we assume that the prefix
wsml has been defined as referring to the WSML namespace; see Section 2.1.1). For
recommended usage of these properties see [Roman et al.,
2004]. 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.
| nfp | = |
|
Example:
nonFunctionalProperties
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.163 $"
endNonFunctionalPropertiesNon-functional properties in WSML are not part of the logical language; programmatic access to these properties can be provided through an API.
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., 2004].
A concept definition starts with the concept
keyword, which is optionally followed by the identifier of the concept. This
is optionally followed by a superconcept definition which consists of the
keyword subConceptOf followed by one or more concept
identifiers (as usual, if there is more than one, the list is comma-separated
and delimited by curly brackets). This is followed by an optional nonFunctionalProperties block and zero or more
attribute definitions.
Note that WSML allows inheritance of attribute definitions, which means that a concept inherits all attribute definitions of its superconcepts. If two superconcepts have 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}
nonFunctionalProperties
dc#description hasValue "concept of a human being"
dc#relation hasValue humanDefinition
endNonFunctionalProperties
hasName ofType foaf#name
hasParent impliesType Human
hasChild impliesType Human
hasAncestor 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 non-functional properties
through the property dc#relation. In the example above we
refer to an axiom with the identifier humanDefinition (see Section 2.3.4 for the axiom).
Different knowledge representation languages, such as Description Logics,
allow for the specification of defined concepts (called "complete classes" in
OWL). The definition of a defined concept is not only necessary, but also
sufficient. A necessary definition, such as the concept specification in
the example above, specifies implications of membership of the concept for all instances of this concept.
The concept description above specifies that each instance of Human is also an
instance of Primate and LegalAgent. Furthermore,
all values for the attributes hasName, hasParent,
hasWeight etc. must be of specific types. A necessary and sufficient
definition also works the other way around, which means that if certain properties hold for the instance, the instance is inferred to be a member of this concept.
WSML supports defined concepts through the use of axioms (see Section 2.3.4). The logical expression contained in the axiom should reflect an equivalence relation between a class membership expression on one side and a conjunction of class membership expressions on the other side, each with the same variable. Thus, such a definition should be of the form:
?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.WSML allows two kinds of attribute definitions, namely, constraining definitions with the keyword ofType and inferring definitions with the keyword impliesType. We expect that inferring attribute definitions will not be used very often if constraining definitions are allowed. However, several WSML variants, namely, WSML-Core and WSML-DL, do not allow constraining attribute definitions. In order to facilitate conceptual modeling in these language variants, we allow the use of impliesType in WSML.
An attribute definition of the form A ofType
D, where A is an attribute identifier
and D is a concept identifier, is a constraint on the
values for attribute A. If the value for the attribute A is
not known to be of type D, the constraint is violated and the attribute value is
inconsistent with respect to the ontology. This notion of constraints
corresponds with the usual database-style constraints.
The keyword impliesType can be used for inferring the type of a
particular attribute value. An attribute definition of the form A impliesType
D, where A is an attribute identifier
and D is a concept identifier, implies membership of the concept D for all values of the attribute A. Please note that if the range of the attribute is a datatype, the semantics of ofType and impliesType coincide, because datatypes have a known domain and thus values cannot be inferred to be of a certain datatype.
Data attributes in WSML can be distinguished from concept attributes through the meta-concept _datatype. Each datatype used in WSML is a member of this meta-concept.
Concept attributes (i.e., attributes which do not have a datatype as range) can be specified as being reflexive, transitive, symmetric, or being the inverse of another attribute, using the reflexive, transitive, symmetric and inverseOf keywords, respectively. Notice that these keywords do not enforce a constraint on the attribute, but are used to infer additional information about the attribute. The keyword inverseOf must be followed by an identifier of the attribute, enclosed in parentheses, of which this attribute is the inverse.
The cardinality constraints for a single attribute are specified by including
two numbers between parentheses '(' ')', indicating the minimal and maximal
cardinality, after the ofType (or impliesType) keyword. The first number indicates the
minimal cardinality. The second number indicates the maximal cardinality,
where '*' stands for unlimited maximal cardinality (and is not allowed for
minimal cardinality). It is possible to write down just one number instead of
two, which is interpreted as both a minimal and a maximal cardinality
constraint. When the cardinality is omitted, then it is assumed that there
are no constraints on the cardinality, which is equivalent to (0
*). Note that a maximal cardinality of 1 makes an attribute
functional.
|
When an attribute is specified as being transitive, this means that if three individuals a, b and c are related via a transitive attribute att in such a way: a att b att c then c is also a value for the attribute att at a: a att c.
When an attribute is specified as being symmetric, this means that if an individual a has a symmetric attribute att with value b, then b also has attribute att with value a.
When an attribute is specified as being the inverse of another attribute, this means that if an individual a has an attribute att1 with value b and att1 is the inverse of a certain attribute att2, then it is inferred that b has an attribute att2 with value a.
Below is an example of a concept definition with attribute definitions:
concept Human
nonFunctionalProperties
dc#description hasValue "concept of a human being"
endNonFunctionalProperties
hasName ofType foaf#name
hasParent inverseOf(hasChild) impliesType Human
hasChild impliesType Human
hasAncestor transitive 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 optionally followed by the identifier of the relation.
WSML allows the specification of relations with arbitrary arity.
The domain of the parameters can be optionally specified using the keyword
impliesType or ofType. Note that parameters of a relation are strictly ordered.
A relation definition is optionally completed by the keyword subRelationOf followed
by one or more identifiers of superrelations. Finally an
optional nonFunctionalProperties
block can be specified.
Relations in WSML can have an arbitrary arity and values for the parameters can be constrained using parameter type definitions of the form ( ofType type-name ) and ( impliesType type-name). The definition of relations requires either the indication of the arity or of the parameter definitions. The usage of ofType and impliesType correspond with the usage in attribute definitions. Namely, parameter definitions with the ofType keyword are used to constrain the allowed parameter values, whereas parameter definitions with the impliesType keyword are used to infer concept membership of parameter values.
| 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/3
As for concepts, the exact meaning of a relation can be defined using axioms. For example one could
axiomatize the transitive closure for a property or further restrict the domain of one of the parameters. As with concepts, it is recommended that related axioms are indicated using the non-functional property dc#relation.
An instance definition starts with the instance keyword, (optionally) followed by the
identifier of the instance, the memberOf keyword
and the name of the concept to which the instance belongs. The memberOf keyword identifies the concept to which the
instance belongs. This definition is followed by the attribute values
associated with the instance. Each property filler consists of the property
identifier, the keyword hasValue and the
value(s) for the attribute.
| instance | = |
|
|||
| memberof | = |
|
|||
| attributevalue | = |
|
Example:
instance Mary memberOf {Parent, Woman}
nfp
dc#description hasValue "Mary is parent of the twins Paul and Susan"
endnfp
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., 2004], is achieved by providing a link to an instance store. Instance stores contain large numbers of instances and they are linked to the ontology. We do not restrict the user in the way an instance store is linked to a WSML ontology. This would be done outside the ontology definition, since an ontology is shared and can thus be used in combination with different instance stores.
Besides specifying instances of concepts, it is also possible to specify
instances of relations. Such a relation instance definition starts with the
relationInstance keyword, (optionally) followed
by the identifier of the relationInstance, the memberOf keyword and the name of the relation to which
the instance belongs. This is followed by an optional nonFunctionalProperties block, followed by the values
of the parameters associated with the instance.
| 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 nonFunctionalProperties block and one or more
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.
A WSML goal or web service may only have one capability. The specification of a capability is optional.
A capability description starts with the capability keyword, (optionally) followed by the name
(identifier) of the capability. This is followed by an optional nonFunctionalProperties block, an optional importsOntology block and an optional usesMediator block. The sharedVariables block is used to indicate the variables which are shared between the preconditions, postconditions, assumptions and effects of the capability, which are defined in the
precondition, postcondition, assumption, and
effect definitions, respectively. The number of such definitions is not
restricted. Each of these definitions consists of the keyword, an optional
identifier, an optional nonFunctionalProperties
block and a logical expression preceded by the definedBy keyword, and thus has the same content as an axiom (see Section 2.3.4). The language allowed for the
logical expression differs per WSML variant and is explained in the
respective chapters.
| capability | = |
|
||||||||||||
| sharedvardef | = |
|
||||||||||||
| pre_post_ass_or_eff | = |
|
Below is an example of a capability specified in WSML:
capability
sharedVariables ?child
precondition
nonFunctionalProperties
dc#description hasValue "The input has to be boy or a girl
with birthdate in the past and be born in Germany."
endNonFunctionalProperties
definedBy
?child memberOf Child
and ?child[hasBirthdate hasValue ?brithdate]
and wsml#dateLessThan(?birthdate,wsml#currentDate())
and ?child[hasBirthplace hasValue ?location]
and ?location[locatedIn hasValue oo#de]
or (?child[hasParent hasValue ?parent] and
?parent[hasCitizenship hasValue oo#de] ) .
assumption
nonFunctionalProperties
dc#description hasValue "The child is not dead"
endNonFunctionalProperties
definedBy
?child memberOf Child
and naf ?child[hasObit hasValue ?x].
effect
nonFunctionalProperties
dc#description hasValue "After the registration the child
is a German citizen"
endNonFunctionalProperties
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.
An interface specification starts with the interface keyword, (optionally) followed by the name
(identifier) of the interface. This is followed by an optional nonFunctionalProperties block, an optional importsOntology block and an optional usedMediator block and then by an optional
choreography block consisting of the keyword choreography followed by
the identifier of the choreography and an optional orchestration block
consisting of the keyword orchestration followed by the identifier of
the orchestration. Note that thus an interface can have at most one
choreography and at most one orchestration. It is furthermore possible to reference interfaces which have been specified at a different location. For reasons of convenience, WSML allows the referencing of multiple interfaces using an argument list.
| interfaces | = |
|
||||||
| minterfaces | = |
|
||||||
| interface | = |
|
||||||
| choreography | = |
|
||||||
| orchestration | = |
|
Below is an example of an interface and an example of references to multiple interfaces:
interface
choreography _"http://example.org/mychoreography"
orchestration _"http://example.org/myorchestration"
interface {_"http://example.org/mychoreography", _"http://example.org/mychoreography"}We do not define ways to specify the choreography and orchestration here. Instead, we refer the reader to the corresponding WSMO deliverable D14 [Roman et al., 2005].
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.
Example:
goal _"http://example.org/Germany/GetCitizenShip"A goal specification document in WSML consists of:
| goal | = |
|
The elements of a goal are the capability and the interfaces which are explained in the previous section.
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., 2004]).
| mediator | = |
|
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.
Example:
ooMediator _"http://example.org/ooMediator"All types of mediators share the same syntax for the sources, targets and servicesused:
| use_service | = |
|
||||||
| source | = |
|
||||||
| msources | = |
|
||||||
| sources | = |
|
||||||
| target | = |
|
ooMediators are used to connect ontologies to other ontologies, web services, goals and mediators. ooMediators take care of resolving any heterogeneity which occurs.
The source of an ooMediator in WSML may only contain identifiers of ontologies and other ooMediators as source.
An ooMediator in WSML may only have one target. The target may be the identifier of an ontology, a goal, a web service or another mediator.
The keyword usesService is used to identify a goal which declaratively describes the mediation service, a web service which actually implements the mediation or a wwMediator which links to such a web service. The entity pointed to is given by an identifier
| oomediator | = |
|
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.
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.
| wwmediator | = |
|
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.
| ggmediator | = |
|
wgMediators connect goals and web services, resolving any data, process and protocol heterogeneity.
wgMediators in WSML may only have one source. The source may be the identifier of a web service or another wgMediator.
wgMediators in WSML may only have one target. The target may be the identifier of a goal or a ggMediator.
| wgmediator | = |
|
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., 2004].
None of the elements in a mediator has any meaning in the logical language. In fact, the complexity of a mediator is hidden in the actual description of the mediator. Instead, the complexity is either in the implementation of the mediation service, in which case WSML does not support the description because WSML is only concerned with the interface description, or in the functional description of the web service or the goal which is used to specify the desired mediation service. As discussed in [Keller et al., 2004], these descriptions often need a very expressive language.
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.
A web service specification document in WSML consists of:
| webservice | = |
|