Re: Feedback on Henry's proposal for ISSUE-34

Having written this it is also be possible to make the distinction I wanted
to make without the use of the notions of ldpx:contains or ldpx:member
relation, by simply defining an ldp:Container this way:

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .


ldp:Container a rdf:Class;
    rdfs:note """
     Deleting a Container with an HTTP DELETE method call MUST delete all its members.
       More precisely: for a container with URI Uc, let the set of its contents S, be all 
        the results given by the query

           SELECT ?c 
           WHERE {  ?container a ldp:Container; 
                              rdfs:member ?c . }     

      where ?container is bound to Uc. Then deleting the resource named by Uc should delete all 
      the resources named in the set S . 
      Furthermore deleting any resource ?r in the container ?c, such that 
          ASK { ?c rdfs:member ?r } .
      MUST remove the element R from the container C. 
    """;
    vs:term_status "unstable";
    rdfs:subClassOf ldp:Collection .

ldp:Aggregation a rdf:Class;
    rdfs:note """
       Creating,  Updating or Deleting an Aggregation does not have any necessary implication as to 
       the state of its rdfs:member object.   This is very different to an ldp:Container.  
       Similarly deleting updating or altering resources that are members of an ldp:Aggregtion
       does not have any required implication on an ldp:Aggregation.
    """ ;
    vs:term_status "unstable";
    rdfs:subClassOf ldp:Collection.

ldp:Collection a rdf:Class;
   vs:term_status "unstable";
   rdfs:note """
   Information Resources ( things that one can interact with HTTP verbs on the Web ) that can have sets 
   of rdfs:member and that are defined by the LDP Spec.
    """ .

As this was meant to be a simple proposal, I have simplified everything on 
the page, now, as I realise that I was adding more new elements than
I had intended to.

http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

So now we should have something that does not really depart at all from the
spec, other than by introducing the class ldp:Aggregation .

Henry

On 19 Jan 2013, at 12:26, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 18 Jan 2013, at 22:56, Arnaud Le Hors <lehors@us.ibm.defendedByom> wrote:
> 
>> I agree with Steve. In particular, I don't see why we need to introduce new predicates to indicate membership. 
> 
> I did this essentially so that we can discuss the ontological implications of the spec in 
> a formal manner. 
> 
> Earlier in the thread people were clamouring for clear distinctions, which led to
> your proposed vocabulary. If we can express those distinctions in natural language then certainly we can also define them in RDF. The advantage is that we then have a namespace,
> and a reference for the words we use, and we can be clear as to what different people
> are proposing and how they are disagreeing. Note that the clarity does not mean 
> rigid determination of everything. RDF is built on the open world assumption. Every
> statement you make in RDF is a restriction on the set of interpretations ( the set
> of possible worlds in which that statement is true ), which can be then later clarified
> with further restrictions. But you don't close the world by doing it.
> 
> It is also possible to specify vocabulary items as unstable and later remove them. Perhaps the following is better.
> 
> @prefix ldpx: <http://www.w3.org/ns/ldpx#>.
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
> 
> 
> ldpx:Container a rdf:Class;
>     rdfs:note "deleting a Container deletes all its members";
>     vs:term_status "unstable";
>     rdfs:subClassOf ldpx:Collection .
> 
> ldpx:Aggregation a rdf:Class;
>     rdfs:note "This covers what was known as weak aggregation.  Deleting an Aggregation does not imply the deletion of its members" ;
>     vs:term_status "unstable";
>     rdfs:subClassOf ldpx:Collection.
> 
> ldpx:Collection a rdf:Class;
>    vs:term_status "unstable";
>    rdfs:note "Thing that can have members, that has some notion of containership, to be clarified further" .
> 
> ldpx:member a rdf:Property;
>     rdfs:domain :Aggregation ;
>     vs:term_status "unstable";
>     rdfs:note "the relation between an aggregation and its members. Deleting an aggregation does not necessarily delete the members" .
> 
> ldpx:contains a rdf:Property;
>     rdfs:domain :Container ;
>     vs:term_status "unstable";
>     rdfs:note "the relation between a container and its contents. Deleting a Container deletes all the resources related to the container by this relation" .
> see: http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
> 
>> 
>> The spec currently defines ldp:membershipPredicate which you can use to specify which predicate you use with a default to rdfs:member. 
> 
> ok, so what we have then is 
> 
> {
>   ldpx:contains rdfs:subPropertyOf rdfs:member .
>   ldpx:member rdfs:subPropertyOf rdfs:member .
> }  defendedBy [ = g1; foaf:member Arnaud ];
>    owl:sameAs :c1 .
> 
> It would be a further topic of simplification then to claim
> 
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
> {
>   ldpx:member owl:sameAs rdfs:member .
> }  defendedBy g2 ;
>    owl:sameAs :c2 .
> 
> I think I agree with those, but since that is one further step of reasoning, I did not
> want to assume that extra step immediately.  I suppose that c1 and
> c2 is currently the default position of the LDP group. So I can add those to my
> ontology. 
> 
> Unless I name these terms clearly, it is difficult to work out what people are aiming at.
> In fact expressing the above questions becomes difficult.
> 
>> 
>> Unless we want to support a mix bag type of collection in which some members are contained and others are aggregated (i.e., some are deleted and others aren't when the collection is deleted) we don't need to add anything else than what we have. I'd say let's simply reuse ldp:membershipPredicate for Aggregations. 
> 
> Ok, so 
> 
> { 
>    ldpx:Container owl:disjointWith ldpx:Aggregation  .
> }  defendedBy [ = g3; foaf:member Arnaud ];
>    owl:sameAs :c3 .
> 
> And I think there are excellent reasons to accept that too, most important of which:
> 
> 1. when you POST content on an ldpx:Container you 
>    a) will create a new GETable resource whose name is added to the ldpx:Container via the (implied) ldpx:contains 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 ( which is an LDPA ) then 
>   a) the contents of the graph are appended to the LDPR,
>   b) the relative URIs are resolved relative to the LDPR
>   c) ie: no new resource MUST be created.
> 
> The nice thing is that we now have a proof for why those are disjoint. So you can add
> me to the members of g3
> 
> ie 
> 
>   g3 foaf:member <http://bblfish.net/people/henry/card#me> .
> 
>> 
>> In general, I think we should try and minimize the number of things we invent.
> 
> indeed, but using the RDF reasoning tools at our disposal makes things a lot
> easier. So we should also make sure we use the tools available to us when 
> thinking about things ( I am not saying we need to have an LDP Server implement
> reasoning! )
> 
> Here is one more thing that came up. In the examples I named the LDPA with
> a hash in order to be able to distinguish it from the LDPR it was defined it. Ie:
> I named the LDPR <http://localhost:9000/2013/aggReg> and the LDPA 
> <http://localhost:9000/2013/aggReg#ion>
> 
> I think that there are two further interesting claims people could make
> 
> Some would like to say that LDPRs can be LDPAs
> 
> {
>   [] owl:intersectionOf ( ldpx:Resource ldpx:Aggregation ) 
>       owl:differentFrom owl:Nothing .
>  }  defendedBy g5;
>     owl:sameAs :c5 .
> 
> That is compatible with my example. It is just that in the example I tried
> not to take the special case. Essentally it would allow 
> 
> <http://localhost:9000/2013/aggregation> to contain 
> 
> { <> a ldpx:Aggregation . }
> 
> Others may want to claim that
> 
> {
>    ldpx:Aggregation rdfs:subClassOf ldpx:Resource .
>  }  defendedBy g6;
>     owl:sameAs :c6 .
> 
> And there may be good reason for that, but I am not aware of it yet.
> 
> 
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>> 
>> 
>> Steve Speicher <sspeiche@gmail.com> wrote on 01/18/2013 01:23:01 PM:
>> 
>> > From: Steve Speicher <sspeiche@gmail.com> 
>> > To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
>> > Date: 01/18/2013 01:23 PM 
>> > Subject: Feedback on Henry's proposal for ISSUE-34 
>> > 
>> > Henry's simple aggregation proposal [1] is close to the model I have
>> > in mind.  I have a few comments:
>> > 
>> > 1) ldp:Collection - this seems unnecessary in vocabulary.  We now need
>> > to define semantics of it.  For talking/terminology it is ok.  it
>> > would be simpler to just have ldp:Container and ldp:Aggregation.  I
>> > don't really see one as a subclass as the other.
>> > 
>> > 2) Why do we need ldp:member and ldp:contains?  What if my model
>> > already has terms defined like foaf:knows?  Do I need to insert
>> > another triple for each entry of the container vs. just using
>> > ldp:containerMemberPredicate?  If I did have my foaf:knows, would it
>> > be expected that I would link to ldp:member?  If so simply use
>> > owl:SubPropertyOf ?
>> > 
>> > 3) What are the semantics of these collections?
>> > 
>> > <1> a :Collection;
>> >    :contains <a>;
>> >    :member <b>.
>> > 
>> > <2> a :Container;
>> >    :member <c>, <d>.
>> > 
>> > <3> a :Aggregation;
>> >    :contains <e>, <f>.
>> > 
>> > <4> a :Container, :Aggregation;
>> >    :contains <g>, <h>.
>> > 
>> > I'd recommend that if there is a conflict, then aggregation is the
>> > default.  Though I don't feel strongly about it.
>> > 
>> > 4) Can I convert a Container to an Aggregation (or vice versa)?  It
>> > would seem that it might make sense to go from Container->Aggregation
>> > but not the other way, otherwise we'd have to define a bunch of rules.
>> > 
>> > 5) Interaction model for resource creation: I would assume the way to
>> > create a resource and add it to a collection would not change for
>> > Aggregation, POST representation to collection, resource created and
>> > added to collection.  Right?
>> > 
>> > [1] - http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>> > 
>> > --
>> > - Steve Speicher
>> > 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/