W3C home > Mailing lists > Public > public-webont-comments@w3.org > May 2003

Fwd: Jena comment: Syntax Checker Implementation Report]

From: Jim Hendler <hendler@cs.umd.edu>
Date: Mon, 12 May 2003 09:10:10 -0400
Message-Id: <p05200f1dbae54d65cb44@[]>
To: public-webont-comments@w3.org
Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>

This comment is from the Jena team as a LC comment.  Jeremy Carroll 
will serve as the spokesmen for this group w/respect to this comment.

Jeremy, we will get you a response as soon as we can.

>This is a comment on OWL Test Cases and Last Call Comment on OWL S&AS.
>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:
>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
>/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).
>**Comment 2**
>+ *A* seems unnecessarily complex
>    Do these constraints  on owl:disjointWith have to be as complicated as
>  they are?
>**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.
>**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.
>- allowing user defined OntologyProperty's with annotations with an 
>abstract syntax axiom
>**Comment 5**
>We did not work directly from the WD, and cannot imagine how one 
>might easily do so. We found the tables in
>considerable more accessable than the mapping rules, and suggest that these
>tables should be included in the OWL recommendation.
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
Received on Monday, 12 May 2003 09:10:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:33 UTC