- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 26 Jul 2021 16:34:04 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYhKfLF0kx+PhbotsCOqSANUPzh2yO8d7DMjkrtTX+jZL0Q@mail.gmail.com>
On Mon, 26 Jul 2021 at 16:02, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 7/26/21 2:34 AM, Melvin Carvalho wrote: > > > > On Mon, 26 Jul 2021 at 03:42, Kingsley Idehen <kidehen@openlinksw.com> > wrote: > >> On 7/25/21 4:32 PM, Melvin Carvalho wrote: >> >> >> >> On Sun, 25 Jul 2021 at 22:06, Kingsley Idehen <kidehen@openlinksw.com> >> wrote: >> >>> On 7/25/21 11:12 AM, Melvin Carvalho wrote: >>> > >>> > Yes, if you said to any web developer in the world, "JSON with URLs", >>> > they'd get it immediately >>> >>> Yes, they do! >>> >>> I tend to phrase it as URLs as Data Source Names that resolve to content >>> comprising any of the following: >>> >>> 1. JSON -- for EAV >>> 2. CSV -- for N-Tuples representing a Table/Grid/Spreadsheet >>> >> >> Yes, JSON as EAV is great >> >> So the issue with WebID is that it's almost unimplementable. >> >> >> You are conflating two things when you make that statement: >> >> 1. WebID -- a resolvable identifier that identifies and Person or Agent >> > > Ah, I see the issue here > > The current WebID spec is in fact tightly coupled to Turtle (and http) via > "MUST" > > https://www.w3.org/2005/Incubator/webid/spec/identity/ > > > That doc should have always give JSON-LD and Turtle equal billing, but it > didn't -- thereby making it vulnerable to distracting JSON-LD vs Turtle > arguments. > > This is how we've ended up in this very strange place. > Yes, I agree > > >> >> 2. WebID-TLS -- a protocol that extends TLS by using a WebID as a pointer >> to a credentials doc (WebID-Profile Doc) that's reconciled to the Public >> Key used to establish a TLS session. >> >> I believe you are stating that the protocol above (WebID-TLS) has >> implementation challenges arising from the manner in which User Agents >> handle TLS sessions. >> > > I dont even think of auth when I think of WebID, though most people do. > I'm thinking of user profiles. Auth is a bonus > > > WebID is just an Identifier used to denote an Agent that resolves to a > Profile Document. > > Unfortunately, it is now associated with: > > 1. Serialization and Storage Format Specificity > At the spec level it mandates Turtle So, if you want to comply with the spec you have to implement that, which is almost impossible. There's the issue We're not arguing about serialization formats, we're talking about complying with the spec > 2. Credentials and Authentication Protocol Conflation > https://json-ld.org/playground/#startTab=tab-compacted&json-ld=https%3A%2F%2Fmastodon.social%2F%40Gargron.json&context=%7B%7D > > Basically, the product of problematic marketing communications that > assumes being generic (rather than specific) is a plus rather than minus. > > Time has demonstrated (quite clearly) that this approach is expensive and > self-defeating. > Well, I never brought that up, but agree people like to talk about the two things together That profile is pretty good to be honest, but would benefit from #me at the end of the @id field and I think we're more or less done > > > >> >> The reason is that you are required to use turtle, which doesnt have a >> native parser, or native user base. >> >> >> That only applies in a world where WebID and Turtle are tightly-coupled. >> That isn't the world I see (past, present, or future). >> > > So your idea of a NetID, if the default serialization was JSON I think > would work well > > NetID = easy, implementable, evolving = anyURI that denotes an agent, and > brings back machine readable profile data in the form of JSON > > > NetID doesn't have a default serialization, it focuses on logic as the > conceptual schema. If an implementer wants to use JSON as their default, so > be it. > Fair enough, maybe that's better > In regards to our authentication layer, we support NetID as a superset of > WebID where HTTP(S) is just one of many protocols for identifier > resolution. > I think that's useful to show people why it's useful > > > Perhaps this is something that could be written up. We could even publish > it in this group > > > Yes, if need be. > > BTW -- we no longer focus solely on Public Key matching when verifying > credentials, you can also use SHA1 fingerprints denoted using ni: and other > hash oriented URI schemes. We even support Hash Emoji's. > This is fine! > > Kingsley > > > >> >> It also struggles to handle any sort of arithmetic. >> >> Then you need to correctly implement content negotiation which always >> breaks something. Almost no one can do it, even large firms >> >> I say 'almost' because perhaps OpenLink is the best out there. So, as a >> quick experiment I just tried the two WebIDs in your profile: >> >> 1. time curl http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i >> Time taken: 8.52s >> Result: a file in turtle, doesnt display in the browser >> >> 2. id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this >> Time taken: 7.78s >> Result: curl: (56) Recv failure: Connection reset by peer >> >> curl -kI >> https://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this >> HTTP/1.1 200 OK >> Server: Virtuoso/08.03.3322 (Linux) x86_64-generic-linux-glibc25 VDB >> Connection: Keep-Alive >> Date: Mon, 26 Jul 2021 01:31:29 GMT >> Accept-Ranges: bytes >> Allow: COPY, DELETE, GET, HEAD, LOCK, MKCOL, MOVE, OPTIONS, PATCH, POST, >> PROPFIND, PROPPATCH, PUT, TRACE, UNLOCK >> Vary: Accept-Encoding, Access-Control-Request-Headers, Origin >> MS-Author-Via: DAV, SPARQL >> Accept-Patch: application/sparql-update >> *Accept-Post: text/turtle, text/n3, text/nt, text/html, >> application/ld+json* >> Link: <http://www.w3.org/ns/ldp#Resource> >> <http://www.w3.org/ns/ldp#Resource>; rel="type" >> Link: <http://www.w3.org/ns/ldp#NonRDFSource> >> <http://www.w3.org/ns/ldp#NonRDFSource>; rel="type" >> Link: >> <https://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl,meta> >> <https://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl,meta>; >> rel="describedby" >> Link: <?p=1>; rel="first" >> Link: <?p=1>; rel="last" >> Link: >> <https://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl,meta> >> <https://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl,meta>; >> rel="meta"; title="Metadata File" >> ETag: "4c2d0dee687e042f34aaa9214d5b7730" >> X-SPARQL-default-graph: >> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl >> Content-disposition: filename=sparql_2021-07-26_01-31-29Z.ttl >> Content-Type: text/turtle >> Content-Length: 19817 >> >> >> And I would say OpenLink are the very best out there, in middleware for >> turtle etc. >> >> >> We are passionately committed to data de-silo-fication which means as >> commitment to content-negotiation and the like. Data transformation is our >> calling, and the very heart and soul of the company :) >> >> >> >> Similarly, solid pods have major bugs in their WebiDs >> >> Conclusion: WebID as a means to facilitate profiles on the social web is >> unimplementable. >> >> >> An resolvable identifier is what's workable. For those committed to HTTP, >> WebID is workable. >> >> >> I actually only just realized this today after about 10 years of >> observing all the different attempts to implement it, out there >> >> An EAV solution with a familiar syntax (JSON), parser etc. as per >> schema.org is what works and WebID needs to adapt to that (somehow) >> >> >> You can implement a protocol based on the same logic that underlies >> WebID-TLS using other resolvable identifiers and JSON-based profile >> documents. Unfortunately, this simple solution is hard for many to accept >> and understand, for reasons I struggle to understand. >> >> >> >> Which of course is the approach of schema.org and a reason it's got >> major traction as the de facto semantic web ... >> >> >> Schema.org offers a general purpose vocabulary supported by Google. Thus, >> any sane Web Master and/or Content Manager would be remiss to ignore it. >> >> Anyway, schema.org provides enough terms definitions to implementing the >> WebID-TLS protocol, we've actually implemented support for that years ago >> too. >> >> -- >> 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 >> >> > -- > 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 > >
Received on Monday, 26 July 2021 14:34:30 UTC