- From: Jan Grant <Jan.Grant@bristol.ac.uk>
- Date: Fri, 9 May 2003 17:13:58 +0100 (BST)
- To: public-webont-comments@w3.org
The following comments are divided up into substantial and editorial
comments (editorial last).
--- owlsas-rdfcore-datatype-denotation
Section 2.1
"In OWL, as in RDF, a datatype denotes the set of data values that is
the value space for the datatype."
- Not true of RDF? A datatype can be treated as a class in RDF - the
class corresponds to its value space, but not the same thing. Strike "as
in RDF"
--- owlsas-rdfcore-equvalent-class
2.3.2.1 BNF for axiom
[[
| 'EquivalentClasses(' description { description } ')'
]]
Other 'equivalentX' productions specify a minimum of two equivalent Xs.
The reason for this production is nonobvious and should be spelled out.
We also note that the rule given in section 3.3 does not cover the
(semantically empty) case of n=1 for the EquivalentClasses(d1 ... dn)
production.
--- owlsas-rdfcore-owl-vocabulary
Section 3.1
Definition of OWL Vocabulary
(Clarification sought) I may have misunderstood, but shouldn't
"rdf:type" be excluded from the definitions of the various "V_x"s ?
--- owlsas-rdfcore-unnamed-ontologies
Section 3.4
Unnamed ontologies: informally, multiple Annontations on an unnamed
ontology don't need to be satisfied by the same "x" according to this
table. Don't think that's right.
--- owlsas-rdfcore-ontology-component-association
Section 4.1
While the abstract syntax naturally associates (via syntactic
nesting) ontologies with all their directives, no such association is
made in the RDF graph expression of the ontology (apart from
Annotations). Therefore, multiple ontologies expressed as an RDF graph
cannot be extracted to produce the component ontologies in the abstract
syntax.
--- owlsas-rdfcore-rdf-translation-opaque
Section 4.1
From a presentation point of view, the translation table in 4.1 seems
overly opaque. However, an alternative compact expression of the
translation into RDF Graph form is not immediately obvious.
---
The following comments are all editorial: since they are trivial, no IDs
have been assigned.
In general, the presentation of the BNF for the abstract syntax is very
well done; the "literate" style is to be commended.
---
Section 2.2
"The second kind of fact is used to make individual identifiers be the
same or pairwise distinct." Nit - same/distinct denotations?
---
2.3 Axioms
[editorial] WG -> working group; don't hyphenate "more-neutral"
---
2.3.1.3
[editorial] "The only information in axiom for them is annotations."
Insert "the".
---
2.3.1.3 & throughout
[editorial] suggest "dataValuedPropertyID" and
"individualValuedPropertyID" (different intercapping)
---
2.3.2.3 Para 1.
[editorial] "As well," suggest "In addition," instead.
---
3.1
Definition of datatype theory
[editorial] stumbled over the parenthetical "(non-disjoint)" - is it
necessary? Would suggest to strike.
---
3.1
[editorial, accessibility] This is a nit, but when I first viewed this
document, the "I"s and "l"s were indistinguishable. Maybe italicise the
"l"?
---
3.2 and elsewhere
[nit] It may be in standard use, in which case ignore this comment, but
the terminology 'oneOf' for sets of singletons doesn't seem to express
(when read informally in Engligh) its intended behaviour. If it's not
too late would replace with 'singletons' or some other term.
---
3.2 [nit]
[[
restriction(p x_1 ... x_n)
]]
Suddest adding ", for n > 1" since n=1 cases are dealt with below this.
---
4.
[typo] "abstarct" in the first para.
---
5.1 and throughout
[editorial, nit++] inconsistent capitalisation rules applied to
headings. Would capitalise "Universe" here. This barely qualifies as a
comment, apologies.
---
5.2, the "Note". The term "constructor" is not defined in the document
and is only used in one other place.
---
Some additional comments from RDFCore are to be supplied by Brian
McBride shortly.
Received on Friday, 9 May 2003 12:14:12 UTC