- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Tue, 31 Aug 2010 11:17:07 +0100
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: public-rdf-dawg@w3.org
On 28 August 2010 10:08, Axel Polleres <axel.polleres@deri.org> wrote: > > On 27 Aug 2010, at 23:32, Birte Glimm wrote: > >> On 27 August 2010 20:13, Polleres, Axel <axel.polleres@deri.org> wrote: >> > Yes, the second one was meant as D-entailment test case, and I expected both not to return any result. >> >> Because it is not well-formed RDF or because you think it is not entailed? > > What would be entailed was > > _:SURROGATE_BNODE_FOR_1 a xsd:integer > > cf. entailment rule rdfD1 (Section 7.4) in the informative entailment rules of rdf-mt [1]. Yes, the entailment rules obviously only produce well-formed RDF. If you just look at the models and the model-theoretic semantics, then the interpretation of the data value is an element of the interpretation of the data range/datatype in every model of the graph. Hence, one could say that the entailment holds and I think should RDF ever be extended to allow for literal in subject position, one would have to adjust the derivation rules accordingly. Then, one would not need the surrogate bnode for literal introduction rules any more, but at the moment the rule is needed to make ranges work. Irrespective of that, we can probably savely say that your example queries have an empty answer under the current spec. > but at the moment we don't bother about "surrogate" bnodes for literals, but only return > terms appearing in the orignal graph. (similarly for the RDFS example) I only meant those test cases for making that clear to users/implementers: That is, if I implement RDFS/D entailment by implementing the informative entailment rules, I get results which are not mandated by our current definitions of RDFS/D entailment in SPARQL. Yes. We shoud do that. Birte > Hope that the intention is clearer now, > Axel > > > 1. http://www.w3.org/TR/rdf-mt/ > >> Birte >> >> > Axel >> > >> > ----- Original Message ----- >> > From: b.glimm@googlemail.com <b.glimm@googlemail.com> >> > To: Polleres, Axel >> > Cc: SPARQL Working Group <public-rdf-dawg@w3.org> >> > Sent: Fri Aug 27 20:11:39 2010 >> > Subject: Re: Thinking out lout about some strange SPARQL entailment test cases... >> > >> > Sorry, I didn't comment on the second test case >> > >> >> Similarly: >> >> >> >> G: >> >> :s :p 1 >> >> >> >> Q: >> >> SELECT ?L >> >> WHERE { ?L a xsd:integer } >> > >> > I think that would need datatype awareness and RDFS does not support >> > the XSD schema datatypes (you would need D-Entailment or higher). Even >> > if we have >> > :s :p "1"^^xsd:integer. >> > a system unaware of xsd datatypes might read that triples, but it will >> > not necessarily infer >> > "1"^^xsd:integer a xsd:integer . >> > or even >> > "1"^^xsd:integer a xsd:short . >> > which is also true I guess. At least for OWL reasoners what counts >> > internally is the denoted data value and "1"xsd:short and >> > "1"xsd:integer is the same data vale with different lexical forms. Now >> > for OWL Direct Semantics that BGP is not legal, so your only hope >> > would be OWL with RDF-Based Semantics or some D-Entailment >> > implementation. >> > >> > Now, even with XSD awareness and not counting it as illegal RDF, the >> > answers would not be infinite because you only consider the data >> > values in the graph. >> > >> > Birte >> > >> >> >> >> Obviously, those will not give an answer, but some people might expect those to return surrogate blank nodes... a colleague of mine just came to me with that (in a different context), and I thought I might share it. >> >> >> >> Axel >> > >> > >> > >> > -- >> > 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 Tuesday, 31 August 2010 10:17:41 UTC