Re: Coherent (modern) definition of RWW

On Tue, May 18, 2021 at 7:45 PM Tomasz Pluskiewicz <tomasz@t-code.pl> 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.

> > 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.

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

> 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.

Received on Tuesday, 18 May 2021 18:07:12 UTC