- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 9 Nov 2023 09:07:20 -0500
- To: public-webid@w3.org
On 11/8/23 10:06 PM, 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. To be clear, since target of that statement above is somewhat vague: My comments are focused on clear definitions regarding what a WebID is. Never ever about branding, which I see as the source of unnecessary confusion. > > 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 disagree, and I don't understand how you arrived at that conclusion. Personally, I've never made an utterance about WebID (since the term emerged) that included conflation with FOAF, SSL etc. Our late friend Henry is the person that pushed the FOAF+SSL meme in the early days. > 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. WebID existed as a concept long before then. It actually dates back to discussions across TimBL, Henry, and I in the old Semweb IRC channel (which I suspect doesn't have a decent archive circa 2023). > > 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. Not at all, Henry was coaxed (by me) to support Turtle in addition to RDF/XML based on the rise of the Linked Open Data (LOD). The simple thinking being: Lots of Turtle documents will emerge around the LOD cloud which helped decouple RDF from RDF/XML. > We all wanted linked data and turtle to catch on, and for W3C RECs to > create an interoperable standard on the Web. As I said before, it was about WebID riding the LOD cloud wave. Today, it is about ridding the new HTML structured data island wave. All of these efforts are about taking a complex issue and delivering it to the masses in "deceptively simple" fashion so that they don't get ensnared in the underlying technical weeds. Today, there are millions (if not billions) of profile pages that that include a WebID constructed using a "#" based fragment identifier (functioning as an indexical). Google has made that happen via its transition from SEO (keywords) to SSEO based E-A-T (knowledge graph based) aided by Schema.org. > > Turtle didnt catch on. Turtle already drives the LOD Cloud, but it isn't the issue. The issue is not separating the notion of a WebID from the implementation details associated with a WebID-Profile document. JSON-LD has emerged as yet another notation and serialization format for RDF, with the added benefit of being supported by Google. Net effect, there's lots of it embedded in HTML docs aimed at (E)xpertise (A)uthority and (T)rust (EAT) based Semantic Search Engine Optimization (SSEO). In addition, JSON-LD as a JSON dialect, is more Web Developer friendly due to a vast number of developer tools that can handle JSON. JSON is what XML was supposed to be, and it took RDF specs a little too long to accept this fundamental reality. > 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. It isn't about Turtle. It is about decoupling from any RDF notation and serialization format combo. A WebID is simply an HTTP based Identifier. That's it. The moment you tinker with that fundamental definition the entire conceptual stack implodes and adoption becomes unnecessarily challenging. > > We'll have WebID-Turtle, WebID-JSON-LD and other things that people want. Again, those are WebID-Profile Document Types. They have zilch to do with what the term WebID denotes. > > Should RDF be mentioned in the super set spec? No. RDF too is a distraction, since it is generally misunderstood. Fundamentally, RDF is just W3C standardization for structured data representation using entity relationship graphs. Prior to RDF, and the Web at large, there were no broadly adopted industry standards naming entities used to construct entity relationship graphs. The old EAV model never had such standardization. The emergence of the Web unleashed the HTTP URI as a ubiquitous identifier for unambiguous entity naming, which is why TimBL used it as the cornerstone of putting the "Web" back into the notion of a "Semantic Web" via Linked Data Principles. As I've stated in the past, a JSON file represents an entity relationship graph where subjects and objects are named using blank nodes (indefinite pronouns), while predicates are named using literal. Thus, it is easily transformable into RDF (even without JSON-LD). Again, document content types and identifier shouldn't be conflated in specs. They are different things that SHOULD be loosely coupled. > 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. Again, when have I ever used the term "branding" in regards to any of my comments about WebID or anything else? We are talking about concepts and specifications i.e., nothing in the world to do with branding. > > So, what is a WebID? It's whatever we want it to be. Sorry, that's incorrect. It is an HTTP URI that names an Agent unambiguously. > 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. WebID was poorly specified due conflation with WebID-Profile documents. That was the fundamental difference between my late friend Henry Story and I i.e., having a MUST for RDF-Turtle (solely) compromised a powerful conceptual abstraction, since Web Developers and Content Publishers wouldn't be using Turtle to craft document metadata (what I refer to when I used the phrase "structured data islands"). > 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. From my vantage point, WebID's woes simply mirror RDF's woes: A powerful concept distorted by implementation details. Developers are fixated on data serialization formats, since they don't even think in terms of abstract modeling and notations, due to the pragmatic aspects of engineering i.e., stuff needs to get done before the budget vaporizes. RDF/XML and RDF used to be conflated. It took the LOD cloud to unshackle RDF from XML, only to end up with Turtle as the replacement, unfortunately repeating the same tight-coupling error. JSON and/or JSON-LD are the formats that developers will use because there are a boatload of tools out their to aid their productivity. That's all that matters in the game of software development. The concept underlying a WebID has already past the point of critical mass, courtesy of SSEO. Nothing in the world is going to put that genie back in the bottle, so I once again encourage everyone to ride the wave by simply accepting what a WebID actually is without any Document Type conflation. Links: [1] https://www.openlinksw.com/data/pdf/Semantic_Web_and_LLM-based_Chat_Bot_Symbiosis.pdf -- from a Lecture I recently gave at Brown University, organized by Andy van Dam (Hypertext pioneer from long before the Web existed i.e., dating back to the 60's). [2] https://medium.com/@kidehen/simple-linked-data-deployment-tutorial-using-json-ld-notation-3e753a5d44a3 -- Linked Data Deployment using JSON-LD -- 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 Thursday, 9 November 2023 14:07:30 UTC