Response to the review comments of the Syntax document, Sections 3--8

Hello Mike, Bijan, and Vojtech (and everybody else :-),

Here are my responses to your review comments in Sections 3--8. Here is the diff:

http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=12769&oldid=12740

Please let me know should you have further comments.

Regards,

	Boris


@Vojtech, beginning of Section 3: Again, how about giving the initial part of text its own heading such as 'Overall Structure of an
Ontology'? In general I believe that avoiding 'mixed content sections' (using analogy with XML stuff) makes reading easier,
including a better overview in the TOC.

In this and in all the following sections, the diagrams have been given at the beginning of the section; then, the various parts of
the diagrams have been explained in the respective subsections. This seems like a reasonable structure: the subsections are
subordinate to the diagram - that is, they explain the various parts of the diagram. Hence, the current structure seems appropriate
to me.


@Mike, Figure 1: I suggest removing the specializations of annotation (the analogous specializations of axiom are not present).

I agree. In similar vein, I've removed the Annotations class from Figure 9.


@Mike, Figure 1: On some annotations you indicate multiplicity with a lone *, in others you use 0..* Choosing one alternative and
using it consistently is easier for the reader.

In fact, 0 .. * is incorrect from the MOF point of view, so please let me know if you find further of those floating around.


@Vojtech, Section 3.5: We should perhaps make sure that 'annotating ontologies' in this context means '...ontologies as wholes'. How
about using this extended formulation? Or, annotating individual entities or axioms is not 'annotating ontologies' in the general
sense?

I'm not sure I understand this comment. An ontology can be assigned an annotation, just like any other entity can. I don't
understand what you mean with "annotating an ontology as a whole".


@Mike, Section 4: Much of this section details the semantics of datatypes. As such, it seems appropriate to move much of it to the
semantics document.

I've been thinking about it. The problem, however, is that we define here both the syntax and the semantics of the datatypes; hence,
it is not clear that this should really belong to the semantics document. Another problem is that, whereas most people won't be
interested in the details of the OWL 2 semantics, they will most likely be interested in the datatype map, including the details of
the value spaces of different datatypes. For example, modelers will need to know precisely what the value space of owl:realPlus is.
I thought of describing the datatypes in an intuitive way here and presenting the datatype map in the semantics document. After some
thinking about it, though, I noticed that the intuitive description of the datatypes is of a rather limited utility (you need to be
precise), and that it would additionally bloat the spec.

To summarize, it seems to me that we might want to keep this section in the Syntax document.


@Vojtech, Section 4: Single quotes ('datatype') would be better?

I'm not sure I know what you mean here.


@Vojtech, Section 4.1: "For DT a datatype different from owl:realPlus and owl:real, ..." There should at least be a comma after
'DT', or so?

The sentence seems OK to me, but native speakers may tell me otherwise.


@Vojtech, Section 4.6: "... a "copy" of the set of real numbers..." Single quotes ('copy') would be better?

Throughout this specification, I've used American English, which is why we are using double quotes.


@Vojtech, Section 5: "annotation properties can be used to associate nonlogical information..." (similarly in 3.5). I do not
strictly argue against such a shortcut in this spec... but just for completeness, I expect annotations to be used for pretty
'logical' information as well - yet this information would not be expressible in OWL and thus not exploitable by tools merely
relying on the DL semantics of OWL...

The term "nonlogical" is inherited from knowledge representation: it means that the information is interpreted outside logic. This,
of course, doesn't mean that the information itself is garbage; this latter sense, I believe, would be denoted by the term
"illogical".


@Vojtech, Section 5.4: By saying "In DL literature this is often called...", do you mean that DLs explicitly deals with roles
connecting object individuals with literals? Is the distinction of 'individuals' and 'literals' maintained in the DLs?

The DL literature usually distinguishes between the abstract domain (i.e., individuals) and the concrete domain (i.e., literals).
There are roles that connect an individual with an individual, and there are roles that connect an individual with a concrete value.
Now the notion of literals is usually not introduced explicitly in the Dl literature: they commonly model literals as predicates.
There is, however, no underlying conceptual difference, and I'm happy with the formulation as it is.


@Vojtech, Section 5.6.2: 'Analogous' (see also para 2 of Sect.5) is too vague a characterisation to me. Are blank nodes always
interpreted as anonymous individuals when RDF is interpreted using the OWL semantics, or when aren't they?

Anonymous individuals are always interpreted as blank nodes and, in fact, anonymous individuals are mapped to blank nodes in the RDF
Mapping. Anonymous individuals, however, aren't blank nodes themselves: in RDF, blank nodes can occur in the schema part as well.
Therefore, "analogous" here should be interpreted as "like".


@Vojtech, Section 5.9.3: Although parsing and repair of ontologies are important topics, I am not quite sure if they have to be
discussed in this (already quite long) spec.

Parsing is really a very important part of OWL 2. The main complication is due to imports and the need to declare entities in
ontologies. The OWL 1 specification did not precisely specify how to handle many of the corner cases. I (and many of the
implementors I've talked with) see this section as a very important contribution in OWL 2.


@Vojtech, Section 6.1: I would not use 'bidirectional navigation' as a prime characteristic of what inverse properties are. OWL is
not a dedicated language for *browsing* bases of entities. And, in fact, they are not an absolute prerequisite for such browsing
(they only guarantee it for *all* pairs of individuals from the given properties).

"Bidirectional navigation" here refers to "bidirectional navigation in class expressions and axioms". To make this clear, I've
rephrased the sentence as follows:

	Object properties are the simplest form of object property expressions, and
	inverse object properties allow for bidirectional navigation in class expressions
	and axioms.

@Mike, Section 6.1.1: This is the first use of "contains in" to associate individuals with a property and reads poorly.  The idea of
property extension is never introduced and properties containing individuals is not intuitive.  Elsewhere the text talks about
associations between individuals, reusing that terminology seems best.

I agree. I've checked, and I've used everywhere the formulation "an object property connects two individuals", apart from Sections
5.3 and 5.4. Changing "connects" to "associates" everywhere would really be a pain; hence, I've rephrased the section as follows:

	An inverse object property expression <span class="name">InverseOf( P
	)</span> connects an individual <span class="name">I<sub>1</sub></span>
	with <span class="name">I<sub>2</sub></span> if and only if the object
	property <span class="name">P</span> connects <span
	class="name">I<sub>2</sub></span> with <span
	class="name">I<sub>1</sub></span>.

I've also changed the formulation in Sections 5.3 and 5.4. Please let me know should you have further comments.


@Vojtech, Section 8: Just like classes, class expressions are sets of individuals..." First, classes are class expressions as well,
so why "like classes"? You even say: "the main difference is that class expressions formally specify conditions..." (!) Second,
saying that "classes are sets": isn't it mixing the intent and extent of a concept outright?

I agree. I've rephrased the paragraph as follows:

	Class expressions represent sets of individuals by formally specifying conditions
	 [<cite>[[#ref-owl-2-semantics|OWL 2 Semantics]]</cite>] that individuals must
	satisfy in order to be instances of the respective class expressions.

@Vojtech, Section 8.1.4: The naming goes against good practice here. Using the class name 'GriffinFamily' for the set of *members*
of this family may confuse people a lot. Please, change to 'GriffinFamilyMember' or so.

I've changed the example to use a:GriffinFamilyMember; however, I'm not sure the original example was all that bad: a family is a
set of people, isn't it?


@Vojtech, Section 8.2.3: Should better be named "Individual Value Restrictions" ?

Yes, I've changed the section's heading.


@Vojtech, Section 8.4: First, the expressions *pave*, not *paves*, a path? Second, I don't see this path really 'paved' in the
structural syntax below... Actually, while in Sect. 7 you say that "This specification currently does not define data ranges of
arity more than one", here you speak about n-ary data ranges... so you mean that 'n' is however restricted to be 1 by some other
part of the spec?

This is actually a very important comment; thanks! This comment is related to the issue of n-ary datatypes. The current proposal is
to provide only unary datatypes in the core OWL 2 spec; however, to allow for extensions, we will provide for n-ary data ranges.
Thus, although in the core spec the arity of everything is 1, the extensions can (and will) introduce data ranges of higher arity.
To allow for such extensions, the idea was to allow in the syntax of OWL 2 for n-ary data ranges. This latter fact has been
documented in Section 7. I've rephrased the text of Section 8.4 as follows:

	These are similar to the restrictions on object property expressions, the main
	difference being that the expressions for existential and universal quantification
	allow for ''n''-ary data ranges. All data ranges explicitly supported by this
	specification are unary; however, the provision of ''n''-ary data ranges in
	existential and universal quantification allows OWL 2 tools to support extensions
	such as value comparisons and, consequently, class expressions such as
	"individuals whose width is greater than their height".

I've also added an editor's note pointing to the n-ary datatypes issue.

Received on Saturday, 13 September 2008 17:18:21 UTC