Re: ISSUE-75 Non-montonic - was: ISSUE-71: second bug tracking example

On 31 May 2013, at 21:14, John Arwe <johnarwe@us.ibm.com> wrote:

> > Just to say "contains" is a bit vague vague. We want a superset of 
> > the elements created 
> > by POSTing to the container. There may be other ways of creating 
> > LDPRs but in the 
> > end one ought not to be able to tell the difference. 
> 
> +1 so far.  yipee! 
> 
> > "POSTed or created in a manner that would be equivalent to had they 
> > been POSTed" 
> > 
> > What about that? 
> 
> The set I think we need to describe is larger still.  It includes members that were created by PUTing/PATCHing membership triples, which is the only mechanism within LDP to accomplish adding an *existing* resource to a container's membership.  What Roger likes to call the "by reference" case. 

By-reference is totally different! That is exactly what I want to not have confused with ldp:contains.
You can add any relations to a graph with PATCH ( within the constraints of logic ).  But the container
is not necessarily responsible for the resources that define the objects of those relations.  So in this 
LDP spec we do not need to concern  ourselves with those relations.
 
The ldp:contains relation is the one I think the container needs to track, since the container was responsible
in creating them. Nobody else is thus responsible. That is the big distinction.

If we have ldp:contains, roger is fully ok to use rdf:member or other relations if he wishes. Those don't imply
creation: the only one that does is ldp:contains. 


> 
> Fine that using PUT for that is discouraged (SHOULD NOT), but PATCH was intentionally left open for that purpose and we have openly discussed that.  We've not discussed it as much recently because work on the PATCH format is moving more slowly than we'd hoped, but PATCH is the only practical alternative I see for adding/removing (sic - not creating/deleting) members at large scale.  Even if it's not a practical spec topic in the first version, we know we'll need it.  It's a When, not an If. 

PATCH is not about creating LDPRs but about adding or deleting relation _IN_  LDPRs! This is completely different. You
don't create LDPRs with PATCHes ( other than perhaps because of logical consistency requirements... )


> 
> 
> > The point of the argument about ldp:creationRule is not to define 
> > the final relation, but to 
> 
> You've been a strong advocate for what I'd call WYSIWYG predicate naming, so I'd expect you'd be all for this.  I was trying to get to something more neutral, not decide on the final value. 

yes, but now I am starting to think that your more "neutral" point of view is one that is making the confusion I described above.
LDP is about HTTP interaction semantics. So it should not be surprising that we have a relation that takes the effects
of those interactions into account.

> 
> Management of the 'other relations' that are the subject of this discussion extends beyond creation (regardless of HTTP method).  It includes deletion of the membership-object resource as well, for example.  If we agree on the members of the set described above, connecting it intimately to create should be obviously wrong-headed.  If we don't, then it's the same issue poking through in multiple ways. 
> 
> 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/