W3C home > Mailing lists > Public > public-ldp@w3.org > June 2013

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

From: Alexandre Bertails <bertails@w3.org>
Date: Tue, 04 Jun 2013 16:14:32 -0400
Message-ID: <51AE4AA8.6010703@w3.org>
To: Henry Story <henry.story@bblfish.net>
CC: Mark Baker <mark@zepheira.com>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
On 06/04/2013 03:13 PM, Henry Story wrote:
> On 4 Jun 2013, at 20:21, Alexandre Bertails <bertails@w3.org> wrote:
>> On 06/04/2013 01:55 PM, Henry Story wrote:
>>> On 4 Jun 2013, at 19:42, Alexandre Bertails <bertails@w3.org> wrote:
>>>> On 06/04/2013 01:10 PM, Mark Baker wrote:
>>>>> On Tue, Jun 4, 2013 at 9:51 AM, Henry Story <henry.story@bblfish.net> wrote:
>>>>>> The HTTP response code tells the client that this is an error code and not the representation.
>>>>> This.
>>>>> Erik, I wish you'd stop invoking the "REST community", when AFAIK,
>>>>> you, Henry and I are the only ones to have ever given serious,
>>>>> brain-cramping thought to the relationship of media types to RDF, and
>>>>> we have you beat 2 to 1 :)
>>>> RDF was not designed with HTTP interactions in mind.
>>> I doubt this. The Open World assumption, URIs for names of relations,
>> URIs, not URLs...
>>> Tim Berners Lee who organised and orchestrated the development of it,
>>> who as far as I know is pretty familiar with HTTP,... all this
>>> goes to tell me that RDF Was designed very much with HTTP in mind.
>> RDF semantics is pretty clear about that:
>> [[
>> The semantics does not assume any particular relationship between the
>> denotation of a URI reference and a document or Web resource which can
>> be retrieved by using that URI reference in an HTTP transfer protocol,
>> or any entity which is considered to be the source of such
>> documents. Such a requirement could be added as a semantic extension
>> ]]
> yes, that's left to other specs. RDF Semantics does not need to go
> into that, it is general enough that it just requires the notion
> of unique reference given by IRIs.
> On the other hand the URI specs, together with the meaning of HTTP URIs
> would probably go into that.  And there
> <http://bblfish.net/people/henry/card>
> refers to the document that you GET with it.
> <http://bblfish.net/people/henry/card#me>
> refers to whatever the previous document describes about it. That's what
> HTTP is about.
>> 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?

>>> That not everybody understood the full picture is another matter.
>> The problem with the "full picture" is that anybody can fit anything
>> that is not yet clearly defined in a document. With that reasoning,
>> you could argue that LDP was always part of the full picture :-)
> You just need to listen to timbl's talks. It was obviously there.
> You just wrote that "RDF was not designed with HTTP interactions in mind."
> In my view it clearly was. That's why its so well built for LDP.

Please point me to any spec that defines how to interact with
something advertising itself as text/turtle (other than LDP of
course). Hint: you should start by looking at why IANA says about

>>>> If I see
>>>> "Content-type: text/turtle", I know that I should look at [1] to know
>>>> about the interactions it allows, but this one does not say anything
>>>> about LDP. At best, I know about the ontology but nothing more.
>>> [1] is not about interactions. [1] tells you how to parse the result and
>>> how to interpret it. That is what mime types do, they allow you to select
>>> among the possible grammers, the ones that you need to interpret the stream
>>> of bytes on the wire.
>> That's not how it works. We register the media-type at IANA to say
>> what is a text/turtle resource.
> No text/turtle is an indication of how to interpret a stream of bytes.

Turtle (and more generally RDF) is only about presentation, it does
not say anything about interaction. It has no standard semantics that
are useful to (REST) API authors. I thought that was why we were
defining LDP.

In my mind (and in Erik's if I understand him correctly),
application/ldp would make explicit the relationship with LDP and its
interactions, while application/ldp+turtle would make explicit the use
of Turtle by referring to text/turtle. We would just need a new entry
in [1].


>> For now, it's still pointing to the
>> Team Submission. Then it will be the REC when the time comes. If you
>> don't know about LDP, then there is no way for you to know what
>> interactions you can have with a text/turtle resource.
> There is no such thing as a text/turtle resource. There are Resources
> that produce text/turtle representations. That is completely different.
> And it's basic Web Architecture.

You're playing with the words. And by the way, webarch is very
explicit about the separation of content, presentation and
interaction. The point is that text/turtle refers to Turtle, and
Turtle is silent about interaction.

>> It's about re-using a standard. The Problem Details spec is general
>> enough to be adapted to our case just by adapting the model to
>> RDF/Turtle (what you did in your example). You can decide to take part
>> of it, that's an option of course but that's a missed occasion.
> RDF stands for Resource Description framwork. The <> above ends up being
> turned into a IRI ( perhaps <http://example.com/borked> that is the IRI
> of the resource ( document ) that you  wanted to GET.

How do you interpret <> in the general case? It works here because
we're in the context of LDP (hence HTTP). But this is not true in the
general case.

> You can then describe that resource with the RDF that the Turtle encodes.
> It's pretty simple.

It is _so_ simple and well defined that we're still arguing about

Also, I don't intend to continue on this thread until people answer me
by pointing at the specs.


>> Alexandre.
>>> Henry
>>>> Alexandre.
>>>> [1] http://www.w3.org/TR/turtle/
>>>>> Mark.
>>> Social Web Architect
>>> http://bblfish.net/
> Social Web Architect
> http://bblfish.net/
Received on Tuesday, 4 June 2013 20:14:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:35 UTC