W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: tests and inference? (and UNSAID)

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 22 Dec 2004 10:32:11 +0000
Message-ID: <41C94D2B.1080701@hp.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT