Re: Review: SPARQL 1.1 Entailment Regimes

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

Received on Wednesday, 27 April 2011 09:35:26 UTC