W3C home > Mailing lists > Public > public-ldp@w3.org > March 2013

Re: Question about binary resources: metadata/representation distinction

From: Erik Wilde <dret@berkeley.edu>
Date: Fri, 15 Mar 2013 09:20:00 -0700
Message-ID: <51434A30.8090809@berkeley.edu>
To: Reto Bachmann-Gmür <reto@apache.org>
CC: "public-ldp@w3.org" <public-ldp@w3.org>
hello reto.

On 2013-03-15 03:43 , Reto Bachmann-Gmür wrote:
> I have to questions about binary resources:
> - May the server support PUT to create new binary resources?

probably not, given the current state of discussions. PUT will be 
supported for updating existing resources, though.

> - The sepc explicitely allows POSTS of binary resources, how that the
> server distinguish between binary resources and LDPR? E.g. how does it
> knows if the intention is to upload an HTML file with RDFa, a textbook
> example of a Turtle document where the comments are relevant or maybe if
> the client want to upload the triples but the server doesn't support
> this serialization format. In other words how does LDP addresses the
> metadata/representation issue that URIQA[1] addresses with the MPUT HTTP
> method?

generally speaking, HTTP uses media types to distinguish between 
interaction vocabularies, so that's what LDP will do. specifically, for 
the problem you're asking, there are two possible solutions:

- you can have one collection URI to POST to and use the POSTed media 
type to distinguish between an LDP resource (when the POST uses the LDP 
media type), or a different one (when the POST uses a non-LDP media 
type). in the latter case, the POST is interpreted as a "binary 
resource", but the naming "binary" here is obviously unfortunate because 
it can be any media type (other than the one LDP is using). the obvious 
disadvantage of this approach is that you cannot have "binary resource" 
(i.e., non-LDP resources) that actually use the LDP media type. this may 
be a trade-off you're willing to except to keep things simple. if not, 
the second approach is the following:

- have two collections that accept POST, with one only accepting the LDP 
media type and always interpreting such POST requests as creating an LDP 
resource. a POST of *anything* to the other collection (the "media 
collection") always is interpreted treating the POSTed opaquely as a 
"media resource", in which case you could safely POST a resource with 
the LDP media type to this collection, and then it would be treated 
opaquely. this design is more powerful than the first one, but requires 
that POSTing is supported in a way that the service can distinguish 
between an LDP resource that should be interpreted, and one that shouldn't.

which of these patterns is used is still open.


Received on Friday, 15 March 2013 16:20:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC