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


From: Tara Athan <taraathan@gmail.com>
Date: Sat, 5 Dec 2015 08:29:46 -0500
To: public-sparql-dev@w3.org
Message-ID: <5662E6CA.50706@gmail.com>
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.


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
Received on Saturday, 5 December 2015 13:27:07 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 5 December 2015 13:27:08 UTC