Re: ACTION-4: Review SPARQL Graph Store Protocol and suggest how we should move forward with it

* Steve K Speicher <sspeiche@us.ibm.com> [2012-09-20 08:15-0400]
> > From: Andy Seaborne <andy.seaborne@epimorphics.com>
> > To: public-ldp-wg@w3.org, 
> > Date: 09/19/2012 05:51 PM
> > Subject: Re: ACTION-4: Review SPARQL Graph Store Protocol and suggest 
> how 
> > we should move  forward with it
> > 
> ..snip..
> > 
> > LDBP is unsuitable for data management - it forbids general RDF data, 
> > for example. (4.1.9 - "BPR representations MUST use only the following 
> > standard datatypes"; 4.4.5 is also problematic where it hints at 
> > changing the predicates it does understand; 4.1.4 is at odds with IRI 
> > resolution; other requirements are problematic in intent and approach).
> > 
> > If LDBP for BPRs removes the restrictions on simple "upload-download" to 
> 
> > result in the same data then it might be able to use GSP(direct), and in 
> 
> > fact it would just be RFC2616.
> > 
> > LDBP for BPCs is not relevant for graph stores.  Graph stores do not 
> > have such a container model.
> > 
> > Alternative:
> > 
> > Why not make LDBP for BPRs be simply a link to RFC 2616? + discussion 
> > that text/turtle be provided.  Then a plain HTTP server can be used to 
> > provide LDBP for BPRs (not BPCs).
>  
> I confess, I am not following what you are proposing here.

I think the idea is that LDBP define HTTP verbs on containers but let
HTTP (or GSP) to define the interactions with resources. So if I start
with the first blue box under
<http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/#bpc-paging> and
I POST

  [] a o:Stock ; dcterms:title "Big Co." ;
     o:value 200.02 ; dcterms:date "2012-09-15"^^xsd:date .

LDBP defines the behavior, which includes creating a resource like
<http://example.org/netWorth/nw1/assetContainer/a5>. Now, if I PUT,
GET, DELETE, FOLD, SPINDLE, or MUTILATE that resource, LDBP, GSP and
HTTP all tell you what to expect (well, HTTP gives you a lot of
freedoms we probably don't want, like, having the resulting resource
not look like the PUT representation). If it's acceptable that a POST
append resources, we can use GSP to define all of the interactions
with BPRs. Note that
<http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/#bpr-HTTP_POST>
doesn't constrain what POST does, and the other verbs are consistent
with GSP.


My question was whether I can consider a service which impelements GSP
on most stuff, but also implements Basic Profile Containers, to be
conformant with GSP. I think it's reasonable of SPARQL implementations
to support the server side of the Basic Profile. Here's a test case
which uses a small extension of SPARQL to implement the BP:

http://swobjects.svn.sourceforge.net/viewvc/swobjects/branches/sparql11/tests/test_LDP.cpp?revision=1824&view=markup#l386


> ..snip..
> > One final comment - I see nowhere in the submission that precludes a 
> > single graph, which has all the resources and containers in it.  A graph 
> 
> > store - multiple graphs, flat structure - is not necessary.  Do you want 
> 
> > to constraint
> 
> I think you got chopped off here.

I think he meant to say that if there's a


> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> 
> http://open-services.net
> 
> 

-- 
-ericP

Received on Thursday, 20 September 2012 15:06:38 UTC