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: Mon, 20 Dec 2004 22:01:08 +0000
Message-ID: <41C74BA4.8020308@hp.com>
To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>



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.

(This use of FROM is one mode for Joseki I'm considering)

	Andy

> 
> - Steve
> 
Received on Monday, 20 December 2004 22:01:43 GMT

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