W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: David Wood <david@3roundstones.com>
Date: Sun, 11 Nov 2012 18:18:18 -0500
Message-Id: <B1B61D9D-591B-4A67-8CAB-B04107B79173@3roundstones.com>
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On Nov 11, 2012, at 16:21, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

> On 07/11/12 23:11, Richard Cyganiak wrote:
>> On 7 Nov 2012, at 22:38, Wilde, Erik wrote:
>>> - designate a magic "container of containers" which essentially works as a
>>> container factory. when you create a new member in this container, it by
>>> definition becomes a new container that is then accessible like any other
>>> container.
>> 
>> Yes, that's the model that works well with the current LDP spec. The nice thing about this is that nothing needs to be said about it in the spec -- it's a pure server implementation issue.
> 
> That lacks control on the containers name yet containers represent some significant grouping in the server so I'd expect that the choice of name matters (e.g. same on several servers, differing just by the host name).
> 
>> 
>>> i think there is something to be said about the fact that managing
>>> collections might be a different set of use cases, and maybe should be
>>> pushed to version 2 or whatever comes after what we're currently doing.
>>> for example, it is almost certain that managing collections often will
>>> require a different level of access control and authorization, so maybe
>>> not including this scenario would allow us to keep or eyes focused on the
>>> simpler use cases of just interacting with existing collections.
>> 
>> General +1 for letting the server decide what affordances are available on what resources.
>> 
>> Clients can of course play dirty by faking affordances via PUTting misleading LDP-ontology triples, as Nathan and Henry point out. But servers *can* avoid that by validating the incoming data or giving access only to trusted clients. That seems sufficient, and I don't think that anything needs to be done about this in our spec.
>> 
>> Best,
>> Richard
> 
> A minimal spec is good but it can be too minimal.  We need to decide if it's needed sufficiently that omitting it will lead to incompatible extensions, making an LDP v2 harder to move to consensus.
> 
> The IRC logs example is a good one here - http://w3/irc-logs/2012/12/25 - in 2013, does the server need to have magic or can it be a client that creates 2013, 2013/01, 2013/01/07irc-ldp.ttl (Jan 7th being the first Monday in 2013).
> 
> The filing system analogy might be to just
>   PUT /irc-logs/2013/01/07irc-ldp.ttl
> and have the intermediates created.

The "mkdir -p" functionality is already enabled by a series of client commands, just like the "move" functionality discussed earlier. 

The spec, IMO, shouldn't over specify these kind of composite functions. 

Regards,
Dave


> 
>    Andy
> 
Received on Sunday, 11 November 2012 23:18:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC