Re: Issue-37: Ontological Modelling

On 22 Jan 2013, at 12:58, Henry Story <henry.story@bblfish.net> wrote:

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

Here: I updated it 

[[


{ 
   ldp:Container owl:disjointWith ldp:Aggregation  .
}  defendedBy [ = g1; foaf:member Arnaud, <http://bblfish.net/people/henry/card#me> ];
   = <#lemma1>;
   rdfs:note """
Reasons:
POST semantics are different:
1. when you POST content on an ldp:Container you 
   a) will create a new GETable resource whose name is added to the ldp:Container 
      via the rdfs:member relation
   b) and relative uris in the posted document are interpreted relative to 
      the created resource
2. when you POST a graph onto an LDPR ( or an LDPA ) then
  a) the contents of the graph are appended to the LDPR  (if 
    ISSUE-45 passes ( http://www.w3.org/2012/ldp/track/issues/45 )
  b) the relative URIs are resolved relative to the LDPR
  c) no new resource MUST be created.
DELETE semantics are different:
1.LDPC 
  a. Deleting an LDPC will delete all its members
  b. Deleting a LDPC member directly, removes it from the LDPC
2.LDPA
   a. Removing a resource membership relation from an LDPA does not delete the resource itself.
   b. Deleting a resource that is a member of an LDPA does not delete the rdf:member relation from the LDPA 
""" .
]]


> 
> 
>> 
>> cheers,
>> 
>> dret. 
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/