Re: comments on abstract syntax for OWL (Lite)

From: "Carlo Wouters" <cewouter@cs.latrobe.edu.au>
Subject: comments on abstract syntax for OWL (Lite)
Date: Sun, 8 Sep 2002 20:35:41 -0400 (EDT)

> 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])

It is rdf:Property.

> 
> Typos [AS]
> ----------
> - in the mapping table section 6
> 
> 	Class( <classID> 
> 	      [partial] 
> 	      [complete] 
> 	      <description1> ... <descriptionn>) 
> 
> => No space between the '<descriptionn>' and the ')'

Spaces are not significant in this context, so no change is necessary.
That said, in other similar places I have a space, so I'm adding one here.

> 	<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'

Correct.  I also had owl:OneOf in one other place.

> 	[<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>'

Correct.  This one doesn't really matter, but the next one, under
differentIndividualFrom does matter. 

> 
> 	_: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.

Correct.  

> 
> 	  _: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)

Hmm. I hadn't seen them.  Thanks for pointing them out to me.

> 
> 	 Class(ex:Student complete ex:Person
> 	                   restriction(ex:enrolledIn
> allValuesFrom=ex:School minCardinality(1))
> 
> => missing the final closing bracket at the end

Correct.


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

It should be [ complete | partial ] throughout.  In the abstract syntax,
for now, it is required to say one or the other.  The problem is that the
natural ``default'' would be partial, but this encourages sloppiness.

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

This would not be correct.  A typical partial definition is something like

Class ( Foo partial Person restriction(friend minCardinality=3) )

> 
> - 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 )

That is the current situation.

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

This would also work, although OWL Lite is supposed to be a constrained
sublanguage, so right now only the useful versions are allowed.

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

This is allowed, from the third option for <cardinality>.

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

is currently not allowed.  I suppose that it should be allowed, but the
abstract syntax is not now an exchange syntax, so disallowing the
wrong-order cardinalities doesn't seem to be a serious problem.

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

Hmm.  Correct.  I've changed to the = construction throughout.

> 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))

I believe that multiple allValuesFrom and cardinalities are allowed
throughout.  The first mapping for restriction breaks up all the
components, which are then treated separately.

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

The purpose of the abstract syntax is yet unclear.  At a minimum, it is a
tool for the working group to use in discussing OWL.  It might also be used
by OWL users as a nicer syntax, but this is not yet approved.  It also
might be used as a presentation syntax by editors, but this is definitely
not approved yet.
> 
> [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.

No problem.  Thanks for your comments.

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


Peter F. Patel-Schneider

Received on Monday, 9 September 2002 12:57:21 UTC