Re: Coherent (modern) definition of RWW

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.

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

Received on Tuesday, 18 May 2021 09:18:57 UTC