Re: What is a WebID?

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