Re: Updated definitions (dataset, FROM/FROM NAMED)

Dan Connolly wrote:
> On Thu, 2005-05-19 at 11:43 +0100, Seaborne, Andy wrote:
> [...]
> 
>>>>Definition: SPARQL Query 
>>>>
>>>>A SPARQL query is a tuple consisting of a graph pattern, an RDF
>>>>dataset description, a number of solution sequence modifiers and a
>>>>result form.
>>>>
>>>
>>>Dataset description? Not just a dataset?
>>>hmm. I wonder where that comes in...
>>>It doesn't seem to show up anywhere else.
>>
>>Could do - the query has dataset, and FROM/FROM NAMED are a description.
>>How the description gets turns into the datset for the query is left open.  I 
>>want to avoid talking about GET (if http://) or what aggregators might do with URIs.
> 
> 
> Hmm... I thought we decided that we shall define this feature w.r.t.
> GET... ah... well, we haven't decided, but polls indicate this
> is the leading option:
> 
> [[
> std (3 supporters; one strongly opposed)
>         FROM/GRAPH are well-defined instructions that interact with the
>         web per URI specs
> ]]
>   -- http://www.w3.org/2001/sw/DataAccess/ftf4.html#item07

I'm not reopening this.  "interact with the web per URI specs" is fine but that 
isn't just GET.  The wording should cover "file:" (we have a requirment for 
local usage) and other URI schemes, whether with a defined resolvability
"urn:lsid:" - and that one could be said to have two resolution schemes, (DDDS 
or the propsed mapping to HTTP - "hdl:"  etc.

http://www.w3.org/2001/sw/DataAccess/UseCases#r3.5

> 
> 
> 
> 
>>>As I think I suggested earlier, the semantics of FROM and FROM NAMED
>>>should be specified by reference to the protocol, not as part of
>>>the query language formalism.
>>
>>The QL should not depend on the protocol:
>>
>>1/ The QL can be used without the protocol
> 
> 
> well, you can't use FROM or FROM NAMED without access to The Web,
> i.e. without *some* protocol, right?

"file:"?  OK - you can say it's a protocol but it isn't GET.

The point is the more general though - that the QL can be used without a 
protocol (requirment: local use).  And anyway, at the moment, protocol doc 
defers to the QL for the meaning of default-graph-uri and named-graph-uri.

This gets back to why we put FROM back into the QL; there have been comments on 
this as well.

> 
> 
>>2/ If the protocol does not specify the dataset, it comes from the query syntax 
>>so we end out looping here.
> 
> 
> My picture is:
>  - the QL spec specifies what a dataset is, and gives the
>   semantics of queries w.r.t. datasets
> 
>  - the protocol spec says how to obtain a dataset from
>    2 lists of URIs, using web protocols and RDF merging
> 
>  - the QL spec says "a query using FROM/FROM NAMED
>    is just like one without FROM/FROM NAMED, where the
>    relevant URIs show up in the default-graph-uri
>    and named-graph-uri slots in the protocol"
> 
> Yes, it's a rat's-nest of dependencies, but that seems to be
> what the WG wants.
> 
> I can imagine other ways to do it, but I don't see them concretely.

I see it as the parameters in the protocol being set in the query execution 
context with defined semantics that they override anything the query says. 
FROM/FROM NAMED are, likewise, informing the context.

> 
> 
>>>That reminds me... the protocol spec needs to say how
>>>to get from the default-graph-uri and the
>>>named-graph-uri's to the corresponding graphs.
>>>I'll try to remember to send mail about that separately.

 Andy

Received on Friday, 20 May 2005 07:57:15 UTC