Re: SPARQL results in RDF

On 25/09/13 15:10, Sven R. Kunze wrote:
> On 09/25/2013 04:02 PM, Dave Reynolds wrote:
>> On 25/09/13 14:57, Sven R. Kunze wrote:
>>> On 09/25/2013 03:53 PM, Dave Reynolds wrote:
>>>> Hi Damian,
>>>>
>>>> On 25/09/13 14:16, Damian Steer wrote:
>>>>> On 25/09/13 12:03, Stuart Williams wrote:
>>>>>> On 25/09/2013 11:26, Hugh Glaser wrote:
>>>>>>> You'll get me using CONSTRUCT soon :-)
>>>>>>> (By the way, Tim's actual CONSTRUCT WHERE query isn't allowed
>>>>>>> because
>>>>>>> of the FILTER).
>>>>>>
>>>>>> Good catch... yes - I've been bitten by that kind of thing too...
>>>>>> that
>>>>>> not all that's admissible in a WHERE 'body', is admissible in a
>>>>>> CONSTRUCT 'body'.
>>>>>
>>>>> As far as I'm aware it is -- Tim's original simply misplaced a curly
>>>>> brace. The filter ought to be in the WHERE body.
>>>>>
>>>>> CONSTRUCT is essentially SELECT with a tabular data -> rdf system
>>>>> bolted
>>>>> at the end of the pipeline.
>>>>
>>>> I think the point people were making is that the syntactic shortform
>>>> "CONSTRUCT WHERE" with implicit template only applies when you have a
>>>> simple basic graph pattern [1].
>>>>
>>>> If the WHERE clause is more complex, e.g. with a FILTER, then you need
>>>> an explicit construct template.
>>>>
>>>> Dave
>>>>
>>>> [1] http://www.w3.org/TR/sparql11-query/#constructWhere
>>>>
>>>>
>>>
>>> How did you come to that conclusion?
>>
>> Based on the part of the specification given by link [1] above, which
>> says (my emphasis):
>>
>> "A short form for the CONSTRUCT query form is provided for the case
>> where the template and the pattern are the same and the pattern is
>> just a basic graph pattern **(no FILTERs and no complex graph patterns
>> are allowed in the short form)**."
>>
>> Dave
>>
>
> I see, Dave. However, my intention was to understand the reason behind
> that decision. This quote is not a justification, just a description of
> what's expected to work.
>
> I can't see why restricting the set of where clauses is necessary.

You can consult the email archives and telecon meeting minutes for the 
discussions.  The spec is not going to have a justification for every 
decision; that's not a spec anymore!

It gets increasingly difficult to define what the implicit template 
should be.  What about OPTIONALS? UNION? Subquery?  There was a 
consideration of BGP+FILTER.

In the end, given the constraints of time and other features, the simple 
case (simple to explain, to implement and to specify)  where the 
template and the WHERE pattern are the same was put in the spec. 
Otherwise you need to give the relation of WHERE to template.

	Andy






>

Received on Wednesday, 25 September 2013 14:32:17 UTC