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

On 1/19/13 6:26 AM, Henry Story wrote:
>
> On 18 Jan 2013, at 22:56, Arnaud Le Hors <lehors@us.ibm.defendedByom 
> <mailto: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.

For the record, good stuff Henry! This is the way to achieve clarity re. 
these matters.


Kingsley
>
>
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>
>>
>> Steve Speicher <sspeiche@gmail.com <mailto:sspeiche@gmail.com>> wrote 
>> on 01/18/2013 01:23:01 PM:
>>
>> > From: Steve Speicher <sspeiche@gmail.com <mailto:sspeiche@gmail.com>>
>> > To: "public-ldp-wg@w3.org <mailto:public-ldp-wg@w3.org>" 
>> <public-ldp-wg@w3.org <mailto: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/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen