Re: Question regarding subselect

Yes, that's my fault, I think I created that wiki page - SubQuery  
would have been a better name, and was my intention. It's SQL legacy  
where the only query verb is SELECT. Well... actually there's SHOW,  
but it's a bit different and you can't do sub-shows.

SubASKs don't have to go in a FILTER, they're also useful in WHERE  
clauses, assuming they project either a solution with no bindings (for  
true) or no solutions (for false). Which I believe matches the SPARQL  
algebra (it matches my implementation of ASK, at least).

I'm not convinced FROM { CONSTRUCT ... } achieves anything, but it may  
aid composability.

- Steve

On 30 Apr 2009, at 21:24, Axel Polleres wrote:

> If have a related question. Do we really talk only about subSELECTS  
> or should we - more generally speak about subQUERIES.
>
> I have the impression, that also ASK and CONSTRUCT subqueries in  
> Specific places make sense, like:
>
> CONSTRUCT subqueries in FROM/FROM NAMED clauses
>
> SELECT ...
> FROM {CONSTRUCT ... }
> WHERE
>
> ASK subqueries in FILTERS
>
> SELECT ...
> WHERE { pattern FILTER( !ASK {...} )}
>
> agreed? The latter would, BTW, be an alternative way to express  
> negation.
>
> Axel
>
>
> Steve Harris wrote:
>> On 30 Apr 2009, at 11:48, Simon Schenk wrote:
>>> If we do not add any features such as aggregates, scalar  
>>> expressions, assignment
>>> or similar - do subselects add anything to the expressiveness of  
>>> the language?
>>> All examples in the wiki include at least one such additional  
>>> feature.
>>>
>>> Typical uses such as FORALL or EXISTS should be possible in the  
>>> current version
>>> of SPARQL using a combination of OPTIONAL, BOUND filters and  
>>> perhaps DISTINCT, I
>>> think.
>> There's nothing you couldn't do with multiple queries before. But,  
>> you can do new things using DISTINCT and LIMIT inside the subselect  
>> in one query, that's enough to do LimitByResource in many cases,  
>> which you can't do without SubSelects.
>> Example off the top of my head (may be incorrect):
>> SELECT *
>> WHERE {
>>  ?x a foaf:Person
>>  SUB {
>>    SELECT ?name
>>    WHERE { ?x foaf:name ?name }
>>    LIMIT 1
>>  }
>>  SUB {
>>    SELECT ?mbox
>>    WHERE { ?x foaf:mbox ?mbox }
>>    LIMIT 4
>>  }
>> }
>> Currently we don't implement sub queries, so we end up doing  
>> something like 20, where 1 would be fine.
>> - Steve
>
>
> -- 
> Dr. Axel Polleres
> Digital Enterprise Research Institute, National University of  
> Ireland, Galway
> email: axel.polleres@deri.org  url: http://www.polleres.net/
>

-- 
Steve Harris
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 Friday, 1 May 2009 07:51:19 UTC