Re: Should we complete the WebID spec?

pá 3. 11. 2023 v 21:03 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
napsal:

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

Not attempting to change that.  So we're good.  Can chat about it offline,
if I can clarify.


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