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

On 19 Jan 2013, at 14:57, Steve Speicher <sspeiche@gmail.com> wrote:

> On Fri, Jan 18, 2013 at 6:11 PM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 18 Jan 2013, at 22:23, Steve Speicher <sspeiche@gmail.com> wrote:
>> 
>>> 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 ?
>> 
>> I should perhaps have chosen a different namespace for these, and not
>> ldp. Perhaps ldpTst or something.
>> 
>> The point of having these three classes, and these two relations,
>> is just to help with clarity. These don't have to be adopted
>> officially. Having a ldp:contains and an ldp:member, and having
>> these have different rdf:domains, does not mean we cannot then make
>> them owl:sameAs some well known vocabulary later, or adopt them for
>> ldp.
>> 
> One primary difference with the owl:sameAs approach is the global
> nature of that statement.  Perhaps there are cases with my specific
> application where the predicate is only a 'containment' predicate for
> the current associated container, not every and all instances.  The
> ldp:memberPredicate minimizes the scope.

Do you accept the following rule?

CONSTRUCT { ?rel rdfs:subPropertyOf rdf:member .}
WHERE {
?collection a ldpx:Collection;
   ldp:membershipPredicate ?rel . 
}

If so then that would seem to be consistent with claim :c1
of my recent response to Arnaud's mail in this same thread
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0125.html


{
 ldpx:contains rdfs:subPropertyOf rdfs:member .
 ldpx:member rdfs:subPropertyOf rdfs:member .
}  defendedBy [ = g1; foaf:member Arnaud ];
  owl:sameAs :c1 .


> 
>> I just find rdfs:member a bit confusing because it comes with a baggage
>> of semantics which is probably not what we want here, or if it is
>> we need to discover that. In any case I did not think it was a good
>> idea to bring that baggage into the discussion when discussion the
>> concept of containership, membership, and aggregations.
>> 
>> 
>>> 
>>> 3) What are the semantics of these collections?
>>> 
>>> <1> a :Collection;
>>> :contains <a>;
>>> :member <b>.
>> 
>> That was left undecided in what I said. It may be possible for
>> a collection to exist with both, or not.
>> 
>>> 
>>> <2> a :Container;
>>> :member <c>, <d>.
>> 
>> member had a domain of a ldp:Aggregation. So the definition only
>> allows that if there is an intersection between ldp:Aggregation
>> and ldp:Container
>> 
> 
> Didn't catch the domain restriction.
> 
>>> 
>>> <3> a :Aggregation;
>>> :contains <e>, <f>.
>> 
>> same as above, but check the definition for :contains in
>> http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>> 
>>> 
>>> <4> a :Container, :Aggregation;
>>> :contains <g>, <h>.
>> 
>> you can either decide that contains can be a relation on both container and
>> Aggregation, or find a relation the is a super property of contains  to do the
>> job.
>> 
>>> I'd recommend that if there is a conflict, then aggregation is the
>>> default.  Though I don't feel strongly about it.
>> 
>> I had not thought through this. But as you see having the above vocabulary
>> written out does make it possible to pose those questions clearly.
>> I think one would have to work from first principles and some intuitions.
>> 
>> So currently the :contains relation means that if you delete the :Container,
>> all its contents, that is after binding the ?container variable in the
>> query below with the name of your container
>> 
>> SELECT ?c
>> WHERE { ?container :contains ?c }
>> 
>> 
>> then all the answers to the above query get deleted too.
>> This is what you'd expect say if you take a filing cabinet and say
>> throw it on the fire. The cabinet burns and so does
>> the content. That is why I think we are using the word "Container"
>> and "content"
>> 
>> It is also what you'd expect if you take a file hierarchy view of a url.
>> so if you delete the "img/" container in
>> 
>> http://example.co/people/joe/img/2012/22-soldiers.jpg
>> 
>> then you have made it impossible to write anything after
>> http://example.co/people/joe/img/.*
>> 
>> Btw we notice that if you delete a container you delete it's
>> contents but as a consequence also the members of some aggregations
>> (they suddenly won't refer to anything anymore) - and it would make
>> sense for a consistent server to delete the elements of those aggregations.
>> 
>> Ok, so those are some intuitions one can build on.
>> 
>> 
>>> 
>>> 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.
>> 
>> I am not sure what you mean. Say you have a
> 
> I'm not sure how to explain it much differently other than, if I have
> a ldp:Container in hand (as a client) and I want it to have
> ldp:Aggregation semantics, do I need to create a new ldp:Aggregation,
> add members from Container.   

I think I found some very good arguments that ldpx:Container and ldpx:Aggregation
are disjoint. Again see the claim c3 and its defense here:

http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0125.html

( Perhaps I should add these to the wiki )

If that argument is right then you need to create a new 
ldp:Aggregation. But perhaps there is no need to pull in one
by one all the members of the collection into the aggregation.

Perhaps your aggregation could refer to your collection by 
reference. One would like to say something like:

<aggReg> a ldpx:Aggregation;
   owl:superClassOf <.> ;
   ldpx:member <http://some.remote/thing> .

ie: <aggReg> has all the members of <.> + <http://some.remote/thing> .

The difficulty with that is that:

 1) We need to work out if an ldpx:Container can be an rdfs:Class 
    What would that entail? ( is that not implied by our using 
    rdf:member in the current spec? )
 1.1) If it can be then of course an the above would mean that an 
     ldpx:Container cannot be  disjoint with an  ldpx:Aggregation 

There may be other ways of expressing that all the members of one
ldpx:Collection are members of the other though. But some such way
would make it easy to create aggregations that contain all the members
of a collection plus some links.


> Or do I PATCH the ldp:Container with <c>
> rdf:type ldp:Aggregation?

The possibility of PATCHing an LDPContainer is another 
thing again.


> 
>> <http://example.co/people/joe/img/> a Container.
>> 
>> then you DELETE
>> 
>> <http://example.co/people/joe/img/>
>> 
>> and then you could have
>> 
>> <http://example.co/people/joe/img/> a Aggregation.
>> 
>> It seems ok. The way I am thinking it at present, as I write my server
>> is that anything that ends in a / is a Container and everything else
>> an LDPR  of which  some can be (or define) an LDPA.
>> 
>>> 
>>> 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?
>> 
>> Is that not clear in the examples here:
>> http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>> 
>> ?
>> Are you asking if you can also POST a graph to an Aggregation?
>> 
> 
> I'm asking if semantics are the same for POSTing to a Container.  I
> would think it would be desirable that they both would have the same
> semantics.  I can see why LDPRs would be different, it would seem odd
> that POST to Aggregation would be different than POST to Container.

I think POST to an LDPA that is an LDPR and POST to an LDPC  clearly have
different semntics as I argued above and in reply to Arnaud in this thread.
In one case you create a  resource, in the other case you don't ( eg 
you add a link to some remote resource ). There were 3 more reasons I have.
Those are very different things in terms of protocol logic.

But to tell you the truth I only discovered this whilst arguing it out
in this thread.

> 
>> If as suggested today in ISSUE-45 you can POST some RDF to a LDPR to
>> append the triples to that LDPR, then POSTing the triple
>> 
>> <#ion> :member <http://bblfish.net/>
>> 
>> to
>> 
>> <http://localhost:9000/2013/aggReg>
>> 
>> would add that triple to the <aggReg#ion> aggregation, which
>> would be a way to add content to the aggregation. Notice that you
>> don't thereby create a new resource to do a GET on.
>> 
>> 
>> 
>>> 
>>> [1] - http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>>> 
>>> --
>>> - Steve Speicher
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> --
> - Steve Speicher

Social Web Architect
http://bblfish.net/