WSML Working Draft 5 March 2005
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.
The variant WSML-Core semantically corresponds with the intersection of Description Logic and Horn Logic (without function symbols and without equality), extended with extensive datatype support in order to be useful in practical applications. WSML-Core is fully compliant with a subset of OWL, albeit that the datatype support in WSML-Core is already beyond OWL, because the datatype support in OWL is very limited.
WSML-Core is extended, both in the direction of Description Logics and in the direction of Logic Programming.
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 stratified negation.
WSML-Rule extends WSML-Flight to a fully-fledged Logic Programming language, including function symbols and non-stratified negation.
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.
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 to and from 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 logical languages. More specifically, we take Description Logics, First-Order Logic and Logic Programming as starting points for the development of the WSML language variants. We provide a clean layering of the WSML variants, both syntactically and semantically. 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 an XML syntax as an exchange language, as well as an RDF syntax and a mapping to OWL for interoperability with RDF- and OWL-based applications.
Ontologies and Semantic Web services need formal languages for their specification in order to enable automatic processing. As for ontology descriptions, the W3C recommendation for an ontology language OWL [Dean & Schreiber, 2004] has serious 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., 2004]. For example, OWL-S offers the choice between different language for the specification of preconditions and effect. 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, uinified language for WSMO.
The deliverable is further structured as follows:
Chapter 2 describes the common elements between the WSML variants, as well as syntax basics, such as the use of namespaces and the basic vocabulary of the languages. 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 describes WSML-Flight, which is an extension of WSML-Core in the direction of Logic Programming. WSML-Flight is a more powerful logic language and offers more powerful modeling constructs than WSML-Core. Chapter 5 describes WSML-Rule which is a full-blown Logic Programming language. It is an extension of WSML-Flight and thus it offers the same kind of conceptual modeling features. Chapter 6 presents WSML-DL, which is an extension of WSML-Core. The extension described by WSML-DL is disjoint from the extensions described by WSML-Flight and WSML-Rule. WSML-DL is a full-blown Description Logic and offers similar expressive power to OWL DL [Patel-Schneider et al., 2004]. Chapter 7, finally, 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 in order to allow for basic interoperation with RDF-based applications. Chapter 11, finally, described a partial mapping to OWL in order to allow interoperation with OWL-based applications.
We conclude the document with describing efforts related to the WSML languages in Chapter 12. These related efforts are mostly concerned with implementation of WSML-based tools and tools utilizing WSML for specific purposes. Chapter 13, finally, presents conclusions and future work.
This document contains a number of appendices. It is therefore worthwhile to describe here the content of these 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. Future versions of this document might integrate (parts of) these resources. However, these resources take up a lot of space and would blow up the size of the document. Appendix C describes the built-in predicates and datatapes 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 they 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.
In Figure 1 the different variants of WSML and the relation between them are shown. In the figure, an arrow stands for "extension in the direction of". The variants differ in the logical expressivity they offer, and thus in the computational complexity of different reasoning tasks. 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, there are 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 either of the two paradigms, thereby effectively adding the expressiveness of either of the two paradigms to the intersection (cf. [Levy &Rousset, 1998]) or by reducing the interface between the two paradigms and independently reason with both paradigms (cf. [Eiter et al., 2004]).[1]
The only languages currently specified in this document, 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 (A.1) 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 quoted, non-terminals are underlined and refer to the corresponding productions. Alternatives are separated using vertical bars '|', and are labeled, where the label is enclosed in curly brackets '{' '}'; optional elements are appended with a question mark '?'; elements that may occur zero or more times are appended with an asterisk '*'; elements that may occur one or more times are appended with a plus '+'. [TODO: remove labels in final version]
In this chapter we introduce the WSML syntax. The general WSML captures all features of all WSML variants and thus corresponds with 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 WSM syntax basics, such as the use of namespaces, identifiers, etc. are described in Section 2.1. The elements all WSML specifications have in common in 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 in Sections 2.5, , 2.6 and 2.7, respectively. The module mechanism of WSML is described in Section 2.8. Finally, the WSML logical expression syntax is specified in Section 2.9
The 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.
Argument lists in WSML are separated by commas and surrounded by curly brackets. Statements in WSML-Core start with a keyword and can be spread over multiple lines.
A WSML specification is separated in 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 used mediators 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 in WSML, identifiers in WSML and datatypes in WSML. Subsequent sections of this chapter will 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 name 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. The WSML keywords themselves have the namespace http://www.wsmo.org/wsml-syntax#. In the remainder of the document, we will use the prefix 'wsml' to denote the WSML namespace http://www.wsmo.org/wsml-syntax#.
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 is 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 of a value which does not in fact belong to this datatype, leads to an inconsistency in the knowledge base.
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 | = |
|
|||
| pos_integer | = | digit+ | |||
| pos_decimal | = | digit+ '.' digit+ | |||
| string | = | '"' string_content* '"' | |||
| string_content | = | escaped_char | not_escape_char_not_dquote |
The built-in predicates which are to be supported by any WSML-compliant application are listed in Appendix C, 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 IRI 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 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 especially 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 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 a IRI which enhances the legibility of the specification. In case 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 argument: namespace and localname. Because sQNames are very common in WSML specification, 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, a sQName does not require special delimiters.
However, sQNames may not coincide with any WSML keywords.
The characters '.' and '-' in an sQName need to be escaped using a '\':
| full_iri | = |
|
||||
| sQName | = |
|
Examples of full IRIs in WSML:
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#):
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: wsml#true, wsml#false.
Please note that the IRI of a resource does not necessarily correspond to its location 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 identifies an object with a new unique identifier. It may be used in case the actual name of the object is not relevant.
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 of 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. In case no identifier is specified, the following default rules apply:
| id | = |
|
In case 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.
We define the notion of a WSML vocabulary in Definition 2.1.
Definition 2.1. A WSML vocabulary V consists of:
The sets VO, VG, VWS, VOOM, VGGM, VWGM, and VWWM are mutually disjoint.
This section describes the elements 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 |
| Table 2.1: WSML variant identifiers | |
| 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" By explicitly stating the intended WSML variant, tools can immediately recognize the intention of the author and return an exception in case the specification does not fall in 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. Notice that, like any argument list in WSML, the list of namespace
references is delimited with curly brackets ‘{’
‘}’.
| namespace | = |
|
||||||
| prefixdefinitionlist | = |
|
||||||
| prefixdefinition | = |
|
||||||
| moreprefixdefinitions | = |
|
An example:
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#"}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 identified by the keyword nonFunctionalProperties or its short form nfp. 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 or an anonymous identifier. 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/2004/wsml). 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 | = |
|
An 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.127 $"
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 in OWL.
This means the resulting ontology is the union of all axioms 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, also these ontologies are imported.
| importsontology | = |
|
An example:
importsOntology {_"http://www.wsmo.org/ontologies/location",
_"http://xmlns.com/foaf/0.1"}In case the imported ontology falls in a different WSML variant than the importing specification, the resulting ontology falls in 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 fall in 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. We are here 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 | = |
|
An example:
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. In case no identifier is specified for the ontology, the locator of the
ontology serves as identifier.
An 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.
| concept | = |
|
|||
| superconcept | = |
|
An example:
concept Human subConceptOf {Primate, LegalAgent}
nonFunctionalProperties
dc#description hasValue "concept of a human being"
dc#relation hasValue CompleteHumanDefinition
endNonFunctionalProperties
hasName ofType foaf#name
hasParent impliesType Human
hasChild impliesType Human
hasAncestor impliesType Human
hasWeight ofType xsd#float
hasWeightInKG ofType xsd#float
hasBirthdate ofType xsd#date
hasObit ofType xsd#date
hasBirthplace ofType loc#location
isMarriedTo impliesType Human
hasCitizenship ofType oo#countryWSML allows to create 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 given we
refer to an axiom with the identifier CompleteHumanDefinition.
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 member of this concept.
WSML supports defined concepts through the use of axioms. The logical expression 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 CompleteHumanDefinition
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 inferring attribute definitions not to 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 of type D, the constraint is violated and the attribute value is
inconsistent with respect to the ontology. This notion of constraints
corresponds the usual database-style constraints and also the universal
values restrictions for DatatypeProperties in OWL.
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 in case 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 that 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 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
*). Notice 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.
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) xsd#float
hasWeightInKG ofType (1) xsd#float
hasBirthdate ofType (1) xsd#date
hasObit ofType (0 1) xsd#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
impliesType or ofType. Note that parameters of a relation are strictly ordered.
A relation definition is optional completed by the keyword subRelationOf followed
by one or more identifiers that refer to the respective superrelations. Finally an
optional nonFunctionalProperties
block can be specified.
Relations in WSML can have an arbitrary arity and besides inference also constraints on the range, i.e. parameter type definitions of the form ( ofType constraint ) and ( impliesType inference ). The definition of relations requires either the indication of the arity or of the parameter inference/constraints. The usage of ofType and impliesType corresponds 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 | = |
|
An example:
relation distance/3 (ofType City, ofType City, impliesType xsd#decimal) subRelationOf measurementSimilarly 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 to indicate related axioms 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 | = |
|
An 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 that are shared together with the ontology. However, most instance data exists outside the ontology in private data stores. In order to access these instances, as described in [Roman et al., 2004], is 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. Each parameter value consists
of the parameter identifier, the keyword hasValue and the value for the parameter (notice that
a parameter may only have one value).
| relationinstance | = |
|
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 a
logical expression preceded by the definedBy
keyword. The language allowed for the logical expression is explained in Section 2.9.
| axiom | = |
|
||||||
| axiomdefinition | = |
|
||||||
| log_definition | = |
|
An example of a defining axiom:
axiom humanDefinition
definedBy
?x memberOf Human equivalent
?x memberOf Animal and
?x memberOf LegalAgent.WSML allows to specify constraints. 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 are 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 and then by a number of
assumption, precondition, effect, and
postcondition definitions. 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. 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 | = |
|
An example of a capability specified in WSML-Full (for reasons of space we only show one assumption; a capability typically also has preconditions, postconditions and effects):
capability
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 ?brithplace]
and wsml#dateLessThan(?brithplace,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 neg (exists ?x (?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. Notice that thus an interface can have at most one
choreography and at most one orchestration.
| interfaces | = |
|
||||||
| minterfaces | = |
|
||||||
| interface | = |
|
||||||
| choreography | = |
|
||||||
| orchestration | = |
|
An example of an interface:
interface
choreography _"http://example.org/mychoreography"
orchestration _"http://example.org/myorchestration"We do not define ways to specify the choreography and orchestration here. Instead, we refer the reader to the corresponding WSMO deliverables D14 [Roman & Scicluna, 2005a] and D15 [Roman & Scicluna, 2005b].
A WSML goal specification is identified by the goal keyword optionally followed by a IRI which serves
as the identifier of the goal. In case no identifier is specified for the
goal, the locator of the goal serves as identifier.
An 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]).
A WSML mediator specification is identified by the keyword indicating a particular kind of mediator (ooMediator, wwMediator, ggMediator, wgMediator), optionally followed by a 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.
An example:
ooMediator _"http://example.org/ooMediator"A mediator specification document in WSML consists of:
| mediator | = |
|
These types of mediators all share the same syntax for the sources, targets and used services:
| use_service | = |
|
||||||
| source | = |
|
||||||
| msources | = |
|
||||||
| sources | = |
|
||||||
| target | = |
|
ooMediors are used to connect ontologies to other ontologies, web services, goals and mediators. ooMediators take care of resolving any occurring heterogeneity.
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 useService is used to identify a goal that declaratively describes the mapping, a web service that actually implements the mapping or a wwMediator that 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, in the general case there are mismatches and overlaps between the different ontologies which requires mediation. Furthermore, if the imported ontology is specified using a WSML variant which has an undesired 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.
A wwMediators in WSML may only have one source. The source may be the identifier of a web service or another wwMediator.
A 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.
A ggMediators in WSML may only have one source. The source may be the identifier of a goal or another ggMediator.
A 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.
A wgMediators in WSML may only have one source. The source may be the identifier of a web service or another wgMediator.
A 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 from the ontology, WSMO 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 is 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 a 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 | = |
|