W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Thu, 8 Nov 2012 10:40:39 +0000
CC: "Wilde, Erik" <Erik.Wilde@emc.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, nathan <nathan@webr3.org>
Message-ID: <55FCEBB5-DA08-477A-A036-5AF13E63444A@uk.fujitsu.com>
To: Henry Story <henry.story@bblfish.net>

On 8 Nov 2012, at 08:25, Henry Story wrote:

> On 8 Nov 2012, at 00:56, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>> hello henry.
>> On 2012-11-07 15:27 , "Henry Story" <henry.story@bblfish.net> wrote:
>>> On 8 Nov 2012, at 00:12, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>>>> that's what on the web media types are doing. i know that this is way
>>>> outside of the scope of this group, but since we're saying REST in the
>>>> charter, this is what we would be doing in a RESTful design: design a
>>>> media type that represented the concepts we're building interactions
>>>> around, and then making the distinction you're pointing out is done by
>>>> virtue of the media type.
>>> I think you are trying to put too much in the media types. The Media type
>>> is just a way to interpret a document - i.e. to extract its semantics.
>> nope, it's more than that. it defines the set of interconnected resources
>> a client can traverse, and defines that traversing this set of resources
>> means. for every link that a client can find, the media type specifies why
>> a client might want to follow that link, and maybe what a client has to do
>> when following that link.
> You can do that with RDF too, you just choose special vocabularies instead
> of choosing special mime types.

I agree with that. we don't want to go the way of many REST apis where a new mediatype is defined for each (XML schema) type in the system. I think that one mime type will be enough for LDP.


>>>> yup, and that would be the header signaling the media type.
>>> As said above that would be like saying that servers MUST speak a
>>> different
>>> language from the other documents they are serving, which seems arbitrary.
>> it's the opposite. it's the difference in functionality that's exposed as
>> media types.
> That's a mistake, that just happens to work.
>> if you are an XML database, you accept any XML and just store
>> it. that's fine. if you also allow people to interact with any kind of
>> management functionality of the database, what you exchange is still XML,
>> but its meaningful (let's say some XACML for managing access right) and
>> thus labeled by a media type that makes that distinction clear. that's
>> just how HTTP works.
> Http allows you to do content negotiation on a resource to get back 
> a preferred representation of that resource. All representations returned
> should be pretty much equal. That is where the idea of semantics comes from:
> there is something all these representations have in common.
> What you are describing is in my view just a lucky error that people on 
> REST mailing lists have used because it seems enough like it solves the 
> problem, when in fact it just makes things more complicated. For example 
> that way of working makes things a lot more complicated as all of a sudden 
> you have to create a whole syntax for servers to work with, just to 
> distinguish when the server is speaking  from when the document is served by 
> it but is not a statement made by the  server.
> That solution is at the wrong place at the logical layer. What you want is
> information about WHO said something, and the solution you are describing
> is telling me HOW it is said. Then there is a backchannel convention of which
> actors can say something which way to get to the WHO.
> Much simpler would be to at least start out by thinking about WHO is 
> saying something, since the original problem was at that layer. Is the
> server telling me that this is a collection? Or is this just a document
> someone else wrote saying it is a collection?
> In any case on could also just argue: don't put a document saying 
>  <> a ldp:Container
> anywhere. It would be like putting up a web page that was lying, and people
> will end up removing links to that resource, and distrusting servers that 
> publish it. If one wanted to help servers publish documents of people on the
> web they did not fully control, then it would be useful to allow the server to
> say that it is not responsible for what is in the document.
>> cheers,
>> dret.
> Social Web Architect
> http://bblfish.net/

Received on Thursday, 8 November 2012 10:41:38 UTC

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