- From: Tara Athan <taraathan@gmail.com>
- Date: Sat, 5 Dec 2015 15:30:39 -0500
- To: public-sparql-dev@w3.org
- Message-ID: <5663496F.6030306@gmail.com>
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. On 12/5/15 12:38 PM, james anderson wrote: > good evening; > >> On 2015-12-05, at 14:29, Tara Athan <taraathan@gmail.com> wrote: >> >> Given that this extension provides closure in SPARQL over RDF datasets, is it now possible to form nested CONSTRUCTs over RDF datasets, or in some other way specify a chain of RDF dataset queries? >> >> I looked at the extended CONSTRUCT form, but I didn't see any spot to plug in another CONSTRUCT to indicate the derived RDF dataset to be queried. > the bnf phrases which define sub-selects, Subselects seem to be a difference concept to me. I haven't yet seen a connection of Subselect to the concept of CONSTRUCT as a (parameterized) operator from RDF datasets to RDF datasets, which can then be composed because the domain and range are the same. Tara > > > [53] GroupGraphPattern ::= '{' ( SubSelect | GroupGraphPatternSub ) ‘}’ (1) > [8] SubSelect ::= SelectClause WhereClause SolutionModifier ValuesClause (2) > > restrict the sub-expression to be a select form only. > the simple explanation is that the other forms do not include the requisite dimensions for the projected fields and, as such, cannot produce legitimate arguments for the algebra operators. > > this could be rectified, by permitting at least construct and describe variants which included projection dimensions, but that would be an extension. > > > --- > (1) http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#rGroupGraphPattern > (2) http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#rSubSelect > >> Tara >> >> On 11/30/15 4:20 AM, Andy Seaborne wrote: >>> On 29/11/15 23:40, Tara Athan wrote: >>>> On a related note, I see that ARQ Construct quad could easily be used > to construct quads where the name is a blank node. Having the quad >>>> name be a blank node is fine according to RDF >>>> http://www.w3.org/TR/rdf11-datasets/#sec-introduction (and is >>>> desirable in my usecase), but is not permitted according to SPARQL. >>> Yes, that should be there. I'll add it. >>> >>> When it gets into TriG or N-Quads it will become a document-scoped blank node only, as do any other blank nodes. >>> >>>> Are such quads >>>> accepted in practice, or does this cause significant interoperability >>>> problems? >>> It's RDF 1.1 that has taken over defining RDF Datasets and the syntaxes for them, which allow blank nodes for graphs. I presume that any SPARQL revision by a W3C WG would remove the definition of RDF Dataset from SPARQL and use the RDF 1.1 one in its place with all the consequences. SPARQL should not take a different position on data. >>> >>> There is a long standing wrinkle that blank nodes aren't allow by syntax in GRAPH in a WHERE clause. >>> >>> RDF 1.1 adds in a natural requirement for blank nodes in quad data templates in the graph position. >>> >>> It's in the SPARQL errata. >>> >>> http://www.w3.org/2013/sparql-errata >>> >>> (because I have just added it :-) >>> >>>> Tara >>> ARQ supports blank node addressing for when you must. >>> IRI(blank node) returns a suitable IRI. >>> >>> Andy >>> >>> >>> >> > > > --- > james anderson | james@dydra.com | http://dydra.com > > > > > > >
Received on Saturday, 5 December 2015 20:27:48 UTC