spec bugs

Now that I've started writing an OWL 1.1 API I'm noticing little things in the 
spec at http://owl1_1.cs.manchester.ac.uk/owl_specification.html. I've been 
working through this over a period of several days, so sorry if this goes 
over things that where covered in the mailing list in the mean time.

The most anoying (and least important) being that in the grammar, URIs are of 
type URI but in the UML, they are of type String. Of course a realisation of 
the UML into your favorite language may well use String for storing the URIs, 
but it also may well not.

section 4.1

individualURI := 'Individual' '(' individualURI ')'
  to
individual := 'Individual' '(' individualURI ')'

Section 4.1 defines Constant in one way in the UML and in another way in the 
grammar. Not sure if this is actually an error (not totaly sure what a UML 
diagram's entailment is), but it is definitely confusing.

Section 4.3 introduces arity for datatype. There's no definition of arity, or 
what it means, or how to use it here. I assume arity must be a non-negative 
integer (or a positive integer if you are dissallowing the zero-length tuple, 
but unit is often very usefull to have about). There's no propper syntax that 
I can see either in the UML or in the grammar for constructing and expressing 
these guys.

Section 4.3 introduces FacetType for restricting datatype values. In the UML, 
this is represented as a string. In the grammar, this is enumerated. The 
values come from the xsd facets, yes? In that case, should we be using a URI 
of the form xsd:<facetType> e.g. xsd:MinLength for these guys? This makes the 
link to the XSD explicit, just as we've done with the datatype URIs. This 
would not affect the enumeration, assuming a function from the enumerated 
values to the URIs. It would change the UML version from String to a URI 
identifying a restriction facet from the XSD spec that is OWL-approved (or 
just use an enumeration again).

Section 5 needs sub-sections like section 6 has. It's too much stuff to have 
no way to refer to bits of it.

Section 5 , all the way through uses class on an association. This is a 
keyword in many languages, meaning that the UML would have to be munged e.g. 
to use clazz or something equally ugly. Also, this uses class and classes to 
link back to Description. The OWL 1 grammar seperated out class and 
description, as does this spec in part and to make class a soft-synonym for 
description is inviting missunderstandings. Is there a better name here, e.g. 
description(s)? Type(s)?

Section 5 figure 6 has some associations with cardinality 2..* e.g. classes on 
ObjectUnionOf. While I understand that it is not very interesting to take the 
union of an empty set or a single item, it does never the less have defined 
semantics. Is this 2..* cardinality a requirement, or a normalization, where 
cardinalities of 1 or of 0 are re-written to another form during 
normalization, for politeness sakes? I'd ask a similar question about 
ObjectOneOf and an empty set of individuals.

Section 5 figure 8 uses cardinality properties on the Object Min/Max/Exact 
Cardinality types. The grammar uses nonNegativeInteger, but the UML just uses 
int. Similar to my comments on URI, some languages may have a native 
non-negative integral type which would be more appropriate than int.

Section 5 figures 9 and 10 have the grammar interspersed with the text in a 
different order to other figures.

Section 6 and 3 define Axiom differently - Section 3 says classAxiom | 
objectPropertyAxiom | ... but provides no UML. Section 6 provides 
deffinitoins for objectPropertyAxiom ... but shows these being directly under 
Axiom in the UML. The description section in Section 5 has a similar 
break-down into types of description, but this is represented by a single 
grammar production and single level of inheritence in the UML. Consistency 
between the two would lower the learning curve.

Section 6.1 uses class refering to description again. 
Section 6.1 Equivalent, disjoint and disjount union all have cardinality on 
the descriptions of 2..* - again, is this a normalised representation 
constraint, or a requirement?

Section 6.2 defines sub-properties and disjoint properties, but not a disjoint 
union of properties. Are unions or properties a DL problem, or is this just 
something that didn't make it in?

Section 6.2 defines subObjectProperties as having cardinality 1..* - is there 
any reasonable interpretation of a property being a super property of a 
zero-length role chain? Sounds like it would collapse properties down onto 
some aspect of description - makes my brain hurt.

Section 6.3 ... you can guess ... cardinalities on disjoint, equivalent - 
required or cannonically-formed?

Section 6.3 does not introduce an inverse functional data property. This would 
be very usefull e.g. when mapping in representations of database tables with 
(foreign) keys. Is there an alternative way to achieve the same outcome?

This document would be helped no end in clarity by providing a single example 
of each axiom, with the grammatical and a human description of what that 
statement means. Perhaps this should go in a sister document? I'm happy to 
contribute to this effort, if others think it's worth while.

Once my Haskell implementation of the OWl 1.1 data-structures is debugged, I 
will post a link to the list. 

Matthew

Received on Sunday, 11 February 2007 21:36:15 UTC