Proposed reply to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0083.html

Thank you for your comments.

> This is a comment on OWL Test Cases and Last Call Comment on OWL S&AS.
> 
> http://www.w3.org/TR/2003/WD-owl-semantics-20030331/
> http://www.w3.org/TR/2003/WD-owl-test-20030331/
> 
> There are five specific points at the end of this message which we ask the 
> WG to consider.
> 
> We implemented an OWL Syntax Checker, as defined in OWL Test Cases, based 
> on the mapping rules in OWL S&AS.
> 
> The approach used was to:
> 1: compute the imports closure
> 
> 2: follow the triple tables found in:
> 
> http://lists.w3.org/Archives/Public/www-archive/2003Mar/att-0089/m
> 
> and to work from those to iteratively classify every node in the RDF graph
> 
> 3: additional actions are used to check that restrictions, for instance, do
> not have too many components, and that blank nodes are the object of at 
> most one triple
> 
> 4: the syntax checker behaves incrementally in the sense that we can check
> whether any non OWL Lite or non OWL DL constructs have been used
> 
> 5: when all the triples have been processed we have a final check for 
> things like orphan restrictions, untyped nodes etc.
> 
> We have slightly updated the tables.
> (The actual table used can be found at
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jena/jena2/src/com/hp/hpl/jena
> /ontology/tidy/Grammar.java?rev=HEAD&content-type=text/vnd.viewcvs-markup )
> 
> 
> In this process we have not implemented the following:
> 
> A: exact constraints concerning owl:disjointWith
> B: exact constriants concerning owl:equivalentClass
> C: non cyclic restricition on unnamed individuals
> D: allowing blank restriction nodes to have class owl:Class
> 
> C and to some extent A and D are a result of laziness; and we can imagine
> implementing them soon.
> 
> We believe that
> **Comment 1**
> +  *B* is seriously flawed in S&AS and should be fixed.
>      (i.e. the constraints on owl:equivalentClass triples cannot
>     even be articulated let alone implemented, let alone
>     implemented reasonably efficiently).

The constraints on owl:equivalentClass triples can be articulated in terms
of Hamilton paths in the component graphs that are created by considering
only connected groups of blank nodes and named nodes that are connected to
these blank nodes.  Neverthless, this is expensive to implement.

The working group decided on 29 May 2003, as recorded in 
http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0003.html, to
change the mapping for owl:equivalentClass from paths to connected graphs.
This should be much easier to implement. 

This change is reflected in the editor's draft of S&AS of 30 May 2003.

> **Comment 2**
> + *A* seems unnecessarily complex
>     Do these constraints  on owl:disjointWith have to be as complicated as
>   they are?

In the current situation it is difficult to have a different mapping for
owl:disjointWith.  However, there may be a change to the treatment of
unnamed classes in the mapping rules that would allow for a simpler
treatment of owl:disjointWith.  The feasibility of this change is currently
being investigated.

> **Comment 3**
> * *D* is clunky and we ask the group to reconsider both optional triples in
> mapping rules such as:
> 
> restriction(ID maxCardinality(max))
> ==>
> _:x rdf:type owl:Restriction .
> _:x rdf:type owl:Class . [opt]
> _:x rdf:type rdfs:Class . [opt]
> _:x owl:onProperty T(ID) .
> _:x owl:maxCardinality "max"^^xsd:nonNegativeInteger .
> 
> (the owl:Class optional triple is more problematic than the rdfs:Class, 
> since it makes the rule on requiring explicit type for all nodes more 
> complicated.
> owl:Class is a possible explicit type for classID and description nodes, 
> but not for restriction nodes). We suggest removing the optional triples 
> from this rule, and other similar rules.

The current situation is that such blank nodes must be typed with the
appropriate class, here owl:Restriction, and can optionally be typed with
some more-general classes, here owl:Class and rdfs:Class.  To change the
mapping for restrictions would make their treatment needlessly different
from the treatment of similar constructs, such as intersections and unions,
which also have an optional rdfs:Class.

No change in response to this particular comment is anticipated.  There are
potential changes to the treatment of such constructs that would make it
even more desirable to allow for typing with rdfs:Class.

> **Comment 4**
> A further clunkiness was with owl:OntologyProperty.
> Triples such as
> owl:priorVersion rdf:type owl:OntologyProperty .
> are permitted by the grammar iff owl:priorVersion is used somewhere else.
> We have correctly implemented this, but it is surprising.
> 
> We suggest either:
> - removing the term OntologyProperty from the owl namespace and simply
> modifiying the mapping rules that produce these triples to not do so.
> or:
> - allowing user defined OntologyProperty's with annotations with an 
> abstract syntax axiom

The working group decided on 29 May 2003, as recorded in 
http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0003.html, to
add an axiom for ontology properties, with a treatment similar to the axiom
for annotation properties.  This should make the situation here better.

This change will be reflected in an upcoming editor's draft of S&AS.
Changes to other documents may also be required.

> **Comment 5**
> We did not work directly from the WD, and cannot imagine how one might 
> easily do so. We found the tables in
> http://lists.w3.org/Archives/Public/www-archive/2003Mar/att-0089/m
> considerable more accessable than the mapping rules, and suggest that these
> tables should be included in the OWL recommendation.

The S&AS document is, as much as possible, a formal document giving only
what is necessary to define the semantics of OWL.  It is thus not too
likely that such an informative section would be attached to S&AS.
However, there are several documents that have been produced giving a
description of the inverse mapping, and one or more of them may be given
some blessing by the working group.


Again thank you for your comments.  We hope that you will be able to
upgrade your OWL Syntax Checker to handle all of OWL DL and look forward to
hearing information about future versions.


Peter F. Patel-Schneider
Bell Labs Research
Lucent Technologies

Received on Friday, 30 May 2003 09:59:46 UTC