Re: (un)blessed container use cases and implementation expectations

On 06/11/12 08:50, Richard Cyganiak wrote:
> On 5 Nov 2012, at 22:03, Andy Seaborne wrote:
>> There was a suggestion in the informal TC today was to use RDF
>> lists to create aggregations - i.e. create non-containers with
>> contaiers only as strong containers.
>
> rdf:List in this context makes no sense to me.

Why not?  Perfectly good way to organise links.  With syntax support.

(Wasn't my proposal.)

> What is the use of “weak aggregation” beyond what's described in
> ISSUE-33 (paging) and ISSUE-34 (adding and removing arcs)?
>
> http://www.w3.org/2012/ldp/track/issues/33
> http://www.w3.org/2012/ldp/track/issues/34

> Both of these issues assume that “weak aggregation” is simply a
> completely normal RDF resource, a completely normal node in the
> graph,

A normal RDF resources is a managed as a LDPR.  You can PUT/GET/DELETE.

If there have special operations for manage link relationships it's not 
a plain LPDR.  It's not an LDPC.  It's something else.

I fail to see how this split can work in practice.  What's wrong with a 
container-like thing that has managed (strong containment) members, and 
link to things on other servers as members?  I really don't see how the 
type can be decided at creation time and fixed from then on.

>> But now we have two ways to have grouping of objects.
>
> Not really -- the paging mechanism and the arc adding/removal
> algorithm would likely be the same for all resources including
> containers.

I'll wait to see a proposal before commenting.

> The only ability that's unique to containers is that you
> can POST to them to create a new member.

That's looking only at the data management aspect.

You can enumerate the members - that gives the app a way to navigate the 
LDP space.  It has special status because of the named container 
membership property.

> So there's one mechanism
> that allows server-controlled naming of new resources, and one
> mechanism that allows dealing with nodes that involve many arcs, with
> some resources supporting both.

I'll wait to see a proposal.
(what about a resources with two sections of many arcs?)


>
>> The client will have to know and deal with each differently.
>
> That's fine as long as the two mechanisms are about orthogonal
> concerns. Containers are about server-controlled naming of new
> resources. Think of them as “member factories”. The other mechanism
> is really about handling large numbers of triples with the same
> subject+predicate. Think of them as “property controllers”.
>
>> Or more than 2 - this is no standardized so if every system does
>> it's own thing, clients have to deal with variety.  The point of a
>> platform is lost.
>
> Not sure where this is coming from. Can you explain?
>
>> Is a resource-that-is-an aggregation supporting paging?  What if it
>> has two list - paging needs to identify what's paged.
>
> Paging would have to be on subject-predicate pairs, not on resources.
> So if a person has many friends and many publications, then there
> would be one “property controller” that allows paging through the
> foaf:knows triples and one that allows paging through the
> ex:isAuthorOf triples. The current paging mechanism (which is tied to
> containers -- I suggest that this should change) already works this
> way.
>
>> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0223.html
>
>>
> Well let's see.
>
> [[ 1. Create a resource and add it to a container ]]
>
> POST to the container.
>
> [[ 2. Add an existing resource to a container ]]
>
> Possible answer: You can't do that. Containers are about assigning
> names to new resources. Existing resources already have names and
> don't need to go into a container.
>
> Other possible answer: See ISSUE-34.

How is that an answer? I don't see a proposal in ISSUE-34 beyond the
verb PATCH.

>
> [[ 3. Remove a resource from a container ]]
>
> See ISSE-34.
>
> [[ 4. Remove a resource from a container and delete it ]]
>
> DELETE the resource.
>
>> Does the strong-delete model work for all use cases?
>>
>> (it does not if an existing resource can be put in a container -
>> it's like creating a file, then putting it in a directory AKA
>> linking).
>
> I don't understand why it doesn't work in this case.
>
> Best, Richard
>

Received on Wednesday, 7 November 2012 09:17:26 UTC