- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 10 May 2012 13:13:55 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
This completes ACTION 614 [[ Write up the different design options on BINDINGS/VALUES to the mailing list for voting ]] Assuming we go ahead with VALUES (née DATA) [1] for putting a constant table into a query pattern, what do we do about BINDINGS? BINDINGS is a similar feature but more restricted (only allowed on the end of a query). BINDINGS is the same in the algebra level but can only occurs after pattern evaluation, aggregation/grouping and all the solution modifiers, but before select expressions (reviewing this, that last bit seems wrong but minor). With just VALUES in a query pattern, a subquery could emulate the effect. If we allow VALUES on the whole query, I suggest putting this after select expressions so the data table is joined with the query results server side. Then it is functionally exactly as if the client had done the same; it can result in substantially less network traffic. BINDINGS and VALUES have slightly different syntax; VALUES has been tweaked to make writing one variable easier and made multiple variable tables more consistent. Options: 1/ Remove BINDINGS, and allow VALUES at that same syntax point. 2/ Allow both forms, keeping BINDINGS as a legacy way of saying what can be said with VALUES. 3/ Keep BINDINGS, not allow VALUES at this point. Personally, I'd go for (1) in this case - take the short term hit of a change to syntax, apologies to early adopters that this a discontinuous change and not end up with legacy for many years. c.f. HAVING and FILTER -- HAVING is simply a FILTER after grouping/aggregation. Traditionally it's called HAVING (from SQL). We discussed using FILTER. Only user expectation persuaded use to use a different word. In this case, there is no such tradition. Andy [1] Thread from: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0076.html
Received on Thursday, 10 May 2012 12:14:33 UTC