Re: SPARQL Protocol for RDF

On Jun 2, 2005, at 17:09, ext Kendall Clark wrote:

> On Thu, Jun 02, 2005 at 10:12:17AM +0300, Patrick Stickler wrote:
>
>> Great work!
>
> Thanks.
>
>> A few questions/comments:
>>
>> 1. All examples explicitly specify the background graph, and while
>> that's
>> of course not incorrect, it would perhaps be good if the
>> first few basic examples would omit specification of a background 
>> graph
>> to
>> reflect what will most likely be the most common use case, that of a
>> given SPARQL portal recieving queries without any specification of a
>> the background graph, and defaulting to the default background graph 
>> of
>> the
>> portal itself.
>
> A good suggestion and one that will be acted upon. :>
>
>> 2. The parameter for specifying the background graph should follow the
>> terminology used in the SPARQL spec and thus should be named
>> 'background-graph-uri' and not 'default-graph-uri' as the term
>> "default graph" has no definition in SPARQL.
>
> Right, but...We talked about synching up on these, and my memory is 
> that we
> chose "default graph" rather than "background graph". I may be
> misremembering or the QL editors may not have fixed those bits yet. 
> But,
> yes, these will be synched eventually.

Fair enough. I guess I am presuming that the SPARQL spec is the
more mature, and central spec, and that the protocol spec would
track it, but if the SPARQL spec is changed to talk about "default
graphs", fine. The key is for the two specs to use consistent
terminology.

>
>> 3. Since the SPARQL language itself provides facilities for
>> explicitly specifying which graph a given query, or components
>> of a query, should be evaluated against, and the query itself can
>> (and if needed, must) include FROM/FROM NAMED qualifications
>> naming the relevant graphs, why is it necessary to redundantly
>> specify any graph URIs in the parameters?
>
> I'll repeat the bits I already wrote in response to Danny:
>
> The design we've come up with allows the RDF dataset (which is 
> composed of
> zero or one default (sometimes called "background") graph and zero or 
> more
> named graphs) to be specified either in the protocol, or in the query
> language, or in both. In the case where it is specified in both, but 
> the RDF
> datasets are not identical, the dataset specified in the protocol 
> trumps the
> one specified in the query.
>
> This is spelled out in the latest draft thus:
>
>   The RDF dataset may be specified either in a legal [SPARQL] query 
> using
>   FROM and FROM NAMED keywords; or it may be specified in the protocol
>   described in this document; or it may be specified in both the query
>   proper and in the protocol. In the case where both the query and the
>   protocol specify an RDF dataset, but not the identical RDF dataset, 
> the
>   dataset specified in the protocol must be the RDF dataset consumed by
>   SparqlQuery's query operation.
>
> Since both you and Danny asked about this, this bit must either be 
> vague
> or just doesn't stand out enough in the draft presently. I'll think 
> about
> ways to make it more difficult to miss. :>
>
> Let me add that the WG spent a *lot* of time talking about this, over 
> the
> course of many months, and we think we had good reasons for allowing 
> this
> flexibility in specifying the RDF dataset. There are very good reasons 
> for
> specifying it in the query language and for specifying it in the 
> protocol,
> reasons which overwhelm the simplicity argument (that is, specifying 
> it in
> one and only one place).

Great. But since any engineer who embraces economy and simplicity
will probably wonder about the redundancy, it would be good to share
at least a basic rationale for this.

Even if it is only offered as a footnote, it should nevertheless
be provided and be convincing.

>
>> If a specific graph needs to be specified, then it seems to me
>> that it would be better, as in more economical and elegant, to
>> use the existing machinery in the SPARQL query language itself
>> to identify those graphs rather than introducing alternative,
>> and potentially redundant parameters for doing so. This also
>> alleviates any chance of conflicts between the query and the
>> parameters, such as if they disagree about which graph is the
>> background graph.
>
> We specify what is supposed to happen if they disagree, per above.

For some reason, I missed that bit. Glad to see that it is there.

But I still remain puzzled about the need for being able to
specify any graph in the parameters rather than just in the
query.

>
> I won't respond in this message to yr comments about the nature of the 
> RDF
> dataset or unnamed graphs. But we're still considering the underlying 
> design
> and someone will respond eventually. :>

OK.

>
> Thanks for the comments.

You're welcome.

Patrick


>
> Kendall Clark

Received on Thursday, 2 June 2005 15:52:54 UTC