Re: What is a WebID?

čt 9. 11. 2023 v 13:57 odesílatel Sebastian Hellmann <
hellmann@informatik.uni-leipzig.de> napsal:

> Hi Melvin,
> On 11/9/23 11:59, Melvin Carvalho wrote:
>
>
>
> čt 9. 11. 2023 v 9:37 odesílatel Sebastian Hellmann <
> hellmann@informatik.uni-leipzig.de> napsal:
>
>> Hi Melvin,
>>
>> I really hoped that this group was about defining a secure,
>> industry-grade standard for decentral identity and authentication.
>>
>
> Yes, it is a secure industry-grade standard for decentralized identity.
> Just with loose-coupling.
>
>
>> Maybe as a side objective making Linked Data simpler * . However, it
>> seems that the goal is to re-build FOAF and Schema.org for machine
>> readable data on the web like https://www.imdb.com/name/nm0000230/ is
>> one of the  WebID's for Sylvester Stallone, if you are not to pedantic
>> about accepting "url": as the identifier.
>>
>
> FOAF was tied to the original concept, but that's no longer a dependency.
>
>
>>
>> Now in 2023, I have the feeling that publication and discovery of
>> machine readable data already works well. So what could this group add
>> on top?
>>
>
> What's the alternatives?
>
> A good checklist here:
>
> https://www.w3.org/DesignIssues/Principles.html
>
> How many of these principles are adhered to by WebID, and how many by the
> alternatives?
>
> You tell me.
>
Evaluating the proposed path, IMHO subjective scores:

Simplicity: 9/10
Modular Design: 9/10
Being Part of a Modular Design: 9/10
Tolerance: 9/10
Principle of Least Power: 10/10
Test of Independent Invention: 7/10
Decentralization*: 9/10

Score: 64/70

* more can be said on this, in another thread

>
> What is actually violated in what way, when putting the following JSON-LD
> in  <script type="application/ld+json">
>
> {
>    "@context" : "https://schema.org" <https://schema.org>,
>    "@type" : "Person",
>    "birthDate" : "1946-07-06",
>    "name" : "Sylvester Stallone",
>    "url" : "https://www.imdb.com/name/nm0000230/"
> <https://www.imdb.com/name/nm0000230/>
> }
>
> Because honestly, I really don't see any practical problems.  I also see
> that you could add a second context and a public key.
>
> -- Sebastian
>
>
>
>
>>
>> -- Sebastian
>>
>> * simpler Linked Data:  you are aware that HTTP-range-14 can be tackled
>> post request, right? curl -H "Accept: text/turtle"
>> "https://databus.dbpedia.org/kurzum#this" even without a 200/Location
>> Header.
>>
>
> Trying to understand HR14 tackled post request?  Adding "#this" I know
> about, and seems like a smart thing.  Unsure #this is documented anywhere,
> maybe that's a good thing to do (A Note perhaps?)
>
>
>>
>> On 11/9/23 04:06, Melvin Carvalho wrote:
>> > Need to go back to the universals here
>> >
>> > The CONCEPT of WebID is a URI -- ie a universal identifier -- you
>> > dereference it, and get back machine readable data, of a certain form
>> > which allows you to useful things.
>> >
>> > The nature of that form is that it denotes an Agent, a machine, user
>> > or group operating on the internet
>> >
>> > The concept is different from the branding.  The concept will remain
>> > working no matter how it's branded.  Much of the recent discussion is
>> > over branding.
>> >
>> > The original branding 15 years ago tied the identifier to both FOAF
>> > and to SSL in order to do client side authentication.
>> >
>> > My idea for a rebrand in 2014.  Was to break the ties of FOAF, SSL (ie
>> > WebID-TLS) and identity to be separate concerns.  I would like to
>> > point out that this was my idea, and my idea alone.  Nobody else was
>> > thinking along these lines, in the slightest.  I pitched it at TPAC,
>> > and, much to my surprise it caught on.  Split the concept into an
>> > identity spec and an authentication spec.  Which is what we did.  I
>> > remember this very well, I was sitting between TimBL and Henry at the
>> > time.
>> >
>> > The specific branding of WebID then went to the group and the new
>> > branding became to tie it to http and to turtle (and http 303 which
>> > was a big debate).  Why?  Because it seemed like a good idea at the
>> > time.  We all wanted linked data and turtle to catch on, and for W3C
>> > RECs to create an interoperable standard on the Web.
>> >
>> > Turtle didnt catch on.  And so, a sensible thing to do, as we are
>> > doing now, is to decouple the WebID brand from turtle, and make it a
>> > modular set of specs.  A good idea for the brand, and the concept.
>> >
>> > We'll have WebID-Turtle, WebID-JSON-LD and other things that people
>> want.
>> >
>> > Should RDF be mentioned in the super set spec?  No.  That's a branding
>> > question, and it depends on whether you want to tie the particular
>> > brand at a particular time to RDF.  RDF has not caught on the way we
>> > wanted it to.  In fact the biggest open deployment on the social web,
>> > activitypub, has deviated from RDF.  So to interoperate with that,
>> > which we should, the term machine readable should be used, and RDF
>> > placed in the subspecs (sub brands).
>> >
>> > Should WebID be tied to HTTP(S).  Probably yes.  The concept itself is
>> > universal, social can happen over many transports.  The brand http is
>> > a good one and it was always a starting point.  I've always been
>> > supportive of the superset brand NetID (any URI), but let's face it,
>> > it didnt catch on anywhere outside openlink in any major way.  Fair
>> > play to Kingsley, to stand up for that brand, and he may well win
>> > through, but NetID is not a self evident thing, it's a brand and a
>> > world view.
>> >
>> > So, what is a WebID?  It's whatever we want it to be.  We ought not
>> > change it too much, but it's beneficial and expedient to tweak it to
>> > reflect the reality that has been observed over the last decade.  Keep
>> > the brand tied (for now) to HTTP(S) a MUST in the spec.
>> >
>> > Keep it tied to machine readable data in the super spec, and to RDF in
>> > the sub specs.  Have two subspecs to start with:  WebID-Turtle and
>> > WebID-JSON-LD which reflect reality. If more want to be added such as
>> > WebID-RDFa (with (X)HTML) that can be debated, personally RDFa a NACK
>> > for me because JSON-LD in html has won that battle already, but that's
>> > a branding debate for another day.
>> >
>> > Let's proceed without being too pedantic or dogmatic, and keep the
>> > concept of WebID as a universal identifier on the web, in line with
>> > the way URIs are universal, but specify specific modular constraints,
>> > at this specific time (2023 vs 2014) to reflect what's useful and what
>> > is reality.  There should be enough in there to give everyone what
>> > they want. The group will end up coming to consensus on some or all of
>> > these points, but the general structure will remain intact.
>> >
>> > WebID was branded and specified before.  Finalizing the detail can
>> > only improve it from what it is now, both conceptually and in terms of
>> > real world adoption.  Where it ends up is almost certainly better than
>> > where it is today. And that's a good thing.  But it doesnt matter what
>> > I think, it's up to the group figure out the details, but the highest
>> > likelihood is one of progress and a better spec, which will be good
>> > enough to become a W3C REC.
>> >
>> > Just my 2 cents.
>>
>