Re: Should we complete the WebID spec?

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.

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.


>
> --
> 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
>
>