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.

Is an implementation that is a single graph for the whole store 
in-scope?  Or does each BPR/BPC does not have to be a separate graph? 
(if so - where is that in the text?)

IBM - what implementation experience is there here?

	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 Friday, 21 September 2012 08:24:16 UTC