Re: Proposal to close ISSUE-19: Adressing more error cases, as is

On 06/04/2013 05:26 PM, David Booth wrote:
> On 06/04/2013 04:14 PM, Alexandre Bertails wrote:
>> On 06/04/2013 03:13 PM, Henry Story wrote:
>>>
>>> On 4 Jun 2013, at 20:21, Alexandre Bertails <bertails@w3.org> wrote:
> [ . . . ]
>>>> At most, RDF is HTTP friendly. For example, that's why SPARQL does not
>>>> operate on datasets living on the web (the dataset is behind the
>>>> service), and you need to interact with the resources through the
>>>> service, whether they are HTTP URIs or not.
>>>
>>> I am not familiar enough with SPARQL, so I'll leave that be.
>>> I am familiar with HTTP though, and that is more important
>>> and more widely used.
>>
>> Where -- other than in LDP -- have you seen people defining how to
>> interact with RDF using HTTP?
>
> The SPARQL Graph Store Protocol defines a standard way to manage and
> interact with a collection of RDF graphs:
> http://www.w3.org/TR/sparql11-http-rdf-update/

Heh, I was expecting someone to mention the SPARQL Graph Protocol :-)

Let me explain why I don't think it answers the problem we're trying
to solve, and what we can learn from it.

First, I'll ignore the Indirect Graph Identification approach, as this
is going back to a service approach, which is by definition different
from the REST approach.

The Direct Graph Identification looks way closer to a REST approach,
but it's clearly not (maybe that's why the mentions to REST were
removed in Last Call?). The main issue is that we're manipulating
named graphs instead of the RDF resources directly. A named graph is a
concept that is defined in SPARQL but not in RDF. There is no good way
to find the named graph that contains an RDF resource just by starting
with the RDF resource.

In a nutshell, the SPARQL Graph Protocol allows the named graphs from
a Graph store (supporting SPARQL) to exist on the Web. But it does not
let you interact *directly* with the resources contained by those
named graphs.

Now, there is something very interesting to learn from this spec,
something very relevant in our discussion about the media
types. You'll notice that all the payloads are involving RDF
serialisations. For example, the Content-Type used in the examples is
text/turtle.

So what does it mean if I see text/turtle on the Web?
1. it could be just a Turtle file behind Apache, it's ok if I'm only
doing GETs
2. I may be using the SPARQL Graph Protocol, but I'm not sure until I
try a SPARQL Graph Protocol operation
3. I may be using the LDP protocol
   3.1. it could be an LDPC, if I see <> a ldp:Container, but I'm not
   sure until I try an LDPC operation
   3.2. it could be an LDPR, but I'm not sure until I try an LDPR
   operation

I just have no way to know just by looking at the Content-Type. And we
may have two specs (the SPARQL Graph Protocol and LDP) defining
conflicting interactions for the same media types. None of them is
pointed by the IANA registry for text/turtle.

I believe that one should expect text/turtle to always be the case 1.
I believe that using text/turtle in 2. makes things confusing.
I believe that it's not too late to get it right for LDP, including
how we deal with the errors.

Alexandre.

>
> David
>

Received on Wednesday, 5 June 2013 02:19:53 UTC