Re: Coherent (modern) definition of RWW

On 18 May 2021 at 19:13:00, Martynas Jusevičius (martynas@atomgraph.com) wrote:
> On Tue, May 18, 2021 at 6:58 PM Tomasz Pluskiewicz 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.

Twist those term all you will, but any time they were used in these conversations, they were storage concerns ;)

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

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.

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

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.

> and how exactly the storage mechanism would work? If not
> GSP, then using SPARQL protocol? Or something else?

I think you did not read my messages carefully. I do not care for the storage. The client should know where (URI), what (SHACL, OWL) and how (PUT/POST) to make requests. Everything else is implementation detail which would only concern the server.

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

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. 

1. Query over named graphs or maybe default graph is union graph?
1. How does one “enable” inferences? This is vendor-specific
1. Do you intentionally want to exclude non-RDF from RWW interface? Or possibly a simple set of RDF resources which are not exposed with a SPARQL endpoint? 

Resource-orientation is the middle ground for all those choices. This is the exact reason why Fielding described Uniform Interface, no?

Because be honest, would you go around, proposing public SQL as a generic data access? Unless the next stop is GraphQL...

Received on Tuesday, 18 May 2021 17:46:07 UTC