Re: Review: SPARQL 1.1 Entailment Regimes

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

Received on Thursday, 28 April 2011 11:48:52 UTC