Re: Coherent (modern) definition of RWW

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

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

GET /foo, POST /foo, PATCH /foo

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

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.

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.

The HTTP protocol is flexible enough, yet not use case-specific, to cater for various design choices. For example Content Negotiation by Profile [1] can be a way to request a representation with or without inferred triples, or shaped to a specific SHACL Shape. This last is an idea I recently expresseed in Hydra CG [2]

All possible thanks to existing web standards

[1]: https://www.w3.org/TR/dx-prof-conneg/
[2]: https://github.com/HydraCG/Specifications/issues/234#issuecomment-839983299

Received on Tuesday, 18 May 2021 16:58:52 UTC