ACTION-552: my review of entailment regimes

Heres comes my review for entailment (I didn't get all through, particularly I didn't check the Appendices in detail, but probably won't manage much more, 
before Christmas, so apart from those comments, the doc is ready to go from my side). Most comments are editorial. Since I won't be able to attend the 
upcoming conf. call and then will be on vacation until december 27, I am happy with however the Editors decide to address them. Overall the doc is in good shape, I think.

1) Abstract

"There are different possible ways  of defining a basic graph pattern matching extension for an entailment relation. This document specifies one such way for a range of standard 
semantic web entailment relations. Such extensions of the SPARQL semantics are called entailment regimes within this document."

I find the second sentence misplaced, and anyways repetitive (the concrete entailment regimes are enumarated anywyas in the end. Suggest to drop that sentence:

"There are different possible ways  of defining a basic graph pattern matching extension for an entailment relation. Such extensions of the SPARQL semantics are called entailment regimes within this document"


2) Introduction

s/an entailment regimes specifies/
 an entailment regime specifies/

s/For example, only a finite number of the infinitely many axiomatic triples can contribute solutions under RDF Schema entailment./
 For example, only a finite number of the infinitely many axiomatic triples can contribute solutions under the RDF Schema entailment regime./

3) the following is under "Working Draft and Last Call text only:"

"References to RDF or RDFS entailment rules from the RDF Semantics specification are in some places used in an informative way and implementations are not expected to implement these rules as they are used here."

Whereas at this stage of the document, this is a bit vague without concrete references, I think a respective remark where the rules are actually used would be useful.

4) 
Section 1.1.1

"A generated blank node may also be denoted with []. "

What does "generated" here refer to? Can we change that to 

"A blank node may also anonymously (without an explicit identifier) be denoted with []."

5) 

Once a prefix such as @prefix foo: <http://example.org/ns#>  is defined [...]
                                                           ^ '.' missing here


6) 
s/the qualified name foo:bar is a shorthand for the IRI <http://example.org/ns#bar>/
 the qualified name <tt>foo:bar</tt> is a shorthand for the IRI <http://example.org/ns#bar>/

7) In Section 1.1.3., the set union symbols are formatted differently here:

  "The set of RDF Terms, RDF-T, is I ∪ RDF-L ∪ RDF-B.The set of query variables is denoted as V and V is assumed to be countable, infinite, and disjoint from RDF-T."
and here 
   "A triple pattern is a member of the set:(RDF-T ∪ V) x (I ∪ V) x (RDF-T ∪ V),"

8) Caption of Figure 1 
"Figure 1: A graphical representation of the RDF graph for the example on the effects of different entailment regimes."

  a) I'd suggest to number examples
  b) I'd leave out "on the effects of different entailment regimes." since the figure doesn't illustrate any of these effects yet.

 So, just something like 
 "Figure 1: A graphical representation of the RDF graph for Example 1"
 or alike.

 Alternatively, the RDFS entailed triples could be added to the figure by dashed lines, indeed ilustrating the "effects".

9)
"In order to retrieve ex:book2 and ex:book3, one would need a system that supports RDFS entailment."
-->
"In order to retrieve ex:book2 and ex:book3, one would need a system that supports at least RDFS entailment."

10) I'd suggest to swap example query 1 (SELECT ?pub WHERE { ?pub rdf:type ex:Publication }) and 2 (SELECT ?prop WHERE { ?prop rdf:type rdf:Property })
  since indeed the former already requires RDFS entailment, whereas the latter requires "only" RDF entailment, so that order would be more bottom-up.

11) suggestion:
"The remainder of this document specifies what correct answers are for the different entailment regimes."
-->
"The remainder of this document specifies correct answers for different entailment regimes using SPARQL's extension mechanism for Basic Graph Pattern Matching."

(that also makes a nicer bridge to the next subsection)


12)
"The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified up to RDF graph equivalence and is E-equivalent to AG."
-->
"The scoping graph, SG, corresponding to any E-consistent active graph AG is uniquely specified up to <a href="http://www.w3.org/TR/rdf-concepts/#section-graph-equality">RDF graph equivalence</a> and is E-equivalent to AG.

(Note: 2 changes suggested here, "E-consistent" and adding a link to RDF Graph equivalence, in order to clarify that this means simple equivalence)


14)

"This specification does not change any of the existing entailment relations, but rather defines the vocabulary from which possible answers can be 
            taken and which answers are legal answers in order to guarantee that query answers are always finite."

since for RIF it is not necessarily finite, I'd suggest to change:

"This specification does not change any of the existing entailment relations, but rather defines the vocabulary from which possible answers can be
 taken and defines certain conditions which guarantee that query answers are finite for most entailment regimes herein (with the exception of RIF, 
 where finiteness is not always guaranteed, see details below in Section 8.3)."

 or alike?

15)
"The IRI for a SPARQL endpoint can be related via the property sd:defaultEntailmentRegime  or via the property sd:entailmentRegime to the IRI of an entailment regime.
 The latter case is used when a particular named graph is used with an entailment regime that is different from the otherwise used default entailment regime."

Better:

"The IRI for a SPARQL endpoint can be related via the property sd:defaultEntailmentRegime to the IRI of an entailment regime which applies per default to 
 graphs queried via this endpoint. Additionally, the property sd:entailmentRegime can be used to relate a particular named graph with an entailment regime that is different 
 from the otherwise used default entailment regime."

16) 
The [XSD] reference link is broken (should be linking to: #XMLSchemaDatatypes


17) Suggest to rename Section "3 General Notes (Informative)" to "3 General Notes on Further Entailment Regimes (Informative)"


18) "Note, however, that the scoping graph SG could equally be a graph that is RDF-equivalent to G, but possibly with renamed 
            blank nodes in which case the solution could contain a blank node other than _:c, but importantly there is just one solution under 
            condition (C1)." 

maybe break up that sentence in two?

19)
"Materialization is a common implementation technique (e.g., for the RDF or RDFS regime) and it is worth pointing out that blank nodes, if they are introduced in the 
            saturation process are not to be returned in the solutions. Consider the following graph and RDFS entailment"

suggestion:

"Materialization is a common implementation technique (e.g., for the RDF or RDFS regime) and it is worth pointing out that new blank nodes introduced in the 
 saturation process are not to be returned in the solutions. Consider the following graph and RDFS entailment"

20)

In case we didn't get respective feedback on the Editorial note in the end of Section 3.2, we might equally drop it?

21) Section 3.2

"but this might be changed in the future"
-->
"but this might change in future versions of RDF"

(BTW, I *think* this change is *not* being considered by the current RDF Working Group)

21)

"A consequence of this would be that under entailment regimes such as RDF(S) one could get less 
  results than with simple entailment."

--in order to make clear that we DON'T do this, suggested to rewrite as follows-->

"A consequence of this would be that for instance under a such modified entailment regime for RDF(S) one could get less results than with 
 simple entailment." 

Section 4:

22)
"The definition of the scoping graph is, however, extended to also cover the case when the queried graph is RDFS-inconsistent. "

I think "extended" is a bit misleading here, since it's not clear with respect to what the definition is extended.
Suggested rewording:

"Note that, as apposed to the general <a href="#condition1">condition 1</a>, in this entailment regime the definition of the scoping graph 
 also covers the case when the queried graph is RDFS-inconsistent."

23)
"To obtain always a finite set of answers, the same conditions (C1) and (C2) as for the RDF entailment regime are used."

not precise, since the condition C1 talks about RDFS entailment, so better:

"To obtain always a finite set of answers, analogous conditions (C1) and (C2) as for the RDF entailment regime are used."

24) Section 7.3.1 
"Condition C3 requires that the axioms from the instantiated BGP satisfy [...]"
-add parentheses->
"Condition (C3) requires that the axioms from the instantiated BGP satisfy [...]"

Likwise, here:
"C3 guarantees that the restrictions[...]" 

25)

 "other examples can cause infinite answers without Condition (C2)."
---lower case "condition"-->
 "other examples can cause infinite answers without condition (C2)."


26) Can the Editorial note in Section 8.4 be removed now?


- that's all -

Received on Sunday, 11 December 2011 23:26:41 UTC