W3C home > Mailing lists > Public > public-sparql-dev@w3.org > October to December 2015

Re: CONSTRUCT an RDF Datest

From: Miguel <miguel.ceriani@gmail.com>
Date: Sat, 05 Dec 2015 23:16:31 +0000
Message-ID: <CALWU=Rs_62fmHjZY7AjPLLcjsZb_LyucRbdYP4-mKRhM5=-PhQ@mail.gmail.com>
To: james anderson <james@dydra.com>, public-sparql-dev@w3.org
Hi James,

In the example you show (in the first query) the template of the inner
CONSTRUCT (i.e., ?A1 co-author ?A2) is matched by the BGP of the outer
query (?P1 co-author ?P2 ...) in just one possible way (i.e., ?P1 = ?A1 and
?P2 = ?A2).
If this is not the case, rewriting the query (with SELECT subqueries in the
place of a CONSTRUCT subquery) becomes more complex.
Generally, I guess we must consider all the possible different ways in
which the template of the CONSTRUCT subquery may be matched by the
corresponding BGPs of the "main query".
This can be done but the query will generally grow (combinatorially) in
size.

Furthermore, if property paths are allowed, the would-be-language using
CONSTRUCT subqueries is strictly more powerful than the one without.
The following query cannot be written in SPARQL 1.1

SELECT ?paper ?influentialPaper
FROM {
    CONSTRUCT { ?citingPaper ex:isJournalAndCites ?citedPaper }
    WHERE {
        ?citingPaper a ex:JournalPaper.
        ?citingPaper ex:cites ?citedPaper.
    }
}
WHERE { ?paper ex:isJournalAndCites* ?influentialPaper }

This is just to say that I don't think CONSTRUCT subqueries in FROM/FROM
NAMED can be considered completely "subsumed" by the subquery forms
available in SPARQL 1.1.

Best Regards,
Miguel


Il giorno sab 5 dic 2015 alle ore 22:35 james anderson <james@dydra.com> ha
scritto:

> good evening;
>
> On 2015-12-05, at 21:30, Tara Athan <taraathan@gmail.com> wrote:
>
> I found this paper http://ceur-ws.org/Vol-749/paper19.pdf which proposes
> allowing CONSTRUCT to be nested within FROM and FROM NAMED. I would be
> interested to know if any engines have implemented this as an extension.
>
>
> I gather that this was considered in the development of SPARQL 1.1, but
> not adopted: http://www.w3.org/2009/sparql/track/issues/7
> I don't understand the justification of the closure
>
> > ISSUE-7
> > CONSTRUCT & DESCRIBE queries in FROM [NAMED]?
> >   ??
> >   CONSTRUCT not needed if bNodes can be introduced by constructor.
>
>
> I looked for emails that explain how introducing bNodes by a constructor
> can take the place of composition of CONSTRUCT ( I can't imagine how this
> can be the case, but am willing to read the arguments...) but I can't find
> it.
>
> As background, the usecase I am considering is a CONSTRUCT view that
> creates a virtual RDF dataset (using the Construct Quad extension) and then
> exposes this virtual view to the user for further queries (which could be
> CONSTRUCT, SELECT, or whatever.) This would have the effect of inserting
> the CONSTRUCT view into the FROM clause of the users query.
>
>
> angles/gutierrez proposes three forms of subquery.
> sparql 1.1 includes the second and third forms.
> the first one (from / from named) is less effective then the second, as it
> is not possible to place the results.
> they would have to be merged into the default graph or made available as a
> named graph.
> the subselect form allows to accomplish the same result as that which
> would be produced by the generated dataset combined with the eventual graph
> pattern in the query itself.
>
> taking, for instance, their example 2:
>
> SELECT ?M1 ?M2
> FROM  <http://.../people.rdf>
> FROM ( CONSTRUCT { ?A1 co-author ?A2 }
>        FROM <http://.../biblio.rdf>
>        WHERE { ?Pub author ?A1 .
>                ?Pub author ?A2 .
>                FILTER ( !(?A1 = ?A2) ) }
>      )
> WHERE { ?P1 co-author ?P2 . ?P1 mail ?M1 . ?P2 mail ?M2 }
>
> would be
>
> PREFIX : <http:/example.org/>
> SELECT ?M1 ?M2
> FROM  <http://.../people.rdf>
> FROM NAMED <http://.../biblio.rdf>
> WHERE { { SELECT ?P1 ?P2
>           WHERE { GRAPH <http://.../biblio.rdf>
>                   { ?Pub :author ?A1 .
>                     ?Pub :author ?A2 .
>                      FILTER ( !(?A1 = ?A2) ) } } }
>          ?P1 :mail ?M1 .
>          ?P2 :mail ?M2 }
>
> best regards, from berlin,
>
>
>
> ---
> james anderson | james@dydra.com | http://dydra.com
>
>
>
>
>
>
Received on Saturday, 5 December 2015 23:17:11 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 5 December 2015 23:17:12 UTC