Re: Aggregation: simple proposal

On 2 Jan 2013, at 18:34, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

>> "<> a ldp:Container; :contains <http://remote.org/resource>"
> 
> How about ":manages"?

Not fussy about the naming, but if you have a container then :contains seems appropriate. :owns is also reasonable.

>> Note that the current topic has switched to 'Composition: simple
>> proposal'. The LDP spec is currently lacking anything like this.
> 
> ?? Did you mean to change the subject line?

Didn't want to lose the thread - just trying to clarify the composition v aggregation distinction.

>> 
>> I see the primary use-case as the management of resources within
>> containers, not for defining any other kind of semantic relationship like
>> author precedence.
> 
> a/ still need to worry about paging a large number of :managed links
> 
> b/ are you saying the the semantic relationship is separately encoded in RDF in the container? (which seems reasonable, caveat the details).
> 

Absolutely - yes - and I wholeheartedly agree with the original subject of this thread to do a sanity check on building aggregations with the limitations of changesets and SPARQL update in mind.

>> 
>>> 2/ No duplicates -- sometimes it matters.
>> 
>> For management, no duplicates is an advantage.
> 
> Agreed - so do you agree that if we go this way, the aggregation aspect is separate and requires repeating, in whatever aggregation fashion is chosen? Aggregations need to have the possibility for duplicates and ordering even if management does not.

Yes. We have two distinct problems:
1) Composition and management of resources with containers, with concerns including lifecycle, entity 'versioning'.
2) Aggregation of resources using existing RDF ontology, with concerns including pagination, ordering, duplication.

Received on Thursday, 3 January 2013 11:13:58 UTC