RE: Review of the Syntax document (action 312)

Hello,

Tanks Ivan! Please find my responses to your review inline. Here is the diff for
the document:

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

Please let me know should you have any further comments.

Regards,

	Boris

> -----Original Message-----
> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] On
> Behalf Of Ivan Herman
> Sent: 27 March 2009 16:55
> To: Boris Motik
> Cc: W3C OWL Working Group
> Subject: Review of the Syntax document (action 312)
> 
> Hi Boris & al,
> 
> here is my review result for the document. Summary: one slightly (but
> only slightly!) more substantial comment and a bunch of editorial
> issues. Overall, the document looks good (not an easy read but, hey,
> that is life:-)
> 
> Ivan
> 
> =========== (Slightly) more substantial issue =============
> 
> As far as I could see, the 'Declaration(' terminal symbol in the
> language is not necessary. Ie, it would be perfectly o.k. to write simply
> 
> Class(<URI>)
> 
> instead of the more verbose
> 
> Declaration(Class(<URI>))
> 
> if I am right, I would propose to drop the 'Declaration(' part. It does
> means some more editorial work in the syntax and the mapping document,
> but it does not seem to be a huge one. Actually, it would also make it a
> little bit closer to the RDF way of declaration, which is a plus.
> 
> (I realise this change request comes a bit late in the game, so I will
> not stick to it if the overall feeling is that it is not worth the trouble)
> 
> 

This change could be made -- that is, the syntax would work. I agree that the
syntax would become much nicer.

The only downside I can see is that the FSS would depart slightly from the
structural specification: in the SS, we have the Declaration class, which
currently nicely corresponds with the 'Declaration' terminal. (A similar
situation exists in the XML Syntax and is necessary there.) I think I could live
with this: it is just us recognizing that UML is different from a linear syntax.

I don't think, however, that I can just change this, so I suggest to discuss
this at the next teleconf.

> =========== Editorial issues ==============
> 
> General remark referring to many different sections, related to the
> texts on OWL 2 DL restrictions (eg, in section 5.1): I wonder whether it
> is possible, through some typesetting trick, to very clearly identify
> the DL restrictions in the text visually. Eg, putting (via some CSS
> statement, for example) a colourful vertical bar on the left of the
> text, or something similar. It is a bit easy to miss those statements
> and they are fairly essential in the DL/Non DL switch...
> 

I was thinking about this; however, note that we have a number of other
restrictions as well. Now just highlighting the DL restrictions might seem
strange: we should either highlight all of them or none of them.

In the end, I managed to convince myself that this would require yet another
pass over the whole document, the overall benefit of which might not be that
great. We already have a summary of the relevant restrictions in Section 3, so I
guess nobody should overlook them.

> -----
> Abstract:
> it says:
> 
> [[[
> If certain global restrictions on OWL 2 ontologies are followed,
> resulting in OWL 2 DL, then reasoning over ontologies can be performed
> using techniques well known in the literature.
> ]]]
> 
> which still reflects a bias towards DL only world:-) I would either
> remove this sentence altogether, or say something like:
> 
> [[[
> Reasoning over ontologies can be made on the basis of either the RDF
> Based Semantics[ref] or the Direct Semantics[ref]. If certain global
> restrictions on OWL 2 ontologies are followed, resulting in OWL 2 DL,
> using the Direct Semantics allows reasoning to be performed using
> techniques well known in the literature.
> ]]]
> 

I have added what you say (slightly rephrased).

> ------
> Introduction, the javascript buttons
> 
> - the label 'Hide RDF syntax' is a bit misleading. It should be
> something like 'Hide/show examples in RDF'
> 
> - I wonder why the buttons are placed in the middle of the text. I think
> the button row should be moved either to the end of the introduction or
> the beginning, but not be placed in the the text flow (I actually
> believe it should be moved to the end of the intro, but I can go either way)
> 
> - It may make sense to give an option to hide the functional syntax in
> the examples. If I look at the document without the grammar, ie, only
> the diagrams, then I may want that. The combination of diagram+no
> grammar+no FS examples+RDF examples would then provide a document
> concentrating on the structure and RDF only...
> 

I agree. I've moved the buttons right after TOC, I've changed their labels, and
I've added the buttons for hiding FSS.

> ------
> Introduction, third paragraph:
> 
> "subset of OWL 2 with favorable computational properties and that can be
> reliably recovered from an RDF graph." I must admit I do not fully
> understand the meaning of the 'reliably recovered from and RDF graph' here.
> 

I've changed this to the following sentence:

Each RDF graph obtained by applying the RDF mapping to an OWL 2 DL ontology can
be converted back into the conceptual structure defined in this document by
means of the reverse RDF mapping [<cite>[[#ref-owl-2-rdf-mapping|OWL 2 RDF
Mapping]]</cite>].

> ------
> Introduction, penultimate paragraph
> 
> I says " The examples in this document are informative and any part of
> the document that is specifically identified as informative is not
> normative." I wonder whether we should make it clear here that the RDF
> versions of the examples correspond to the RDF Mapping of the structural
> syntax.
> 

Adding such a sentence to this paragraph wouldn't be appropriate, as this
paragraph merely talks about what parts of the document are normative or not. If
such a statement is necessary, then we should add another paragraph about
examples. I'm not sure this is worth the bother, though: it should be pretty
obvious that the examples in RDF correspond to the ones in FSS, should it not?

> ------
> 2.1 Structural specification
> 
> (Caveat: I am _not_ familiar with the UML terminology!)
> 
> - I must admit I got a bit messed up because the term 'class' in the
> section is, I believe, used in the UML sense and not in the OWL sense. I
> wonder whether it would not be possible to use another term instead
> (acknowledging the fact that the official UML terminology uses that
> term:-). Unfortunately, that term is used elsewhere in the document,
> too, like "In the structural specification, IRIs are represented by the
> IRI class" (beginning of 2.3). At the minimum, at all occurrences of
> this type we should say 'UML class'...
> 

I noticed that and tried to use the term "UML class" in all places where I talk
about the parts of UML. I have checked the document and have added the prefix
"UML" in several places.

> - Right before the last example, the text says "Duplicates should be
> eliminated from such constructs during parsing.". I presume what was
> meant is during mapping to the structure. I associate the term 'parsing'
> to the process turning, say, the RDF/XML or Turtle file into RDF
> triples. I propose to avoid the term in this context and use 'mapping'
> instead.
> 

I've changed this sentence to this:

Duplicates <em title="SHOULD in RFC 2119 context" class="RFC2119">SHOULD</em> be
eliminated when ontology documents written in such syntaxes are converted into
instances of the UML classes of the structural specification.

Note, however, that we have defined parsing in Section 3 as the process of
mapping a document into the corresponding structures of the SS. I believe this
to be quite a natural term that is syntax independent; for example, if you start
with an FSS document, you are going to *parse* it into the instances of the SS.

> -----
> 2.2. BNF notation, last sentence:
> 
> "Whitespace and comments cannot occur within terminal symbols (explicit
> or defined) other than quotedString". Either write "quoted string" or
> refer to the definition of what quotedString means. This is the first
> occurence of this term in the text...
> 

I've actually removed the reference to quotedString as it wasn't needed:
whitespace is defined as not being enclosed in quotes, so, by definition, it
cannot occur inside quoted strings.

As part of the CURIE change, I've made a couple of further changes to this
section; please let me know should you have any comments.

> ----
> 2.3. IRIs and namespaces
> 
> - the SPARQL reference is missing from the reference list
> 
> - "To this end, commonly used IRIs - called namespaces - are associated
> with a prefix" -> "To this end, commonly used IRIs - called namespaces -
> are associated with a prefixes" (I could read the original text by
> saying that the same prefix can be used with several IRI-s
> 
> - definition of abbreviated-URI: "a string matching the as PNAME_LN" ->
> "a string matching the PNAME_LN"
> 
> - Although in a different section, but belonging to the issue of our own
> version of curies: the very end of section 3.7 still refers to CURIE-s.
> I presume that whole portion should be reformulated referring to the
> abbreviated syntax of IRI-s instead. The CURIE reference becomes than
> unnecessary in the reference list.
> 
> - Also: Section 13.1 still refers to the curie rules for IRI-s. That
> should also be updated to the abbrevited IRI-s.
> 

You must have been reading the document while I've been implementing the CURIE
change. This part of the document has changed now considerably, so please let me
know should you have any comments about the new version.

> ----
> 2.4. Integers, Stings, etc
> 
> The nodeID production refers to SPARQL (which is fine with me), but
> section 13 refers to N triples for nodeID in 13.1. I guess the latter
> should be updated to SPARQL, toov
> 

The same as above: the new version refers to SPARQL everywhere.

> 
> ------
> 3.6. Canonical parsing
> 
> The typesetting used for the items is such that 'CP-3.2' has a line
> break after '-' and '3.2'. This is at least the way it looks in my
> browser (Chrome) but also on Safari. I find it a bit difficult to read,
> shouldn't that be in one line?
> 

I've changed '-' to &ndash; so it should not break any more. Please let me know
if the problems persist.

> ------
> 4. Datatype Maps
> 
> Last paragraph says: "The semantic consequences of OWL 2 ontologies
> depend exclusively on the set of actually used datatypes [OWL 2 Direct
> Semantics],...". Either remove the reference to the Direct Semantics or
> refer to both semantics. I would be happy with the former.
> 

Unfortunately, this statement is true only for the direct semantics and only for
OWL 2 DL ontologies. I've just removed the sentence.

> ------
> 4.1. Real numbers,
> 
> Remove the qualifier 'rich' from the first sentence. (What is rich or
> not is not something we should define:-)
> 

OK.

> ------
> 5.2 Datatypes
> 
> In the first paragraph: "All datatypes have arity one." This statement
> comes a bit out of the blue: there is no preceding text explaining what
> the term arity actually means with regard to datatypes. (I checked, this
> is the first occurence of the word 'arity'...). I think some explanation
> is necessary here, or a reference to data ranges where these are defined
> further. Alternatively, the sentence can be removed from here and, in
> the data range section, make it clear that all the basic data types have
> an arity one.
> 

Thanks for spotting this. It is, however, rather hard to present all the
definitions in a linear way in this document. Therefore, I've added the
following forward pointer:

As explained in [[#Data_Ranges|Section 7]], each data range is associated with
an arity; for datatypes, the arity is always one.

I hope this should be sufficient to prevent any confusion.

> ------
> 5.6.2. Anonymous individuals
> 
> The text says "The latter is achieved by standardizing anonymous
> individuals apart ". The word "standardizing" sounds a bit funny in a...
> standard:-) Could we use some other term here? (The same term is used in
> the example)
> 

The term "standardizing apart" comes from the RDF Semantics document.

> ------
> 5.9 Metamodeling
> 
> The text in the example says "the class view of a:Species is interpreted
> as a unary predicate, while the individual view of a:Species is
> interpreted as a constant". Shouldn't that refer to a:Dog rather than
> a:Species?
> 

Oops, thanks!

> -------
> 7.1 Intersection of Data ranges
> 
> The current specification says
> 
> "An intersection data range DataIntersectionOf( DR1 ... DRn ) contains
> all data values that are contained in the value space of every data
> range DRi"
> 
> But a data range is defined to consist of (tuples of) literals; each
> literal being a combination of a lexical form and a dataype per section
> 5.7. Ie, mathematically, the definition should something a bit
> convoluted like
> 
> "An intersection data range DataIntersectionOf( DR1 ... DRn ) contains
> all literals whose mapping to data values are contained in the value
> space of every data range DRi"
> 
> As the same formulation is used for union, enumeration, etc, maybe the
> best approach is to put something after the figure at the beginning of
> section 7 to say that we will use a simplified formulation to reduce the
> complexity of the proze. Actually, I am not sure the value space of a
> data range is defined; the definition only says it is a set of literal
> tuples...
> 
> (I may misunderstand something here)
> 

You are right -- this is a bit messed up. There are several problems here.

- I deliberately didn't want to talk in this document about the syntactic things
(i.e., individuals and literals) independently from their semantic meaning
(i.e., domain objects and data values). Hence, I glossed over the distinction
between literals and the data values that the literals stand for. I'm not really
sure whether going there is worth it: it would just make the formulations
tricky.

-  I agree, however, that the formulation was broken here. I've changed it to
talk about tuples of literals.

- I (silently) consider a tuple of one literal to be the same as the actual
literal. This is why, for DataOneOf, I don't talk about tuples any more but of
simply literals. Let me know whether you consider this worth an explicit
discussion.

> -------
> 8.2.2. Universal Quantification
> 
> I wonder whether an example could be used that does not use cardinality
> restriction. This features comes later in the text and for a user it is
> a bit disturbing to find a non-trivial feature at that point...
> (recognizing the necessity, in _this_ example, to use the cardinality
> expression:-(
> 

The problem is that, for a universal expression to be entailed, you need to
somehow close the set of individuals, and the only way to do it is via number
restrictions.

I'm aware of the fact that, at this point QCRs have not been introduced;
however, I found it impossible to present all the constructs linearly. I'm not
sure whether this is so bad after all: this is supposed to be a reference. If
people want a didactic introduction to OWL, they should probably read the
Primer.

> -------
> 8.3.1. Minimum cardinality
> 
> The RDF example should use owl:minQualifiedCardinality and not
> owl:minCardinality
> 

Oops, sorry!

> -------
> 8.3.3. Exact cardinality
> 
> The RDF example should use owl:qualifiedCardinality and not owl:cardinality
> 

Oops, sorry!

> -------
> 9.5 Keys
> 
> - I just wonder whether one of the examples could be modified to use
> more than one properties in Keys. This is one major aspects of keys that
> is not emphasized here...
> 
> - In the last example in this section, the RDF encoding has a bug: the
> last two occurences of _:x should be _:z.
> 

Thanks for spotting the error. Regarding the first comment, I don't know...
There are already four examples in this section, and I'm really out of
inspiration here. Let me know if you consider this really important.

> ------
> 9.6.2. Individual inequality
> 
> For a person coming from OWL 1 + RDF the example might suggest that the
> old owl:differentFrom does not exist any more. Maybe an extra tiny
> example that simply refers to two individuals instead of three might put
> that person's mind at ease:-)
> 

Oh, I don't know... This document makes no attempt to show all variants of the
RDF encoding. Furthermore, note that owl:AllDifferent version has already been
available in OWL 1 and is by no means new to OWL 2.

> -------
> 9.6.4. Positive Object Property Assertions
> 
> I got mixed up for a moment reading the comment in the example 'Things
> having a dog are dog owners' and looking at the code seeing
> 'owl:Thing'... and that did not look right (although it is!). I would
> rather say 'Individuals having a dog are dog owners' or something like that.
> 

I've changed it as follows:

Objects that have a dog are dog owners.

I'm not sure whether the term "individual" is appropriate here: in this document
this term refers to the syntactic part of an OWL 2 ontology.

> I would also use the term 'individual' in 9.6.6. rather than 'Thing' in
> the comment to the example
> 

I've changed it to:

Objects that are often than 13 and younger than 19 (both inclusive) are
teenagers.

> -----
> 9.6.5. Negative Object Property Assertions and
> 9.6.7. Negative Data Property Assertion
> 
> The RDF encoding seems to be wrong in both cases. The mapping uses
> owl:sourceIndividual, owl:assertionProperty and owl:targetValue, and not
> the rdf terms.
> 

Oops, sorry! I generated the RDF using OWL API, and it has not been updated yet.

> -----
> 11.1 Property hierarchy
> 
> Explanation text under the example: the preceding definitions defined
> 'composite' and 'simple'. I am not sure we have the formal definition of
> 'nonsimple' being composite. Ie, isn't it more precise to say:
> 
> "The object property a:hasUncle occurs in an object subproperty axiom
> involving a property chain, so it is composite. Consequently, the object
> property a:hasRelative is not simple, because a:hasUncle is a composite
> subproperty of a:hasRelative."
> 

Simple and composite are not 100% opposite of each other. I agree, however, that
the text was not that clear. I've changed it like this:

Consequently, the object property ''a:hasRelative'' is not simple either,
because ''a:hasUncle'' is a subproperty of ''a:hasRelative'' and ''a:hasUncle''
is not simple.

> ------
> 11.2 Restrictions
> 
> - Example 'a particular kind of cyclic definitions' (right before
> 'restrictions on the usage of anonymous individuals") the explanation
> text says 'As per the fourth and the fifth bullet'. But this is not 100%
> clear, it is the "As per the fourth and the fifth bullet of the third
> bullet" which is a bit ugly:-( Maybe by giving number 1, 2, 3, 3.1, 3.2,
> 3.3, etc, to those restrictions they can be back-referred unambiguously.
> The same problem occurs in the previous example which refers to the
> 'third bullet', and this is not clear either (well, one can find out in
> both cases thinking through the meaning of the examples, but it would be
> better to make it cleaner).
> 

I agree that this is messy. The problem, however, is that Mediawiki's
typesetting of ordered lists is really appalling; furthermore, you can't ask it
to create the hierarchical numbered lists. I'm therefore now referring to "the
third subcondition of the third condition", as well as "the fourth and the fifth
subcondition of the third condition".

> - Example on the usage of an. individuals, explanation right after the
> example and before the rolled up version: it should say _:a1 instead of _:x.
> 

Oops, thanks!

Received on Sunday, 29 March 2009 16:24:30 UTC