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 <[email protected]> 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 | [email protected] | http://dydra.com
