- From: Miguel <miguel.ceriani@gmail.com>
- Date: Tue, 8 Jul 2014 10:28:03 +0200
- To: james anderson <james@dydra.com>
- Cc: "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>
Hi, I would add that the original expected behaviour could be achieved using LIMIT: SELECT ?a ?b { { BIND(1 as ?a) BIND(1 as ?b)} UNION { BIND(2 as ?a) BIND(2 as ?b)} } LIMIT 1 But of course, using LIMIT, the other variations you discussed for the union would lead to having always at least one unbound variable. I guess it is developer's choice, according to the application, to choose between sampling a whole tuple or separately sampling a value for each variable. Best, Miguel On Tue, Jul 8, 2014 at 8:16 AM, james anderson <james@dydra.com> wrote: > good morning; > > On 8 Jul 2014, at 02:36, Jeremy J Carroll <jjc@syapse.com> wrote: > > Ah yes > > What about > > SELECT (SAMPLE(?a) as ?A) (SAMPLE(?b) as ?B) > { > { BIND(1 as ?a) } > UNION > { BIND(2 as ?b)} > } > > then 1, 2 looks like an attractive answer > > > should that remain ones expectation in this case as well? > > SELECT (SAMPLE(?a) as ?A) (SAMPLE(?b) as ?B) > { > { BIND(1 as ?a) } > UNION > { BIND(2 as ?b)} > UNION > { BIND(3 as ?b)} > } > > > Jeremy > > > On Jul 7, 2014, at 3:49 PM, james anderson <james@dydra.com> wrote: > > good morning; > > On 8 Jul 2014, at 00:27, Jeremy J Carroll <jjc@syapse.com> wrote: > > > > I was thinking about SAMPLE and feel that there is a bug with the spec > because it allows > > > A=1 B=2 > > as an answer from > > SELECT (SAMPLE(?a) as ?A) (SAMPLE(?b) as ?B) > { > { BIND(1 as ?a) BIND(1 as ?b)} > UNION > { BIND(2 as ?a) BIND(2 as ?b)} > } > > > I think the principal of least surprise would suggest that a single select > should use the same solution to pick out the sample values, giving either > 1,1 or 2,2 as possible solutions here. > > > what would be the consequence of a solution in which one of the variables > was not bound? > > > Jeremy > > > > > --- > james anderson | james@dydra.com | http://dydra.com > > > > > > > > --- > james anderson | james@dydra.com | http://dydra.com > > > > >
Received on Tuesday, 8 July 2014 08:28:53 UTC