- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 14 Aug 2006 12:53:56 +0200
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mon, Aug 14, 2006 at 05:02:32AM +0100, Bijan Parsia wrote: > > As I was working on DISTINCT, I realized that there were other > corners of RDF semantics that might be a bit odd. Forgive me if these > have been raised already. They are mostly inspired by Jeremy > Carroll's weird datatype tricks shown to me at WWW in Japan. > > We have some text that sort of addresses this issue: > > """3.4 Matching Values and RDF D-entailment > RDF defines D-Entailment where extra semantic conditions are allowed > for datatypes. When matching RDF literals in graph patterns, the > datatype lexical-to-value mapping may be reflected into the > underlying RDF graph, leading to additional matches where it is known > that two literals are the same value. RDF semantics does not require > this of all RDF graphs.""" > > I don't understand this last bit, especially if it is to be some sort > of loophole. I would think that the presence of typed literals would > require datatyped interpretations. We could, I supposed, designate a > mode where all matching was done on the lexical form, or something > similar. But I don't see that we *have* done that. > > Let me just give some of the very simple ones, and see if there's > anything to discuss: > > :bob rdf:type xsd:negativeIntegerr. > :mary rdf:type xsd:positiveInteger. Query1: > SELECT ?x > WHERE {?x rdf:type _:type. > ?y rdf:type _:type. FILTER ?x < ?y} > > Should this have an answer? that is :bob? How about: > > :bob rdf:type xsd:negativeInteger. > :mary age "10"^^xsd:integer. Query2: > SELECT ?x ?y > WHERE {?x rdf:type _:type. > :mary age ?y. FILTER ?x < ?y} > > How about this? <;bob, 10^^xsd:integer>? > > More complex examples are possible with range or domain that are, > perhaps, a little less artificial. But I hope these are clear. You > could replace the URIs with BNodes as well. > > The type testing functions (e.g., isLiteral()) are similarly doggy if > you consider :bob rdf:type rdfs:Literal. Huh, interesting problem. I would certainly expect the naive implementation (not supporting D-entailment) to conclude: isLiteral(?x) => F isBlank(?x) => T Having a D-entailment implementation say that isLiteral(?x) => T would violate the monotinicity rules we appear to have set down for ourselves (wrongly or rightly). Thus, I think that isLiteral has to operate on the symbol in the graph, and not on what we may know that symbol to represent. >From this, I would expect Query1 to give no answers as evaluating :bob < :mary would result in a type error as A < B is only valid for paris of {numeric, simple literal, xsd:string, xsd:boolean, xsd:dateTime}. I also expect Query2 to yield no answers as :bob < "10"^^xsd:integer is also a type error. Is there a way the current wording could be improved? Do we need another paragraph on what not to expect from D-entailment? > Of course, we could understand all the functions, as they seem to be > implicitly, as applying strictly to the lexical form. But that's not > quite right since the comparison operators, for example, operate on > the value space. :bob *has a value* in the value space, we just don't > have access to it. > > Cheers, > Bijan. > > -- -eric home-office: +1.617.395.1213 (usually 900-2300 CET) +33.1.45.35.62.14 cell: +33.6.73.84.87.26 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
Received on Monday, 14 August 2006 10:52:39 UTC