Re: Coherent (modern) definition of RWW

On 5/18/21 4:26 AM, Jonas Smedegaard 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.


In my experience, as an implementor of said protocol, LDP addresses the
fact that data may live in a file within a file system i.e., your
conventional file and folder setup. Thus, you can perform the following
operations:

1. Create a Folder

2. Delete a Folder

3. Add a File to a Folder

4. Delete a File from a Folder

5. Add content to a file, using a variety of content-types

HTTP Methods used for these operations include PATCH and the
content-type includes "application/sparql-update" .

Information about folders and files (i.e., metadata) is available in RDF
via negotiable content-types (*our implementation addition* since the
spec is MUST for RDF-Turtle and possibly SHOULD for others).

Poor naming aside, it serves a purpose as OpenLink, Inrupt, and others
that support this protocol demonstrate via their respective product
offerings.

At OpenLink we also support other protocols e.g. basic HTTP, WebDAV and
SPARQL Graph Protocol for CRUD operations on resources.


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


See my comment above.

"Linked Data Platform" is a bizarre name for a Protocol.

The protocol itself is kinda RDF-Turtle (one of many document types)
specific with SPARQL specificity re PATCH method. It can be confusing to
any constituency which is its fundamental problem, IMHO.


>
>
>>> Graph Store Protocol is more appropriate for RWW. After all, Linked 
>>> Data can be looked at as a giant global table of quads.


I wouldn't frame it that way. A RWW is really about a Read-Write global
Entity Relationship Graph. Parts of the Graph might be in a DBMS while
other parts might be managed by a File System.

In my experience, the problem is that we easily get into "this vs that"
arguments driven by "all or nothing" instincts. As you know, there are
situations where a DBMS is optimal and others where a File System is
optimal.

When we were designing Virtuoso (eons ago) we thought about these
problems and ensured we catered to both modalities from day one. The
File System started with WebDAV and over time evolved to include both
LDP and the SPARQL Graph Protocol.

This is why I speak more about apps and services than infrastructure
these days since all the infrastructure magic is subject to exposure and
exploitation by apps and services.


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


SPARQL is for the DBMS world view, fundamentally.


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


LDP (which is Abstract RDF-based) is an alternative to WebDAV (which is
XML Document Type -based) for the File System scenario which is
eternally important re File Create, Save, and Share Pattern -- the very
pattern that underlies the Web's actual bootstrap and explosion.


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


They won't bridge RDF and LDP.

They might just provide yet another protocol for HTTP-based CRUD
(Create, Update, Delete) operations supported by a wider (anything but
RDF ) audience.


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


Correct!

RDF is an implementation detail that gets distracting fast. Ditto SPARQL
etc..


>
> The first wave of "the web" with mostly static content was boosted by 
> the Apache web server project.


Yes, courtesy of the File Save, Create, and Share pattern. Everyone
looked up some HTML (most didn't understand any of it), copied it to
their file system, tweaked it, and then opened from the file system
using their browser. If it worked, the mapped the folder to their HTTP
server etc..


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


Yep!


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


This is where is all started to go very wrong.


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


Yes.


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


WebID-TLS (and the option for Delegation) will ultimately have its day.
The big issues is lies in the power of Entity Relationship Type
semantics exposed via apps and services that are usable from browsers.

At OpenLink, we solved the TLS UX headache via an extension for desktop
browser. The TLS headache doesn't exist on Mobile Devices since the
Browser isn't the paramount User Agent.

Don't write off WebID-TLS or an ability for the same concept to work
using other protocol schemes (what we call NetID-TLS which is part of
our YouID portfolio), it is utterly superior to OpenID Connect + WebID 
re PasswordLess authentication [which everyone actually needs and wants] :)


>
>
>  - Jonas
>
>
> ¹ SPARQL has had some success, but mostly without the "write" bit.
>

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com
Weblogs (Blogs):
Company Blog: https://medium.com/openlink-software-blog
Virtuoso Blog: https://medium.com/virtuoso-blog
Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog: https://medium.com/@kidehen
Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
              http://kidehen.blogspot.com

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this