W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2012

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

From: Eric Prud'hommeaux <eric@w3.org>
Date: Thu, 20 Sep 2012 11:06:05 -0400
To: Steve K Speicher <sspeiche@us.ibm.com>
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp-wg@w3.org
Message-ID: <20120920150603.GA31331@w3.org>
* 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

  [] 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,
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
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:


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:31 UTC