Re: ACTION-552: my review of entailment regimes

Hi Axel,

thanks for the review. I have addressed the points, see my comments inline.

Birte

On 12 December 2011 00:25, Axel Polleres <axel.polleres@deri.org> wrote:
> 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"

This sentence was added to satisfy Enrico after the arguments we had last
year, so I would prefer not to mess with it, unless we want to ask Enrico
whether he is also happy with the change.

> 2) Introduction
>
> s/an entailment regimes specifies/
>  an entailment regime specifies/

done

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

done

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

I enumerate the (linked) sections now.

> 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 []."

done

> 5)
>
> Once a prefix such as @prefix foo: <http://example.org/ns#>  is defined
[...]
>                                                           ^ '.' missing
here
Hm, theASCII art didn't really work here. I added '.' after the prefix
declaration.

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

done

> 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),"

done

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

I went for this, since the doc contains a lot of examples and I don't see
any mechanism of generating the numbers. If I move text or forget one
example, all numbers have to be aligned manually, which is a pain.

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

done

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

done

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

done

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

done

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

done

>  or alike?

seems fine to me

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

done

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

fixed

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

changed to "3 General Notes on Entailment Regimes (Informative)"
since the notes also apply to the RDF entailment regime and not only to the
following (further) regimes

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

done

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

done

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

ok, done

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

True, it is listed as out of scope. Maybe in RDF 3.0 ;-)

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

done

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

done

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

done

> 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 [...]"

done

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

done

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

done

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

I guess so. It has been in there for some time incl. LC.

>
> - that's all -

Thanks!

Birte
>



-- 
Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
University of Ulm                         Fax:   +49 731 50 24188
D-89069 Ulm                               birte.glimm@uni-ulm.de
Germany