- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 4 Jun 2013 22:29:24 +0200
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Mark Baker <mark@zepheira.com>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
On 4 Jun 2013, at 22:14, Alexandre Bertails <bertails@w3.org> wrote: > 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? see cwm's log:semantics for example http://www.w3.org/2000/10/swap/doc/Reach > >>>> 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 > text/turtle. As I said text/turtle are representations. You don't interact with those, they don't change - they are sequences of bytes. What you can do is interpret them, ie first parse them, then apply the rules define by that interpretation to create a model - in this case a graph. You can interact with resources on the other hand. HTTP resources can be interacted with using HTTP verbs such as GET/PUT/POST/DELETE > >> >>> >>>> >>>>> 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. URIs are Uniform *Resource* Identifiers REST stands for Representation of State Transfer - where Representations are what are returned by HTTP resources - the things you need mime types for to interpret RDF is *Resource* description Framewrok This is web architecture. > 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]. yes, I understand what he wants to do, but that is a misunderstanding of web architecture that stems from a confusion that arises from using syntaxes such as JSON that don't come with a clear semantics. You need mime types there to fill the gap. You use Resource descriptions to describe resources. If you can describe them as ldp resources and you trust the source that gave you the representation, then you interact with them that way. So if I GET a resource and it says <> a ldp:Container . I can expect to interact with it as an LDP Container. If I can't repeatedly on a site, then I stop interacting with it that way: the same way you avoid spam web sites. > > [1] http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xml > >> >>> 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. I am not playing with words. As I said text/turtle tells you how to interpret the bytes in the body of the HTTP Requrest. The content of the turtle on the other hand can tell you what the resource you are interacting is by refering to it. As I can tell you "I am Henry". > > [snip] >>> 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. What do you mean in the genral case? Outside of HTTP? What has that got to do with LDP in any case then. > >> >> 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 > it... > > Also, I don't intend to continue on this thread until people answer me > by pointing at the specs. Fine. I don't have time to fill you in with background Web Architecture. Perhaps someone else can take the relay. > > Alexandre. > >> >>> >>> Alexandre. >>> >>>> >>>> Henry >>>> >>>> >>>>> >>>>> Alexandre. >>>>> >>>>> [1] http://www.w3.org/TR/turtle/ >>>>> >>>>>> >>>>>> Mark. >>>>>> >>>>> >>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >>>> >>> >> >> Social Web Architect >> http://bblfish.net/ >> >> > Social Web Architect http://bblfish.net/
Received on Tuesday, 4 June 2013 20:29:59 UTC