Re: Issue-34 Back_to_Basics proposal

Hi John:
I believe the WG accepted your proposal that Container and Aggregation were separate
classes.  We left the ontology open and I recommend, as I had said earlier, that both classes
be modelled as direct children of LDPR
All the best, Ashok

On 2/22/2013 12:09 PM, John Arwe wrote:
> In the process of drafting the changes to update the editor's draft to reflect the WG resolution, I was reminded that the proposal explicitly treated the method by which a client would introspect this affordance (is the ldp:Container acting like an aggregation or what we've been calling a container/strong container) as out of scope.  That is, it used ldp:Aggregation and so on in the text of the proposal to keep things concrete, but also stated (under assumptions) that it had no dependency on ldp:Aggregation for the syntax.  As we also noted in the discussion on this week's call [1], Ashok had proposed an alternative earlier [2].
>
> In order to get 34 fully draftable, we need to close on how we want clients to introspect this affordance.  Since the WG discussion and email threads appear to have simply carried the proposal's assumption of ldp:Aggregation and friends, I drafted up what the resulting ontology might look like (below - just the types of interest for this discussion, not the full document) using that assumption.  Ashok's would be one alternative, although (since [2] was somewhat abstract) this might fall within what Ashok had in mind - I just cannot be sure.  There might be other proposals I've forgotten about, missed, or that people have not yet shared.
>
> I'm thinking that we can at least agree on this specific one, since the WG is "pretty familiar" with it, even if there are others potentially yet to be resolved.  I'll also include it as unresolved in the wiki page I'm building, and I agree in advance that it's *possible* that we'll change our minds about the syntax once we look affordances more generally.  If that were to happen, we'd just have to update this one; in the mean time we can close issue-34.
>
> Also in the drafting process, I found it rather daunting to contemplate the number of places we'd have to update if we used "container" *only* in places where the distinction from aggregation matters.  To simplify that, inherent in the draft set of classes below is a proposal to use container for the "superclass" of both delete behaviors, and "composition" for the "recursively delete members" sub-species.  It does seem to align with Web usage at least.  I also included ldp:Resource since that seems to be where the mailing list discussion was going.
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0109.html
>
> [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0014.html
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
>
>
> :Resource
>     a rdfs:Class;
>         rdfs:comment "A HTTP-addressable resource with a linked data representation.";
>         vs:term_status "unstable";
>         rdfs:isDefinedBy :;
>         rdfs:label "Resource".
>
> :Container
>     a rdfs:Class;
>         rdfs:subClassOf :Resource;
>         rdfs:comment "A Linked Data Platform Resource (LDPR) that also conforms to
>         additional patterns and conventions for managing membership.";
>         vs:term_status "unstable";
>         rdfs:isDefinedBy :;
>         rdfs:label "Container".
>
> :Aggregation
>     a rdfs:Class;
>         rdfs:subClassOf :Container;
>         rdfs:comment "A Linked Data Platform Container (LDPC) that also conforms to
>         additional patterns and conventions for managing members, for example its
>         members may continue to exist after its deletion.";
>         vs:term_status "unstable";
>         rdfs:isDefinedBy :;
>         rdfs:label "Aggregation".
>
> :Composition
>     a rdfs:Class;
>         rdfs:subClassOf :Container;
>         rdfs:comment "A Linked Data Platform Container (LDPC) that also conforms to
>         additional patterns and conventions for managing members, for example its
>         members are deleted as part of its deletion.";
>         vs:term_status "unstable";
>         rdfs:isDefinedBy :;
>         rdfs:label "Composition".
>