- From: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Thu, 20 Sep 2012 08:15:08 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-ldp-wg@w3.org
> 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. ..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. Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net
Received on Thursday, 20 September 2012 12:15:50 UTC