Re: Issue-37: Ontological Modelling

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

maybe : 

<> ldp:link <http://www.someremoteserver.com/Tracker/1/Bug/1> .

Roger

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