- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 28 Jul 2021 15:23:45 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYhJHc9zOFqPLNsTAoP1M=OtDHfVXG4fHtvoBv6-DBDv2ZA@mail.gmail.com>
On Wed, 28 Jul 2021 at 15:17, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 7/27/21 6:48 PM, Melvin Carvalho wrote: > > > > On Wed, 28 Jul 2021 at 00:42, Kingsley Idehen <kidehen@openlinksw.com> > wrote: > >> On 7/27/21 2:34 PM, Melvin Carvalho wrote: >> >> >> >> On Tue, 27 Jul 2021 at 19:59, Kingsley Idehen <kidehen@openlinksw.com> >> wrote: >> >>> On 7/27/21 1:01 PM, Melvin Carvalho wrote: >>> >>> >>> >>> On Tue, 27 Jul 2021 at 17:58, Kingsley Idehen <kidehen@openlinksw.com> >>> wrote: >>> >>>> On 7/27/21 5:52 AM, Melvin Carvalho wrote: >>>> >>>> >>>> >>>> On Tue, 27 Jul 2021 at 04:22, Kingsley Idehen <kidehen@openlinksw.com> >>>> wrote: >>>> >>>>> On 7/26/21 1:08 PM, Melvin Carvalho wrote: >>>>> >>>>> >>>>> >>>>> On Mon, 26 Jul 2021 at 18:27, Ted Thibodeau Jr < >>>>> tthibodeau@openlinksw.com> wrote: >>>>> >>>>>> >>>>>> On Jul 26, 2021, at 02:34 AM, Melvin Carvalho < >>>>>> melvincarvalho@gmail.com> wrote: >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> >>>>>> Those who fail to read the "Status of This Document" are >>>>>> doomed to pain and agony all the days of their implementation. >>>>>> >>>>>> To wit: >>>>>> >>>>>> This document is produced from work by the W3C WebID Community Group >>>>>> <http://www.w3.org/community/webid/>. This is an internal draft >>>>>> document and may not even end up being officially published. It may also be >>>>>> updated, replaced or obsoleted by other documents at any time. It is >>>>>> inappropriate to cite this document as other than work in progress. The >>>>>> source code for this document is available at the following URI: >>>>>> https://dvcs.w3.org/hg/WebID >>>>>> >>>>>> This document was published by the WebID CG >>>>>> <http://www.w3.org/community/webid/> as an Editor's Draft. If you >>>>>> wish to make comments regarding this document, please send them to >>>>>> public-webid@w3.org (subscribe >>>>>> <public-webid-request@w3.org?subject=subscribe>, archives >>>>>> <http://lists.w3.org/Archives/Public/public-webid/>). All comments >>>>>> are welcome. >>>>>> >>>>>> Publication as an Editor's Draft does not imply endorsement by the >>>>>> W3C Membership. This is a draft document and may be updated, >>>>>> replaced or obsoleted by other documents at any time. It is inappropriate >>>>>> to cite this document as other than work in progress. >>>>>> >>>>>> In other words: This is not a spec, current or otherwise. >>>>>> >>>>>> It is very much an Editor's Draft, coming from the discussions >>>>>> of what was then an Incubator Group, and transformed into a >>>>>> Community Group, but really reflecting the opinions of the >>>>>> Chair who was doing double-duty as Editor, much more than of >>>>>> the group as a whole. >>>>>> >>>>>> It does not come close to reflecting consensus of that old XG >>>>>> (of which I was a member), never mind transition to a Candidate >>>>>> Recommendation, and further progress down the REC-track was >>>>>> likewise years away, as there was never a WebID Working Group. >>>>>> >>>>>> In my opinion, it should never have received the Respec skin >>>>>> it has, which makes it *look* like something it isn't, and >>>>>> at a minimum, W3C should find a way to put the watermarks >>>>>> now in common use on draft specs in the github.io space onto >>>>>> all the old draft specs that will otherwise continue to draw >>>>>> people into thinking that output of one person's keyboard >>>>>> have the same weight as the work product of several if not >>>>>> dozens of people intellectual and technical efforts. >>>>>> >>>>> >>>>> Good points. I guess it was last updated over 7 years ago and both of >>>>> the editors are no longer active >>>>> >>>>> And a lot has changed in that time! >>>>> >>>>> >>>>> >>>>> Yes, but it was never a spec endorsed by the W3C. >>>>> >>>>> Today, it still isn't a spec endorsed by the W3C. >>>>> >>>>> All we have in reality is "WebID" as a colloquialism for an HTTP >>>>> Identifier that denotes an Agent, and is generally conflated with a >>>>> protocol for credential verification that goes by the moniker "WebID-TLS" . >>>>> >>>> >>>> Makes sense. Tho WebID still is in use by some of the RDF folks, and I >>>> think they would argue that RDF/Turtle is mandated. >>>> >>>> >>>> Let them, at the end of the day freedom should reign supreme :) >>>> >>>> >>>> In time that may change, but in years probably, given the run rate >>>> >>>> >>>>> I am betting on verifiable credentials working via an emergent de >>>>> facto protocol that's adopted en masse by developers at some point. However >>>>> we get there, the following constants will be in play: >>>>> >>>>> 1. Logic as the Conceptual Schema >>>>> >>>>> 2. Resolvable Identifiers >>>>> >>>>> 3. Credentials that manifest as an Entity Relationship Graph >>>>> comprising Resolvable Identifiers >>>>> >>>>> 4. Credential verification protocol >>>>> >>>> >>>> I think what we need is JSON Objects, denoting an Agent, that can >>>> optionally have a URI. >>>> >>>> >>>> There isn't a "one size fits all" solution to this matter. >>>> >>>> Folks should simply build around an abstract core and ship apps and >>>> services. The notion of one spec adopted by the world will not work, IMHO. >>>> >>>> >>>> >>>> If it has an abstract model that's fine also, which allows middleware >>>> solutions, and you can put it in a data store, including redis, mongo, >>>> browser stores, virtuoso, quad stores etc. >>>> >>>> >>>> It is 100% about being abstract. >>>> >>> >>> Why is it 100% about being abstract? >>> >>> >>> Because that's how you negate politics. >>> >>> An Entity Relationship Graph is simply a technique for representing >>> logic i.e, things are related to other things in a variety of ways. >>> >>> >>> ie what's the benefits and what are the possible abstractions? >>> >>> >>> >>> Abstraction ensures loose-coupling of: >>> >>> 1. Identity -- enabled using a variety of Identifier types >>> 2. Identification -- Credentials Documents >>> 3. Authentication -- TLS, OpenID Connect, either + WebID, NetID, etc. >>> (with or without delegation) >>> 4. Authorization -- RBAC (Role-based Access Controls) or ABAC >>> (Attribute-based Access Controls) >>> 5. Storage -- Filesytems or DBMS >>> >>> This trumps any notion of a golden spec that will be mass adopted by >>> programmers, developers, engineers (of any variety). >>> >>> Apps will always trump specs i.e., specs simply provide frameworks for >>> App interoperability. Specs cannot precede App development, as history has >>> demonstrated, repeatedly. >>> >>> There wasn't a spec for the Web prior to its explosion. Basically, It >>> exploded before the creation of a custodial organization like W3C aimed at >>> ensuring interoperability by way of infrastructure standardization. >>> >> >> OK, so two abstractions >> >> 1. Data model abstraction -- EAV + arrays -- ability to use URIs -- in >> some cases it's a Set, in some cases it's RDF, a semantic web for both >> humans and machines >> >> >> Basic RDF is primarily EAV with IRIs. >> >> It handles structured data representation in a manner suited to the >> complexity that exists in this realm. >> >> >> >> 2. Architectural abstraction -- clean separation of concerns, REST style >> architecture, includes many protocols via URIs. e.g. its important that >> the file: URI system is part of the web space too, important for anything >> to be back compatible >> >> I'm absolutely convinced we dont have anything like this anywhere today, >> tho there have been some good efforts. >> >> >> I wouldn't speak in absolutes re non-existence. We (OpenLink) don't >> design any of our products without these separations at the core. >> >> >> I think we could make such a spec, which is based on existing web >> standards (though there now exists more than just one standard), in a few >> pages. >> >> >> I don't believe in making specs. They take too long, and they shouldn't >> precede apps i.e., they arise following the existence and establishment of >> apps, IMHO. >> >> We implement specs when they exist, since we have a vested interest in >> interoperability and data flow. >> >> >> >> Then layer on top newer things like web scale time commits and version >> control, all in a developer friendly way, that does not require a high >> learning curve >> >> >> Possibly, but apps are never the result of a public spec. This is where I >> diverge from what you are seeking here. >> > > Yes, I've been making apps for quite some time now. I perhaps have 20,000 > hours of implementation experience. That has lead me to hit many walls, > but I think the solutions are in sight. I have a good idea of what can be > implemented, and what cant, and where the gaps lie > > Writing a short spec would be so that others can do it, and that this > group has something to publish after working for quite some time on stuff. > There actually seems two parts. An architecture and an actual spec that > conforms to that architecture > > I can make quite a lot of apps now, but it's more fun if lots of > developers are able to do so too. > > > How about just deploying your apps and then use their design and > implementation details as marketing collateral for your target audience? > Basically, that's just another way of showcasing the virtues of "best > practices" that can evolve into open standards etc.. > > Historically, there isn't a single market-leading product today that I am > aware off that took the spec first approach. > > Years ago, when Microsoft was late to the DBMS market they introduced the > ODBC spec as an open standard -- behind the scenes though, they had SQL > Server (oem'd from Sybase) and Microsoft Access in place. > > Developers follow apps and platforms provided by market leaders, that's > how this game has always worked :) > OK, that makes sense! > -- > 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 Wednesday, 28 July 2021 13:25:11 UTC