W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Fwd: OWL Quick Reference

From: Jie Bao <baojie@cs.rpi.edu>
Date: Wed, 15 Apr 2009 18:47:20 -0400
Message-ID: <b6b357670904151547t4bca8bd9g132a6e35874745c0@mail.gmail.com>
To: OWL 2 <public-owl-wg@w3.org>
This is just for record purpose. It's my response to Ivan Herman's
comments on QRG

---------- Forwarded message ----------
From: Jie Bao <baojie@cs.rpi.edu>
Date: 2009/3/11
Subject: Re: OWL Quick Reference
To: Ivan Herman <ivan@w3.org>
Cc: "Deborah L. McGuinness" <dlm@cs.rpi.edu>, Alan Ruttenberg
<alanruttenberg@gmail.com>, Sandro Hawke <sandro@w3.org>, Ian Horrocks
<ian.horrocks@comlab.ox.ac.uk>, Elisa Kendall <ekendall@sandsoft.com>,
Evan Wallace <ewallace@cme.nist.gov>

Thank you, Ivan.

I made a few changes according to your comments. The diff is



On Wed, Mar 11, 2009 at 10:25 AM, Ivan Herman <ivan@w3.org> wrote:
> Deb, Jie
> I attach some comments that I noted while reading through the QR. If you
> want me to send that through an 'official' mail to the WG, that is also
> fine, just tell me.
> I did not check the cross links because we agreed those should be
> updated when everything else is done. The same for the list of
> datatypes; these are still in a bit of a turmoil, so they can be
> finalized in this document when they are final elsewhere...
> Cheers
> Ivan
> More substantial
> - 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.)
I added  " "[a1 ... an]" stands for a list " to notation conventions at
the beginning. Will that be clear?

As to triple forms of list, I think keeping it will make the guide
more self-contained. That may be even more important for the
print-ready version, where links will not be available.

> - 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...)
All secondary section headings (e.g., 1.2) and beyond now are only for
the ease of editing (section editing) - I don't think it will make too
much sense in the pdf version. I'm not sure whether the WG will like
to keep subsections in the HTML version, or just the bold form of
headings.  But one things is for sure: we will only keep one form in
the final version.

> - 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
Agreed, I made a separate table and a statement

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

> - 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...
Agreed, same to 1.3.3 Datatype Properties

> - 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.
I checked the Syntax document, you are right. I have it removed. Its
RDF translation is obsolete anyway.

> - 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:-(
The 4th column is the comment column. Now it mainly plays two roles 1)
notation explanation; 2)  some semantics hints. I admit it's
inconsistent -- not all entries have comments. However, some of them
would be useful, as the naming of some constructs are not
self-explanatory. On the other hand, we can't repeat all semantic
definitions in this crammed table either... I would keep some
(informal, short) semantic  explanation for those "hard" ones (which
again, I admit not all covered by the current Guide).

> 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)
How about adding a note "=" stands for owl:sameAs and "≠" stands for
owl:differentFrom ?

> - 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...
In this case, the annotated resource is _:x, so "y P v. " is actually
"_:x P v". The reification form (y P v.
x rdf:type owl:Annotation. x owl:subject y. x owl:predicate P. x
owl:object v.) is needed only if the annotation itself has annotation.

> - 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...
Reification is needed only the AnnotationAssertion has annotation...
maybe I should add a note, or split it into two entries, one has
annotation, one has not.

> - 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.
Will follow him

> - 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,
Will italic form be better?

>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...
Maybe we can follow some javascript trick used in Primer to switch
on/off shading/link/bolding...

However, those options will not be possible on the pdf version.

I will add an editor's note on this issue.

Received on Wednesday, 15 April 2009 22:48:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC