- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 3 Nov 2023 13:33:13 -0400
- To: public-webid@w3.org
- Message-ID: <9ead9c23-4f1f-4cf1-884f-5132be76c40b@openlinksw.com>
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.
--
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 17:33:22 UTC