Re: Reconsidering REST

On Fri, 2011-12-16 at 17:07 -0500, Lee Feigenbaum wrote:
> For me, I don't really care that much how things are specified as long 
> as there are test cases for interoperability and the specification is 
> reasonably rigorous.

Me, too.

It does get to be a problem, though, when an significant part of the
user base has no idea the spec applies to them because of the title and
phrasing.    The charter says we're doing REST with RDF, for people who
don't want SPARQL.    It's a bit odd to have such a spec titled SPARQL
1.1 ... something.   I think that's a mistake, but I can live with it,
because, as you say, it doesn't affect test cases.

> I believe that the argument that the language of a 
> specification is crucial to its adoption is somewhat silly. I don't 
> think that XML caught on with enterprise developers because the idea of 
> the infoset was something that resonated with them. (There are many 
> other forces that affect the adoption of a specification, such as 
> educational materials and working code, but also many practical ones 
> such as adoption by Big Players.)

Sure.

> Anyways, as I've expressed elsewhere I think removing the recommendation 
> that POST to a graph be append is a mistake.

I don't remember that, but I'll go look.

> Also, I couldn't support this version of the specification 

I'm not proposing my version of the spec be adopted in place of the
current one -- I just wrote it to help myself, and maybe some other
folks, understand what a SPARQL-free spec might look like, and how it
might differ in terms of testable behavior.

I'm not sure whether I'm suggesting (1) we make a few changes to GSHP to
make it in line, test-case-wise, with what I'm suggesting we'll need
down the road, or (2) we hold off on GSHP, maybe letting another WG take
care of it.

> because of 
> this removal:
> 
> """
> GSHP defines how to construct URIs for access to graphs in SPARQL 
> datasets, with a graphstore+"?graph="+graphlabel construct. Perhaps this 
> is better done in the SPARQL Service Description, instead, with a 
> predicate relating the dataset to a URI prefix string, not necessarily 
> graphstore+"?graph=".)
> """
> 
> ...that makes the specification largely useless to me.

What's your use case here?   My suspicion is that the design I suggest
there would be equivalent to what we have now, for your use case.

In the current GSHP, if you have the endpoint address and the graph
name, to construct the graph address, you have to get the service
description, match inside it for { <Service> sd:defaultDataset
?GraphStore }, then use that ?GraphStore binding to compute
?Graphstore+"?graph="+URLescape(graphname).

I'm suggesting it's cleaner and more flexible (and semantically less
confusing, since there's no need for a "graphstore" concept) to just
match { <Service> sd:graphHostingPrefix ?Prefix }, then compute ?Prefix
+URLescape(graphname).

My underlying point is that architecturally, RDF+REST shouldn't have to
know about SPARQL named graphs, and mechanically, there's no need to
force them to.

    - Sandro

> Lee
> 
> On 12/16/2011 2:41 PM, Sandro Hawke wrote:
> > So, I've tried to express my concerns with the Graphstore HTTP Protocol
> > document by writing a new document.  I know that seems a little crazy,
> > but I needed to try to make sense of this protocol for a very different
> > audience.   The two documents are very similar in the behavior they
> > specify, but entirely different in focus and approach.  In particular,
> > the one I drafted leaves out SPARQL and is agnostic about SPARQL
> > artifacts like datasets and graph stores and endpoints.   To motivate
> > that a little, I'll quote our "SPARQL New Features and Rationale", which
> > says, "It should be possible to manipulate RDF graphs using HTTP verbs,
> > notably PUT, POST and DELETE. By this, clients doesn't need to know the
> > SPARQL language to update graphs when it is not needed."   I read that
> > to say this should be welcoming to people who don't want to learn SPARQL
> > or SPARQL concepts.
> >
> > Anyway, here it is:
> >
> >          http://www.w3.org/2001/sw/wiki/REST
> >
> > For people who don't know, this area is the focus of a possible new
> > Working Group, which is why I'm suddenly so interested in it.  See:
> >
> >          http://lists.w3.org/Archives/Public/public-ldp/2011Dec/0000
> >
> > for more on that.
> >
> >        -- Sandro
> >
> >
> >
> >
>

Received on Saturday, 17 December 2011 01:36:49 UTC