- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Wed, 9 Jun 2004 08:47:28 -0700
- To: "Jim Hendler" <hendler@cs.umd.edu>, "Jos De_Roo" <jos.deroo@agfa.com>
- Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
> Maybe I didn't understand what 4.6 was about, I assumed it was > something like this: > > if I have > a rdfs:subClassOf b > b rdfs:subClassOf c > > then I was assuming that the requirments in UC&R would imply that if > I query for > a rdfs:subClassOf ?x > then ?x would be bound to b > however, if we include 4.6, then we would be expected to return > ?x = b and ?x = c I think it would be wrong to require implementations to return both 'b' and 'c', because that would be *requiring* implementations to process RDFS. But I think it would also be wrong to forbid returning 'b' and 'c' from queries against some larger knowledgebase. In this case the problem is hard to produce, since most (every?) extra piece of RDFS can simply be encoded as a whole bunch of extra triples in an RDF graph, but that's not the case for all extra sources of knowledge. For example, if the standard were to define disjunction such that the predicate "(a R b) OR (c S d)" is defined to return 'true' if and only if "a R b" returns 'true' or "c S d" returns 'true', then it's impossible for a standards-compliant processor to return sensible results in a situation where the disjunction is a logical consequence of the knowledgebase, yet neither of the individual triples is. If, however, the standard were written in terms of the semantics of the graphs which match such a disjunctive predicate, then more advanced processors could legally return results that actually represented all the knowledge at their disposal. This is the difference between specifying the semantics of the query language and specifying its implementation.
Received on Wednesday, 9 June 2004 11:57:46 UTC