Re: Review of the Syntax document (action 312)

Hey Boris,

that was quick! :-)

For all those comments for which I have no explicit answers below, I
just agree with the possible reformulations or even objections to my
comments:-)

Boris Motik wrote:
[skip]
>>
>> 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.

Actually... I saw Bijan's argument that this is the only way we can
consistently use annotation constructs, which is quite convincing. That
and the fact that we should not reopen closed issues if we can avoid it
makes me revoke this comment and proposal. So let us consider that it as
moot.

> 
>> =========== 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.
> 

It is one of those issues where if we decide to go against my comment, I
would not have sleepless nights on it:-)

That being said, the major divide, so to say, is between the DL and Full
usage of OWL 2 ontologies. The FS spec covers the whole (ie, Full),
which is great, but making the DL restrictions very well visible would
be good. I let the collective wisdom of the group decide:-)

[snip]

> 
> 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.
> 
>

Section 2.4, 4th paragraph:

"Certain concrete syntaxes, such as the RDF Syntax [OWL 2 RDF Mapping],
allow IRIs to be abbreviated in relation to the IRI of the document they
are contained in."

There is no such thing as a (generic) 'RDF Syntax'. I guess you refer to
the RDF/XML syntax (and then the reference should also be changed).


[skip]

>> ------
>> 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 – so it should not break any more. Please let me know
> if the problems persist.

It does:-(

[skip]


> 
> 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.
> 

We may want to add a remark in the introduction of Data Ranges that a
singleton tuple is considered identical to the tuple element itself,
although that is one of the syntactic 'abuses' that is often done
elsewhere, too.

Otherwise this (plus the other changes you did on datatypes) look o.k.
to me!

[skip]

> 
>> -------
>> 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.

No it is not... If nothing really comes to your (or anybody's) mind,
forget it.

[snip]


Ivan

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 30 March 2009 09:07:20 UTC