- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 17 Nov 2009 11:44:48 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 17 Nov 2009, at 11:35, Andy Seaborne wrote: >>> This is where the fact relational algebra rename is just a rename >>> (no >>> expressions, it changes the name of a column) makes a difference >>> here. >>> We could special case the translation to the SPARQL algebra: >>> >>> SELECT ?x => project((?x), ....) >>> SELECT (?x AS ?y) => project((?y), rename(?x as ?y) ....)) >>> SELECT (?x+1 AS ?y) => project((?y), extend(?x+1 as ?y) ....)) >> >> But the example above was MAX(?x), so it would fall under the >> "extend" >> semantics anyway, I think. > > Yes, it would fall under extend - it returns a value - I was bring > up a simpler and yet nasty case :-) > > We do have the opportunity to define MAX itself. MAX/empty-set can > be a defined to return term sparql:noValue. Not a null per se but > it might work out. sparql:noValue + 0 is an error. Right, that may have some slightly strange consequences, and will land us more obviously in tri-value logic space, but overall it may be less confusing to users. The slightly odd corner cases are things like: A) SELECT ?x (MAX(?y) AS ?max) ... you get ?x and unbound value for ? max - probably expected B) SELECT ?x (MAX(?y) + 1 AS ?max1) ... you get no row. But probably users will figure this out. It's reasonably logical. I think SQL would always give you the row, as per A), because NULL+1 is NULL, not an error. - Steve, hoping sparql:noValue wasn't supposed to be a URI :) -- Steve Harris, CTO, Garlik Limited 2 Sheen Road, Richmond, TW9 1AE, UK +44(0)20 8973 2465 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 17 November 2009 11:45:18 UTC