Re: future work item: real solution to issue-15 (metadata on non-RDF resources)

On Tue, Feb 25, 2014 at 12:34 PM, Sandro Hawke <sandro@w3.org> wrote:
>
> [This is not Last-Call critical.   Just flagging an item for future work,
when I'm thinking about it.]
>
> We closed ISSUE-15 (sharing binary resources and metadata) by saying that
the server MAY provide metadata via rel=describeby.  (Typo -- the spec says
describedBy.)
>
> In the spec, and in my memory of the discussions, we never provided a way
for the client to provide metadata.   This leaves the problem mostly
unsolved.

This was never a use case people asked for other than using Slug to name
the thing, so there was no problem to solve.  We did talk about it and said
that clients would need to updated separately the associated LDP-RS.  Work
I have done in OSLC [1] in using this approach highlighted there were few
cases where we needed it.   How much meta stuff do you need to send?

So this definitely sounds like LDP++ stuff from what I recall of this
discussion and resolution.

>
> What follows is some brainstorming about how to solve this.   My best
solution is at the end.
>
> My first thought was to mandate the server MUST create and link to an
empty metadata resource.   Then the client can PUT/PATCH there.    But I
think there's a problem with that timing window.   I expect there will be
other clients and processes waiting for NRs to appear, and which will begin
to do things with them immediately.  If the metadata doesn't appear for one
or two RTTs, that could be problematic.
>
> Probably the clean solution, though it's a little more complex, is to use
multipart/related (RFC-2387).   I don't know all the details of how that's
supposed to work, or works in practice, though.
>
> I guess we can just leave this to some future guidance on
multipart/related.     And I guess if one were going to use
multipart/related, one could also allow multiple new Contained resources to
be created at once, which could be useful.
>
> Or maybe use multipart/form-data (RFC-2388), so that users COULD just use
an uploading from a client to post to a server.  That would require a bit
of a hack in pre-determining how ldp:Container resources handle field names.
>
> Oh, this gets really messy, since the metadata wont know the URL for
itself OR the thing it's describing.  It can use the empty URL for one of
those, but not both.   I guess it uses the empty URL for the thing it's
describing and can't refer to itself, ... but that could be bad, too.
>
> Okay, okay, best solution:
>    1.  POST an empty text/plain resource.
>    2.  Pray the server creates a companion metadata resource
>          - you could strongly hint that it should by doing a GET Prefer:
follow-link rel=describedby
>    3.  Fill in the metadata
>    4.  PUT to replace the text/plain thing with the real thing.
>

So you are saying this doesn't work for you as you might expect to not get
the rel=describedBy (meta) resource soon?

1. POST LDP-NR, no meta resource LDP-RS is created and therefore no
rel=describedBy Link header
  Are you worried about not server not providing you this link header?
2. POST LDP-SR, with { <ldp-nr>, wdrs:describedBy, <> } triple

[1] -
http://open-services.net/wiki/change-management/Attachments-for-Change-Requests/

- Steve

>    -- Sandro
>
> [1] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
>