Re: SPARQL 1.1 Construct Composition

Thanks for the replies.
The problem I'm tackling is to generate a single (legal) SPARQL query
that is equivalent to the following "pseudo-SPARQL" query:

CONSTRUCT {...}
  FROM ( CONSTRUCT {...} WHERE {...} )
  WHERE {...}

At the same time also the Frithjof case seems interesting to me. If I
correctly understood it would like being able to write something like
the following code:

CONSTRUCT {...}
  WHERE {
    LET B = { SELECT {...} WHERE {...} } .
    { ...
      B
    ... } .
    { ...
      B
    ... } .
 }

For that case I think there is a partial solution (a part from the
naive one of repeating the subquery everywhere is needed).
Using a syntax mapping a SPARQL query to a DAG, like SPIN SPARQL,
parts of the query can be used more than once, avoiding repetition of
subqueries or patterns that are in common between different "query
branches".
But of course we'd need a "SPIN SPARQL" editor capable of directly
generating such a syntax.

Best,
Miguel

On Fri, Feb 22, 2013 at 8:23 AM, Dau, Frithjof <frithjof.dau@sap.com> wrote:
> Hi,
>
> what about using B (as select-query, not construct-query) as subquery in A? If you only have to use the result of B once (!), then this should work fine, and you don't have to worry about having created triples  which are not needed after the execution of A.
>
> Anyway, I am interested in an answer to that as well, as I sometimes had the wish to reuse the result of a query A in a query B several (!) times, and here subqueries do not work.
>
> Best
> Frithjof
>
>
>
>
> -----Original Message-----
> From: Miguel [mailto:miguel.ceriani@gmail.com]
> Sent: Donnerstag, 21. Februar 2013 18:07
> To: public-sparql-dev@w3.org
> Subject: SPARQL 1.1 Construct Composition
>
> Hi everybody,
> I'm studying the possibility of doing automatic functional composition
> of SPARQL (1.1) Construct queries.
>
> A basic use case is the following.
> Throught a SPARQL construct query A, I define a local view of a remote
> SPARQL end point.
> Then I want to execute a (construct or select) query B on this local view.
> To do that, I could materialize the local view and then query it with B.
> But, if I'm able to compose query B to query A in a new query C to
> send to the SPARQL end point, I can have directly the result,
> potentially reducing the amount of data that has to be transmitted.
>
> Has anybody already worked on this?
>
> Thanks,
> Miguel
>

On Fri, Feb 22, 2013 at 8:23 AM, Dau, Frithjof <frithjof.dau@sap.com> wrote:
> Hi,
>
> what about using B (as select-query, not construct-query) as subquery in A? If you only have to use the result of B once (!), then this should work fine, and you don't have to worry about having created triples  which are not needed after the execution of A.
>
> Anyway, I am interested in an answer to that as well, as I sometimes had the wish to reuse the result of a query A in a query B several (!) times, and here subqueries do not work.
>
> Best
> Frithjof
>
>
>
>
> -----Original Message-----
> From: Miguel [mailto:miguel.ceriani@gmail.com]
> Sent: Donnerstag, 21. Februar 2013 18:07
> To: public-sparql-dev@w3.org
> Subject: SPARQL 1.1 Construct Composition
>
> Hi everybody,
> I'm studying the possibility of doing automatic functional composition
> of SPARQL (1.1) Construct queries.
>
> A basic use case is the following.
> Throught a SPARQL construct query A, I define a local view of a remote
> SPARQL end point.
> Then I want to execute a (construct or select) query B on this local view.
> To do that, I could materialize the local view and then query it with B.
> But, if I'm able to compose query B to query A in a new query C to
> send to the SPARQL end point, I can have directly the result,
> potentially reducing the amount of data that has to be transmitted.
>
> Has anybody already worked on this?
>
> Thanks,
> Miguel
>

Received on Friday, 1 March 2013 10:16:44 UTC