Re: Coherent (modern) definition of RWW

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.

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

What is still missing in this picture are the rich clients that can
edit data using the GSP as well as projecting client-side collections
etc. using the SPARQL Protocol. That's the approach we are taking with
LinkedDataHub lately, the goal being an RDF-native intersection
between Jupyter notebooks and Roam Research

As for LDP as a Linked Data "filesystem", I agree with Thomas that it
is an outdated approach and an impedance mismatch. Those who need to
emulate a filesystem can do so on the vocabulary level (e.g. using
SIOC), there is no need to try to bake it into the protocol.



On Tue, May 18, 2021 at 5:06 PM Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
>
> 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 16:43:07 UTC