Re: ldp-ISSUE-75 (monotonicity): rdf:membershipProperty makes LDP PATCHing non-monotonic [Linked Data Platform core]

> This mean you may have to parse the whole graph to get to know how 
> to deduce the ldp:includes relation I postit in ISSUE-79

[reads, rubs eyes, searches using browser, refreshes, searches again]
*what* ldp:includes relation ... in ISSUE-79 ?


> This means also you are requiring inferencing. 

I'm starting to wonder what you mean be inferencing, if we have different 
definitions of THAT floating around too (it's prose, wouldn't be the first 
time).  So to get more concrete quickly, tell me what You mean by that. 
What's the minimum "doing X" that qualifies as a 'yes'/maximum that means 
'no'.

> Is this closed world inferencing? 

Ditto.  Is this
> the  ldp:membershipPredicate has 
> to be in THAT graph. 
the operational definition of 'closed inferencing' here?

One problem I'd see is that I don't know what URI corresponds to 'THAT'. I 
can retrieve HTTP URI R and get back an LDPC (or several) none of whose 
subject URIs is R.  I would probably (speaking now as a human) conclude 
that R 'names' the graph (1:n LDPCs) in the response.

Off the cuff, I look at this as: the server gives you back a graph of 
triples, i.e. assertions, you have to decide as a client whether or not to 
trust any/all of them.  This no different with one graph than with 
multiple.  If you trust more than one server or combine more than one 
graph, you can get (back) conflicting statements; be a big client and deal 
with it, one way or another ("help!" is one way).  Nothing LDP-specific 
about any of that.


> ok. Note that if a resource other than the given <ldpc> says 
> 
>    <ldpc> a ldp:Container .
> 
> Then I cannot conclude that the ldp:membershipPredicate is rdf:member .

Your application can choose to trust any (including none) of them.
Let your use cases and their constraints be your guide.



> We have an asymmetry here between how the LDPC can speak about itself, 
> and how other resources can speak about it.

Why is this different from any other part of RDF?  Anyone can assert 
anything about anything - literally.  Just watch competing news channels 
or weather forecasts, not limited to RDF either it's just reflecting the 
real world.

I see nothing to support the statement above aside from an 
application-level decision.  If your app chooses to trust one over the 
other, do it.



> Still you have the same problem now. Any resource and than the <ldpc>
> resource itself has to specify both the ldp:membershipPredicate and the 
> ldp:membershipSubject . 

Excellent!  Same problem, same solution - I call re-use!

Could your graph (input data, maybe in this case you'd call it metadata) 
be incomplete?  Yup.  Will your client's behavior be other than as desired 
given incomplete/incorrect input?  Likely.


> The ONLY place where you can have the default
> reasoning is in the LDPC itself!

Most reliable place (pesky trust issues!) probably.  Only place?  Hardly.



Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario