Re: [TF-ENT] Review of the Entailment regime document, 2009-12

Birte,

First of all, thanks, you have indeed covered all my comments.

However... (I know, I am a pain in the neck), re-reading the text, I
have the following (minor) additional comments. My apologies if it was
already present in the previous version and I missed it... That being
said: _none of these are critical_. In other words, I am happy to
publish the document as is in this round, and possibly address these
comments in the next release only. This is especially true for entry #1
below.

1- Section 6.2: if one goes outside the OWL DL circles then the
Functional Syntax for axioms is not really known and well readable. (I
must confess that I also 'see' OWL statements in Turtle and not in FS.)
I wonder whether we should not consider the approach we took in the OWL
documents, where the examples were all available in various syntaxes and
people could choose which one they would use. It is a little bit of
extra work, but we have got extremely positive feedbacks on this, it was
worth the trouble. For this document I think having the examples in FS
and in Turtle would be enough (the OWL documents also had M'ter syntax
and RDF/XML).

Again: this is _not_ for this release, the publication can and should
happen without it!

2- Section 6.1.1: "These restrictions require that blank nodes are only
connected in a tree-like way": a short example of what this means would
be helpful (or a reference of such example). Lambda RDF users may not
really understand what you mean here...

3- Section 6.1.3 and elsewhere: we should try to make the Turtle/SPARQL
mapping more readable, and really making use of its syntactic
possibilities. Eg, the first example could be written as

ex:Peter a [
    a owl:Restriction ;
    owl:onProperty ex:hasSon ;
    owl:maxCardinality "1"^^xsd:nonNegativeInteger .
  ] .

the second could be

ex:Peter a [
     a owl:Class ;
     owl:complementOf [
       a owl:Restriction ;
       owl:onProperty ex:hasSon ;
       owl:minCardinality ?n .
     ]
  ]

Which I do fine more readable. This is even more visible for the example
in 6.1.5. The axiom in Turtle could be:

ex:Peter a [
    a owl:Restriction ;
    owl:onProperty ex:dp ;
    owl:qualifiedCardinality "2"^^xsd:nonNegativeInteger .
    owl:onDataRange [
      a rdfs:Datatype ;
      owl:onDatatype xsd:int ;
      owl:withRestrictions (
        [ xsd:minExclusive "5"^^xsd:int ]
        [ xsd:maxExclusive "8"^^xsd:int ]
      )
    ]
]

Let us not make the RDF version more cryptic than necessary!

Cheers

Ivan





On 2010-1-5 18:21 , Birte Glimm wrote:
> Ivan, Axel, others,
> a new version of the document is now checked in, see
> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml. Axel, the
> Direct Semantics section is now up to date, so can review it. I'll
> start implementing your changes for the RDF(S) part now.
> I comment on the changes to address Ivan's review below.
> Thanks for the very useful reviews,
> Birte
> 
> 2009/12/18 Ivan Herman <ivan@w3.org>:
>> Birte, all
>>
>> here are my review comments on the document. All in all, none of the
>> comments seem to constitute a show-stopper in my view, ie, with those
>> changes done, I think the document is read to be published. Actually, my
>> comments on section 2.5 may require more work but, if those are
>> postponed for the next release, it is fine with me to publish without
>> that change.
>>
>> Ivan
>>
>>
>> (Slightly more) substantial:
>>
>> Abstract, last sentence
>> -----------------------
>>
>> I would actually drop the "Time permitting," at the beginning. On the
>> one hand, it is clearly the case that those will happen:-) and I suspect
>> that this document would not be accepted for final publication without
>> those items anyway...
> 
> Dropped.
> 
>> Section 1.1.3, triple patterns are defined by:
>> ----------------------------------------------
>>
>> (RDF-T union V) x (I union V) x (RDF-T union V),
>>
>> but 'I' is not defined in the sequel. I presume you mean IRI-s (as
>> defined in 12.1.1 of the original SPARQL doc)
> 
> Added the definition.
> 
>> Editorial note at the end of 2.2.1
>> ----------------------------------
>>
>> I regard editorial notes as places where we, essentially, put
>> alternatives and let the community react if those alternatives are
>> considered to be better. However, most of this editorial note (up until
>> "A consequence of not requiring...") is more an
>> informative/clarification note on the current definition. I think it is
>> valuable for the reader and I would consider moving that into the main
>> text as an informative section.
> 
> Mentioned part of the note is now in an informative section.
> 
>> Section 2.5, definition of Direct Semantics entailment, point 3.a
>> -----------------------------------------------------------------
>>
>> I presume the usage of sk(O(SG)) here is necessary for the _:y case
>> described in the preliminary text. If so, then sk has to be defined in
>> the sequel, to make the definition of the entailment regime's condition
>> self-contained.
> 
> It is and sk(O(SG)) is defined now.
> 
>> Section 2.5 generally
>> ---------------------
>>
>> This is not a trivial editorial issue, hence I put it here. In the
>> RDF(S) cases the text carefully took the restrictions (C1) and (C2) and
>> gave examples with a clear reference to the restrictions and showing why
>> they were there. And that is fine. I think the issues and descriptions
>> for 2.5 should follow the same structure to make the text more readable
>> (Which does not exclude having additional info, of course.)
>>
>> For example, the first part of section 2.5.2, referring to top property
>> is not, as far as I could see, referring to any of the restriction in
>> the entailment definition but rather to a restriction defined by OWL 2.
>> On the other hand, the second half of the same section describes (I
>> guess) 3.b. Ie, this should be editorially separated in my view. 2.5.3
>> refers to restrictions 1.
>>
>> I see no explanation/example for 3.c and 3.d. I must also admit that I
>> do not understand the necessity of 3.d. I thought that non-logical
>> axioms are, sort of, comments for the direct semantics, so why asking
>> for a structurally equivalent axiom? What does that mean?
> 
> The Direct Semantics section is restructured now. I hope the
> conditions are now clearer stated, similar as for RDF(S) and the
> sections following the table for the Direct Semantics entailment
> regime now go through each condition explaining the underlying
> intention.
> 
>> General comment
>> ---------------
>>
>> I would put, somewhere, an editorial note that the WG is looking to
>> describe available entailment regimes in terms of service descriptions,
>> and that this may also involve giving a reference to EL and QL. Getting
>> comments from the community for that would be good...
> 
> I added that at the end of the introduction. Each entailment regime
> now includes the URI for that regime and for the profiles that are
> already described (DL, EL, QL) I added sections that mention the URI
> that can be used to describe the input restrictions for systems that
> just handle a profile.
> 
>> =================================================
>>
>> Editorial:
>>
>> Abstract, 1st paragraph:
>> ------------------------
>> "What correct answers to a SPARQL query are"
>> ->
>> "What the correct answers to a SPARQL query are"
> 
> done
> 
>> "The first version of SPARQL [SPARQL/Query 1.0] was defined only for
>> simple entailment, but it defines"
>> ->
>> "The first version of SPARQL [SPARQL/Query 1.0] was defined only for
>> simple entailment, but it defined"
> 
> done
> 
>> "The goal of this document is to specify conditions such that SPARQL can
>> be used with entailment regimes other than simple entailment."
>> ->
>> "The goal of this document is to specify conditions such that SPARQL can
>> be used with some other entailment regimes beyond simple entailment."
>>
>> (for the latter: the original sentence suggests that this document
>> defines how to use sparql with _any_ entailment regimes, which not the case)
> 
> Agreed and changed.
> 
>> Introduction, 1st paragraph
>> ---------------------------
>>
>> "In this document, we specify how SPARQL can be used with entailment
>> regimes other than simple entailment."
>> ->
>> "In this document, we specify how SPARQL can be used with some other
>> entailment regimes beyond simple entailment."
>>
>> (same issue as above...)
> 
> Done.
> 
>> Introduction, bulleted list of references
>> -----------------------------------------
>>
>> I am not 100% about that, but I wonder whether it is not better to list
>> the 1.1 documents for all items, rather than a mixture of the two...
>> (realizing, however, that the current 1.1 draft does not contain yet the
>> parts from the old SPARQL...) An alternative is to make this issue
>> explicit. I just want to avoid misunderstandings that this draft is not
>> relevant to SPARQL Query 1.1...
> 
> I removed the SPARQL 1.0 reference and now use the latest version URIs
> (with the short names) everywhere so as soon as the documents are
> published the UR should point to the then complete 1.1 spec.
> 
>> Section 1.2, paragraph after the SELECT example
>> -----------------------------------------------
>>
>> varaibles -> variables
>  Done.
> 
>> Section 1.3, first sentence
>> ---------------------------
>>
>> "...matching to other entailment regimes and SPARQL 1.0 says:"
>> suggest removing "and SPARQL 1.0 says:"
> Done.
> 
>> Section 2.1.1, penultimate paragraph
>> ------------------------------------
>>
>> "...sk(G) C1 is satisfied" -> "...sk(G), C1 is satisfied"
> Added.
> 
>> Section 2.1.2, first paragraph
>> ------------------------------
>>
>> "The following example illustrates mainly the use of condition C2."
>> ->
>> "The following example mainly illustrates the use of condition C2."
> Done.
> 
>> Section 2.2, first paragraph
>> ----------------------------
>>
>> inconsistet  -> inconsistent
> Done.
> 
>> Section 2.5.2,  ultimate paragraph
>> ----------------------------------
>>
>> are return -> are returned
> Done.
> 
>> Section 2.5.4.2, first paragraph
>> --------------------------------
>>
>> annotaated -> annotated
> Done.
> 
>> Section 2.5.4.2, last paragraph
>> -------------------------------
>>
>> "Apart from the annotations and annotation axioms itself"
>> ->
>> "Apart from the annotations and annotation axioms themselves"
> Done.
> 
>>
>> Section 2.5.5, first paragraph
>> ------------------------------
>>
>> Smeantics -> Semantics
> Done.
> 
>> Appendix, CVS history
>> ---------------------
>>
>> Empty? That looks odd. Either you do not use CVS comments (in which case
>> it is fine to remove this appendix) or fill it with meat:-)
> 
> Now I added that CVS log command and it is not empty any more. Should
> I manually add all the previous comments that where not added
> automatically?

-- 

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
vCard  : http://www.ivan-herman.net/HermanIvan.vcf