comments on abstract syntax for OWL (Lite)

Hi, 

I have been going through the documents that have been put up in regards
to OWL and OWL-Lite, and I have several comments/questions/remarks that
I thought are worth sharing (I'll focus mostly on the abstract syntax
working draft here).  I have to admit that I'm inexperienced in this
area, so it is definitely not with great confidence that I bring these
issues forward.  Especially my ignorance in terms of BNF (in whatever
extended form) might mean that my remarks are completely of the mark
there, but after some consideration I decided to share them anyway, as I
might not be the only one misunderstanding these documents, and even
wrong comments might be helpful in targetting the documents towards a
broader (and less knowledgeable !) audience (as I read was one of the
proposed improvements).


small mistakes [RS]
-------------------
- [FS] defines rdfs:Property, while in section 'Property Elements'[RS]
it has namespace rdf. I assume that it should be rdfs, but I might be
wrong (in which case the error is in [FS])


Typos [AS]
----------
- in the mapping table section 6

	Class( <classID> 
	      [partial] 
	      [complete] 
	      <description1> ... <descriptionn>) 

=> No space between the '<descriptionn>' and the ')'


	<classID> rdf:type owl:Class . 
	<classID> owl:sameClassAs _:x . 
	_:x owl:OneOf T(SEQ <individualID1> ... <individualIDn>) . 

=> Should be 'owl:oneOf' (small 'o' for one) instead of 'owl:OneOf'


	[<ID> owl:sameIndividualAs _:x .] 
	_:x rdf:type <classID1> . ... _:x rdf:type <classIDn> . 
	_:x <IDi> T(<value1>) . ... _:x <IDn> T(<valuen>) . 

=> Should be '<ID1>' instead of '<IDi>'


	_:l1 rdf:type owl:List . 
	_:l1 owl:first T(<item1>) . _:l1 owl:rest _:l2 . 
	... 
	_:ln rdf:type owl:List . 
	_:ln owl:first T(<itemn>) . _:ln owl:rest owl:nil . 

=> As discussed by Peter F. Patel-Schneider and Jos de Roo all the
'owl''s should be replaced by 'rdf''s.


	  _:x rdf:type ex::Book .
	  _:x dc:author _:x 1
	  _:x1 ex:name "Fred" .

=> instead of 'ex::Book' it should be 'ex:Book' (one colon)
=> instead of '_:x 1' it should be '_:x1' (no space between x and 1)
=> missing a '.' at the end of the second line
(I've seen these comments - or at least one of them - somewhere in a
mailing list, but I can't seem to find the message anymore, so sorry to
the person who first spotted these mistakes for missing reference)


	 Class(ex:Student complete ex:Person
	                   restriction(ex:enrolledIn
allValuesFrom=ex:School minCardinality(1))

=> missing the final closing bracket at the end



- Questions [AS]
----------------
- 5.1.1. Owl Lite Class Axioms:

	<axiom> ::= Class( <classID> <modality> {<classID>}
{<restriction>} )
	<modality> ::= complete | partial

This seems very strange to me, and similar expressions have been made by
Martin Bryan as well (as a general issue that the notation '{}'
sometimes would make more sense as occuring at least once).

	Class( ex:Book complete ) 	; // this is correct
	Class( ex:Book )		; // this is wrong
	
To me (but as usual, I might be completely wrong) this says it is
impossible to define a Class without providing any details.  Not that
that is a bad thing, I just thought that one was allowed to do that (Of
course it is still possible by saying Class( ex:Book partial owl:Thing),
which is true for all classes).  However, in the mapping in section 6 we
find that the terminals of modality are both made optional :
	
	Class( <classID> 
      		[partial] 
      		[complete] 
      		<description1> ... <descriptionn>) 

All of a sudden Class( ex:Book ) is considered correct.  For that
matter, even Class( ex:Book partial complete ) is correct, which strikes
me as very strange.  My intuition is that the BNF used in the table has
a less strict syntactical impact, but if so, this probably should be
made clearer, as it makes the syntax open to very different
interpretation.
Another one : Class( ex:Book complete partial) is wrong, but Class(
ex:Book partial complete ) is still correct.  In general a lot of -
unnecessary - restrictions on the order of elements are insinuated.
Completely disregarding the order is not possible, as <description> can
be a ClassID as well, resulting in an ambiguity of which <ClassID> is
which.

Would Class( <classID> [partial | complete <description1> ...
<descriptionn>] ) be closer to the truth ? I know it still lacks a
grouping of the modalities (so that the '|' only applies to them), but
I'm not sure how to do that.


- 5.1.2 OWL Lite Restrictions

As noted by Martin Bryan, and acknowledged by Peter F. Patel-Schneider,
the minCardinality and maxCardinality can both have a zero value.  I
assume this will change the syntax to something like:

	<Cardinality> ::= minCardinality( 1 )
			| maxCardinality( 1 ) 
			| minCardinality( 0 ) 
			| maxCardinality( 0 ) 
			| cardinality( 0 )
			| cardinality( 1 )
		
(or maybe introducing <CardinalityOption> ::= 0 | 1 would be a better
solution)

Assuming this to be corrected, I still have following problem with the
<restriction> syntax:

	<restriction> ::= restriction( <datavaluedPropertyID>
{allValuesFrom=<dataRange>}
	                               {someValuesFrom=<dataRange>}
{value=<dataLiteral>}
	                               [<cardinality>] )
	<restriction> ::= restriction( <individualvaluedPropertyID>
{allValuesFrom=<description>}
	                               {someValuesFrom=<description>}
{value=<individual>}
	                               [<cardinality>] )
	<cardinality> ::= minCardinality( <positive-integer> )
	                | maxCardinality( <non-negative-integer> )
	                | minCardinality( <positive-integer> )
maxCardinality( <non-negative-integer> )
	                | cardinality( <non-negative-integer> )

Is it intentional that only one cardinality can be given in a
restriction ? A statement like :

restriction(dc:author allValuesFrom=ex:Person minCardinality=1
maxCardinality=6) 

is incorrect (as I read the syntax specification), and should be defined
in two steps (at least), which seems a bit cumbersome.

	
Ambiguity issues between OWL and OWL Lite
------------------------------------------
- section 6, second example after mapping table.

	Class(ex:Student complete ex:Person
	                   restriction(ex:enrolledIn
allValuesFrom=ex:School minCardinality(1))

'minCardinality(1)' is used here, which has previously been defined
(section 5.1.2) as being part of the OWL Lite syntax.  Because OWL Lite
is said to be a subset of OWL, these OWL Lite syntax can be used in OWL
as well (or is this a wrong assertion ?).  However, the mapping table
states the following:

restriction( <ID> minCardinality=<min> ) 

Doesn't this mean that the 'minCardinality(1)' should read
'minCardinality=1' ? If both are allowed (I thought that any OWL Lite
ontology specification is also a valid OWL ontology specification),
maybe this can be represented in the mapping as well.

Also notice that according to the strict interpretation of the mapping
it doesn't cater for the appearance of an 'allValuesFrom' and a
'minCardinality' in the same restriction.  A more correct (if I
interpret the syntax correctly) statement would be:

	Class(ex:Student complete ex:Person restriction(ex:enrolledIn
allValuesFrom=ex:Scool) restriction(ex:enrolledIn minCardinality=1))
	
Of course I prefer the example as it is given in the document (and so
would most people, I believe), but I can see that the mapping table
grows a lot more difficult when incorporating all these possibilities.
As I mentioned before, maybe the mapping table shouldn't be taken as a
strict syntax mapping (i.e. those are the only ways statements can be
expressed), but rather as examples of how small pieces individually are
mapped (without carrying any implications on how the pieces are allowed
to be fitted together (which can be more accurately defined - and IS
more accurately defined most of the time - in section 5)).  If this is
the case, again, it might prove useful to emphasize that point.



As a more general, and also final, point; a clarification of the
expected or intended usage of the abstract syntax is most welcome, as I
first considered to use it as a more user-friendly and non-graphical way
of interactively letting users construct ontologies, but in its current
form the abstract syntax doesn't seem to be rigorous enough to provide
the users with a unambiguous syntax for doing this.  Maybe this is not
the intention of the abstract syntax at all, so a purpose statement
might shed some light on this.


[AS]: W3C, OWL Web Ontology Language 1.0 Abstract Syntax
(W3C working draft 29 July 2002)
[RS]: W3C, OWL Web Ontology Language 1.0 Reference Specification
(W3C working draft 29 July 2002)
[FS]: W3C, Feature Synopsis for OWL Lite and OWL
(W3C working draft 29 July 2002)


I hope my inexperience hasn't produced too many incorrect assumptions or
misinterpretations, and that this mail is helpful.  My apologies that it
turned out this lengthy.


Regards,


Carlo Wouters


****************************************************
Carlo Wouters
La Trobe University
Dept. of Computer Science and Computer Engineering
Melbourne, Australia
****************************************************

Received on Monday, 9 September 2002 12:16:29 UTC