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

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. 

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

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

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

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/