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

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

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.


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

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