- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 22 Dec 2004 10:32:11 +0000
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Steve Harris <S.W.Harris@ecs.soton.ac.uk>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
Pat Hayes wrote: >> Steve Harris wrote: >> >>> On Sun, Dec 19, 2004 at 09:01:05 -0600, Dan Connolly wrote: >>> >>>>> My engine has no way to turn off inference (though it wouldn't be >>>>> hard to >>>>> add globaly), but I'd like it if that was possible on a >>>>> per-statement way >>>>> via the query language. >>>> >>>> >>>> I'm not sure what you mean; it makes more sense, to me, to specify what >>>> you're querying against in the FROM clause. If we wanted explicit >>>> support for "turning RDFS inferencing off" in SPARQL, I'd expect it >>>> to look something like: >>>> >>>> SELECT ?C FROM rdfs(<mydata.rdf>) WHERE ( :x rdf:type ?C). >>>> vs. >>>> SELECT ?C FROM <mydata.rdf> WHERE ( :x rdf:type ?C). >>> >>> >>> >>> [turning off wasn't really what I was thinking of, but I cant think of a >>> better term, ignoring maybe] >>> >>> OK, well I would expect it to look more like >>> >>> SELECT ?C WHERE GROUND (:x rdf:type ?C) >>> >>> I dont really like FROM as it doesn't make much sense in server-like >>> systems where all the graphs are preloaded (for performance or security >>> reasons), or systems that are reflecting underlying data in another >>> format >>> and translating queries on the fly. >> >> >> FROM could make sense - the server offers a numer of graphs and the >> URI in teh FROM must choose one of them. If it names some graph the >> server is not publishing, then the query generates an error. FROM >> isn't a requirements to load any graph (I worry about the security >> issues of that). A server may require that there is only one URI in >> the FROM clause - i.e. no arbitrary RDF merge of graphs. It is just a >> request for something that the server does not offer. > > > Agreed. I think we should allow a server to refuse to answer a query if > it names FROM a graph that the server cannot (prefers not to) access, > and we should allow the query to provide a variable in the FROM position > which gets bound to the name of the source as part of the answer, so > that a query can say, in effect: answer this from any source you choose, > but tell me what the source was. Woudl using "SOURCE ?src { ... query pattern ... }" achived this effect if the query is over the collection of named graphs? > Query-answering servers should be > required to provide a binding to any such variable, even if it is a > 'trivial' one which simply identifies the server itself (which means, > roughly: I am the source, and that's all you are going to get out of me > on that topic.) Interesting - this is saying the default graph has a URI. I wonder how that interacts with the protocol. Andy > > BTW, there should not be a requirement on a server that the same query > from the same source will produce the same result each time. But it > might be useful to enable a server which does undertake to be stable in > this way, to advertise the fact that it is stable. > > Pat > >> (This use of FROM is one mode for Joseki I'm considering) >> >> Andy >> >>> >>> - Steve > > >
Received on Wednesday, 22 December 2004 10:32:44 UTC