- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 8 Nov 2012 09:25:03 +0100
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, nathan <nathan@webr3.org>
- Message-Id: <9321C719-C7E3-4577-B4C6-F9A970BEBEAE@bblfish.net>
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 http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 8 November 2012 08:25:53 UTC