Re: MKCOL for making collections

hello alexandre.

On 2013-01-22 22:52 , "Alexandre Bertails" <bertails@w3.org> wrote:
>On 01/22/2013 03:27 PM, Wilde, Erik wrote:
>>On 2013-01-22 19:13 , "Alexandre Bertails" <bertails@w3.org> wrote:
>>> Can you define what you mean by "LDP home document"?
>> not in a very specific way right now, but something following the spirit
>> of http://tools.ietf.org/html/draft-nottingham-json-home, providing a
>>way
>> how clients can start navigating the most important affordances of a
>>REST
>> service starting from a LDP home resource.
>In the case of LDP, I have the feeling that the LDPC from where you
>want to create a sub-LDPC would be its own home document anyway. At
>least, I don't see a counter-example.

every resource in REST is interconnected with others through links, so
yes, you could call many resources "home documents". in practice, however,
there often are resources that are better suited than others to start
interacting with a service, and this is what pretty much every REST
service has, explicitly or implicitly. think of it, like mike amundsen
often puts it, as "UX for web devs". how do you make common tasks easily
achievable? it's the same question as for home pages in human-oriented web
pages: you make common tasks available with as few clicks as possible.

a home document really isn't anything fancy at all, it is just a good
landing spot for a client that wants to start interacting with a LDP
server, and doesn't have a URI from previous interactions or bookmarks.
where would you send it to make things easily reachable? where would it
find convenience links such as a list of all collections currently
managed, and a link for creating new collections? this is what such a home
document is supposed to do.

>>how linking is done exactly (i.e., which interactions affordances are
>> exposed by which resources) still needs quite a bit of work, and in the
>> end specific URIs don't matter anyway. but i'd assume that many services
>> might expose a home resource at some URI x, and that there may be a
>> collection factory that might end up creating x/y collections, but all
>>of
>> that really is up for the implementation to decide. it might also decide
>> that the home resource is x and then a new collection always has a URI
>> x/collection/y or something along these lines.
>If I know that X is an LDPC, and that the LDP spec tells me how to
>create a sub-LDPC from there directly, then I don't need anything
>else, do I?

the spec couldn't tell you unless we hardcode URI patterns, which i very
much hope we're not doing. so the only way to support collection creation
would be to include a link for that in the representation of a collection.
if we do that, we're fine. and if we want to allow sub-collections, then
maybe linking their "factory URI" from a collection makes a lot of sense.
but that still wouldn't answer the question how to create a new collection
that's not a sub-collection of an existing one. we need to provide a link
for that interaction as well.

>It looks like the home document notion is overkill to me and much more
>general.

it is general and maybe we don't need the exact way it's proposed
currently. but any REST service does have some form of "preferred entry
point" where clients are supposed to have a useful set of interaction
affordances they can start working with. whether you call this resource
"home document" or not is mostly a matter of terminology.

cheers and thanks for the feedback,

dret.

Received on Wednesday, 23 January 2013 08:23:40 UTC