review of ODM

(Note I will generally use 1st person plural, so that these comments 
could be sent as WG comments if so desired. While there are just over 50 
individual comments most are editorial in nature, I regret not having 
managed to separate the editorial from the more substantive comments. I 
highlight nine comments at the beginning of the review)

I feel that it may help if one of the authors of our n-ary relations doc 
reviewed page 68/69 of this spec.


We have reviewed ODM dated 05-01-01 including the following sections:
  1,2,3,4,5,6,7,9,10,11,12,16,18

We welcome this specification and believe it will be an important 
contribution to allow UML modellers to make better use of Ontology tools 
such as OWL. Congratulations to the authors.

In the detailed comments below we highlight the following more 
significant comments:


190:
Section 10.2.3 page 72, 2nd para
This paragraph is disingenuous.
While UML might not formally forbid the treatment you take, the reality 
is that UML tools and modellers expect both the closed world assumption 
and the unique names assumption and that these expectations are one of 
the major obstacles that should be being addressed by this 
specification. Elegant philosophizing about a zoo of nulls does not 
constitute a helpful way of addressing the problem.

280:
Section 10.3.2 page 75 5th para
'UML at the M1 ...'
see comment 190.

390:
section 12 (throughout)
overly strong cardinality constraints on some constructs
The OWL DL abstarct syntax and OWL full both permit empty intersections 
and unions, enumerations and dataRanges.
The OWL Metamodel typically requires at least two elements in each. Is 
this deviation from OWL intended?
(e.g. 12.2.12, 12.2.6, 12.4.2)

400:
section 12 (throughout)
OWL DL-isms
The section is presented as being an OWL Full metamodel, but there are a 
number of OWL DL like constraints presented which are not part of OWL Full.
For example the constraints mentioned in
sections 12.2.10, 12.2.9, 12.3.1, 12.3.2, 12.6.1


415:
section 12.2.9 page 100
The complete attribute should be dropped.
It appears in the OWL abstract syntax and the OWL XML syntax but plays 
no role in the more OWL Full like modelling used here.
The sentence describing what it means does not relate to the discussion 
in the OWL Semantics document.


420:
section 12.3.1 page 104
suggest adding inverseFuntional attribute
This is used extensively in OWL Full, e.g.by foaf ontology

430:
section 12.3.1, 12.3.2 page 104
'The default is "false"' is problematic (five times)
A property may be symmetric even when not declared as such ... this 
causes problems with any default value for the symmetric attribute.

440:
section 12.3.2 page 105
last sentence under semantics is:
- an OWL DL restriction
- a syntactic restriction not a semantic restriction
suggest delete






Detailed Comments (numbering deliberately non-consecutive)

5: Section 2 page 37
Are the conformance statements adequately precise.
The W3C Quality Assurance group discuss conformance statements in
http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#specifying-conformance
It may be helpful to improve section 2 on the basis of their advice.


10:
Section 3 page 38
OWL Reference is described as a normative reference, but itself has no 
normative content

20:
Section 3 page 38
OWL Overview is described as a normative reference, but itself has no 
normative content


30:
Section 3 page 38
OWL XML Syntax is described as a normative reference, but itself has no 
normative content

40:
Section 4 is empty
in particular this reviewer could have benefited from having definitions 
of EMOF and CMOF

50:
Section 7.2 page 46
Suggest this information could have been better presented.
In particular the possible values for each perspective could have been 
listed underneath each perspective

60:
Section 7.4.1 page 49
The first two bullet points on the page are unclear.
Is this a high level or a low level?
Is this a large amount or a small amount?
Suggest rephrasing to clarify

70:
Section 7.4.3 page break 50-51
This is non-grammatical, suggest rephrasing.

80:
Section 7.7 table 8 page 53
The linking of requirements to sections felt dubious. Don't many of 
these requirements emerge from more sections than is listed?

90:
Section 7.7 page 53, 54
The text under the table uses different terms from the table
Generic concepts <-> Generic content
structural <-> structure features

Also the term 'abstract syntax' in the text under the table seems 
inappropriate, suggest 'requirements'.

100:
Section 10.2.1 page 65 table 10
Should the heading of the column be "ownedAttribute Properties"

110:
Section 10.2.2 page 65 'represented by names', some individuals in OWL 
are unnamed.

120:
Section 10.2.2 page 66 last sentence before table 15
We believe it is very natural to translate a UML model into OWL and then 
use that as a base for further development. Is the appropriate 
translation mentioned adequately specified? How easy is it to do this?

130:
Section 10.2.2 page 67 table 15
Note that it may be more natural to use xsd:unsignedInt or 
xsd:nonNegativeInteger for the NumEnrolled property

140:
Section 10.2.2 page 66/67 table 15 and text below
perhaps course.code and student.ID would be better mapped to 
owl:DatatypeProperty the text discusses string concatenation.
Notice that OWL individuals are named, if at all, with absolute URIs, 
and that 1234.INFS3101 is not an absolute URI.

150:
Section 10.2.3 page 69
The phrase '(Note that the OWL construct unionOf .... use.)'
is false. Any resources mentioned in such a construct are classes, by 
virtue of such use.

160:
Section 10.2.3 page 70/71
RDF/XML example ...
is muddled and needs to be syntax checked; it could probably benefit 
from the use of XML Entity declarations at least for &xsd;
The following mistakes are evident, there may be others:
   the namespace declaration all duplicate the URIs
   the rdf:datatype attributes do not have values being URIs but have 
illegal use of qnames as values.

The final rdf:resource attribute in the example is messed up.

170:
Section 10.2.3 page 71
suggest spelling minCardinality and maxCardinality with camel case

180:
Section 10.2.3 page 71
Incorrect: 'is optional (or partial) for that class'
The property cannot be used for that class.

190:
Section 10.2.3 page 72, 2nd para
This paragraph is disingenuous.
While UML might not formally forbid the treatment you take, the reality 
is that UML tools and modellers expect both the closed world assumption 
and the unique names assumption and that these expectations are one of 
the major obstacles that should be being addressed by this 
specification. Elegant philosophizing about a zoo of nulls does not 
constitute a helpful way of addressing the problem.
See comment 280.

200:
Section 10.2.3 page 72 5th para:
'must be type compatible'
not quite true, if they are not type compatible then the property is emtpy

200:
Section 10.2.3 page 72 6th para:
owl:hasValue is a more natural way of achieving this goal

200:
Section 10.2.3 page 72 6th para, final phrase:
'is common to all instances of A' is slightly misleading, the property 
remains a property of the class and is not a property of the instance

210:
Section 10.2.3 page 72 last para:
'OWL does not have a comparable feature'
We believe owl:AnnotationProperty may be such a comparable feature

220:
Section 10.2.4 page 73 table 18
Suggest RDF:Property rather than RDF:Properties

230:
Section 10.3.1 page 74
typo subClassOf not subclassOf

240:
Section 10.3.1 page 74
possible typo equivalentClass not EquivalentClass
maybe with rephrasing to avoid sentence initial position.

250:
Section 10.3.1 page 74 example
Is incorrect it also needs a someValuesFrom restriction since the text 
says: 'if we have an individual which has the property locatedIn...'

260:
Section 10.3.1 page 75 last para
Should the tense 'will not' be replaced with 'does not'

270:
Section 10.3.2 page 75 4th para
unclear suggest
Two classes can be stated to be equivalent
(equivalentClass) and two properties can be stated to be equivalent 
(equivalentProperty). Equivalent classes have the same members,
equivalent properties relate the same pairs.

280:
Section 10.3.2 page 75 5th para
'UML at the M1 ...'
see comment 190.

290:
Section 11.1.2 page 78
A note should be added explaining how rdfs:Class and rdf:Property are 
abbreviations for URIs using conventional namespace prefixes and 
concatenation. This is not familiar to non-SW people. This is worse 
because syntactic rdfs:Class and rdf:Property both follow the URI 
syntax, but that that isn't the URI that is intended.

300:
Section 11.2.3 page 80
I think the inherited URI attribute should be obligatory for 
RDFSDatatype, it's worth checking the phrasing in the RDF Semantics 
document.

310:
Section 11.2.5 page 81
The text describing the uri attribute.
The "is" is a bit too strong.
Suggest
It may be constructed from the namespace and localName of the RDF 
resource (if both are present), and, in most cases, the namespace and 
localName may be constructed from the uri.

320:
Section 11.2.5 page 81
Is it possible to constrain the localName to be an NCName?

330:
Section 11.2.7 page 82
It may be a better model to have a datatype: RDFSDatatype attribute 
rather than the datatypeURI: String attribute. The URI is merely the 
syntactic representation, both in the RDF abstract and RDF/XML concrete 
syntaxes, the underlying idea is that the typed literal is linked with a 
datatype.

340:
Section 11.4.4 page 86
We note that discussion of rdf:_1 rdf:_2 and rdfs:member has been omitted.

350:
section 11.6.1 page 88
Typo: RDFsubbject should be RDFsubject

360:
section 12.2 page 96 Figure 14
Suggest replacing RDFSLiteral box with typedliteral box, since all the 
legal values are xsd:nonNegativeInteger

370:
section 12.2 pages 96-103
Suggest reordering by a top-down left-to-right tree traversal of the 
diagram, with a table at the beginning giving an alphabetic listing of 
the classes and the sections in which they are discussed.
This will give a more natural reading path from start to finish of the 
section.

380:
section 12.2.9 page 101 final para
Should the ODM mandate naming conventions for owl:Thing and owl:Nothing 
at the model level to promote interoperability?

390:
section 12 (throughout)
overly strong cardinality constraints on some constructs
The OWL DL abstarct syntax and OWL full both permit empty intersections 
and unions, enumerations and dataRanges.
The OWL Metamodel typically requires at least two elements in each. Is 
this deviation from OWL intended?
(e.g. 12.2.12, 12.2.6, 12.4.2)

400:
section 12 (throughout)
OWL DL-isms
The section is presented as being an OWL Full metamodel, but there are a 
number of OWL DL like constraints presented which are not part of OWL Full.
For example the constraints mentioned in
sections 12.2.10, 12.2.9, 12.3.1, 12.3.2, 12.6.1

410:
section 12.2.4 page 98
It is probably worth specifying that the elements of an enumerated class 
are not necessarily distinct and no unique names assumption applies

415:
section 12.2.9 page 100
The complete attribute should be dropped.
It appears in the OWL abstract syntax and the OWL XML syntax but plays 
no role in the more OWL Full like modelling used here.
The sentence describing what it means does not relate to the discussion 
in the OWL Semantics document.
See comment 480

420:
section 12.3.1 page 104
suggest adding inverseFuntional attribute
This is used extensively in OWL Full, e.g.by foaf ontology

430:
section 12.3.1, 12.3.2 page 104
'The default is "false"' is problematic (five times)
A property may be symmetric even when not declared as such ... this 
causes problems with any default value for the symmetric attribute.

440:
section 12.3.2 page 105
last sentence under semantics is:
- an OWL DL restriction
- a syntactic restriction not a semantic restriction
suggest delete

450:
section 12.4.1 page 106
these slots are curiously absent from the RDFS metamodel.

460:
section 12.4.2 page 107
could Individual be named OWLThing?

470:
section 12.5 figure 17 page 109
owl:DataRange is not a subclass of RDFSDatatype

480:
section 16.2.1 Table 39 page 178
The complete attribute is not listed.
Suggest dropping complete attribute from section 12
See comment 415

490:
section 18
Is this specification adequately detailed for implementors of UML tools 
to achieve interoperability? (This is intended as a genuine question 
which is best answered by such implementors).

Received on Thursday, 27 January 2005 16:05:02 UTC