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

Re: Review: SPARQL 1.1 Entailment Regimes

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Wed, 27 Apr 2011 18:27:08 +0100
Message-ID: <BANLkTi==G36eEmfPiY+qA_eHUR-9dTezHQ@mail.gmail.com>
To: "Pan, Dr Jeff Z." <jeff.z.pan@abdn.ac.uk>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, "Zhao, Yuting" <yuting.zhao@abdn.ac.uk>
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
Received on Wednesday, 27 April 2011 17:27:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT