Re: ISSUE-79 ldp:contains

On 3 Jun 2013, at 16:37, John Arwe <johnarwe@us.ibm.com> wrote:

> > That's fine. Many clients may create a member and just go on from 
> > there, without ever doing a GET on the LDPC again. 
> 
> Not what I said.  Most of my clients do the opposite ... only ever enumerate the container's members, never create.  Might update members already listed. 

Ok. So what is the problem. For every relation { a ldp:contains ?b } you'll know
b is one of those members that is an LDPR that was created using POST.

> 
> 
> > It helps us if the ldp:contains relation is the default predicate in
> > our spec, because this is the one 
> > most closely related to the protocol. 
> 
> Not ok making this the default. 
> I care much more about addressing the scenarios I see as most common, which is clients enumerating members.

What do you mean by member?  For the moment my feeling is that you want to say
ANY relation. But in that case why is this not just your business model intruding into the
the spec and LDPC? You can create containers in LDPRs that are not LDPCs, you can
even put them in LDPCs if you want. But that that has nothing to do with the protocol.
I don't see how we are limiting you in any way by defining ldp:contains.

What is your scenario?

IF you think of an LDPC as a Database Catalog, you would not put your domain model
in your catalog: you put it in the tables - in our language in LDPRs that are not LDPCs .

There are an infinity of types of LDPRs. Your domain model can create specialised
forms of LDPRs which will accomplish all possible needs you have. If you want subrelations
of ldp:contains you can create an infinite number of those relations.
 
> Maybe turning this around will be informative: what fails if there is no relation specifically saying which subset of the container's members (membership triples as defined in the spec) also belong to the subset of those *created by* the container?  What can't clients do
> 
We have no way then of saying which resources were created by the container. Clients that
wish to keep track of resources they created in an account, won't have a good way to find
those resources if say their hard disk failed once. 

Then there are a whole number of closely realted things such that usually if you create a 
resource in a container you'll usually also be also able to DELETE, PATCH or UPDATE it too.

Notice we are not saying you cannot have a rdf:member link to other resources. But without
this there is a certain amount of administration work that cannot easily be done. I think Erik
Wilde mentioned this a few times as a princple of HATEOS.




> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/