Re: Coherent (modern) definition of RWW

Hello

I second the RESTful approach! LDP is somewhat that, albeit made very strict and too much like filesystem access from what I understand.

Store Graph is on the other hand very crude, making it difficult to apply authorization for one.

A resource-oriented approach using HTTP is potentially better for generic clients (given enough descriptions using Hydra, SHACL, etc) and also easier on more human audience (meaning developers, for starters).

Rather than figuring out an all-encompassing protocol which will suit no-one, I would propose to start from the simplest possible thing of RDF over HTTP and add necessary machine-readable components to allow control using standard HTTP features. I think it would also be beneficial to actually separate concerns here, some of which should be only relevant to a server. I think this would lead to a more robust solution.

This is what we’ve been trying lately with Hydra. To keep the Core slim but devise ways for more specific requirements a given API may have. I would totally see Hydra as the foundation on which to build RWW.

If this makes sense, I’ll be happy to elaborate some more

Best,
Tom

On 18 May 2021 at 16:20:59, Nathan Rixham (nathan@webr3.org) wrote:
> On Tue, May 18, 2021 at 10:22 AM Martynas Jusevičius  
> wrote:
>  
> > When you remove collections from LDP, there's pretty much nothing left
> > else than a graph store.
> >
> > https://www.w3.org/2012/ldp/wiki/Linked_Data_Platform_(LDP)_vs_SPARQL_Graph_Store_HTTP_Protocol_(GSP)  
> >
> > I am convinced we need a formal definition of RWW, akin to SPARQL
> > algebra, in order to ensure interoperability.
> >
>  
> I'm not sure you can have a formal definition of such a loose concept, you
> could try to make a single RWW Protocol, being RESTy and using HTTP it'd
> end up something like webdav, and if it required RDF or linked data then
> it'd end up being something like LDP.
>  
> When you try to include too many technologies, specifications become
> cumbersome to read, implement, and adhere to.
>  
> Perhaps there's some merit in exploring a loosely coupled modular protocol,
> a base read-write that's a subset of http perhaps with a couple of headers
> that allows updating the state of *any *media type, an extension that
> exposes that state and a temporal element, an extension that handles auth*.
> Maybe by requiring that it works *without *linked data, as well as with
> linked data, that it's all media type agnostic, we can be truly
> interoperable and pull together the intersection of work that the
> membership here has been on for the last decade.
>  
> This may have all been done, my radar is a bit foggy these days.
>  
> There is also the distinct possibility that the write bit of rww just isn't
> needed and already handled in a multitude of ways, that it's too
> simplistic when often resources are an amalgamation of multiple different
> resources in multiple differents states, automatically compiled deployed
> from different places and different teams via layers of different building
> and updating agents.
>  
> I'm thinking through my own use cases over the years, and think it's fair
> to say that the only time I could use a RWW protocol would be to update
> single data items/documents, which would probably be json documents, but
> then it's immediately invalidated as 99% of the time any data I publish as
> json, ld, or anything else, is just a transformation of data from a
> different source, and is managed elsewhere often by somebody else or a
> different process where there's no need for a transfer protocol in the
> middle
>  
> Simply, I've not had to solve this write-web problem because it's not a
> problem for me in any of my various work capacities over the years, even
> though I do see it as a nice thing to have or do.
>  
> Interested to hear other people's thoughts here.
>

Received on Tuesday, 18 May 2021 15:06:47 UTC