Response to the review comments of the Syntax document, Sections 1 and 2 from Boris Motik on 2008-09-13 (public-owl-wg@w3.org from September 2008)

From: Boris Motik <boris.motik@comlab.ox.ac.uk>
Date: Sat, 13 Sep 2008 16:27:41 +0100
To: <public-owl-wg@w3.org>
Message-ID: <000101c915b5$430673d0$2b12a8c0@wolf>

Hello Mike, Bijan, and Vojtech,

Thanks a lot for your review of the Syntax document! Since there are quite a few comments, I'll group the responses to several
sections. I've just gone through Sections 1 and 2 and have made a bunch of changes; here is the diff:

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

Below are my responses to some nontrivial comments of yours. Please let me know if you are unhappy with how I addressed some of
them.

My responses for the remaining sections will follow shortly.

Regards,

Boris

@Mike: A definition of ontology is needed.

I've added a definition of what an ontology is. There are, however, 1000 different definitions floating around, and picking the
right one is rather hard. Please let me know should you not be happy with the definition that I've added.

@Bijan, Section 1.1: Insert: The structural diagrams are intended to serve as the abstract model of all the normative and
non-normative syntaxes of OWL as well as a guideline for API developers. The primary task of the functional syntax is to provide a
clear linear syntax for specifying the semantics and for describing the translations between the various exchange and authoring
syntaxes and the structural model.

Section 1.1 is intended to just say what is and what is not considered normative in OWL 2. Your comments, however, seem to be more
explanatory. To reflect them, I've modified the first paragraph of Section 1 as follows:

This document defines the OWL 2 language. The core part of this specification
&mdash; called the ''structural specification'' &mdash; is independent of the
concrete exchange syntaxes for OWL 2 ontologies. It describes the conceptual
structure of OWL 2 ontologies and thus provides a normative abstract model for
all (normative and nonnormative) syntaxes of OWL 2. This allows for a clear
separation of the essential features of the language from issues related to any
particular syntax. Furthermore, such a structural specification of OWL 2 provides
the foundation for the implementation of OWL 2 tools such as APIs and
reasoners.

The essence of your second sentence is, I believe, already represented by the second paragraph of the introduction.

@Bijan and Mike: Both of you complained about the fact that I tried to redefine the semantics of the RFC 2119 keywords (SHOULD,
MUST, and so on). Furthermore, Mike has noticed that we are using keywords other than SHOULD (and I was mentioning only SHOULD). I
agree with these comments: initially, I thought we will be using only SHOULD, but then we started using other keywords so this
paragraph is obsolete. I've rephrased the paragraph as follows:

Italicized keyword MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY specify certain aspects of the
normative behavior of OWL 2 tools, and are interpreted as specified in
<nowiki>RFC 2119</nowiki> [<cite>[[#ref-rfc-2119|RFC 2119]]</cite>].

BTW, we are using these keywords in other documents as well. I've added this sentence to RDF-Based Semantics (a similar sentence was
already there, but I made it the same as in the other documents) and the Profiles. Thanks to Vojtech for noticing the wrong HREF!

@Vojtech: "Should/not" in normative sense is typically italicised in the spec; this should be explicitly said in the 'Normative
Status' section I guess. In fact, the non-italicised uses of the term correspond to 'probabilistic' meaning (e.g. "...should be
clear from the context"), to instructions for the reader rather than implementer ("...should be understood"), or they appear in the
text of examples.

Apart from two examples where rewriting was really difficult, the Syntax document currently doesn't use the word "should" in any
sense other than the normative one. It was determined a while ago that the document should (pun not intended) be written in such a
way. In the meanwhile, I've succumbed to using "should" in the natural-language sense, but I've now removed it from all places that
were not examples. I've also modified the sentence introducing the keywords.

@Vojtech, Section 2: I wonder if 'basic' is the best term. What follows are supportive notes and definitions of low-level notions
rather than the 'basics' of OWL structural syntax, I would say.

How about "Preliminary Definitions"?

@Vojtech: Perhaps the first two paras of Sect.2 could be viewed as a specific subsection, e.g. "UML and BNF notations used"?

I've added two section names. Please let me know should this not correspond with your ideas.

@Vojtech, Section 2.3: It is a bit surprising to start a text talking about 'associations between components' before giving any
suggestion on what the components are.

I was referring here to the elements of the UML diagrams. I don't think we should here go into the detail and specify what these
elements are. To make this clear, I've merged this section into the part about the structural specification and I've rephrased the
section.

@Bijan, Section 2.3, the third point in the second list of items: This doesn't seem right. First, is "repetition" defined wrt
structural equivalence? Or some stronger notion of equality? Consider two sets [a, b, c] and [d,e,f] where a and b are structurally
equivalent (SE) to D and c is SE to e and f. Are these two sets structurally equivalent?

I didn't understand this comment. Section 2.3 states that there are two types of associations: by default they are without
repetition, but you can allow for repetition if you add {ordered, nonunique } to the association end.

@Mike: The grammar does not associate a full-IRI with a prefix, it associates an NCName with a prefix.

After reading your comment, I came to the conclusion that the whole URI expansion algorithm was described in a confusing way. I've
rewritten the whole paragraoph. I would appreciate it if you could let me know how you feel about the new text. I've also changed
appropriately the grammar in Section 3 in order to align the terminology with the namespaces in XML.

@Mike: Some organization within this table [i.e., Table 3] beyond namespace would be helpful (perhaps alphabetical).

I've sorted the table alphabetically.

Received on Saturday, 13 September 2008 15:29:22 UTC