Aggregation: simple proposal

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.

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

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.

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

> 2/ No duplicates -- sometimes it matters.

For management, no duplicates is an advantage.

Steve.

Received on Wednesday, 2 January 2013 15:51:09 UTC