- From: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
- Date: Thu, 9 Nov 2023 09:37:29 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>, public-webid <public-webid@w3.org>
Hi Melvin, I really hoped that this group was about defining a secure, industry-grade standard for decentral identity and authentication. 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. 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? -- 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. 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.
Received on Thursday, 9 November 2023 08:37:43 UTC