Re: Coherent (modern) definition of RWW

On 18 May 2021 at 20:06:23, Martynas Jusevičius (martynas@atomgraph.com) wrote:
> On Tue, May 18, 2021 at 7:45 PM Tomasz Pluskiewicz wrote:
>  
> > > Replace "graph" with "document" -- better? :) We can only consider
> > > named graphs using direct identification (i.e. .../resource/id and not
> > > /graph-store?graph=.../resource/id) and forget the default graph, if
> > > that helps.
> >
> > Twist those term all you will, but any time they were used in these conversations, they  
> were storage concerns ;)
>  
> And that is fine as long as the client is rich enough to deal with
> everything else, e.g. collections.
>  
> > True enough, and I never said it did not. But it hardly provides the necessary flexibility.  
> >
> > Put differently, Graph Protocol is RESTful, but the resource (in HTTP/REST understanding)  
> is the graph.
> >
> > In a domain-specific RWW interface the graph does not exist, if it is not part of said  
> domain. If your domain is the archetypal To Do list, then resources are To Do items, etc.  
> You interact with those resources and not graphs.
>  
> We have designed a system that interacts with such domain resources
> and still stores data in named graphs, so I don't see any
> contradiction here.

Yes, I store data in named graphs in some applications. And in another still, I store all resources in a single graph. Because of “politics”.

And guess what. Because both applications are exposed as resources over HTTP, the client uses the "uniform interface”, which is exactly the same ion both cases, that is addressing resources by their URIs and interacting with HTTP methods.

>  
> > > Please describe a write-oriented scenario (e.g. agent loading a
> > > representation from a RDF remote source and storing it in the agent's
> > > own store)
> >
> > GET /resource/A
> > Host: some.external.source
> >
> > PUT /resource/A
> > Host: my.app
> >
> > The first resource gets the representation of /resource/A
> > The second stores it. Could also be a POST if you’re willing to have the server at my.app  
> decide the identifier for the new representation.
> >
> > There are a number of ways, all agnostic of the ins and outs of RDF too.
>  
> Presumably the protocol is symmetrical, i.e.
>  
> GET /resource/A
> Host: my.app
>  
> returns the same graph that was stored using PUT? And DELETE removes
> that description/graph etc.

Ah the graphs again. DELETE removes a resource. Period. Nothing about graphs. 
It may not in fact remove anything at all. It may set some kind of soft-delete flag or rename a resource, as in moving it to a bin or something.

>  
> In that case, how exactly is it different from GSP? "If it walks like
> a duck and talks like a duck…"

No the same, because a resource-oriented server does not have to be just a glorified storage device. When you PUT a representation, it does not mean that that immediately getting it back will give the exact same content. This is bad approximation.

>  
> > Wouldn’t it be more common that you’d be dealing with multiple clients to a single server?  
> I think that is good reason not to shift complexity to the clients, unless there is a real  
> compelling reason.
> >
> > So yes, SPARQL is not good default choice because again, it requires knowledge which  
> the client might no have.
>  
> The reason is expressivity. First you introduce an API protocol for
> server-side collections, then you need ordering by parameter, then you
> add filtering by parameter etc. etc. You get the idea. But you will
> not be able to reach the expressivity of SPARQL this way (or if you
> would it would be a crazy monstrosity). The only logical step is to
> move the expressivity to the client-side, where a rich client can
> generate SPARQL and execute it via the SPARQL protocol.
>  
> While we keep arguing about filesystem-like API and SPARQL being too
> complex for clients, platforms like data.world and Roam Research have
> raised millions in funding and gathered larged communities -- and they
> are essentially rich clients over tuple stores.
>  

And yet isn’t most software worldwide plain JSON over HTTP, with some RAML or Open API if you’re lucky?

But I think I will stop here, since we appear to be getting nowhere :)

Received on Tuesday, 18 May 2021 18:20:55 UTC