Re: Aggregation: simple proposal

On 02/01/13 15:50, Steve Battle wrote:
> I like Henry's suggestion to introduce LDP ontology to describe the
> containment/compositional relationship using ldp:contains to describe
> (strict) composition.
> It satisfies the need to talk specifically about composition (in the
> strict sense) in a way that is orthogonal to the use of existing RDF
> relationships to describe aggregations.

Yes- let's see if we can separate composition and aggregation.

> Henry suggests that this "can work with the notion of strict containership
> of collections", so in this example the subject is an LDP container. I
> may, or may not, have subverted Henry's original idea.
>
> "<> a ldp:Container; :contains <http://remote.org/resource>"

How about ":manages"?

> Specifically, :contains should be defined to be inverse functional, as no
> more than one resource may contain another.
> The domain would be an LDP Container.
>
> 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?

> To answer Andy's concern that "yet another
> container/collection/aggregation construct is being invented for RDF."
> Yes, but I'm not aware of an existing ontology that defines (strict)
> composition.
>
> I think we should avoid overloading existing aggregation properties
> because we may want the option to add existing (i.e. unmanaged) resources
> to a container via aggregation (e.g. using rdfs:member or its ilk).

+1

In fact, if a LPDC :manages an item, it may not aggregate it, or more 
likely it may aggregate in a specific fashion, saying combining with 
unmanaged or elsewhere-managed links.

So "may want" becomes "will provide"

> Indeed, I see this as the function of the ldp:membershipPredicate; as a
> convenience to create a structured aggregation/collection over and above
> the container structure.
>
>> 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.
>
> 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).

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

>
> Steve.
>

	Andy

Received on Wednesday, 2 January 2013 18:35:26 UTC