Re: Fedora Commons implementation/LDP Feedback

Hi,

Let me try to answer some of your questions...

On Mon, Aug 5, 2013 at 10:57 AM, Chris Beer <cabeer@stanford.edu> wrote:

> 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.
>
Good to hear of your interest.  The implementation wiki page even has
efforts that are planned and may happen.  Just need to be clear what the
status is.  Up to you if you'd like to be added, fill out the template and
email to me (if you don't have direct access to edit).


>
> 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.
>
Yes I can see how this isn't very clear.  I can make an editor's todo to
improve this.  Up to you if you want to raise as formal LC comment.


>
> 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. […]
>
I'm curious what you think it should be, to see if we'd reach the same
conclusion.  Seems like a 400 to me.


>
> 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.
>
Yes, this is what we concluded in the WG as well.  Perhaps the outcome of
the RDF Validation Workshop will provide a direction for use for such a
vocabulary [1].

[1] - http://www.w3.org/2012/12/rdf-val/


>
> 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)
>
We discussed this but we don't have a recommended solution.  As you can
see, you POST the binary data and a companion LDPR should be created.  An
LDPR server implementation will probably take various request headers:
content type, size, creation date, Slug, etc and prime the LDPR with that
data.  A client could later PUT/PATCH any additional meta data.  It would
be good to hear more about what people are doing here, for example if
something we should consider for future spec.  I know there various
implementations have been using multipart POST).


> 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?
>
There are a number of introspection items that are supported within the LDP
spec today.  For example, we using Accept-Post for a server to indicate
what formats are acceptable for POSTing to a LDPC.  Perhaps it would be
good to hear more about the introspection cases you have that are not
covered by the current specification to learn how we could improve in the
future or understand how we might be able to solve them with techniques
already available.

Appreciate the feedback and look forward to hearing about the progress.

Thanks,
Steve Speicher



>
>
>
> Thanks,
> Chris Beer
> Digital Library Systems and Services
> Stanford University Libraries
>
> [1]  http://wiki.duraspace.org/display/FF
>
>