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

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

> > So we want it to be the case that when we read 
> 
> For some values of 'we', i.e. I read the statement to assert broader consensus than I have seen evidence for to date. 
> 
> > 
> >   <> ldp:contains <member> . 
> > 
> > we don't need any more relations to conclude that <member> was created by the 
> > LDPC <>  . 
> 
> 'created', sigh.  If I can read 'was created by' as 'is a member of' without changing your intent, OK so far.  If not, I start disagreeing here.  Since you later equate ldp:contains with "membership relations", my less create-centric phrasing should work. 

I use creation vocabulary to give the relation a protocol level meaning. 
We used to have DELETE semantics that could give the relation meaning at the
protocol level too.

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. Perhaps that is the way to think of
it:

"POSTed or created in a manner that would be equivalent to had they been POSTed"

What about that?

> 
> >        ldp:creationRule [ subject <source>;  property ex:attachment ] . 
> 
> Applying the same rationale as for my changes above, and taking inspiration from your later words, would ldp:memberRule work?  Because I think this should be every bit as useful for a read-only container (populated via out of band implementation means, or for other reasons) as it is for a "create-enabled" container. 
> 
> If 'member' is too contrary to your purpose as I begin to think I might understand it, ldp:relationExistenceRule ?  I resisted the urge to stick Inference in there for several reasons, not the least of which being I think it's trivially easy to avoid the use of inferencing as this group would mean it in the implementation. 

that would be ok, but then perhaps ldp:member would be better instead of ldp:contains.

The point of the argument about ldp:creationRule is not to define the final relation, but to 
point in the direction of a space one can look to that may satisfy the use cases people 
here wanted when they were asking for ldp:membershipXXX relations. The simple
membershipXXX relations are problematic as argued in ISSUE-75. So, thinking out loud,
I got to a solution with one level of indirection that seemed to get us out of the problem, 
while revealing what seems like a hidden rule. This is a better position to be in because 
once we move to an inferential space we can use the work in semweb logic to help us go further
in understanding what we are doing, and we have some very good work done in semantic
web reasoning to help us along.

So in short: 
 •  the current ldp:membershipXX relations don't work if my reasoning is correct
 •  for people keen on ldp:membershipXXX rels one needs to find a way of describing 
   to ldp agents either:
     a.  that by creating a resource in a specific LDPC they are going to add a relation 
          somwhere else
     b.  or a way of saying that certain relations in certain graphs imply an ldp:contains 
         relation
    
I think the main use case people want is (a). Perhaps (a) and (b) are the same
problem with (b) describing (a) declaratively. 

Hope this helps,

	Henry

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

Social Web Architect
http://bblfish.net/