Re: Coherent (modern) definition of RWW

On Tue, May 18, 2021 at 6:58 PM Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
>
> On 18 May 2021 at 18:42:40, Martynas Jusevičius (martynas@atomgraph.com (mailto:martynas@atomgraph.com)) wrote:
>
> > I don't agree RWW is a loose concept. Even WWW is not a loose concept
> > -- HTML, HTTP etc. have well-defined (though not formal) semantics.
> >
> > Graph Store is only crude if the client chooses it to be so, e.g.
> > stores all data in the default graph, or in a few huge named graphs.
> > Storing (roughly) a resource per named graph does not have this
> > drawback.
>
> The terms (default/named) graph do not even belong to the “webby” abstraction. It is predominantly a storage concern and should not leak into a generic RWW (unless explicitly chosen to).

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.

> > And what is even a resource-oriented approach? It's all nice and easy
> > while we're considering read-only use cases. Let's say you want to
> > store the description of the Linked Data resource you have been
> > browsing in your own triplestore, then a named graph is the only unit
> > of storage that can be used generically. The other standard write
> > method for RDF is SPARQL update, but I think it's safe to say there is
> > no update that can be used generically, in all cases (unless it does
> > the same as the GSP).
>
> Resource-oriented should be understandable to most.

As per Architecture of the World Wide Web:
"By design a URI identifies one resource. We do not limit the scope of
what might be a resource. The term "resource" is used in a general
sense for whatever might be identified by a URI."
https://www.w3.org/TR/webarch/#id-resources

So named graphs conform to this definition as well.

> GET /foo, POST /foo, PATCH /foo
>
> The first is Read the, second could be both and PUT/PATCH are Write.

I think here you are referring to the Uniform interface, a constraint of REST:
https://en.wikipedia.org/wiki/Representational_state_transfer#Uniform_interface

Again, Graph Store Protocol conforms to it -- it uses the 4 HTTP
methods and optionally PATCH as well.

> Resource oriented that clients are only interested in resources and their representations, which they exchange (hence *Representational* state *Transfer*). It is, as it should be, irrelevant whether the resource is store in relational database, triple store, document store, or filesystem.

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) and how exactly the storage mechanism would work? If not
GSP, then using SPARQL protocol? Or something else?

> So again, graphs have no place here, as you may have a representation which is composed of multiple graphs and not itself materialised (think a collection resource with query-string filtering). Or you may include inferred triples, which are not otherwise stored explicitly in the database.

I am sympathetic with these use cases, but there is no reason why they
cannot be implemented on the client side, using SPARQL protocol. As a
result, the server-side can be vastly simplified by removing the
collection-related functionality.

Received on Tuesday, 18 May 2021 17:13:24 UTC