- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 27 Jul 2021 18:41:25 -0400
- To: public-rww@w3.org
- Message-ID: <5b9f6900-103b-be4f-1ff5-8473364d36a0@openlinksw.com>
On 7/27/21 2:34 PM, Melvin Carvalho wrote:
>
>
> On Tue, 27 Jul 2021 at 19:59, Kingsley Idehen <kidehen@openlinksw.com
> <mailto: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 <mailto: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 <mailto: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
>>>> <mailto:tthibodeau@openlinksw.com>> wrote:
>>>>
>>>>
>>>> On Jul 26, 2021, at 02:34 AM, Melvin Carvalho
>>>> <melvincarvalho@gmail.com
>>>> <mailto: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/
>>>>> <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
>>>>> <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
>>>>> <mailto:public-webid@w3.org> (subscribe
>>>>> <mailto: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
>>>> <http://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.
Kingsley
>
>
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com <http://www.openlinksw.com>
> Community Support: https://community.openlinksw.com <https://community.openlinksw.com>
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog <https://medium.com/openlink-software-blog>
> Virtuoso Blog: https://medium.com/virtuoso-blog <https://medium.com/virtuoso-blog>
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers <https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers>
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen <https://medium.com/@kidehen>
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ <http://www.openlinksw.com/blog/~kidehen/>
> http://kidehen.blogspot.com <http://kidehen.blogspot.com>
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/ <https://www.pinterest.com/kidehen/>
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen <https://www.quora.com/profile/Kingsley-Uyi-Idehen>
> Twitter: https://twitter.com/kidehen <https://twitter.com/kidehen>
> Google+: https://plus.google.com/+KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about>
> LinkedIn: http://www.linkedin.com/in/kidehen <http://www.linkedin.com/in/kidehen>
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i <http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i>
> : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this <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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 27 July 2021 22:42:19 UTC