Re: Jena comment: Syntax Checker Implementation Report]

> This is a comment on OWL Test Cases and Last Call Comment on OWL S&AS.

Thank you for your comments.

> 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/2003May/0402.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 as of 30 May 2003,
which says:

--------
S: EquivalentClasses(description1 … descriptionn)

T(S): T(descriptioni) owl:equivalentTo T(descriptionj) . 
 for all <i,j> in G where G is a set of pairs over
 {1,...,n}x{1,...,n} that if interpreted as an undirected graph
 forms a connected graph for  
--------

If you'd like to review this in context, you can take a look at the
editor's draft, in the the "Transformation to Triples" table at
http://www-db.research.bell-labs.com/user/pfps/owl/semantics/mapping.html

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

In the current situation the constraints on owl:disjointWith are required.
There is a proposal to modify the situation, but it depends on some work
that is needed to determine if the modification is feasible.  When the
final determination as to whether to make this modification is made, we
will respond futher.

> **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.  

> **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/2003May/0402.html, to
add an axiom for ontology properties, with a treatment similar to the axiom
for annotation properties.  

This change is reflected in the editor's draft of S&AS as of 30 May 2003,
available at 
 http://www-db.research.bell-labs.com/user/pfps/owl/semantics/
which includes a new axiom of the form 
 OntologyProperty(ontologyPopertyID {annotation})
in the abstract syntax for both OWL Lite and OWL DL, a mapping for this
construct to RDF graphs, and an enhancement of the correspondence proofs to
handle the construct.

> **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.  An informative
description of the mapping rules would thus be somewhat out of place in
this document.  However, the new Appendix E of the OWL Reference, currently
available at http://www.daml.org/2002/06/webont/owl-ref-proposed, has some
rules of thumb as to what is needed in an OWL DL document.  I realize that
this is somewhat different from what you are asking for, but it is
related. 


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 Monday, 16 June 2003 12:24:41 UTC