Re: Review: SPARQL 1.1 Entailment Regimes

Hi Birte,

Yes, it does.

Many thanks,

Jeff


On 28/04/2011 12:48, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:

>Jeff, Yuting,
>I added now two diagrams along the lines of what you suggested. Since
>I am already in the middle of the publication process for last call. I
>don't want to upload the changed .xml version, which is linked from
>our wiki as it says already "This document is a Last Call Working
>Draft". You can, however, see the changes in:
>http://www.w3.org/2009/sparql/docs/entailment/gen.html
>Does that address you comment?
>Cheers,
>Birte
>
>On 27 April 2011 18:27, Birte Glimm <birte.glimm@comlab.ox.ac.uk> wrote:
>> Hi Jeff and Yuting,
>> thanks for the clarification. The example diagrams make it clear what
>> you are looking for. I'll check how I can incorporate the files.
>> Best regards,
>> Birte
>>
>> On 27 April 2011 17:06, Pan, Dr Jeff Z. <jeff.z.pan@abdn.ac.uk> wrote:
>>> 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.
>>>>Regards,
>>>>Birte
>>>>
>>>>
>>>>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?
>>>>>Thanks,
>>>>> 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
>>>>>>>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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> 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
>>
>
>
>
>--
>Dr. Birte Glimm, Room 309
>Computing Laboratory
>Parks Road
>Oxford
>OX1 3QD
>United Kingdom
>+44 (0)1865 283520



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

Received on Thursday, 28 April 2011 13:02:14 UTC