- 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