This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability, trademark,
document use, and software licensing rules apply.
We introduce WSML-Core, an ontology modeling language, based on the semantics of OWL Lite- (a restricted subset of OWL Lite) and the conceptual model of ontologies presented in WSMO.
We describe each modeling element in the syntax of WSML-Core and describe the semantics through a mapping to (the OWL Lite- subset of) the OWL abstract syntax, which has a direct model-theoretic semantics associated with it. When analyzing the applicability of WSML-Core to the current version of the WSMO use cases we see some limitations of WSML-Core.
The major goal of the WSML working group is to develop a formal language for the description of Semantic Web Services based on the WSMO conceptual model. As is described in deliverable D16.0 [Oren, 2004], there are several WSML languages with different underlying logical formalisms. The two main logical formalisms exploited in different WSML languages are Description Logics [Baader et al., 2003] (exploited in WSML-DL) and Rule Languages [Lloyd, 1987] (exploited in WSML-RL). WSML-Core (described in this document) exploits the intersection of both formalisms.
We introduce WSML-Core, an ontology modeling language, based on the semantics of OWL Lite- [de Bruijn et al., 2004], which is based on [Grosof et al., 2003], and the conceptual model of ontologies presented in WSMO [Roman et al., 2004]. Because WSML-Core is based on OWL Lite- and there exists a translation from OWL Lite- to plain (function- and negation-free) Datalog, the decidability and complexity results of Datalog apply to WSML-Core as well. The most important result is that Datalog is data complete for P, which means that query answering can be done in polynomial time.
Chapter 2 describes all the elements of the WSML-Core language. Chapter 3 specifies the mapping from WSML-Core to the OWL Lite- abstract syntax, thereby actually defining the semantics of WSML-Core. Chapter 4 provides a mapping from the OWL Lite- abstract syntax to WSML-Core. Chapter 5 summarizes the applicability of WSML-Core to the use cases of WSMO D3.2 [Stollberg et al., 2004]. Finally, we present some conclusions in Chapter 6.
In this chapter we explain the ontology modeling elements in the WSML-Core language. The modeling elements are based on the WSMO conceptual model of ontologies [Roman et al., 2004]. Each description is accompanied by an example. Most of the examples were taken from [Stollberg et al., 2004].
The recommended namespace to be used to reference this version of WSML-Core is http://www.wsmo.org/2004/d16/d16.7/v0.1/.
Please note that WSML-Core definitions should follow the ordering as presented in the sections below.
The syntax for WSML-Core has a frame-like style, where a collection of information about a class or property is given 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-Core 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.
Identifiers in WSML-Core follow the conventions of WSMO [Roman et al., 2004]. An identifier is either a URI or a Qualified Name (QName). QNames without a prefix are resolved with the default namespace. Conventionally, internal words within QNames are designated by initial capital letters, not by hyphens or underscores. Variable names start with an initial question mark, "?". Depending upon context, a variable can stand in for a concept, attribute, instance, attribute value, or literal; it may not stand in for a language keyword or special symbol.
Argument lists are separated by commas. Statements in WSML-Core start with a keyword and can be multi-lined. There is no specific end-of-statement syntax -- a keyword for a new statement is sufficient.
An ontology definition in WSML-Core starts with the ontology keyword followed by an identifier, which serves as the identifier of the ontology. When a full URI is used for this identifier and no explicit target namespace definition exists, this identifier is used as the target namespace of the definitions in the ontology specification document.
An example:
ontology <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/resources/po.wsml>
Below the ontology URI declaration, there is an optional block of namespace definitions, which is preceded by the namespace keyword. The namespace keyword is optionally followed by the default namespace and a number of namespace definitions. Each namespace definition, except for the default namespace, consists of the chosen prefix, a ':' and the URI, which identifies the namespace. Finally, the (optional) target namespace is specified with the use of the targetNamespace keyword. If the target namespace is designated by the URI which is specified by the ontology declaration, the targetNamespace line is redundant and may be omitted.
An example:
namespace
<http://www.wsmo.org/ontologies/purchase#>
dc: <http://purl.org/dc/elements/1.1#>
wsml: <http://www.wsmo.org/2004/d2/v1.0#>
targetNamespace <http://www.wsmo.org/ontologies/purchase#>
Following the namespace definition block is an optional non-functional properties definition block, identified by the keyword nonFunctionalProperties. Following the keyword is a list of properties and property values. 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 defines one property, absent in the Dublin Core, namely version. The value of each of the properties is either a URI or a literal. If a property has multiple values, these are separated by commas.
An example:
nonFunctionalProperties
dc:title hasValues "Purchase ontology"
dc:creator hasValues <http://www.example.org/deri/foaf.agent>
dc:subject hasValues "Buyer", "Seller", "Product", "Price",
"Payment method", "Delivery"
dc:description hasValues "General purchase order request ontology"
dc:publisher hasValues <http://www.example.org/deri/foaf.agent>
dc:contributor hasValues <http://www.example.org/deri/armin.haller/foaf.agent>
dc:date hasValues "2004-07-19"
dc:type hasValues <http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos>
dc:format hasValues "text/plain"
dc:language hasValues "en-US"
dc:relation hasValues
<http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml>,
<http://www.wsmo.org/ontologies/dateTime#>
dc:coverage hasValues "ID:7029392 Name:World"
dc:rights hasValues <http://www.deri.org/privacy.html>
version hasValues "Revision: 1.12"
endNonFunctionalProperties
Following the nonFunctionalProperties definition block is an optional imported ontologies definition block, identified by the keyword importOntologies. Following the keyword is a list of URIs identifying the ontologies being imported. An importOntologies definition serves to merge ontologies, just as an OWL import statement does. This means the resulting ontology is the union of all axioms in the importing and imported ontologies. Please note that recursive importation of ontologies is also supported. This means that if an imported ontology specifies any importation of ontologies, also the axioms in these ontologies are taken in the union.
An example:
importOntologies
<http://www.wsmo.org/ontologies/dateTime#>
<http://www.wsmo.org/ontologies/currency#>
Mediators are used to import other ontologies. This concept of mediation between ontologies is more flexible than the importOntologies statement, which is used to import an WSML ontology into another WSML ontology. The ontology import mechanism simply appends the definitions in the imported ontology to the importing ontology. The importing ontology should contain the axioms to relate the definitions in the imported ontology to the local definitions. This mechanism enforces a strong coupling between the ontologies, which is undesirable in the general case and it does not allow importing parts of ontologies.
By externalizing the mediation from the ontology, WSMO allows loose coupling of ontologies; the mediator is responsible for relating the different ontologies to each other. A mediator can provide, for example, translation services between ontology languages or adjust for argument-order differences. This notion of mediators corresponds with ooMediators in WSMO [Roman et al., 2004].
The (optional) mediators definition block is identified by the usedMediators, followed by one or more identifiers of WSMO ooMediators.
An example:
usedMediators
<http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/resources/owlFactbookMediator.wsml>
<http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/resources/owlAddressMediator.wsml>
A concept definition starts with the concept keyword, which is followed by the identifier of the concept.
This is followed by
zero or more implicitly conjoined direct superconcept definitions (using the subConceptOf keyword followed by the identifier for a named concept),
an optional nonFunctionalProperties block,
and zero or more attribute specifications. An attribute specification consists of the identifier of a relation, the ofType keyword and the identifier of a concept of which the attribute values must be instances.
A concept can only be a subConceptOf named concepts. WSML-Core does not allow complex concepts definitions as superconcepts, as is allowed in OWL.
An attribute definition of the form A ofType D, where A is an attribute identifier and D is a concept, asserts that for each instance of concept C, each value for the attribute A is of the type D. This corresponds with universal value restrictions in OWL.
An example:
concept Human subConceptOf Primate, LegalAgent
nonFunctionalProperties
dc:description "Members of the species Homo sapiens"
endNonFunctionalProperties
parentOf ofType Human
A relation definition starts with the relation keyword, which is followed by the identifier of the relation and an optional specification of direct super-relations through the subRelationOf keyword.
This is followed by an optional nonFunctionalProperties block. In WSML-Core, relations are restricted to binary predicates, which correspond with ObjectProperties in OWL Lite-. Parameters can be used to restrict the domain and range of the property (denoted by the domain and range keywords, respectively). It fact, no other parameters are allowed.
Particular aspects of the relation are denoted by particular keywords. The relation can be a specialization of a different named relation, denoted with the subRelationOf keyword. Transitive, symmetric, and inverse properties are denoted with the transitive, symmetric, and inverseOf keywords, respectively. For a complete account, see Table 1 in Chapter 4.
An example:
relation hasAncestor subRelationOf hasRelative
transitive
nonFunctionalProperties
dc:description "Relation between ancestors"
endNonFunctionalProperties
domain ofType Person
range ofType Person
An instance definition starts with the instance keyword, followed by the identifier of the instance, the memberOf keyword and the name of the concept to which the instance belongs. An instance corresponds with an individual in OWL Lite-. 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 hasValues[1] and the value for the attribute.
An example:
instance innsbruckHbf memberOf station
name hasValues loc:ibk
code hasValues loc:inn
locatedIn hasValues loc:innsbruck
The second way of accessing 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 with the use of a mediator. In order to distinguish mediators used for linking ontologies and mediators used for linking instance stores, we introduce the keyword instance-stores followed by one or more identifiers to indicate the instance stores.
An example:
instanceStores
<http://www.example.org/instance-stores/personnel-store>
<http://www.example.org/instance-stores/client-store>
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 then by a logical expression preceded by the
definedBy keyword. The language allowed for the logical expression is explained in Chapter 3 and the allowed expressions are detailed in Table 2 in Chapter 4.
An example:
axiom humanDefinition
definedBy
?x memberOf Human <->
?x memberOf Animal and
?x memberOf LegalAgent.
In this chapter we explain the syntax of logical expressions used in the WSML-Core language. Each description is accompanied by an example.
Logical expressions may be simple or complex. A logical expression is terminated by a period. Simple logical expressions can be combined to form complex expressions.
WSML-Core has the following simple logical expressions:
WSML-Core has the following complex logical expressions:
Notice that the use of the logical expression syntax is restricted by the allowed logical expressions of Table 2 in Chapter 4 in order to allow for a direct translation into OWL Lite-.
The three basic types of simple logical expressions are relation expressions and molecules.
A relation logical expression consists of a predicate identifier followed by the comma-separated arguments of the predicate, enclosed by parentheses. The predicate corresponds to a regular relation. A relation value logical expression is one that can be expressed by a single binary relation relating the two arguments. The first argument is an instance of a concept. The second argument is also an instance of a concept.
An example:
parentOf(Mary, John)
A molecule in WSML-Core is either a concept molecule or an instance molecule.
An instance molecule is one of the following statements:
I memberOf C, where I is an instance identifier and C is a concept identifier.I[A1 hasValues v1,..., An hasValues vn], where I is an instance identifier, A1,...,An are attribute identifiers and v1,...vn are either instance identifiers or data values.A concept membership assertion of the form I memberOf C states that I is an instance of concept C. An attribute value list specifies the values for certain attributes for this particular instance.
Two examples:
myCC memberOf creditCard
myCC[number hasValues ccnr12345, owner hasValues jos]
A concept molecule is one of the following statements:
C subConceptOf D, where C and C are a concept identifiers.C[A1 ofType D1,..., An ofType v1], where I is an instance identifier, A1,...,An are attribute identifiers and D1,...Dn are concept identifiers.A subconcept assertion of the form C subConceptOf D states that C is a subconcept of D, which means that each instance of C is also an instance of D. An attribute definition of the form C[A ofType D] asserts that for each instance of concept C, each value for the attribute A is of the type D.
Two examples:
creditCard subConceptOf paymentMethod
creditCard[number ofType ccNumber, owner ofType person]
WSML-Core has the following complex logical expressions:
and keyword.A compound logical expression consists of a number of simple logical expressions connected with the keyword and. The compound logical expression is satisfied if each of the simple logical expressions is satisfied.
An example:
myCC memberOf creditCard and myCC[number hasValues cc12345, owner hasValues jos]
Molecules involving the same instance or concept, occurring in a compound logical expression, can be collapsed into one compound molecule to allow for more concise syntax. The example above can be thus rewritten:
myCC memberOf creditCard[number hasValues cc12345, owner hasValues jos]
A formula in WSML-Core consists of two (simple or compound) logical expressions, separated by an implication symbol. This implication symbol can be left implication (<-), right implication (->) or dual implication (<->). In formulas, variables are allowed to occur in the place of identifiers.
E1 <- E2, where E1 and E2 are (simple or compound) logical expressions. E1 is true wrt. a certain variable binding, if E2 is true wrt. the same variable binding. E2 is called the antecedent and E1 is called the consequent of the formula.E1 -> E2, where E1 and E2 are (simple or compound) logical expressions. E2 is true wrt. a certain variable binding, if E1 is true wrt. the same variable binding. E1 is called the antecedent and E2 is called the consequent of the formula.E1 <-> E2, where E1 and E2 are (simple or compound) logical expressions. E1 is true wrt. a certain variable binding if and only if E2 is true wrt. the same variable binding. A dual implication E1 <-> E2 is actually equivalent to the two implications: E1 <- E2 and E1 -> E2. Therefore, both E1 and E2 are both the antecedent and the consequent of the formula.Note that variables occurring in the consequent of a formula must also occur in the antecedent of the same formula. Note also that all variables are implicitly universally quantified outside of the formula.
An example:
?x memberOf Human <-> ?x memberOf Animal and ?x memberOf LegalAgent.
In this chapter we define the semantics of WSML-Core through a mapping to the OWL Lite- abstract syntax [de Bruijn et al., 2004], which is a subset of the OWL abstract syntax. The syntax and semantics of the OWL abstract syntax can be found in [Patel-Schneider et al., 2004].
Table 1 shows the mapping between the WSML-Core conceptual syntax and OWL Lite-. In the table, C and D refer to named concepts (classes in OWL), R refers to an ObjectProperty, A refers to an attribute (this can be either an ObjectProperty or a DatatypeProperty in OWL), O refers to an ontology and M refers to a mediator.
Through the mapping to the OWL abstract syntax, the precise semantics of the WSML-Core primitives is defined. Please note in WSML-Core, each construct can have non-functional properties associated with it. This is not reflected in the table. Rather, there is a separate row in the table, which addresses the non-functional properties and the way they are reflected in the OWL abstract syntax. The annotation properties occur inside each class, property or instance definition.
We need to make two notes here about the WSML-Core syntax compared to the syntax presented in WSMO-Standard [Roman et al., 2004]. First of all, the attribute definitions in the concept signature (see the second row of Table 1) are interpreted as universal value restrictions in OWL Lite-. This does not correspond with the intuition behind these attribute definitions, as was pointed out in [de Bruijn et al., 2004]. Second, we on the one hand restrict the WSMO-Standard syntax for relations by allowing only two parameters (domain and range) in order to restrict the relations to those of binary arity. On the other hand, we extend the WSMO-Standard syntax with the keywords subRelationOf, transitive, symmetric, and inverseOf in order to capture the epistemology of the ObjectProperties in OWL.
In Table 2, we have identified exactly which logical expressions can be translated to OWL Lite-. In the table, C and D refer to named concepts (classes in OWL), R and S refer to ObjectProperties, A refers to an attribute. These logical expressions add little[2] in expressivity over the conceptual syntax, but sometimes the user prefers a different way of modeling axioms. Furthermore, this syntax for logical expressions can be directly used in goal descriptions and capability descriptions of web services for the modeling of assumptions, pre-conditions, effects and post-conditions. All and only those logical expressions that are either in the first column of Table 2 or can be reduced to logical expressions in Table 2 are valid in WSML-Core.
| WSML-Core conceptual syntax | OWL Lite- Abstract syntax | Remarks |
| Logical Declarations | ||
|
Ontology(O) | All definitions and axioms in the ontology are nested inside the Ontology statement, according to the other mappings in this table. |
|
Class(C partial D1 ... Dn restriction(A1 allValuesFrom C1) ... restriction(An allValuesFrom Cn)) |
|
|
ObjectProperty(R super(R1) ... super(Rn) [inverseOf(R0)] [Symmetric] [Transitive] domain(C1) ... domain(Cn) range(D1) ... range(Dn)) |
|
|
Individual(o type(C1) ... type(Cn) value(A1 o1) ... value(An on)) |
|
| Extra-Logical Declarations | ||
|
annotation(P1 v1) . . annotation(Pn vn) [annotation(owl:versionInfo v0)] |
Annotation properties are nested inside other definitions, such as ontology, individual, class and property definitions. For some strange reason, if annotations occur on the ontology level, they should be written with a capital 'A' (e.g. Annotation(owl:versionInfo "$Revision: 1.87 $")). |
|
The OWL abstract syntax does not provide a construct for the import of ontologies, although the RDF/XML serialization does provide this facility through the import statement.
|
|
|
OWL does not have the concept of a mediator. Therefore, this construct cannot be translated to OWL. | |
| Table 1: Mapping between WSML-Core and OWL Lite- abstract syntax | ||
| WSML-Core Logical Expression | OWL Lite- Abstract Syntax | Remarks |
| TODO: find a better way to characterize the allowed logical expressions | ||
|
Class (C partial D1 ... Dn) | |
|
Class (D partial C1 ... Cn) | |
|
Class (D complete C1 ... Cn) | |
|
Class (C partial restriction(R allValuesFrom D)) | |
|
ObjectProperty (R super(S)) | |
|
ObjectProperty (R domain(C)) | |
|
ObjectProperty (R range(S)) | |
|
ObjectProperty (R inverseOf(S)) | |
|
ObjectProperty (R Symmetric) | |
|
ObjectProperty (R Transitive) | |
|
Individual(o type(C) value(A1 o1) ... value(An on) |
Both the memberOf C and all the property values are optional. |
| Table 2: Mapping between WSML-Core logical expressions and OWL Lite- abstract syntax | ||
Table 3 shows the mapping between OWL Lite- (abstract syntax) and WSML-Core. It contains the conceptual syntax as well as any additional logical expression that might be necessary to capture the semantics of the OWL Lite- statement. The table shows for each construct supported by OWL Lite- the WSML-Core syntax in terms of the conceptual model and additional logical expressions necessary to capture the construct.
As we can see from Table 3, all of OWL Lite- can be captured in WSML-Core. Most of the axioms can be captured with the conceptual model. However, some axioms rely on additional logical expressions. Notice that if both conceptual syntax and a logial expression is given in the table, this means that they are both introduced in the translation and should be taken in conjunction.
| OWL Lite- Abstract syntax | WSML-Core conceptual syntax | WSML-Core logical expression |
| Logical Definitions | ||
| Class(C partial D1 ... Dn) |
|
|
| Class(C complete D1 ... Dn) |
|
|
| EquivalentClasses(C1 ... Cn) |
|
|
|
ObjectProperty(R super(R1) ... super(Rn) domain(C1) ... domain(Cn) range(D1) ... range(Dn) |
|
|
| [inverseOf(R0)] |
|
|
| [Symmetric] |
|
|
| [Transitive]) |
|
|
| SubPropertyOf(R1 Rx) |
|
|
| EquivalentProperties(R1 ... Rn) |
|
|
| Individual(o type(C1) ... type(Cn) value(R1 o1) ... value(Rn on)) |
|
|
| Extra-Logical Definitions | ||
| annotation(P v) |
|
|
| Table 3: Mapping between OWL Lite- abstract syntax and WSML-Core | ||
This chapter enumerates the listings in the WSMO Use Cases document [Stollberg et al., 2004] and identifies whether the listing is in WSML-Core and if not, why it is not. Furthermore, we describe reductions, which would be necessary to make the listing fall inside WSML-Core. Note that WSML-Core does not distinguish between single-valued and set-valued attributes. Note also that in the evaluation we do not take into account inter-dependencies between the ontologies.
When evaluating the goal and web service descriptions, we only focus on the logical expressions, which are used for the assumptions, pre-conditions, effects and post-conditions.
Note that we have not evaluated the mediator descriptions, because they were not available in enough detail.
In the reason why a particular listing is not in WSML-Core we distinguish:
| Listing | In WSML-Core? | Why not? | Steps to make it fall inside WSML-Core |
| Ontologies | |||
| 1: Domain Ontology "International Train Ticket" | no |
- data types - data type predicates - integrity constraints - equality |
- Remove all (3) axioms - Replace occurrences of data types with abstract concepts |
| 2: Domain Ontology "Date and Time" | no |
- data types - data type predicates - mixing abstract and concrete domains - integrity constraints - equality |
- Complete remodeling of ontology |
| 3: Domain Ontology "Purchase" | no |
- data types |
- Replace occurrences of data types with abstract concepts |
| 4: Domain Ontology "Locations" | no |
- data types - data type predicates - mixing abstract and concrete domains - integrity constraints - equality (and also '<' and '>'; in the head!) |
- Replace occurrences of data types with abstract concepts - Remove all axioms |
| Goals and Web Services | |||
| 5: Goal - buying a train ticket online | no | - data types | - Replace occurrences of data types with abstract concepts |
| 6: ÖBB Web Service for Booking Online Train Tickets for Austria and Germany | no |
- data types - data type predicates - equality |
- Removing all restrictions written in the preCondition and the postCondition |
It turns out that in the listings in [Stollberg et al., 2004] data types are often used, as well as data type predicates. An extension of WSML-Core with, for example, data type groups [Pan and Horrocks, 2004], could solve most of the problems.
In many of the listings in the use cases document, abstract concepts are mixed with datatypes. Often, an abstract concept is the subconcept of a datatype. This seems to be done mostly because it was necessary to create user-defined data types (cf. [Pan and Horrocks, 2004]). If user-defined data types were to be introduced, a lot of this mixing of domains could be easily eliminated. Furthermore, it turns out that very often, integrity constraints are used.
In this deliverable we have introduced the syntax of WSML-Core, which is based on the WSMO conceptual model for ontologies [Roman et al., 2004]. We have given a precise characterization of the semantics through a mapping to the OWL abstract syntax [Patel-Schneider et al., 2004].
From the evaluation of the ontologies developed in the WSMO use cases [Stollberg et al., 2004] we have seen that there are still some things lacking in WSML-Core, which are essential for the modeling of ontologies. The main elements lacking in WSML-Core are datatypes and datatype predicates. WSML-Core currently does not have these feature because it is based on OWL Lite- [de Bruijn et al., 2004] and OWL Lite- lacks these features. However, [de Bruijn et al., 2004] already proposed datatype groups [Pan and Horrocks, 2004] as an extension to OWL Lite-, which can then be integrated in WSML-Core.
The following major updates have been done since the August 2nd version of the deliverable:
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[Berglund et al., 2004] A. Berglund, S. Boag, D. Chamberlin, Mary F. Fernández, M. Kay, J, Robie, and Jérôme Siméon (eds.): XML Path Language (XPath) 2.0, W3C Working Draft, available from http://www.w3.org/TR/xpath20/.
[de Bruijn et al., 2004] J. de Bruijn, A. Polleres, R. Lara and D. Fensel. OWL-. Deliverable d20v0.2, WSML, 2004. To be published at http://www.wsmo.org/2004/d20/v0.2/ on 2004-08-16.
[Dean et al., 2004] M. Dean, G. Schreiber, S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein: OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
[Fensel et al., 2001] D. Fensel, F. van Harmelen, I. Horrocks, D.L. McGuinness, and P.F. Patel- Schneider: OIL: An Ontology Infrastructure for the Semantic Web. IEEE Intelligent Systems, 16:2, May 2001.
[Grosof et al., 2003] B. N. Grosof, I. Horrocks, R. Volz, and S. Decker. Description logic programs: Combining logic programs with description logic. In Proc. of the Twelfth International World Wide Web Conference (WWW 2003), pages 48-57. ACM, 2003.
[Horrocks et al., 2004] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof and M. Dean: SWRL: A Semantic Web Rule Language Combining OWL and RuleML. W3C Member Submission 21 May 2004. Available from http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/.
[Lloyd, 1987] J. W. Lloyd. Foundations of Logic Programming (2nd edition). Springer-Verlag, 1987.
[Malhotra et al., 2004] A. Malhotra, J. Melton, N. Walsh: XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Working Draft, available at http://www.w3.org/TR/xpath-functions/.
[Oren, 2004] E. Oren (ed.): Languages for WSMO, WSML deliverable D16.0 version 0.2 Working Draft. available from http://www.wsmo.org/2004/d16/d16.0/v0.2/.
[Pan and Horrocks, 2004] J. Z. Pan and I. Horrocks, I.: OWL-E: Ex- tending OWL with expressive datatype expressions. IMG Technical Report IMG/2004/KR-SW-01/v1.0, Victoria University of Manchester, 2004. Available from http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf.
[Patel-Schneider et al., 2004] P. F. Patel-Schneider, P. Hayes, and I. Horrocks: OWL web ontology language semantics and abstract syntax. Recommendation 10 February 2004, W3C, 2004. Available from http://www.w3.org/TR/owl-semantics/.
[Roman et al., 2004] D. Roman, H. Lausen, and U. Keller (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), WSMO deliverable D2 version 1.0 Working Draft 9 August 2004. available from http://www.wsmo.org/2004/d2/v1.0/20040809/.
[Stollberg et al., 2004] M. Stollberg, H. Lausen, A. Polleres, and R. Lara (eds.): WSMO Use Case Modeling and Testing, WSMO d3.2v0.1, version 2004-06-28. available from http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/.
[Weibel et al. 1998] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.
We would especially like to thank the reviewer of the deliverable, Ian Horrocks, for useful comments and discussions around this deliverable.
The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSML working group for their advice and input into this document.
[1]Note that in WSML-Core there is no keyword hasValue for single-valued attributes, because there are not cardinality restrictions in WSML-Core. Only set-valued attributes are allowed through the hasValues keyword.
[2]The only expressivity added by the logical expressions over the conceptual syntax is the complete class definition, which is an equivalence relation between the defined class and the intersection (conjunction) of the defining classes.
Here follow the reviewer comments from the reviewer Ian Horrocks on the August 2nd version of this deliverable. Find in-line the responses of the authors to the comments:
| The language seems to fall into the same trap as OWL Lite in that it | tries to impose *syntactic* restrictions on what can be said without | being clear about the objective in terms of a target logic. The result | may be (as in OWL Lite) that the restrictions don't achieve their | objective (the language is stronger than was intended), or that some | things that are allowed can only be expressed in a very convoluted | way. JB: The objective of the language is to have an ontology modeling language based on the conceptual model of ontologies presented in WSMO, which can be translated both to a subset of OWL Lite (OWL Lite-) and to plain Datalog. You are right that the conceptual syntax does not capture the full ex- pressiveness of the language, but we believe that these features will not be used very much in practice. If, however, it turns out that certain feature are used in practice, we can always extend the conceptual syntax. | I would strongly recommend that you specify what the intended language | is in terms of a DL or some other subset of FOL (e.g., function free | Horn). You will then have a much crisper definition, and a much better | understanding of the characteristics of your language (decidability, | complexity etc); the underlying motivation for the design can also be | made much clearer (e.g., easier reasoning). Of course it may also be | useful to specify translations to-from languages such as OWL Lite, but | these don't tell you anything very useful about your language. JB: This has now been stated more clearly in the introduction. | Choosing to only include value (allValuesFrom) restrictions seems | rather strange, is (as you point out) counter-intuitive, and makes the | language of very limited value in many applications. Why not support | both some/all values as in OWL Lite? If the reason is a requirement to | restrict expressive power, this would be made much clearer by using a | translation into logic as suggested above (to make it clear if the | restriction really has any justification/benefit). If you do need to | avoid having both forms of restriction, why not use a combined | semantics (attributes translate to a combination of some/all), which | is what is often intended in any case? JB: The translation to a logic is done in OWL Lite-, therefore the trans- lation is done indirectly. I'm not sure whether it would be necessary to provide a direct translation, although I guess we will have to do this when building an implementation. | You say that the language is an intersection of a DL and rules | language - it might be appropriate to cite our WWW paper at this point | [1]. JB: Reference is added to the introduction. | Are you sure that the syntax is parsable? (i.e., did you use a parser | generator to produce a parser?). I am a little sceptical about | this. E.g., using key-words (such as "subconcept-of") as the names of | non-functional properties looks as though it could be | problematical. (You don't mention any restriction on the use of | key-words.) JB: Note that the syntax in this version has been slightly updated to reflect the syntax updates to WSMO D2. The syntax is in fact based on the syntax defined in D2 (http://www.wsmo.org/2004/d2/). In fact it is a restriction and a slight extension of it. The grammar in Appendix B of D2 is parsable. There is not yet a grammar for WSML-Core, but this will be produced as soon as the syntax is fixed. | Is order important anywhere/everywhere in the syntax? This isn't made | very clear. JB: Yes, the order is important. I added a sentence about this to the introduction of chapter 2. | "non-functional-properties" seems a rather strange and unintuitive | term for annotations. JB: You could also say the 'annotations' is an unintuitive term for non-functional properties ;-) We have decided to use this term in WSMO and I actually like it, because it seems to give the non-functional properties more impor- tance than the 'annotations' keyword. | The split of expressivity between frames and axiom definitions seems | arbitrary and unintuitive. You say that the axiom definitions don't | really add anything, but are just a different way of writing things | down. It would be much better if this were true, but it isn't! In | particular, frames provide no way of specifying complete definitions | (which you do note later on). Why not add a "complete" key word to | frames? JB: You are right, this statement is not completely true. I actually considered adding the 'complete' keyword to the frames, but for complete class definitions, allValuesFrom restrictions are not allowed in OWL Lite-, because universal value restriction on the left-hand side of the GCI can not be translated to Datalog. Therefore, I think it would be un- intuitive to have this keyword here. I also think that people who use WSML-Core are not that interested in complete class definitions. People who want more expressiveness can use of the extensions of WSML-Core. These extensions are to be developed. An overview of WSML languages can be found at: http://www.wsmo.org/2004/d16/d16.0/ | It may be rather difficult for users to understand the restrictions on | the form of axiom definitions - the only specification is a list of | allowable forms, which is rather hard to understand/remember. There | must be some clearer way of specifying the restrictions than this. As | far as I can understand it, the example you give in S2.10 doesn't fit | into the forms given in Table 2! JB: Indeed. We'll try to come up with a better way of describing these in the next version of the deliverable. | You need to state explicitly what all of the notation (C, D, R, S etc) | in the tables stands for. JB: Will be done for the next version. | S2: "In this chapter we explain ... Most of the examples were taken | from [Stollberg et al., 2004]" is repeated twice. JB: fixed | S2.5 Your description of the meaning of import makes it sound as | though some concatenation of ontologies is going on at the syntactic | level, whereas OWL imports simply specifies that the *semantics* is | equivalent to a union of the axioms in all relevant ontologies. This | is important because of, e.g., cyclical imports statements. You also | don't explicitly state if you support recursive importation. JB: The semantics is the same as in OWL. I added a note about this. | S2.6 The specification of mediators is rather vague. JB: I added a reference to WSMO D2 and tried to make it a bit more clear. | S2.7 "implicitly anded" - I would say "explicitly conjoined" (anded is | rather ugly). Moreover, given that you don't have any "complete" | definitions, conjoining the superconcepts is superfluous - a set of | superconcept statements is completely equivalent to a single conjoined | one. JB: fixed. | You should also say something here about the semantics of attribute | specifications (even though we find out later). JB: fixed. | You say that "We do not allow complex concepts definitions as | superconcepts". This isn't quite true - attribute specifications are | complex concepts. JB: indeed, attribute specifications are complex concepts in the translation to OWL, but not in WSML-Core. We see concepts and attributes as conceptually very different elements and therefore, I would not want to say that an attribute definition is a complex concept. | S2.8 "specialization of a direct super-relation" - do you really mean | specialisation or specification? Also, this makes it sound as though | there can only be one such super-relation, which is not the case. JB: fixed | S2.10 Axiom definitions. See general comments above. JB: fixed. | S4 "The table shows..." is repeated. JB: fixed | S5 the list of reasons for use case problems ends with "equality", | with no explanation as to what this is about. JB: fixed | [1] Benjamin N. Grosof, Ian Horrocks, Raphael Volz, and Stefan | Decker. Description logic programs: Combining logic programs with | description logic. In Proc. of the Twelfth International World Wide | Web Conference (WWW 2003), pages 48-57. ACM, 2003.
$Date: 2004/08/23 10:28:44 $