Re: Coherent (modern) definition of RWW

On Tue, 18 May 2021 at 11:22, Martynas Jusevičius <martynas@atomgraph.com>
wrote:

> LDP assumes, as does most of Web 2.0 APIs, that collections is a
> server-side thing. But collection is just a form of a subgraph
> projection from the underlying dataset. It doesn't have to be
> pre-defined by the server -- now that we have SPARQL query language
> and protocol, the client can define its own projections, including
> collections.
> 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. Algebra is why SPARQL
> semantics are agreed upon across vendors (except a few minor bugs in
> the spec), while the text of LDP is being interpreted in various ways
> to this day.
> We have some denotational semantics definitions of Linked Data in this
> spec: https://atomgraph.github.io/Linked-Data-Templates/
> The mapping to SPARQL might not be necessary but I think the general
> definitions (LDRequest, LDResponse) can be reused.
>

Regarding a formal definition of RWW, there's two approaches.  One is a
bottom up set of modular specs that can be tied together.  The other is a
branded stack or framework that people of all backgrounds can jump into and
do useful things

The two are not mutually exclusive

The issue is that people tend to disagree on the tiniest thing.  A good
example some like data stores and Graph store protocol and others prefer
file systems and LDP (I dont actually know many people that are huge fans
of everything in LDP)

So getting consensus on a top down design is quite hard, and requires
people to put the work in and champion it.  Then it requires evangelism to
gain critical mass

The bottom up approach is something that I think we'll have to do anyway,
and that could be input into a more branded approach, but would need the
resources to take that on, which would probably be a stretch right now,
unless we got a funded team together.  There is an appetite right now for
funding well articulated projects, especially in the decentralized web
space, but it's time intensive to raise those funds, and also you need some
luck

So I think we'll we can create small modular specs, around reading and
writing, identity, authn, authz, storage etc.  I'll add that the trust and
reputation CG was folded into this group, but we've not done much there
yet.  I think simply a trust rating ontology would work well as a first step

And now I think, after this good discussion, we are closer to proposing a
temporal aspect to the read write web.  Both local in scope, and global in
scope.  With integration and plumbing in some specs.  After all the write
operation of the RWW inherently changes something in time, so I would argue
that RWW and time do go together.  IMHO this will open a whole new
generation of apps, as distributed agents can participate in the RWW, over
time, gain good reputations, and generally be helpful to humans


>
> On Tue, May 18, 2021 at 10:29 AM Jonas Smedegaard <jonas@jones.dk> wrote:
> >
> > Quoting Kingsley Idehen (2021-05-17 23:26:33)
> > > On 5/17/21 11:37 AM, Martynas Jusevičius wrote:
> > > > LDP is a poor protocol period.
> >
> > I guess that's "Linked Data Platform 1.0": https://www.w3.org/TR/ldp/
> >
> > Write is done using WebDAV extensions to HTTP:
> >
> https://en.wikipedia.org/wiki/Linked_Data_Platform#LDP_and_WebDAV_relationship
> >
> > Seems the main benefit of LDP is that publishers can host RDF data on
> > legacy non-RDF systems - likely adequate and efficient for large bulks
> > of data.
> >
> > Seems the main criticism of LDP is that while technically read-write,
> > write support is optional and not graph-based (SPARQL is only suggested
> > and only when not conflicting with spec'ed non-RDF update method).
> >
> >
> > > > Graph Store Protocol is more appropriate for RWW. After all, Linked
> > > > Data can be looked at as a giant global table of quads.
> >
> > > Graph Store Protocol is yet another protocol for a RWW driven by
> > > SPARQL :)
> >
> > I guess that's "SPARQL 1.1 Graph Store HTTP Protocol":
> > https://www.w3.org/TR/sparql11-http-rdf-update/
> >
> > Write is done using SPARQL (as indicated by the full official name but
> > not the shorter nickname).
> >
> > SPARQL offers flexibility, which is great for users, but is a pain for
> > implementers to cover the large spec, and is a pain for administrators
> > of not-fully-public data in securing access rights.
> >
> > I agree that LDP is inferior to SPARQL, but I recognize the need for
> > taking into account the needs of hosting providers if we want not only
> > great concepts but also widespread adoption.
> >
> > ISO is working on an extension to SQL to cover graphs, called "Graph
> > Query Language" with nickname GQL:
> > https://en.wikipedia.org/wiki/Graph_Query_Language
> >
> > That will likely spawn a range of data hosting producs supporting
> > graph-oriented read-write operations, which are not themselves
> > RDF-oriented but might be easier to (efficiently and safely and
> > securely) bridge to RDF than e.g. LDP.
> >
> > Getting back to the topic of this thread: Seems to me that the answer to
> > "Coherent (modern) definition of RWW" should take into account not only
> > "is it both read-write and webby?", but also "is it realistic to
> > convince publishers to adopt?" - and that latter (sub)question involves
> > factors not directly related to RDF at all.
> >
> > The first wave of "the web" with mostly static content was boosted by
> > the Apache web server project.
> >
> > The second wave of "the web" with larger amount of dynamic content was
> > boosted by the Perl and PHP languages interpreted by plugins to Apache.
> >
> > The third wave of "the web" with larger amount of standards-structured
> > read-write content was argually attempted with WebDAV (and later CalDAV
> > and CardDAV extensions) with some success, and was attempted with
> > AtomPub with lesser success, and was attempted with SPARQL with much
> > lesser success¹.
> >
> > So I propose to add these to the list of requirements (or
> > considerations, at least) for a modern RWW definition:
> >
> >   * is realistic for hosting providers to adopt
> >     * can extend (i.e. need not replace) existing infrastructure
> >     * runs reliably and efficiently at extremely large scale
> >     * runs reliably and efficiently at self-hosted systems
> >     * runs reliably and efficiently in internet-of-things
> >     * securely handles access rights
> >
> > If we define the concept without regard for real-World adoption needs,
> > we end up with a situation similar to that of WebID-TLS (which was
> > elegant assumed browser support for client-side TLS certificates would
> > evolve).
> >
> >
> >  - Jonas
> >
> >
> > ¹ SPARQL has had some success, but mostly without the "write" bit.
> >
> > --
> >  * Jonas Smedegaard - idealist & Internet-arkitekt
> >  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> >
> >  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
>