- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 06 Jul 2015 08:31:24 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Peter, there is little point in continuing a discussion on this topic if
you deny your own previous statements and selectively ignore my own
concerns as it suits your agenda by calling them "irrelevant stuff".
That "irrelevant stuff" is the very reason why blank node support of
SPARQL endpoints is basically unusable.
Holger
On 7/5/2015 21:44, Peter F. Patel-Schneider wrote:
> On 07/04/2015 05:23 PM, Holger Knublauch wrote:
>> 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...
> I did not say that at all. What I said was that blank nodes do not cause
> problems with implementing SHACL by using single SPARQL queries for each SHACL
> shape. Blank nodes in the results are treated just as they would be in SPARQL.
>
> [Irrelevant stuff removed.]
>
>> 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.
> How can this be reconciled with your statement above?
>
>> Holger
> peter
>
Received on Sunday, 5 July 2015 22:32:01 UTC