Re: Issue-37: Ontological Modelling

On 22 Jan 2013, at 11:59, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

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

The argument I put forward is written up in the Lemma:

 http://www.w3.org/2012/ldp/wiki/ISSUE-37#Lemmas

LDPC and LDPAs/LDPRs are different because of the semantics of 
how you interact with them. 



> 
> cheers,
> 
> dret. 
> 
> 

Social Web Architect
http://bblfish.net/