- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 3 Nov 2023 16:02:34 -0400
- To: public-webid@w3.org
- Message-ID: <3bd71bcf-ad07-4331-a65a-f58bf6f1d78b@openlinksw.com>
On 11/3/23 1:36 PM, Melvin Carvalho wrote:
>
>
> pá 3. 11. 2023 v 18:33 odesílatel Kingsley Idehen
> <kidehen@openlinksw.com> napsal:
>
>
> On 11/3/23 1:26 PM, Melvin Carvalho wrote:
>>
>>
>> pá 3. 11. 2023 v 18:00 odesílatel Kingsley Idehen
>> <kidehen@openlinksw.com> napsal:
>>
>>
>> On 11/3/23 9:47 AM, Melvin Carvalho wrote:
>>>
>>>
>>> pá 3. 11. 2023 v 14:12 odesílatel Kingsley Idehen
>>> <kidehen@openlinksw.com> napsal:
>>>
>>>
>>> On 11/2/23 9:48 PM, Melvin Carvalho wrote:
>>>>
>>>>
>>>> pá 3. 11. 2023 v 1:09 odesílatel Kingsley Idehen
>>>> <kidehen@openlinksw.com> napsal:
>>>>
>>>>
>>>> On 11/2/23 5:53 PM, Melvin Carvalho wrote:
>>>> > 2. urn scheme for webids: urn:webid
>>>>
>>>> What's that, and why?
>>>>
>>>> A WebID has always been an HTTP based URI used to
>>>> name an Agent.
>>>>
>>>>
>>>> Yes indeed. But not every authentication process gives
>>>> a URI (sadly). Some will give a string of characters
>>>> that denote an Agent, which need to be turned into a URI.
>>>
>>> I didn't see our focus right now being on solving for
>>> authentication protocols and URI combinations. I believe
>>> the primary objective is to propel WebID forward by
>>> delineating its essence and its potential usage,
>>> especially within the context of Solid.
>>>
>>> The shift from understanding WebID as an HTTP URI that
>>> identifies an Agent to something else doesn't align with
>>> the aforementioned goal.
>>>
>>> Presently, we utilize the term NetID for a URI that
>>> identifies an Agent, grounded on the reality that we
>>> have authentication services accommodating a range of
>>> schemes right from the outset.
>>>
>>> The discourse around WebID and Solid Lite seems to
>>> diverge slightly from the issues pertinent to a NetID.
>>> Furthermore, with billions of pages on the Web currently
>>> utilizing HTTP URIs to identify Agents, it seems prudent
>>> to harness this established practice with the existing
>>> WebID definition.
>>>
>>> Isn't the ultimate aim to employ HTML profile documents,
>>> encompassing RDF structured data islands (i.e., metadata
>>> articulated through various RDF notations), via a more
>>> streamlined derivative of Solid?
>>>
>>>
>>> Kingsley, you are completely correct. I agree with everything.
>>>
>>> I'm just outlining the things I would like to complete to
>>> make a working system, bearing in mind that this comunity
>>> group may close.
>>>
>>> The problem of turning a string into a URI post
>>> authentication, is something I'll need to do.
>>>
>>> Turning: "userid" into urn: <something> : userid is a quick
>>> hack. Whether it's webid or netid, the software doesnt care,
>>> so long as it's consistent.
>>>
>>> It would be in this case something like an "indirect
>>> identifier" as described in awww. Example:
>>>
>>> "Today 10 Downing Street said that ..."
>>>
>>> Of course the building 10 Downing Street didnt say
>>> anything. It's an incorrect sentence. But the consumers of
>>> the sentence understand it well enough.
>>
>>
>> You handle that using blank nodes, which is basically the
>> default in JSON or JSON-LD without explicitly indicating an
>> object id. Bascially, your example is ground zero for JSON
>> and JSON-LD where both denote subjects using indefinite
>> pronouns (a/k/a blank nodes).
>>
>>>
>>> Example: What is a WebID URN? A webid URN is a web
>>> identifier that is a URI but where the software was unable
>>> to locat an HTTP URI but wishes to store the authenticated
>>> username as a URI.
>>>
>>> I need to get something working in any case, in order to
>>> have a pluggable auth system.
>>
>>
>> My point is that you are swimming against the current if you
>> want to venture down this path. More importantly, it cannot
>> be named WebID -- since that's a massive change from the
>> original definition.
>>
>>
>> Not sure I agree on this, but I'll back burner it for now, given
>> the push back.
>>
>> Let me give some context:
>>
>> There are two things, one is a string as a name "kidehen" the
>> other is a universal name aka a urn which is also a URI
>>
>> So one issue with the urn spec is:
>>
>> I'd like to just say:
>>
>> urn:kidehen
>>
>> Problem solved.
>>
>> Unfortunately this brakes the URN spec, because for some strange
>> reason it's not allowed, you have to subclass it:
>>
>> so it has to be:
>>
>> urn:<something>:kidehen
>>
>> And whatever goes in there needs to be consistent. This is
>> simply a constraint imposed by RFC8141. I wish it wasnt there,
>> then this would not be an issue, but I need to put in something
>> logical to pass the Test of Independent Invention (TOII).
>>
>> I am unsure I agree with your assessment on a webid namespace,
>> but I'll give it more thought. In any case it will likely be an
>> internal software matter, at this point.
>
>
> I believe its an internal software matter (i.e., implementation
> detail) that shouldn't have any bearing on:
>
> 1. The existing WebID definition
> 2. Authentication Protocols that operate of credentials expressed
> in a WebID Profile Document.
>
>
> Well namespaces have to be non colliding thanks to the IETF. So you
> should tell them if you're going to use them. I dont believe that you
> can make the argument that urn:webid is confused with http webids.
I am only making one fundamental point.
A WebID is an HTTP based URI that names an Agent. Attempting to change
that doesn't help the cause in anyway.
>
> If you feel that strongly that's not a battle I want to pick right
> now. We can perhaps talk about it privately another time, unless I've
> been unclear.
>
I don't understand why the definition of WebID is now cause for concern.
It has nothing to do with the pursuit of a Solid Lite spec, or anything
else in this Read-Write Web realm -- IMHO.
--
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 Friday, 3 November 2023 20:02:45 UTC