BINDINGS and VALUES

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