- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sun, 05 Jul 2015 10:23:24 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
On 7/3/2015 23:21, Peter F. Patel-Schneider wrote:
> On 07/02/2015 05:05 PM, Holger Knublauch wrote:
> [...]
>
>> Since every SPARQL endpoint can be turned into a
>> virtual graph with SPO queries,
> [...]
>
> How can this be done? In particular, how are blank nodes handled?
Oh, in the recent call you said yourself that blank nodes are no problem
at all with SPARQL endpoints...
No, in reality it is very difficult to work with blank nodes on
endpoints. Although it's possible to run SPARQL queries that internally
use bnodes, it is impossible to communicate about them. So for example
if a bnode is the subject of a constraint violation, there is no way to
follow up with more requests to check if the bnode has been fixed, to
add triples about it or even to ask about triples involving that bnode.
I think this is an unfortunate limitation of the result set
serialization format that could easily be fixed by introducing bnode
identifiers and _:ID syntax, but that's not what the standard currently
says. All this is probably a left-over from the old days of RDF before a
proper query language was created (SPARQL), where bnodes were treated as
existential wildcards. Let's better not go there. None of these
limitations exist when you are working with an API and datasets directly
- there is no text serialization involved but they work on node objects
directly.
A graph interface in general requires an implementation of a function
such as find(s, p, o) : iterator of triples. As long as these don't
involve bnodes, they can obviously turned into SELECT * WHERE { ?s ?p ?o
} queries, substituting the variables with the constants from the find call.
Holger
Received on Sunday, 5 July 2015 00:24:08 UTC