Re: Issue-34 Back_to_Basics proposal

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


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