Re: Issue-37: Ontological Modelling

On 22 Jan 2013, at 14:34, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> Hi Henry:
> Erik's solution will work.
> You either POST to a collection which will create the LDPR

You POST a Graph or a binary to a collection,  right? Those are pretty much complementary
classes of things. 


> or you do a POST which will create a link to an already existing LDPR.  

You would POST what to the collection? 
Whatever you POST can be interpreted as a graph or a binary, and so falls into the previous model of 
creating a  new LDPR. 

> When you delete the collection all the members are deleted.  The members may be LDPRs - which gives the containment semantic - or they may be links to LDPRs which gives the aggregation semantic.

Currently at the protocol level a ldp:Container and an ldp:Resource have 
exclusive methods of interaction, which is why those types of objects do not 
have any members in common.

That does not mean that you cannot create different subProperties
of rdfs:member such that one requires deletion and the other not.
Call the one that requires deltion ldp:contains. The problem is that:

  1. you can only add ldp:contains to an ldp:Container, and the
   deletion property be true. 
  2. You have no way of adding with a POST other an rdf:member property
    to a ldp:Collection that is not an ldp:contains relation at present
    ( Perhaps by PATCHing an ldp:Container? That has not been defined though)

In any case distinguishing such a relation would not change that
ldp:Containers and ldp:Aggregations are very different things.



> 
> The advantage of this approach is that you can mix containment and aggregation semantics in the
> same collection.  The disadvantage is that it's a bit more complex and requires the user to
> be smarter.  We could try and fix that with examples in the spec.
> All the best, Ashok
> 
> On 1/22/2013 4:05 AM, Henry Story wrote:
>> 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/
>> 
> 

Social Web Architect
http://bblfish.net/