Thanks Rob, this also does the job.
What are advantages of this approach compared to using BIND() ? Performance?

Thanks again and best,
Peter

> -----Ursprüngliche Nachricht-----
> Von: Rob Vesse [mailto:[email protected]]
> Gesendet: Dienstag, 24. November 2015 12:02
> An: [email protected]
> Betreff: Re: BIND in CONSTRUCT query with sub-SELECT (SPARQL)
> 
> Instead of BIND you can simply use a project expression, this is essentially
> the same as you would do for a BIND but placed on the SELECT line with
> variables and aggregates e.g.
> 
>     PREFIXES
>     CONSTRUCT { ?s rdfs:label ?var . }
>     WHERE {
>       SELECT ?s (AVG(?single) as ?agg) (IRI(expr) AS ?var)
>       WHERE {
>         ...
>       }
>       GROUP BY ?s ...
>     }
> 
> Where expr is some expression that generates your desired constant
> 
> 
> Rob
> 
> On 24/11/2015 10:24, "Wetz Peter" <[email protected]> wrote:
> 
> >Related to the answer of a previous question of mine (see [1]) I have a
> >new question: I currently have a CONSTRUCT query with a nested SELECT
> >which makes use of aggregates. What I now want to do is to construct
> >new URIs in the CONSTRUCT statement.
> >
> >What I want to do is basically similar as can be seen in [2]. There I
> >see that BIND is used in the WHERE class to construct new URIs which
> >are then used in the CONSTRUCT clause. Unfortunately this approach does
> >not work for my case (nested SELECT which resides in the CONSTRUCT's
> >WHERE clause). The difference is, that in this example no nested SELECT
> >is present.
> >
> >My current query looks like this (simplified):
> >
> >    PREFIXES
> >    CONSTRUCT { ?s rdfs:label ?var . }
> >    WHERE {
> >        SELECT ?s (AVG(?single) as ?agg)
> >            WHERE {
> >            ...
> >            }
> >        GROUP BY ?s ...
> >    }
> >
> >The question is: Where to place a BIND statement which is used to bind
> >values to variables, which are then used in the CONSTRUCT statement (e.g.
> >?var)?
> >
> >Thanks for your help.
> >
> >Best,
> >Peter
> >
> >[1]
> >https://mail-archives.apache.org/mod_mbox/jena-
> users/201511.mbox/%3C194
> >403 [email protected]%3E
> >[2]
> >http://mail-archives.apache.org/mod_mbox/jena-
> users/201111.mbox/%3C4ED6
> >672
> >[email protected]%3E
> 
> 
> 

Reply via email to