Re: next steps on http graph store protocol

[replying to your two messages at once]

> What is a subdirectory of a graph store?
> 
> Is it a "Graph Store" - i.e. a SPARQL concept or soemthing else?

Something else.   It's not my intention to precisely define it, simply
to give an example of the kind of thing someone might want to someday
define.

There are other examples of things one might want to do with POSTing a
graph to a graph:

* posting a "buy" order (encoded in RDF) to a product page 

* posting a subscription (please notify me when your state changes) to
any sort of RDF graph

* posting a friend-request (encoded in RDF) to a personal information
page on a social network system

* posting a vote ("like" or "+1" or whatever) to record the user's
opinion about something presented on a page.

These might not be the only ways to perform these operations, or even
the best ones, but we have not yet done the research and outreach and
consensus-building necessary before prohibiting them. 


> >> It's not the lexical similarity that makes me think they should be
> >> governed by the same protocol document, it's that similarity in the
> >> protocol.   For both graph1 and magicCollectionThing, everything in
the
> >> protocol is the same except the behavior on POST.   GET, PUT,
DELETE,
> >> and PATCH, for RDF content types, all the same.
> 
> That is because RFC 2616 defines GET, PUT, DELETE, HEAD semantics and 
> they apply more widely than SPARQL, RDF or semantic web.

True.   In that sense, nearly all of this document is implied by
existing specs.   I think the only new parts are:

 * indirect graph identification (which is needed only because SPARQL
creates private namespaces for IRIs)

 * that the thing identified in Service Description as a "Graph Store"
is the kind of thing you can POST to, to create new Graphs

 * for the resources to which this spec applies (and there's no way
defined for a client to know which those are) -- when the client sends
content without indicating a content-type, there are situations where
"the server SHOULD attempt to parse the RDF payload as RDF/XML"

 * for those same resources -- POST should be understood to mean MERGE
 
 * for those same resources -- the server SHOULD implement SPARQL Update
(even though this spec is presented as an alternative to SPARQL).   I
think we probably have consensus to take this bit out.

I probably missed something, but that's most of it.  I think the first
two of these are good, the second is questionable but harmless (since
the client can just specify a content-type if it cares), and the fourth
and fifth are problems.


> For anything else, I think we should leave it open to another working 
> group and not try to second guess.  They have to, e.g. work on the 
> relationship to the Atom Publishing protocol, the world of JSON
linking, 
> embedded RDF content.

I'm only looking into the future enough to make sure we don't rule it
out.  I don't claim to know how we'll want to do things, only that it's
too soon to rule out a whole area of possible designs.

On Tue, 2012-01-10 at 08:49 +0000, Andy Seaborne wrote:
> 
> On 09/01/12 23:55, Sandro Hawke wrote:
> ...
> > It's not the lexical similarity that makes me think they should be
> > governed by the same protocol document, it's that similarity in the
> > protocol.   For both graph1 and magicCollectionThing, everything in the
> > protocol is the same except the behavior on POST.   GET, PUT, DELETE,
> > and PATCH, for RDF content types, all the same.   They just different in
> > how they handle POST of RDF.  So, (1) it seems odd to have two W3C
> > Recommendations that differ in only one small part, and (2) I'd think it
> > would cause lots of market confusion, as people didn't understand which
> > of those documents they were supposed to be using.   Especially since
> > the second one doesn't exist yet, and the first one doesn't acknowledge
> > that the second one might, someday.  So as people try to do the second
> > one, many people will be unhappy, I predict, that they are, apparently,
> > violating the first one.  What I want is for the first one to admit the
> > possibility of the second one, explicitly.
> 
> Sandro,
> 
> Does this mean that the charter for the Linked Data Patterns WG will 
> include a requirement to use the graph store protocol? 

That's not the kind of question that's addressed in a charter, because
it goes without saying.   If the overall system of standards is working,
then all future work inside and outside of W3C is to follow all relevant
standards, including W3C Recommendations and IETF Internet Standards.  

>  Because if it 
> does not (and I don't expect it would), then we are in grave danger of 
> designing for a situation that will never arise.

It sounds like where we actually disagree is about the scope of
applicability of this spec.

If I understand how you're approaching the situation, maybe you'd be
okay with the following text in Graph Store HTTP Protocol.   This text
would probably go in the introduction, with its first sentence in the
abstract:
        
        This protocol is only one of many possible HTTP (REST) protocols
        one could use involving RDF payloads and RDF Graph Resources.
        This specification only applies to one particular sort of RDF
        graph storage system, the sort for which these operations are
        the appropriate ones.  In contrast, for example, if one wanted a
        Graph Store which also included some service components, where
        POST was used to invoke operations, one would need to use a
        different Graph Store HTTP Protocol and the constraints of this
        document would not apply.
        
I could actually live with that.   I don't think it's what our charter
asks for, but I'm prepared to let go of that concern.

So, does that work for you, too?   Would you prefer that to the approach
of saying that POST only applies some of the time?

If we do that, and change 5.7, taking off the label "Informative" and
changing "is RECOMMENDED for use" to "MAY be used", I'm okay with the
document.

    -- Sandro

Received on Tuesday, 10 January 2012 13:24:30 UTC