Re: Issue-37: Ontological Modelling

On 2013-01-21 22:22 , "Andy Seaborne" <andy.seaborne@epimorphics.com>
wrote:
>1/ The reference may be to an external resource.
>2/ An LDP-R may be in several aggregations.
>3/ An LDP-R may exist before it's put in an aggregation and be a free
>standing resource (one person in several address books)
>Server-driven deletion isn't appropriate.
>A container provides management, which is ties to the creation, sole
>managed reference and responsibility.  An aggregation does not have
>those features.

i still don't understand why we would even have to differentiate
collections for containment and aggregation, this unnecessarily
complicates the model. a collection accepts members. these may be
self-contained or have a link to external content, but the collection
doesn't care. the collection just manages whatever you hand it. it does so
with the protocol-relevant data that members MUST/SHOULD/MAY specify.
content is not protocol-relevant data, it's payload.

- if you always POST self-contained members, you effectively have a
"containment" collection.

- if you always POST members with references, you effectively have an
"aggregation" collection.

- you can happily POST a mix of both, and when GETting each member,
clients can tell which member is self-contained and which is linked,
because of what they GET.

- when you DELETE the collection, you DELETE the things that you've POSTed
to it. nothing more, nothing less.

what's keeping us from simplifying our model like this, and why would we
need to distinguish "collection types"? what's the benefit of a more
complicated model?

cheers,

dret.

Received on Tuesday, 22 January 2013 11:00:27 UTC