- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Wed, 27 Apr 2011 18:27:08 +0100
- 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 UTC