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

Re: Primer ready for internal review

From: Ivan Herman <ivan@w3.org>
Date: Wed, 08 Apr 2009 18:39:07 +0200
Message-ID: <49DCD32B.3000905@w3.org>
To: Sebastian Rudolph <rudolph@aifb.uni-karlsruhe.de>
CC: W3C OWL Working Group <public-owl-wg@w3.org>
Thanks Sebastian,

the text you added for the profiles is certainly useful. The primer not
being in last call it will still have to be reviewed, and we can really
'feel' that text in its full context later. For this round, I am happy
with what you did!

Thanks

ivan

Sebastian Rudolph wrote:
> Hi Ivan,
> 
> thanks again for the review, I worked through it, find my my editorial
> comments below (hardly any controversy, though).
> 
> Best,
>  Sebastian
> 
> 
>> Markus et al,
>>
>> I have made a first review of the document, see details below.
>>
>> All in all, I think there are some bugs in the examples that have to be
>> taken care of before publication. For some others that might require
>> more work an editorial note indicating that more work is to be done
>> should suffice by publication on the 15th.
>>
>> Thanks for the huge work!
>>
>> Ivan
>>
>> =========================================================================
>>
>> General comments
>> ----------------
>>
>> I have had my discussions with the editors on improving the formatting
>> of the turtle examples; this will happen, eventually. We also noted that
>> the encoding of rdf lists in turtle is currently bogus, and has to be
>> changed.
>>
> 
> Agreed, this will be adressed.
> 
>> --------------
>>
>> I missed a section on keys in the main section. I think keys are awfully
>> important in practice and should be listed and shown alongside the main
>> text (in section 4).
>>
> 
> Indeed, this is scheduled for the section "Advanced Axioms and Entities"
> where it IMHO would fit in most nicely. I added an explicit note on that.
> 
>> --------------
>>
>> I think we agreed that the OWL 2 vs OWL 1 differences should move out of
>> this document, so I have not reviewed that section
>>
> 
> Yes, this part has been deleted now.
> 
>> ---------------
>>
>> On the section on profiles: for all three profiles what I miss is what
>> _cannot_ be done. Without these, it is fairly difficult to really
>> understand what is behind the shiny words that are used for
>> characterization:-) Maybe by listing those constructions in the generic
>> example that would _not_ fit into the given profile would give some
>> insight; possibly even more than the possibilities that can be done,
>> which is what is there now. Or listing both.
>>
> 
> Good point. I tried to add some short explanations on the most striking
> limitations here and there (these could be further extended if
> considered crucial):
> 
> For OWL Profiles in general:
> "In order to guarantee for scalable reasoning, the existing profiles
> share some limitations regarding their expressiveness. In general, they
> disallow negation and disjunction, as those constructs complicate
> reasoning and have shown to be only rarely needed for modelling. For
> example, none of the profiles would allow to specify that every person
> is male or female. Further specific modelling restrictions of the
> profiles will be dealt in the sections on the single profiles."
> 
> For OWL 2 EL:
> "Besides negation and disjunction, OWL 2 EL also disallows universal
> quantification on properties. Therefore propositions like "all children
> of a rich person are rich" cannot be stated. Moreover, as all kinds of
> role inverses are not available, there is no way of specifying that,
> say, parentOf and childOf are inverses of each other."
> 
> For OWL 2 QL:
> "Among other constructs, OWL 2 QL disallows existential quantification
> of roles to a class expression, i.e. it can be stated that every person
> has a parent but not that every person has a female parent. Moreover
> property chain axioms are not supported."
> 
> For OWL 2 RL:
> "One downside of OWL 2 RL is that it cannot express that the existence
> of an individual enforces the existence of another individual: for
> instance, the statement "every person has a parent" is not expressible
> in OWL RL."
> 
> 
>> --------------
>>
>> General comment on all examples. I use the example in  Section 3.1
>> because I just realized it while reading that one...
>>
>> Technically, the RDF/XML syntax should say
>>
>> <owl:Class rdf:about="#Woman">
>>   <rdfs:subClassOf rdf:resource="#Person/>
>> </owl:Class>
>>
>> Similarly, the turtle should say
>>
>> :Woman rdfs:subClassOf :Person
>>
>> or, as it stands in the Appendix
>>
>> f:Woman rdfs:subClass f:Person
>>
>> The Appendix actually uses the proper syntax. I realize that the
>> examples might become a bit uglier, but I believe they should be
>> syntactically correct....
>>
>> Also, in other examples, you have statements like
>>
>> <rdf:Description rdf:about="John">
>>   <hasWife rdf:resource="Mary"/>
>> </rdf:Description>
>>
>> that is, technically, correct for RDF/XML, but it might be better to use
>> the f:hasWife form for the predicate. Having said that, the
>> corresponding turtle example:
>>
>> John hasWife Mary .
>>
>> is _not_ correct, it has to say either :hasWife or f:hasWife.
>>
> 
> All agreed; we will go through the examples in the subsequent days and
> correct them.
> 
>> -------------
>>
>> I believe that mainly the introductory part of section 8 needs a rewrite
>> (and possibly the rest of the paragraph, too), because it is not in line
>> with the intention of the 'naming' discussion that we had. DL is a
>> syntactic subset, does not automatically mean direct semantics; as we
>> put it into the overview, we have a common usage of Full equated to OWL
>> plus the RDF based semantics, but we should not emphasize that the way
>> it is done here.
>>
>> I actually wonder whether we should have a long description here, and
>> whether we should not simply refer to what has been written in the
>> overview, and showing the effects of some of the DL syntactic
>> restrictions.
> 
> In fact, Peter has come up with an alternative suggestion for that
> section which has now been exchanged.
>>
>>
>> =========================================================================
>>
>> Specific comments
>> -----------------
>>
>>
>> Section 1.1, first paragraph
>>
>> 'This documented' -> 'This document'
>>
> done.
>> -------------
>>
>> 1.2 Syntaxes
>>
>> I think that, for consistency with other document, we should remove the
>> reference to CURIE-s. This is a primer and not a formal spec, so the
>> text is probably o.k. without it. It may be worth adding a sentence that
>> all syntaxes provide syntactic means to define such prefixes and
>> references
>>
> done.
>> -------------
>>
>> Section 2, paragraph right before the editor note, 3rd sentence:
>>
>> 'Later' -> 'Latter'
>>
> done.
>> -------------
>>
>> Section 2, last paragraph, end of the 4th sentence:
>>
>> 'also the latter is' -> 'the latter is also true'
>>
> done.
>> ---------------
>>
>> Section 3.4, 2nd paragraph after the first example
>>
>> 'Note that it is necessary to mind the order in which the individuals
>> are written down' ->
>> 'Note that the order in which the individuals are written down is
>> important'
> done.
> 
>>
>>
>> Same paragraph, third sentence: 'Indeed ' -> 'Indeed, '
> done.
>>
>>
>> The right term in the FS for negative object property assertion is:
>> NegativeObjectPropertyAssertion and not NegativePropertyAssertion.
> done.
>>
>>
>>
>> ----------------
>>
>> Section 3.8
>>
>> The right term in the FS for negative data property assertion is:
>> NegativeDataPropertyAssertion and not NegativePropertyAssertion.
> done.
>>
>>
>> ----------------
>>
>> Section 3.8, just wondering about the RDF/XML encoding examples...
>>
>> I know that the usual approach of encoding datatypes is to use the XML
>> entity facilities, eg, &xsd;integer. But for the reader it might be
>> worth (in the introduction) to make this clear, similarly to the
>> sentence on prefixes and references. Alternatively, we could byte the
>> bullet and write the full URI for datatypes. I have a slight preference
>> for the latter.
> 
> Good point. I also tend to the latter and changed the example accordingly.
>>
>>
>> ----------------
>>
>> Section 4.1., after the first example block:
>>
>> 'this is, that all ' -> 'this is that all '
>>
> done.
> 
>> after the example on complements:
>>
>> 'But of course,' -> 'But, of course,'
>>
> done.
> 
>> ----------------
>>
>> Section 4.2, after the example on universal quant.
>>
>> 'occurs far more frequently;.' -> 'occurs far more frequently.'
> done.
> 
>>
>>
>> ---------------
>>
>> Section 4.2, example on the usage of both the universal and existential
>> quant., in the RDF/XML example the </owl:intersectionOf> is missing in
>> the second block.
> You've got eagle eyes. Corrected.
>>
>>
>> ---------------
>>
>> Section 4.2, before the last but one example block.
>>
>>
>> 'class of individuals which are related to one particular individual' ->
>> 'class of individuals that are related to one particular individual'
> done.
>>
>>
>> ----------------
>>
>> Section 4.3, first paragraph
>>
>> 'The following example states that John has at most four children that
>> which are themselves parents' -> 'The following example states that John
>> has at most four children who are themselves parents'
> done.
> 
>>
>>
>> ---------------
>>
>> Section 5, first paragraph
>>
>> 'By now, our considerations were focused on classes and properties were
>> merely used as building blocks for class expressions.' -> 'Until now we
>> focussed on classes and properties that were merely used as building
>> blocks for class expressions'.
> done.
>>
>>
>> ---------------
>> Section 5.1, 2nd example block
>>
>> - the indentation of the ')' for the FS example is wrong
>> - there is a '7>' instead of '>' in the RDF/XML
> done.
>>
>>
>> ---------------
>> Section 5.1, example on disjoing properties
>>
>> Stricly speaking the RDF/XML and the turtle examples do not generate the
>> same triples; the RDF/XML encoding also generates the
>>
>> hasChild rdf:type owl:ObjectProperty .
>>
>> which is not part of the turtle encoding. Either this could be added to
>> the turtle encoding or one can simply say
>>
>> <rdf:Description rdf:about="hasParent">...
>>
>> not a big deal, but it may be better to keep these two strictly
>> identical triple-wise...
>>
> I agree. To keep things simple, I chose the second option.
> 
>> ----------------
>>
>> Section 5.1, text before functional properties
>>
>> 'As every person can have only one husband, '
>>
>> is it true everywhere in the globe? :-) Just add a caveat...
> 
> So be it... ;o)
>>
>>
>> ---------------
>>
>> Section 5.1, text after functional properties
>>
>> 'Mark that this statement does' -> 'Note that this statement does'
> done.
>>
>>
>> 'It is also possible to indicate, that ' -> 'It is also possible to
>> indicate that '
> done.
>>
>>
>> --------------
>>
>> Section 5.2., property chains
>>
>> The RDF mapping of property chains have changed recently. The two
>> example syntaxes should be:
>>
>> <rdf:Description rdf:about="#hasGrandparent">
>>     <owl:propertyChainAxiom rdf:parseType="Collection">
>>         <owl:ObjectProperty rdf:about="#hasParent"/>
>>         <owl:ObjectProperty rdf:about="#hasParent"/>
>>     </owl:propertyChainAxiom>
>> </rdf:Description>
>>
>> f:hasGrandparent owl:propertyChainAxiom (f:hasParent f:hasParent) .
>>
> done.
>> -------------
>>
>> Section 7.1 on the RDF/XML and turtle examples: as before there is a
>> discrepancy between the OWL/XML and the turtle examples, because the
>> former would generate an extra triple defining Person to be a Class,
>> whereas this does not happen in turtle.
>>
>> Also, either use a datatype in both cases or don't. In fact, the
>> datatype is not really necessary here, a plain literal is just as fine.
>>
> done.
>> -------------
>>
>> Section 7.3. paragraph after the example block:
>>
>> 'However, the an IRI may denote different entity-types ' -> 'However, an
>> IRI may denote different entity-types '
> done.
>>
>>
>> I am also not sure that the term 'punning' is used in the rest of the
>> documents, and it certainly does not have any real sense in terms of OWL
>> Full. The full paragraph is, in fact, only OWL DL specific. It should be
>> moved and possibly rephrased to the OWL DL vs Full section.
> I see your point... I have to think about that, for now I added a note.
> 
>>
>>
>> --------------
>>
>> Section 9
>>
>> [[[
>> So you might choose to use a profile that doesn't fit as well with your
>> modeling problem in order to use the better Java tool. Before making a
>> major commitment we would suggest at least consulting with
>> public-owl-dev@w3.org which hosts such discussions, or consulting with
>> an expert.
>> ]]]
>>
>> This paragraph, though probably true, would really just scare away
>> people, think of the LC comment of Susie Stephens! I would rather not
>> have it here.
> 
> OK. Done.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>>
>> 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
> 
> _________________________________________________
> Dr. Sebastian Rudolph
> Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
> rudolph@aifb.uni-karlsruhe.de    phone +49 (0)721 608 7362
> www.sebastian-rudolph.de                 fax +49 (0)721 608 5998
> 
> 
> 
> 

-- 

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 Wednesday, 8 April 2009 16:39:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 April 2009 16:39:47 GMT