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

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?

Received on Tuesday, 5 January 2010 17:22:28 UTC