Re: Closing action-306: Comments on the QRG

Hi Deb,

there was a tiny pending issue simply because I was not clear in my
comment and, I believe, Jie misunderstood me. Here is what I wrote back
last week:

[[[
> The rationale to have both the binary and n-ary forms for
>> SameIndividual is because I want to distinguish features available/not
>> available in OWL 2. Same rule applies to DisjointClasses.
>> EquivalentClasses is different because both the two forms are already
>> supported in OWL 1. If n=2, the n-ary form translation actually covers
>> the binary case.

I think I was not clear, sorry. What I meant is as follows (and this is
only editorial): in what is now 2.5 you have, eg:

ij owl:sameAs ij+1.
j=1…n-1

which is fairly concise an clear. So why not using

Ci owl:equivalentClass Ci+1
i=1..n-1

in 2.1.4? Ie, to make this type of notations consistent. That is all I
wanted to say...
]]]

That is all!

Cheers

ivan



Deborah L. McGuinness wrote:
> Thanks very much for the comments Ivan.  I believe you agreed with the
> QRG updates in response to your valuable feedback.
> Do you believe  that there are any issues remaining or should we
> consider the updates and responses to have satisfied your comments?
> 
> thanks,
> Deborah
> 
> Ivan Herman wrote:
>> For the records, these were my comments on the QRG document. In fact,
>> these comments went to Jie before I took the action last week, and the
>> current wiki page reflects most of the proposed changes already. But as
>> there was a public action on me, it is better to have that on record,
>> too.
>>
>> Ivan
>>
>> ---------------
>>
>>
>> - The explanation for the [...] syntax for lists is in 1.6, although it
>> is used right at the begining already. I wonder whether it is not better
>> to move that section up where the notations are described. After all, as
>> far as this document goes, this is a notation. (I am not even sure it is
>> worth spelling it out in terms of triples, just make a reference to the
>> appropriate RDF Semantics entry.)
>>
>> - The term 'self' is used in the fourth entry of table 1.1.2. Wouldn't
>> 'local reflexivity' be a better term?
>>
>> - 'Restrictions Using Object Properties owl:Restriction' in 1.1.2 and
>> 1.1.3 appears right before the tables. I am not sure why you have
>> 'owl:Restriction' listed there there. I do not think it is necessary.
>> Actually, the rest of the line is just the section heading which does
>> not seem to add any new information. I would propose to leave only the
>> second line there ("Every owl:Restriction is an owl:Class.")
>>
>> This is something that is repeated all along. There is a section
>> heading, and then the same text as the section heading is repeated in
>> bold referring to some owl vocabulary element. I do not see the value of
>> these; just shorten things by removing them (I realize the PDF card may
>> need that, but then this should be visible on the PDF only...)
>>
>> - I wonder about the treatment of n-ary datatypes in 1.1.3. We have them
>> _syntactically_ as 'hooks' in the spec, but they are not part of the
>> core spec. I wonder whether the corresponding two lines (n-ary universal
>> and n-ary existential) should not be clearly separated from the rest
>> with a clear statement warning the user that these are _not_ part of the
>> core OWL 2 spec. Editorially, this also means (I guess) that the D^n
>> reference from the intro paragraph in section 1 should be moved out to a
>> separate place
>>
>> - 1.1.4 just for the sake of consistency: 1.5 includes an abbreviated
>> format for SameIndividual when there are more than 2; I think the same
>> format should be used for, eg, EquivalentClasses, or for similar
>> constructions elsewhere
>>
>> - in 1.3.1. I would repeat the top/bottom property term in the third
>> coloumn. The reader might be misled by the table to think that those
>> terms are not available in RDF. It is redundant, I know, but, well...
>>
>> - 1.3.1. In my understanding the property chain (ie,
>> ObjectPropertyChain) appears in a subproperty position only, ie, as it
>> appear in the second row of 1.3.2. I guess this should be checked with
>> Boris and Michael. If I am right (which is not sure...) it should
>> probably be removed from 1.3.1. In any case, the owl term used is wrong,
>> it should be owl: propertyChainAxiom.
>>
>> - 1.3.2. I wonder about the fourth coloumn of the table. I am not 100%
>> sure we should have those there or, if we do, whether we should have it
>> for all entries. Again, I am not sure, but there is a level of
>> inconsistency there:-(
>>
>> By the way, strictly speaking in the RDF semantics, some of the
>> statements are not 100% correct. Functional property means that
>>
>> i0 P i1. i0 P i2 => i1 owl:sameAs i2
>>
>> I know, I am nit picking, but, well... (the same is repeated all along
>> that coloumn)
>>
>> - I am not 100% sure the first table in annotation (1.9) is correct
>> although, I must admit, I am not sure how to put this whole annotation
>> business in concise form:-(
>>
>> If I have Annotation(P v), and this appear within an axiom, ie something
>> like
>>
>> SubclassOf( Annotation(P v) A B )
>>
>> this gets translated into the triples
>>
>> A rdfs:subClassOf B
>> _:x rdf:type owl:Axiom
>> _:x owl:subject A
>> _:x owl:predicate rdfs:subClassOf
>> _:x owl:object B
>> _:x P v
>>
>> ie, the first triple in the table (y P v) does not seem to be correct...
>>
>> - 1.9.2, again I am not 100% sure about the annotation assertion. If I
>> use
>>
>> AnnotationAssertion(p SomeURI v)
>>
>> this gets translated, simply, into
>>
>> SomeURI p v
>>
>> ie, no extra reification there...
>>
>> - Section 2: just a heads up: Boris is rewriting this part as we speak,
>> so this may have to be updated at some point, too.
>>
>> - Section 4
>>
>> I wonder whether this should not be moved to the top of the page. These
>> are the namespaces we use, better specify them upfront...
>>
>> Minor nit:
>>
>> - This is a matter of taste, of course. Personally, I find the gray
>> background shading a little bit disturbing. I wonder what other
>> typographic trick we should use to denote OWL 2 specific features, but
>> something less disturbing would be nice. (Maybe some lighter colour, for
>> example?) I also wonder whether we could find a trick (eg, by chaning
>> the css values via a javascript?) so that I could choose _not_ to
>> highlight the differences. It is of course great to have those clearly
>> denoted for those who make a transition from OWL 1 but, after a while,
>> these differences become without interest, and I might prefer not to
>> have them highlighted at all. The same holds for the '?' links that
>> refer to the NF&R; once people are hooked on OWL 2, those issues become
>> moot, and the really important reference will be the primer (in my
>> view...) and not that one...
>>
>>   
> 

-- 

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