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

Re: Creation of Containers

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 8 Nov 2012 09:25:03 +0100
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, nathan <nathan@webr3.org>
Message-Id: <9321C719-C7E3-4577-B4C6-F9A970BEBEAE@bblfish.net>
To: "Wilde, Erik" <Erik.Wilde@emc.com>

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.

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

Received on Thursday, 8 November 2012 08:25:53 UTC

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