RE: Question regarding subselect



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Steve Harris
> Sent: 1 May 2009 08:51
> To: SPARQL Working Group
> Subject: 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).

The result from ASK is a boolean.

We can make it go in patterns - like UNSAID would have - it's a filter in disguise

But then ({}) and () (that's a solution of one row, no bindings and a solution of no rows) for true and false work so you get the right answers.


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

Observation: If this is a SELECT with a FROM/CONSTRUCT, putting the pattern of the CONSTRUCT onto the front of the SELECT pattern will expose the same information (won't it?).  Currently, a CONSTRUCT template can generate bNodes and introduce new constants but other wise it's the same variables as the pattern.

 Andy

> 
> - 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 08:44:24 UTC