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

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.

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, 

> 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. The only ability that's unique to containers is that you can POST to them to create a new member. 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.

> 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.

[[
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 Tuesday, 6 November 2012 08:51:21 UTC