Re: Coherent (modern) definition of RWW

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