- From: Jonas Smedegaard <jonas@jones.dk>
- Date: Tue, 18 May 2021 19:57:10 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>, public-rww@w3.org
- Message-ID: <162136063067.2043441.11619233115627203977@auryn.jones.dk>
Quoting Kingsley Idehen (2021-05-18 17:16:30) > 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 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. Ah, thanks. Makes sense now. > > 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. Thanks for emphasizing that GQL indeed won't bridge anything on its own. Requires additional effort to bridge it (and in an ideal World they would have spent their efforts on doing that bridge directly instead of inventing yet another protocol that need bridging). > > 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] :) Thanks again for emphasizing what I agree on but didn't write explicitly: Yes, WebID-TLS was an elegant design _and_ _still_ _is_ - it is relevant for authentication needs not involving a web browser. - Jonas -- * 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 17:57:57 UTC