Re: Aggregation: simple proposal

Henry - excellent, real examples.

There are certainly lots of ways to do general aggregation because, at 
some level, linking to another resource is "aggregation".

This is the sort of thing that would go well in a primer to explain good 
practice so that there is some commonality that clients can exploit in 
working with different LDP instances.

To draw up consequences of Henry's default suggestion:

1/ No ordering -- if it's authors of a paper or a playlist, order 
matters.  Also for paging, some kind of ordering for stable pages may be 
required.

(digression below)

2/ No duplicates -- sometimes it matters.

3/ These are equivalent to untyped links.

	Andy

Digression:

The LDP-C text describes the use of an auxiliary property (o:value in 
example 3) for a semantic ordering of a container although it's not 
completely deterministic (what is two o:value are the same?)

At a minimum this needs to be declared:

<http://example.org/netWorth/nw1/assetContainer>
   ldp:orderingPredicate o:value

but what I see as happening is that yet another 
container/collection/aggregation construct is being invented for RDF. 
Each time this happens there is a belief "it's better" but really "its 
better for some cases and not for others."

IBM - what alternatives were considered for containership?

On 19/12/12 13:58, Henry Story wrote:
> Since Andy started a mail on aggregation just now, I'll put forward
> a default suggestion that can work with the notion of strict containership
> of collections we have settled with at TPAC2012.
>
> 1. Create a aggregation container
> ----------------------------------
>
> POST your collection to the container
>
> <> primaryTopic <#wk> .
>
> <#cnt> a WeakContainer;
>      :contains <http://remoThe LDP-C text describes the use of an auxiliary property (o:value in example 3) for a semantic ordering althouhgh it's not completely deterministic (what is two o:value are the same?)

At a minimum is needs

<http://example.org/netWorth/nw1/assetContainer>
   ldp:orderingPredicate o:value
te.org/resource>,
>             <localRes> .
>
> This creates a resource named say <resourceC> which defined
> <resourceC#cnt> .
>
> the :contains relation is left open for later.
>
> 2. Delete your container
> ------------------------
>
> send an HTTP delete message
>
>    DELETE resourceC HTTP/1.1
>
> or change the container as below by removing the <#cnt> from <resourceC>
>
> 3. Change your container
> ------------------------
>
> Say you want to remove <http://remote.org/resource> from <resourceC#cnt>
> then just
>
> PUT resourceC HTTP/1.1
> ...
>
> <> primaryTopic <#wk> .
>
> <#cnt> a WeakContainer;
>      :contains <localRes> .
>
> 4 Optimisations
> ---------------
>
> Define a Patch method to make it efficient to make changes.
>
> Using SPARQL - just as an example - one could
>
> DELETE { <#cnt> :contains <http://remote.org/resource> }
>
> Since one does not use lists, this is really easy.
>
> Henry
>
>
> A short message from my sponsors: Vive la France!
> Social Web Architect
> http://bblfish.net/
>

Received on Thursday, 20 December 2012 10:14:44 UTC