- From: Chris Beer <cabeer@stanford.edu>
- Date: Mon, 5 Aug 2013 07:57:20 -0700
- To: public-ldp@w3.org
Hi all, I'm a developer with the Fedora Futures project [1], building a durable content repository with some linked data principles baked into it. We discovered the LDP spec recently, and I've spent some time trying to bring our project into alignment (which, fortunately, was fairly straightforward). It may be too early to add to the wiki, but we're certainly interested in the WG's output. I've collected some comments and requests for clarification, which I'm happy to also send to public-ldp-comments, if that's a more appropriate venue for some of these comments (presumably thread-per-issue?). 1) Paging and base-URI resolution Section 4.2.12 states: > LDPR servers must assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource. Later in the document (5.1.3), this is given as an example: > # The following is the representation of > # http://example.org/netWorth/nw1/assetContainer/ > <> > a ldp:Container; > > <?firstPage> > a ldp:Page; > ldp:pageOf <>; (I'm not very clear on RDF base URI, so maybe I'm missing something there, but…) the example suggests (to me) the resource URL is used as the base URI, not the request URI. 2) When an LDPC server rejects PUT requests with inlined member information, should there be a suggested error code? > 5.5.3 LDPC servers should not allow HTTP PUT requests with inlined member information in the request representation. […] 3) The HTTP PUT clause allows LDPR servers to ignore properties: > 4.5.1 If HTTP PUT is performed on an existing resource, LDPR servers must replace the entire persistent state of the identified resource with the entity representation in the body of the request. LDPR servers may ignore server managed properties such as dcterms:modified and dcterms:creator if they are not under client control. My LDPR server can define what properties are managed and will be ignored. This is probably outside the scope of LDP, but I am interested in a vocabulary for expressing that. 4) We're interested in, but don't have a solution for, sending a single request containing both LDPR and non-LDPR data. Often, we'd like to send both some binary data and some metadata about the binary in one request. Is something like this in-scope for LDP, or can anyone suggest an alternative approach (e.g. using multipart post requests with well-known part IDs) 5) I'd appreciate additional guidance about LDPC servers creating non-LDPR members: > 5.4.3 LDPC servers may accept an HTTP POST of non-RDF representations for creation of any kind of resource, for example binary resources. See 5.4.13 for introspection details. I've implemented basic introspection logic (e.g. is it an RDF format we support? make a new LDPR member, otherwise make a non-LDPR member), however, we may want to store RDF formats as non-LDPR blobs. We've added an additional query parameter for forcing the correct behavior, but is there an approach LDP could recommend or standardize? Thanks, Chris Beer Digital Library Systems and Services Stanford University Libraries [1] http://wiki.duraspace.org/display/FF
Received on Monday, 5 August 2013 15:47:43 UTC