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

> From: Andy Seaborne <andy.seaborne@epimorphics.com>
> To: public-ldp-wg@w3.org, 
> Date: 09/21/2012 04:24 AM
> Subject: Re: ACTION-4: Review SPARQL Graph Store Protocol and suggest 
how 
> we  should  move  forward with it
> 
> 
> 
> On 20/09/12 16:06, Eric Prud'hommeaux wrote:
> > * 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.
> 
> HTTP.
> 
> GSP does not define anything except the indirect naming.
> 
> If this WG adopts use of GSP then there is huge assumption on the 
> implementation of the server, that it is a graph store. I don't think we 

> want that.
>

I am in agreement with that (we don't want to depend on GSP for LDP).
 
> Is an implementation that is a single graph for the whole store 
> in-scope? 

I don't see why not

> Or does each BPR/BPC does not have to be a separate graph? 
> (if so - where is that in the text?)
> 
Not sure we need to say one way or the other, perhaps we could give 
guidance to various approaches but why would we require one versus the 
other?

> IBM - what implementation experience is there here?
> 

For non-GS-based impls, the wire RDF formats match what is defined in the 
member submission.  For example for almost all impls that I'm aware of 
that we've done, the named graph isn't represented.
For GS-based impls, we see a mixture.  A good deal separate each resource 
into its own graph (whether BPR or BPC).

- Steve

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

Received on Monday, 24 September 2012 13:57:35 UTC