WSML Issues List

Last update: $Date: 2007-01-19 14:52:43 $


All comments refer to WSML D16.1v0.2, final draft:
http://www.wsmo.org/TR/d16/d16.1/v0.2/

The current draft of WSML D16.1v0.21 can be found at:
http://www.wsmo.org/TR/d16/d16.1/v0.21/

List of Outstanding Issues

id Description Target version

Issues for v0.21

6 Equality in translation to XML

The translation to XML (i.e., definition of the XML syntax) does not treat the built-in form of (inequality), namely: unification, equality and in-equality. Furthermore, no URIs have been defined for these operators.

Appendix C will define the URIs for these operators:

unification: wsml#equal
inequality: wsml#inequal
user-defined equality: wsml#strongEqual

The definition of the XML syntax will take these into account

done
v0.21
7 Implementing the erratum to D16.1v0.2

The erratum to D16.1v0.2 should be fully implemented.

done
v0.21
11 Using anyURI for WSML IRIs in the XML Schema

The XML Schema datatype 'anyURI' can be used in the XML Schema definition of the WSML XML syntax for the type wsmlIRI.

done
v0.21
12 lhs and rhs in WSML-Core definition

The definition of the WSML-Core logical expression syntax should have a short note on what 'lhs' and 'rhs' stand for.

done
v0.21
13 Definition of molecules

'molecules' are used, but not defined

done
v0.21
14 Implementing bug-fixes doen in WRLv1.0 document in WSMLv0.21 document

done


Major changes wrt. previous version of WSML (v0.2):

- WSML-Rule now allows full Lloyd-Topor
- WSML-Rule now allows unstratified negation with well-founded semantics

Remaining differences between the ontology part of WSML-Core/Flight/Rule and WRL-Core/Flight/Full:
- WRL partly uses RuleML for its XML syntax for logical expressions, whereas WSML uses its own format
- Namespaces, and thus all keywords, are different
v0.21
9 Error for invalid IRIs

It should be noted in the document that if any symbol used in place of an identifier is in fact not a valid identifier (e.g., sQNames with non-existing namespace), the document is not valid WSML.

done
v0.21
17 Nesting of implication in the head in WSML-Flight/Rule

It is currently possible to nest implication in the head in WSML-Flight/Rule rules.  This should be disallowed

done
v0.21
18 Equality operator

The equality operator (:=:) is not included in the grammar

done
v0.21
20 Inferring role of identifier from context (editorial)

it should be more descriptive that you can infer the type of entity that an id represents by its position in a molecule (confuses people at moment).

Done. Note added in definition 2.3
v0.21
21 naf on non-atoms

Currently, we allow default negation ('naf') on non-atomic formulae in WSML-Flight/Rule, but do not specify how this is to be rewritten (for the safety condition and semantics) to negation on atomic formulae

Resolution: we specify how to rewrite negation on complex formulae a la Lloyd-Topor

done
v0.21
24 Missing transformation rules for naf on non-atomic formulae for checking WSML-Flight safety condition

The section which defines the WSML-Flight logical expression syntax defines a number of transformations which have to be done before the safety condition can be checking. These transformation are incomplete, because they do not deal with 'naf' on non-atomic formulae.

Resolution: add transformation rules

done
v0.21
25 Unused and outdated references

Many references in the section 'references' are outdated or not used in the document.


done. Unused references are removed and outdated references have been updated
v0.21
27 Semantics of restrictions on relation parameters undefined

it is not defined in chapter 8 what
the semantics of a parameter restriction (within relations like
distance(ofType city, ofType city, ofType _integer) is. This is an omission in Table 8.1.
v0.21

Issues for v0.3

1 Possible future extensions

The possible future extensions are:

- introducing namespaces as a separate concept. Right now, namespaces do not have a status in the language and their only function is to make it easier to write IRIs. A possible future extension is to treat identifiers as tuples <namespace, localname>. See also issue 6.
resolution: skip the namespaces as concepts
- External built-ins? It is not yet clear whether external built-ins will be included in the current version. See also issue 14
resolution: implementation issue
- non-inheritable attributes (as in F-Logic) have been identified as a possible future extension. With non-inheritable attributes it is possible to create truly local attributes; a non-inheritable attribute is not inherited by any subconcepts
resolution: possible future extension; default values
- Switches to enable/disable particular features (this mostly applies to WSML-Rule). PDDL (Planning Domain Definition Language), for example, has the possibility to say which features of the language are used in a particular specification. Also forum-flogic will most likely have such a system. Such a switch could be used for at least the following features: enabling equality in the head (issue 16) and default evaluation of evaluable functions (issue 15).
resolution: skip features
- Allowing built-in functions as term constructors (see issue 15)
resolution: disregard
- Special syntax for defining new evaluable functions, for example (example by Michael K):
defineFunction _f(X) = Y:
pqr(X,Y) :- body.

resolution: disregard
- path expressions; the semantics of path expressions in FOL would need to be defined and also of path expressions in the head of LP rules (issue 22)
resolution: we want to have them at least in the body, we decide later
- local OIDs (issue 27)
resolution: use '$' in front of local OID
- parameterized modules
resolution: there are no modules at present, skip for the moment.
- giving elements of the conceptual syntax (such as non-functional properties, used mediators and imported ontologies) a status in the logical
language so that all elements of the language can be accessed through a single query mechanism and no specific APIs are required
for accessing these elements
resolution: resolved in wsmo.
- using '@pre' in the postcondition of a capability to refer to the pre-state of a predicate
resolution: no.
- nominals in WSML-DL
resolution: no.
- named parameters for predicates and functions
resolution: no.
v0.3
2
Datatype functions/operators

Currently, only version few datatype functions and comparators have been defined; only some for strings and integer. For example, comparators for dates are missing.This is to be resolved.
resolution: define comparators for complex data types - not necessary for next version of wsml
v0.3
3 Defining 'datatype wrappers'

The term 'datatype wrapper' is used (section 2.1.2), but never defined
resolution: to be implemented in the next version
v0.3
4 Defining 'object constructors'

The term 'object constructor' is used (def. 2.1), but never defined
resolution: to be implemented in the next version
v0.3
5 Interface and capability as stand-alone entities

It is not apparent from the current syntax(es) that capabilities and interfaces can be defined in a stand-alone fashion (i.e. not in the context of a goal or web service). It should be evaluated which entities can be defined in a stand-alone fashion and the syntax, as well as the textual description in the reference document, should reflect this (i.e., should facilitate stand-alone specification of these entities).
resolution: to be implemented in the next version
v0.3
8 Identification of datatypes

In WSML v0.2, datatypes are identified as members of the (built-in) concept _datatype (= wsml#datatype). However, since datatypes are treated as unary predicates in WSML-Core and WSML-DL, this might give some semantic problems.
resolution: remove from wsml that they are member of 'wsml#datatype'; up to the implementer
v0.3
10 Semantic incompatibility of attributes/relations between WSML-Core/DL and WSML-Flight/Rule

WSML-Core and DL treat attributes and (binary) relations both as binary predicated, whereas WSML-Flight/Rule treat attributes as (many-valued) F-Logic methods (with 0 arguments).
The same holds for memberOf and subConceptOf statements. In WSML-Core/DL these are ground atoms of unary predicates and (material) implications between unary predicates, respectively, whereas in WSML-Flight/Rule these are F-Logic class membership and subclass molecules, respectively.

The relationships between the two styles of modeling, as well as the exact semantic incompatibilities, have to be mapped out and dealt with.
resolution: done - see d28.3
v0.3
15 User-defined datatypes

It is often convenient to define datatypes in terms of existing datatypes.
resolution: skip this for the moment
v0.3
16 Two meanings of anon IDs

We should stop to use anon ids with two different semantics:
a) as IDs for top level concepts where they are replaced by the locator of the document (which is not well defined)
b) as real anonymous ids.

using a symbol in 2 different meanings is not good to a language.
resolution: disallow annon id for top level elements
v0.3
19 Semantics of instances without concept membership

WSML allows instances which are not members of a particular concept. In DLs, individuals are always member of a top concept. There is no top concept in WSML. The semantic( incompatibilitie)s of instances w/o concept membership should be evaluated across the different variants.
resolution: a) top level element - it can be specified as 'a ofType {}' b) semantics need to be updated disallow annon id for top level elements
v0.3
22 Inheritance of attributes over multiple namespaces

If a concept inherits attributes from a superconcept in a different namespace, these attribute remain in this different namespace. This might be confusing to the user.

For example:

concept a#foo
  a#att1 ofType a#bla1

concept b#bar subConceptOf a#foo
  b#att2 ofType b#bla2


Now, b#bar has two attributes:
  a#att1 ofType a#bla1
  b#att2 ofType b#bla2
resolution: we decided not to have namespaces as concepts so we skip this one
v0.3
23 ambiguous identifier

At some place in the syntax (e.g. useMediator) one can not infer the type of entity an identifier stands for. This is at least problematic for some tool support.

Example: useMediator, nfp-value.
resolution: skip this for the moment
v0.3
26 Specifying the type of an attribute is mandatory

It is currently mandatory to specify the type of an attribute when defining an attribute for a concept. However, there are cases where it is desirable to specify attributes without a type, especially in more generic ontologies. One possibility to introduce untyped attribute definitions might be to define a top concept.
resolution: resolved see issue 19
v0.3
28 Disallowing the use of the same relation/function symbol with different arities

WSML currently allows the use of the same relation or function symbol with different arities. This means that a relation of function is not just identified by its identifier, but also by the arity. This can be confusing to the user, especially in the case of inheritance of constraints on parameters. For example:

relation measurement(ofType Location, ofType Location, ofType int,
ofType String)
relation distance/3 subRelationOf measurement
relationInstance distance(ham, muc, 12.20)

this would would imply
relationInstance measurement(ham, muc, 12.20)

but not entail that the KB is inconsistent, since the constraints are defined on measurement with arity 4.
The question is whether we want to disallow the use of the same predicate/function symbol with different arities. This is common in classical logics and in databases, but Prolog typically allows different arities for a symbol.
resolution: no reason for this
v0.3
29 The description of "inverseOf"

The description of "inverseOf" for attributes states:
"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."
This does not explicitly say that if att1 is defined as an inverseOf att2, then att2 is also an inverseOf att1; i.e. that inverseOf is a symmetric relationship between attributes. For example, att1 being "sonOf" and att2 being "parentOf" fits the above description, but sonOf is not the inverse of parentOf.
I'd suggest clarifying this to indicate that inverseOf is a symmetric relationship between attributes.
resolution: fix in the text
v0.3
30 Possible new keyword: "subAttributeOf"
We have a language construct "inverseOf" which relates two attributes such that the specification of either attribute implies that the other attribute holds for the same arguments in the opposite order. But we lack a language construct that says that if attribute 1 relates two arguments attribute 2 holds for the same arguments in the same order.
An example use:
  concept Human
   hasRelative symmetric impliesType Human
   hasChild subAttributeOf hasRelative
would allow the system to determine:
    Henry hasRelative Elizabeth
and
    Elizabeth hasRelative Henry
given
  instance Elizabeth Woman
   hasChild hasValue Henry
Note that for a subattribute, any impliesType or ofType should be copied from the superattribute, although specification of a more specific type such as Man instead of Human should be allowed.
resolution: same syntax as inverseOf
v0.3
31 Attribute values in conceptual syntax
According to the current definition in D16.1v0.21, the values of attributes of instances in the conceptual syntax are allowed to be any term. This should be restricted to IRIs, data values and unnumbered anon IDs.
resolution: we implement this
v0.3
32 Adding HiLog to WSML-Rule

resolution: we don't need it.
v0.3
33 More readable translation tables
I must have gotten lost in those att_id and Y mixed symbols on my first reading of the definition. Let me try to suggest a rephrasing to the axiomatic definition so that it's clearer at the first glance: ?(inverseOf(Inv), X, Att) : ?x memberOf X and ?x[Att hasValue ?y] implies ?y[Inv hasValue ?x]. ?x memberOf X and ?y[Inv hasValue ?x] implies ?x[Att hasValue ?y]. Note that I use similar names for similar things here (Att and Inv, as opposed to Y and att_id) and that I don't start variable names with y, instead the usual x,y,... sequence is kept in both rules. It says exactly the same things, but the renaming would be beneficial for people with less skill in reading such things than that possessed by the authors of D16.1. 8-)
resolution: writing issue
v0.3
34 Context of nfps not clearly defined
see thread http://lists.deri.org/mailman/private/wsml/2006-February/001361.html
The wsml human readable syntax suggests that nfps are are attached to to the definition of some wsml element (concept, instance, etc). However it is unclear how to handle nfps e.g. in the case where a concept and an instance have the same id, similarly it is not clear what happens if one concept has 2 definitions with different nfps.
resolution: solved by the proposal on nfps
v0.3
35 attribute features on attributes with a data type in its range
Editorial: Currently it is not clear from the spec if this is allowed or not, it should be better clarified, certainly WSML-Core and WSML-DL, this cannot be allowed.
resolution: Attribute features on attributes with a data type in its range - just editorial
v0.3
36 giving wsml annotations a logical meaning so that they can be accessed through a single query mechanism and no specific APIs are required for accessing these elements

In WSML telecon on 2006/09/13 we have agreed to change npfs which are not related to service non-functional properties to the better suited term "annontation" in the conceptual sytax. In this context we also resolved the issue on how to treat these logically in the language of WSML:

We agreed to translate annotations such as dc#creator, etc. from the conceptual syntax as follows:

concept c1
dc#creator "Holger" 

is logically treated as:

_annotation(c1,wsml#concept)[dc#creator hasValue "Holger"].

where _annotation is a new defined function in WSML. We remark that this special case of function symbols which (when only occurring from the conceptual syntax)only create ground contructed terms and no arbitrary nesting offunction symbols is also compatible with low WSML variants such as WSML Core which disallow the general use of function symbols. This is due to the fact that these special function symbols rather play the role of skolem functions here that cannot appear arbitrarily. A slight drawback is that this also disallows querying of these annotations in WSML Core, probably, or at least we have to define this cautiously.


resolution: Need to be implemented except annotations for annotations
v0.3
37 Allowing (nested) molecules in attribute values.

We agreed in the WSML telecon on 2006/09/13 to allow nested molecules such as:

  service s1
     dc#creator http://www.holger.ex/me[
           foaf#name hasValue "Holger Lausen",
           foaf#knows hasValue  http://www.michael.ex/me[
                  foaf#name hasValue "Michael Kifer"]]

in attribute values of the conceptual syntax as a shortcut for defining complex objects in attribute values in a separate ontology. We need to resolve, however

  1. The namespace ontology where the reulting instance definitions belong to.
  2. We agreed that such nesting shall not be allowed in WSML core.
  3. Preobably we need to refine/revisit the definition of nested molecules (currenctly, I think it is not mentioned that nesting can be recursive as in the example above.

resolution: Need to be implemented (nested molecules are assertions of facts)
v0.3
38 Correct treatment of Dublin core

Related to the example in issue 37: Strictly speaking attributes from Dublin core such as dc#creator allow only string values, they were not conceived to hold URIRefs or object Ids. For that reason for instance, FOAF introduced a new property foaf#maker which has a foaf#agent as its range, in order to circumvent this restriction with dublin core. Is this issue covered with our treatment? We do not make this limitation in our use of Dublin core.


resolution: statement in the issue is incorrect
v0.3
39 WSML-Flight/Rule: Incomplete Logical Expression Syntax Definitions (1)

Add to Definition 5.4 and Definition 6.4 that the Logic Programming implication symbol ':-' is not needed. If it is missing, a formula is in Head.


resolution: writing issues
v0.3
40 WSML-Flight/Rule: Incomplete Logical Expression Syntax Definitions (2)

Definition 5.4 and Definition 6.4 say that for formulae 'α implies β', 'α impliedBy β' and 'α equivalent β', both α and β need to be in Head.

Looking at the following example, we see, that this definition is not complete:

  ?x memberOf Human or ?x memberOf Animal implies ?x memberOf Mammal.
is invalid, as the disjunction is not allowed in the head. Now we can apply the following transformation steps:
Step 1: ?x memberOf Human or ?x memberOf Animal implies ?x memberOf Mammal :- true.
Step 2: ?x memberOf Mammal :- (?x memberOf Human or ?x memberOf Animal) and true.
Step 3: ?x memberOf Mammal :- ?x memberOf Human or ?x memberOf Animal.
The formula we got in Step 3 is perfectly valid.
The fact that we can use the transformation steps defined on page 35 (d16.1 v0.21), means that the above stated definitions are insufficient.

The definitions should say that for formula 'α implies β', β must be in Head and and α may be in Body. For formula 'α impliedBy β', α must be in Head and β may be in Body. For formula 'α equivalent β', both α and β may be in Body.


resolution: writing issues
v0.3
41 WSML-DL definition problem - Universal quantification

Currently, a formula like

  neg(?x memberOf PlaceInAustria and ?x memberOf PlaceInUs) implies true.
is valid WSML-DL. This formula is equivalent to
  forall ?x (neg(?x memberOf PlaceInAustria and ?x memberOf PlaceInUs) implies true.
which is not valid WSML-DL any more.

The specification says that all variables that are not explicitly quantified, are implicitly universally quantified. So it should be possible to write an explicit universal quantification.


resolution: will be implemented by Nathalie
v0.3
42 WSML-DL definition problem - Top level implications

Currently, a formula like

  forall ?y (?x[father hasValue ?y] implies ?y memberOf Child).
is not valid WSML-DL. But this formula is equivalent to
  forall ?y (?x[father hasValue ?y] implies ?y memberOf Child) implies true.
which is valid WSML-DL. It should be possible to write semantically correct formulae without this required top level implication.


resolution: will be implemented by Nathalie
v0.3
43 Possible WSML-DL definition extension - Qualifiers

The usage of WSML-DL is not always very user-centric. This regards for example cardinality qualifiers. In WSML-DL cardinality constraints are not allowed in the conceptual syntax.
However they are allowed in Description Logics or OWL. In Description Logics, both cardinality and qualified cardinality restrictions are allowed:

  ≤nR,  ≥nR,  ≤nR.C,  ≥nR.C
In OWL, only simple cardinality restrictions are allowed:
  maxCardinality, minCardinality
In WSML-DL cardinality constraints can be expressed by defining respective axioms. These are quite complicated and not user-friendly to use:
The following logical expression defines that a bike has at most two wheels (maxCardinality in OWL):
  ?x memberOf Bike implies forall ?W1, ?W2, ?W3 (?x[hasWheel hasValue ?W1] and ?x[hasWheel hasValue ?W2] 
    and ?x[hasWheel hasValue ?W3] and ?W1 memberOf Wheel and ?W2 memberOf Wheel and ?W3 memberOf Wheel 
    implies ?W1 :=: ?W2 or ?W1 :=: ?W3 or ?W2 :=: ?W3).
To express that the bike has exactly two wheels, we would need to add logical expression that defines that a bike as at least two wheels (minCardinality in OWL):
  ?x memberOf Bike implies exists ?W1, ?W2, ?W3 (?x[hasWheel hasValue ?W1] and ?x[hasWheel hasValue ?W2] 
    and ?x[hasWheel hasValue ?W3] and and ?W1 memberOf Wheel and ?W2 memberOf Wheel and ?W3 memberOf Wheel 
    and neg(?W1 :=: ?W2) and neg(?W1 :=: ?W3) and neg(?W2 :=: ?W3)).

These expressions could be expressed much simplier, by allowing to express cardinality constraints within the WSML-DL conceptual syntax. The following approach, analogous to WSML-FLIGHT/RULE is not allowed, as the cardinality features of attributes are defined locally to a concept, instead of being defined globally, as it is done in Descriptions Logics and OWL:

  concept Bike
    hasWheel ofType(2) Wheel
  concept Wheel
A possible way of nevertheless expressing cardinality restrictions could be in allowing cardinality restrictions on relations:
  relation hasWheel(2)(impliesType Bike, impliesType Wheel)

Also qualified cardinality restriction can be expressed in WSML-DL by the use of respective axioms. The following logical expression defines that a normal hand must have 5 fingers and one of them must be a thumb:

  ?x memberOf NormalHand implies exists ?F1, ?F2, ?F3, ?F4, ?F5 (?x[hasFinger hasValue ?F1] and
    ?x[hasFinger hasValue ?F2] and ?x[hasFinger hasValue ?F3] and ?x[hasFinger hasValue ?F4] and 
    ?x[hasFinger hasValue ?F5] and ?F1 memberOf Finger and ?F2 memberOf Finger and ?F3 memberOf Finger 
    and ?F4 memberOf Finger and ?F5 memberOf Finger and neg(?F1 :=: ?F2) and neg(?F1 :=: ?F3) and 
    neg(?F1 :=: ?F4) and neg(?F1 :=: ?F5) and neg(?F2 :=: ?F3) and neg(?F2 :=: ?F4) and neg(?F2 :=: ?F5) 
    and neg(?F3 :=: ?F4) and neg(?F3 :=: ?F5) and neg(?F4 :=: ?F5)) and forall ?F1, ?F2, ?F3, ?F4, ?F5, ?F6 (
    ?x[hasFinger hasValue ?F1] and ?x[hasFinger hasValue ?F2] and ?x[hasFinger hasValue ?F3] and 
    ?x[hasFinger hasValue ?F4] and ?x[hasFinger hasValue ?F5] and ?x[hasFinger hasValue ?F6] and
    ?F1 memberOf Finger and ?F2 memberOf Finger and ?F3 memberOf Finger and ?F4 memberOf Finger and 
    ?F5 memberOf Finger and ?F6 memberOf Finger implies ?F1 :=: ?F2 or ?F1 :=: ?F3 or ?F1 :=: ?F4 or 
    ?F1 :=: ?F5 or ?F1 :=: ?F6 or ?F2 :=: ?F3 or ?F2 :=: ?F4 or ?F2 :=: ?F5 or ?F2 :=: ?F6 or ?F3 :=: ?F4 
    or ?F3 :=: ?F5 or ?F3 :=: ?F6 or ?F4 :=: ?F5 or ?F4 :=: ?F6 or ?F5 :=: ?F6) and exists ?T1 (
    ?x[hasThumb hasValue ?T1] and ?T1 memberOf Thumb and ?T1 memberOf Finger) and forall ?T1, ?T2 (
    ?x[hasThumb hasValue ?T1] and ?x[hasThumb hasValue ?T2] and ?T1 memberOf Thumb and ?T2 memberOf Thumb 
    implies ?T1 :=: ?T2).
Again, the following approach, by allowing cardinality constraints on concept attributes, is not allowed, and would not yet be complete:
  concept NormalHand
    hasFinger ofType(5) Finger
    hasThumb ofType(1) Thumb
  concept Finger
  concept Thumb subConceptOf Finger
  
I don't have a valid solution to this issue, but any solution would need a change in the WSML-DL syntax.


resolution: will be implemented by Nathalie
v0.3
44 Error in WSML-DL Logical Expression Syntax Definition

In Definition 4.2., the description:

  forall Var1, ..., Varn+1 G1 and ... and Gn+1 and F1 implies neg (Var1 :=: Var2) 
    or ... or neg (Var1 :=: Varn+1) or ... or neg (Varn :=: Varn+1)
must be:
  forall Var1, ..., Varn+1 G1 and ... and Gn+1 and F1 implies (Var1 :=: Var2) 
    or ... or (Var1 :=: Varn+1) or ... or (Varn :=: Varn+1)
without the negations.


resolution: need to be implemented
v0.3
45 Replace WSML to OWL mapping table.

The mapping in Section 11.1, from WSML-Core to OWL DL abstract syntax should be replaced by the mapping from WSML-DL to OWL DL abstract syntax.


resolution: need to be implemented
v0.3


Table Legend

id
Persistent issue number
Description
Short description of issue, possibly including link to origin of issue
Target version
Identifies the target version for resolving the issue (v0.21 or v0.3). v0.21 is the bugfix version of v0.2 and only minor bugs will be fixed.

Maintained by Jos de Bruijn.