Re: Issue-37: Ontological Modelling

Hi Henry:
Erik's solution will work.
You either POST to a collection which will create the LDPR or you do a POST which will create
a link to an already existing 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.

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

Received on Tuesday, 22 January 2013 13:35:20 UTC