W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

Re: Review: SPARQL 1.1 Entailment Regimes

From: Pan, Dr Jeff Z. <jeff.z.pan@abdn.ac.uk>
Date: Wed, 27 Apr 2011 17:06:47 +0100
To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>, "Zhao, Yuting" <yuting.zhao@abdn.ac.uk>
Message-ID: <C9DDFC96.15C55%jeff.z.pan@abdn.ac.uk>
Hi Birte,

We are happy to see these changes addressing most of our comments.

As for the suggestion of adding diagrams, we simply think it is an option
to improve the readability of this document.

Attached are some sample diagrams. Diagram1.2.jpg is for [1.2 Effects of
Different Entailment Regimes], which visualizes the 3 patterns.
diagram2.1.jpg is for [2.1 Blank Nodes in the Queried Graph], in which the
reader could immediately indentify G3 having a different pattern from G,
and understand why G3 is a problem for the query.

Many thanks,

Jeff and Yuting

On 27/04/2011 10:34, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:

>Jeff, Yuting,
>since I haven't heard from you, I assume that my changes addressed
>your comments. Please let me know ASAP if that is not the case.
>On 19 April 2011 15:02, Birte Glimm <birte.glimm@comlab.ox.ac.uk> wrote:
>> Jeff, Yuting,
>> could you give me some feedback on the questions I had for your review?
>> Birte
>> On 5 April 2011 13:35, Birte Glimm <birte.glimm@comlab.ox.ac.uk> wrote:
>>> 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
>>>> has room for improving its presentation:
>>>> Abstract:
>>>> "SPARQL is a query language ": shouldn't SPARQL be both a query
>>>> and a protocol?
>>> True. I changed it to "SPARQL is a query language and a protocol
>>>> "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
>>>> 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,
>>>> 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
>>>> issue in this specification. It might be useful for readers if a
>>>> version of this specification  includes a sub-section as a single
>>>> 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
>>> --
>>> Dr. Birte Glimm, Room 309
>>> Computing Laboratory
>>> Parks Road
>>> Oxford
>>> OX1 3QD
>>> United Kingdom
>>> +44 (0)1865 283520
>> --
>> Dr. Birte Glimm, Room 309
>> Computing Laboratory
>> Parks Road
>> Oxford
>> OX1 3QD
>> United Kingdom
>> +44 (0)1865 283520
>Dr. Birte Glimm, Room 309
>Computing Laboratory
>Parks Road
>OX1 3QD
>United Kingdom
>+44 (0)1865 283520

The University of Aberdeen is a charity registered in Scotland, No SC013683.

(image/jpeg attachment: diagram1.2_1_.jpg)

(image/jpeg attachment: diagram2.1_1_.jpg)

Received on Wednesday, 27 April 2011 16:07:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:04 UTC