Re: On ISSUE-58: Property for asserting that complete description of members is included in LDPC representation

Yes, I do remember that [1] now.  I did like it at the time.  I think it 
has the same problem I attempted to outline in my May 1 email however. 
Although it might be possible to handle that as part of the definition of 
the new header (more on that after I attempt to demo the problem).

Re-pasting option D from Arnaud's April 30 email [2]
Option D:

# The following is the representation of
#                 http://example.org/netWorth/nw1
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp:      <http://www.w3.org/ns/ldp#>.
@prefix o:       <http://example.org/ontology/>.

<>
   a o:NetWorth, ldp:Container;
   ldp:membershipPredicate o:asset;
   o:asset <a1>, <a2>.

<a1>
   a o:Stock;
   o:value 10000.
<a2>
   a o:Bond;
   o:value 20000.

HTTP Headers:
X-Cacheable-for: http://example.org/netWorth/nw1/a1
X-Cacheable-for: http://example.org/netWorth/nw1/a2

I think that does work *in the subset of cases* where the following is 
also true (below are representations of <a1> and <a2>):
# The following is the representation of
#                 http://example.org/netWorth/nw1/a1
@prefix o:       <http://example.org/ontology/>.

<a1>
   a o:Stock;
   o:value 10000.


# The following is the representation of
#                 http://example.org/netWorth/nw1/a2
@prefix o:       <http://example.org/ontology/>.

<a2>
   a o:Bond;
   o:value 20000.


In other words, it works when HTTP GET <URL> returns a representation 
whose triples (assumption 1: it's an RDF media type, not a text file) all 
have a subject of <URL> or <URL#anything>.  If you prefer, all the triples 
have a subject whose effective HTTP request URI would be <URL>.  A very 
natural case for anyone familiar with OO, certainly all of my devs start 
off with this case in mind.

I don't think it works in the general case of RDF/LDP where /a1 and /a2 
may contain other triples.

If you add in Steve's wish for etags, then you also need to match up each 
etag value with the correct URI it describes ... probably doable, and 
maybe even worthwhile, but you can see the direction it goes in I suspect. 
 

(counter-) Example: I think it fails in the case where the assets happen 
to link back to their container, which is something we've discussed.  If 
the linkage changes the representation of /a1 to the following (trivial to 
imagine similar changes to /a2)

# The following is the representation of
#                 http://example.org/netWorth/nw1/a1
@prefix o:       <http://example.org/ontology/>.

<a1>
   a o:Stock;
   o:value 10000.
<http://example.org/netWorth/nw1> o:asset <a1>.

Then Arnaud's example (including new headers) is valid, but ...wait for 
it... how would a cache know that <nw1,o:asset,a1> triple was part of <a1> 
rather than <nw1>?  I don't see that it can know without actually 
performing the retrieval action -- which is what this new header is trying 
to avoid/enable in the first place.  To push things to an extreme: how 
does the cache know from the original nw1 response whether or not 
<nw1,a,ldp:Container> (or ANY other triple) is part of ANY of the 
resources named in the new extension header?  I am unable to answer that 
question.

One easy fix might be to say that the server is only permitted to expose 
this new header for LDPRs when the additional assumptions are met.  I 
suspect that IF we attempt that some of us would like to permit my 
counter-example too - this is a pattern that some parts of IBM use quite 
happily.  Doing so would require more thought (I'm optimistic that doing 
so is feasible, just have not attempted it).  There might easily be other 
patterns like my counter-example that others want to admit as well.


[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0049.html 
(thank you Roger)
[2] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0141.html

Best Regards, John

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




From:   John Arwe/Poughkeepsie/IBM@IBMUS
To:     Linked Data Platform Working Group <public-ldp-wg@w3.org>, 
Date:   05/01/2013 07:09 AM
Subject:        Re: On ISSUE-58: Property for asserting that complete 
description of  members is  included in LDPC representation



> My preference would be for option D (I was convinced by Pierre-Antoine's 
argumentation a few weeks ago). 
Could someone provide a [URL] to some version of that argumentation ?  I 
have a sense it occurred on one of the calls I missed for travel. 
In advance of that, I'm hopeful that it tells me what kind of cache could 
use this proposed header and how. 
I don't think an HTTP cache would find it useful.  Without knowing which 
subset of the response where the header occurs corresponds to the response 
for each of the asserted cacheable members' contents, I don't see any way 
for a pure HTTP cache (by which I mean one unaware of RDF and LDP) could 
do this, even given the proposed cacheable assertion and matching etags. 
If we talk instead about an RDF/LDP-aware cache, I can see how it Might 
work for storing triples only but as soon as the HTTP response comes into 
it I'm back to it not knowing how to divide up one response into several, 
since the set of triples returned by each HTTP URL can overlap arbitrarily 
in the general case. 
There are assumptions under which things are easier (e.g. 1 HTTP URL == 1 
RDF resource, i.e. a given HTTP URL's state consists only of RDF triples 
whose subject URI's HTTP request URI == the HTTP URL lvalue), but that is 
an assumption not anything that LDP guarantees. 
Best Regards, John

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