W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2009

RE: SPARQL 1.1: project expressions and type errors

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 30 Oct 2009 15:33:48 +0000
To: Arjohn Kampman <arjohn.kampman@aduna-software.com>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3694058EF9A@GVW1118EXC.americas.hpqcorp.net>


> -----Original Message-----
> From: public-rdf-dawg-comments-request@w3.org [mailto:public-rdf-dawg-
> comments-request@w3.org] On Behalf Of Arjohn Kampman
> Sent: 30 October 2009 14:17
> To: public-rdf-dawg-comments@w3.org
> Subject: SPARQL 1.1: project expressions and type errors
> 
> Dear WG,
> 
> I was wondering how a SPARQL query engine should handle project
> expressions that apply an operator to an incompatible argument. For
> example with the following query with ?p bound to a URI:
> 
>     select ?s, datatype(?p) as ?q
>     where { ?s ?p ?o }
> 
> I can think of two ways to handle this:
> 1) Produce a solution with ?q unbound
> 2) Do not produce solutions for these cases
> 
> What would be the best way to handle this?

Yes - this is one of issue that needs to be nailed down.  We need to go for a consistent error handling approach with, say, aggregates.  Another choice - fail the whole query - would seem out of keeping.  For me, your choice (2) accords closely with errors in FILTERs.

	Andy

> 
> Regards,
> 
> --
> Arjohn Kampman, Senior Software Engineer
> Aduna - Semantic Power
> www.aduna-software.com

Received on Friday, 30 October 2009 15:35:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 October 2009 15:35:20 GMT