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

> From: "Eric Prud'hommeaux" <eric@w3.org>
> To: Steve K Speicher/Raleigh/IBM@IBMUS, 
> Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp-wg@w3.org
> Date: 09/20/2012 11:17 AM
> Subject: Re: ACTION-4: Review SPARQL Graph Store Protocol and suggest 
how we
> should  move  forward with it
> Sent by: "Eric Prud'hommeaux" <ericw3c@gmail.com>
> 
> * 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.
> 
I see what Andy is saying a bit more clearly now.

Perhaps there needs to be 2 names for BPRs (RDF-based or not).  I'm not 
going to propose them here but the idea behind the submission is that it 
defines the kind of web resources whose state can "fully" be defined with 
RDF and therefore we can clearly define the rules to create, update, fetch 
and delete.  We define the rules to map its web identifier (URI) to 
RDF-based representations, among other things.  We are already having 
separate discussions on rules and best practices on these RDF-based 
representations, so we need a place for this.

RFC2616 defines the rules for non-BPRs, LDBP defines no additional rules 
on resources of this kind.  So I believe we are compatible with what is 
being proposed.  Is this just a naming issue where implementations will 
feel that they are not "LDBP" compliant because they serve up content that 
follows RFC2616 for some of its resources?

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

Cool, will check it out. 

> 
> > ..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 Eric, I will now

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

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

Received on Monday, 24 September 2012 13:45:32 UTC