Re: Review: SPARQL 1.1 Entailment Regimes

Jeff, Yuting,
many thanks for the review in particular given the very short notice.
I comment inline below.
Birte

On 5 April 2011 07:16, Pan, Dr Jeff Z. <jeff.z.pan@abdn.ac.uk> wrote:
> Overall: Due to very short notice, we  were only able to give a brief
> review. In short, the specification has good quality in general and still
> has room for improving its presentation:
>
> Abstract:
>
> "SPARQL is a query language …": shouldn't SPARQL be both a query language
> and a protocol?

True. I changed it to "SPARQL is a query language and a protocol for..."

> "It is desirable to utilize SPARQL as a query language in these cases …":
> given the importance of RDF and OWL in the Semantic Web, we propose to
> replace "desirable" to "necessary".

My understanding is that the much stronger term "necessary" might be
considered too strong for many who don't think that querying for
inferred statements is necessary. How about relativising this for the
application's requirements. Below is my suggestion including the
preceeding sentence to give the context:

"Various W3C standards, including RDF and OWL, provide semantic
interpretations for RDF graphs that allow additional RDF statements to
be inferred from explicitly given assertions. Many applications that
rely on these semantics require a query language such as SPARQL, but
in order to use SPARQL basic graph pattern matching has to be defined
using semantic entailment relations instead of explicitly given graph
structures. "


> "…  standard entailment relations in the semantic web such as RDF
> entailment, RDFS entailment, etc. are defined in this document": Are the
> definitions different from those in the RDF and OWL specifications? If so,
> we need to summarise the differences somewhere in this specification.

The full sentence is
"Such extensions of the SPARQL semantics are called entailment regimes
within this document and entailment regimes for standard entailment
relations in the semantic web such as RDF entailment, RDFS entailment,
etc. are defined in this document. "

An entailment regime says not only which entailment relation is to be
used, but also specifies what queries and graphs are well-formed, how
inconsistencies are handled etc. The docuement defines entailment
regimes *for* standard entailment relations, i.e., the entailment
relaions themselves are unchanged, but also well-formedness for graphs
and queries etc.

To clarify this, I changed the sentence to:

"An entailment regime defines not only which entailment relation is
used, but also which queries and graphs are well-formed for the regime
or what kinds of errors can arise. The entailment relations used in
this document are standard entailment relations in the semantic web
such as RDF entailment, RDFS entailment, etc."


> Inconsistent graph:
>
> Inconsistency is not defined formally in the specification. The terms
> "inconsistency" and "inconsistent graph" are first used in Sec 1.3, without
> formal definitions.

The first section is introdutory and does not aim at defining
anything. The concrete regimes do link to the relevant definitions,
e.g., in the RDFS Entailment regime RDFS-inconsistent is linked to the
relevant section from the RDF Semantics spec, which also defines the
RDFS semantics incl. RDFS-inconsistent graphs.

I now say in Section 1.3, which introduces the general idea of BGP
matching extensions and the issues that any ent. regime has to
address:
An inconsistent graph is one for which no interpretation exists that
satisfies all conditions of the semantics that is used. The issue is
discussed in more detail in <link>Section 3.1</link>, which also
provides an example for an RDFS-inconsistent graph. Since inconsistent
graphs entail any triple, special care has to be taken to to adress
the situation. The effect of a query on an inconsistent graph is
covered by the particular entailment regimes and, for each regime, the
relevant details can be found in the corresponding section for that
entailment regime.

How exactly an inconsistent graph is defined depends on the semantics
that is used and can, therefore, not be defined in an overview that
discusses the general issues that all regimes have to adress. However,
any E-inconsistent graph (for E some semantics such as RDFS or OWL
Direct Semantics) has the same problem, i.e., any triple is entailed.

> Due to the nature of the Web, the handling of inconsistent graph is a key
> issue in this specification. It might be useful for readers if a future
> version of this specification  includes a sub-section as a single entrance
> point on inconsistent graphs.

This is now discussed per entailment regime, i.e., each table that
defines a regime has an entry that defines how inconsistencies are
handled. In addition, the issue is discussed in informal sections
where relevant new issues arise, e.g., since the RDFS ent. regime is
the first where inconsistencies can arise, Section 3.1 discusses that
in quite some detail. Also note that the OWL ent. regimes require
inconsistency checking as it is typically done by OWL reasoners,
whereas the RDFS and D-Entailment regimes only require that a warning
is generated if the quey processor detects the inconsistency. The RDF
on the other hand is not powerful enough to state inconsistencies.
Thus, a per regime discussion seems to me the only real option.
Splitting Section 1.3 into two seems quite difficult to me since also
SPARQL Query, which defines the conditions on BGP matching extensions,
discusses all issues in one section.

> Diagrams: some diagrams might be useful to illustrate some abstract ideas in
> the following sections:
>
> 1.2 Effects of Different Entailment Regimes
> 2.1 Blank Nodes in the Queried Graph

It is not clear to me what kind of diagrams you suggest. Could you
describe in more detail what you would expect to see in such a
diagram?

> Greetings,
> Jeff Pan and Yuting Zhao
>
> The University of Aberdeen is a charity registered in Scotland, No SC013683.
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Tuesday, 5 April 2011 11:36:08 UTC