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

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

> 
> 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? )

Just looked up the definition, and I discovered that that is not the
case.

[[
The rdfs:domain of rdfs:member is rdfs:Resource. The rdfs:range of rdfs:member is rdfs:Resource.
]]
 http://www.w3.org/TR/rdf-schema/#ch_member


> 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 


I think that even if it were the reasoning would in fact be wrong: I 
would be mixing two different classes.

ldpx:Aggregation and ldpx:Container are both rdfs:Classes 
containing  individuals that are themselves collections. 
So there may be no ldpx:Aggregation that is an ldpx:Container, 
but that does not mean that individual ldpx aggreations may not
have overlapping or the same members as individual ldpx:Containers.

ldpx:Collections are not Sets, and their identity is not defined
by their membership.

in any case the "<> owl:superClassOf <.>" relation won't work (at present
for the reasons above) One would need to invent a relation to 
incorporate the members.

> 
> 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/
> 

Social Web Architect
http://bblfish.net/