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

Re: Fedora Commons implementation/LDP Feedback

From: Martin P Pain <martinpain@uk.ibm.com>
Date: Tue, 6 Aug 2013 15:18:24 +0100
To: Chris Beer <cabeer@stanford.edu>
Cc: public-ldp@w3.org
Message-ID: <OF9733A743.F3A32F3E-ON80257BBF.004E422B-80257BBF.004E9F1B@uk.ibm.com>
> 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) 

This is also something that I'm interested in - a convention for POSTing 
some non-RDF (likely binary) data with some RDF metadata describing it.
Is anyone aware of any such conventions?

Thanks,
Martin




From:   Chris Beer <cabeer@stanford.edu>
To:     public-ldp@w3.org, 
Date:   05/08/2013 16:47
Subject:        Fedora Commons implementation/LDP Feedback



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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Received on Wednesday, 7 August 2013 12:14:50 UTC

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