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

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.

> 
>> 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.

> 
>> 
>>> 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.

> 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.

> 
>> 
>>> 
>>> To be honest, I've never been sure how LDP was solving this issue. I'd
>>> be happy to know the general answer.
>> 
>> So by now, I no longer no what issue you are talking about.
>> 
>> I can guess. If you get a 401 and you have a well known ontology of
>> error descriptions, and the error description says something like
>> 
>> HTTP/1.1 403 Forbidden
>> Content-Type: text/turtle
>> Content-Language: en
>> 
>> @prefix : <http://problems.example/#>
>> ...
>> 
>> <> :hasproblem   [ a <http://example.com/probs/out-of-credit>;
>>         dc:title "You do not have enough credit.";
>>         atom:summary "Your current balance is 30, but that costs 50.";
>>         :problemInstance  <http://example.net/account/12345/msgs/abc>;
>>         :balance [ currency:dollars 30 ],
>>         :accounts  ( <http://example.net/account/12345>,
>>                      <http://example.net/account/67890> ) .
>> 
>> What else do you need? The 403 tells you that your transaction was forbidden, and so the
>> content can only be an explanation of the problem, not a description of the resource.
> 
> 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. 

You can then describe that resource with the RDF that the Turtle encodes.

It's pretty simple.

> 
> 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 19:14:26 UTC