search

w3c / WebID

https://www.w3.org/groups/cg/webid
MIT License
14 stars 7 forks source link

Minor comment: D is not for Discovery #39

Closed melvincarvalho closed 8 months ago

melvincarvalho commented 8 months ago

This is a minor comment that can be closed at any time

I'm just noting that WebID is not a recursive defintion where I=Identity and D=Discovery

Although that is a clever observation by @kidehen

The D in WebID doesnt actually stand for anything

Just a fun historical context. Back in 2008 Henry bought the domain foafssl.org

And Toby Inkster pointed out that it was a bit of a mouthful for a project, what should we call it instead.

He suggested "Secure WebID"

I suggested just "WebID"

Kingsley suggested "Secure Web Idenitty (SWI)" or "Secure Web Idenitty via FOAF (SWIF)"

Funnily enough a big sticking point with Toby at the time was the "D" because he said that D didnt stand for anything. To be fair he has a point.

In the end we settled with WebID as timbl was using "Web ID" in other papers at the time, and once we got his blessing it became a kind of project codename

So I dont think we should do D=Discovery in an recursive definition, to honour the original concept, smart as it is

I dont think this is a sticking point with anyone, so this can simply be closed, feel free to add any interesting context of WebID Origins for the historical record, so they dont get lost.

kidehen commented 8 months ago

He suggested "Secure WebID"

I suggested just "WebID"

Kingsley suggested "Secure Web Idenitty (SWI)" or "Secure Web Idenitty via FOAF (SWIF)"

Do you have links regarding the above? I know there's a lot of terrible link-rot blurring history right now -- most unfortunately.

WebID was coined in an IRC chat involving TimBL, Henry, and I. That happened circa 2007.

Toby was certainly instrumental to what lead Henry to FOAF+SSL, for sure.

Right now, addressing the "D" in WebID (making a recursive acronym) is a potential way out of the current problem i.e., a specification that isn't inherently confusing and subject to perpetual stalemates associated with terminology and/or testsuites.

melvincarvalho commented 8 months ago

Do you have links regarding the above? I know there's a lot of terrible link-rot blurring history right now -- most unfortunately.

Indeed there is. The foaf protocols lists page is no longer up. But it's on the foaf project site.

I have been through a few 1000 emails to get that chain tho

Do you mean IRC Swig? If so, it was logged.

Re D=Discovery, it is just a coincidence, as things stand. It might be possible to make something more of it, but it may end up being more confusing than it is worth.

I found this too:

https://www.w3.org/wiki/WebID

A WebID is a way to uniquely identify a person, company, organisation, or other agent using a URI. The term "WebID" was coined by Dan Brickley and Tim Berners-Lee in 2000. (Citation needed)

kidehen commented 8 months ago

Re D=Discovery, it is just a coincidence, as things stand. It might be possible to make something more of it, but it may end up being more confusing than it is worth.

Be it coincidence or outright serendipity, my point is as follows: WebID as a recursive acronym for WebID Identity and Discovery offers a way out of the current quagmire. It provides a better title for the specification doc by addressing the following:

  1. Confusing definition of a WebID due to spec title -- which is currently "Web 1.0 Specification"
  2. Broken abstract that doesn't explain the WebID and WebID Profile Doc codependency

We are once again at a point where "The Wisdom of Solomon" is before us. Do we save the baby or split it in half?

melvincarvalho commented 8 months ago

Definitely dont kill the baby. This is the root page of the 2014 spec family:

https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

Maybe D=Discovery is serendipity, but it might be helpful to clarify what exactly you'd like to see on the page instead of:

image

melvincarvalho commented 8 months ago

We are once again at a point where "The Wisdom of Solomon" is before us. Do we save the baby or split it in half?

What about:

"WebID Definitions"

melvincarvalho commented 8 months ago

So perhaps we should consider these as two potential options:

To avoid name clashes?

kidehen commented 8 months ago

What about:

"WebID Definitions"

It fails the "is your WebID conformant" test.

We need a spec that isn't susceptible to "Your implementation isn't conformant" based on nuanced interpretation of a spec.

We need something that's properly named, implementable, and verifiable using a testsuite.

For instance, I shared one of my WebID's earlier and it was perceived as non-conforming because it didn't return Turtle, a matter trivially fixed by a re-write rule.

melvincarvalho commented 8 months ago

What about: "WebID Definitions"

It fails the "is your WebID conformant" test.

We need a spec that isn't susceptible to "Your implementation isn't conformant" based on nuanced interpretation of a spec.

We need something that's properly named, implementable, and verifiable using a testsuite.

For instance, I shared one of my WebID's earlier and it was perceived as non-conforming because it didn't return Turtle, a matter trivially fixed by a re-write rule.

@woutermont was right here. The webid that you showcased was non-conformant.

$ curl -I https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html curl: (60) SSL certificate problem: unable to get local issuer certificate

Also:

$ curl -k -H "Accept: text/turtle" https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>

But this is not a debugging session.

I was pointing out that D does not mean Discovery. In the transition from foaf+ssl -> WebID we had a nomenclature thread where D was actually problematic in that it didnt stand for anything

melvincarvalho commented 8 months ago

PS the link is no longer there to the conversation but if you do a search in your inbox for "nomenclature" by Toby Inkster, you may find it, in full

melvincarvalho commented 8 months ago

I still dont fully understand why you want to introduce a recursive definition, after the fact

I will concede it's a clever observation

But I dont see how it tangibly helps the standards effort. I'm missing the logic completely.

kidehen commented 8 months ago

@woutermont was right here. The webid that you showcased was non-conformant.

$ curl -I https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html curl: (60) SSL certificate problem: unable to get local issuer certificate

Also:

$ curl -k -H "Accept: text/turtle" https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html

Hmm, okay, what's wrong with this WebID ?

kidehen commented 8 months ago

I still dont fully understand why you want to introduce a recursive definition, after the fact

Because a recursive acronym solves the problem.

You are not going to have a spec titled "Web 1.0" or "Web 1.0 Core" that will reach consensus, and rightly so.

You could have a spec titled "WebID Identity and Discovery 1.0." or even "WebID Identity and Discovery Core 1.0" that stands a chance.

We need a draft spec with the following characteristics:

  1. It passes a basic coherence test i.e., no confusing conflations
  2. It has a probable route to manifestation by applying PRs to the current broken spec
  3. In the absolute worst case, it can manifests via the draft put forth by @jacoscaz

Again, I call on the "Wisdom of Solomon" to move this thing forward.

If you disagree with my suggestion, please articulate your opposition on a point by point basis. That will help everyone understand the roadblock.

Nathan (@webr3) spelt out his issue very clearly i.e., he wanted the notion of a WebID to be verifiable using a testsuite (software) rather than informatively in natural language prose. My suggestion about a recursive acronym (which I don't even particularly like) offers a middle ground solution that can move things forward (as he has already indicated).

melvincarvalho commented 8 months ago

Hmm, okay, what's wrong with this WebID ?

LGTM, though I havent done a deep dive, we would need a test suite for that.

kidehen commented 8 months ago

LGTM, though I havent done a deep dive, we would need a test suite for that.

Because?

melvincarvalho commented 8 months ago

Because?

Because eye balling something is never perfect, because humans can make mistakes.

For example, I was uncertain on:

  <ttps://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid> owl:sameAs  <https://linkedin.com/in/kidehen#identity> ,
    <https://twitter.com/kidehen#identity> ,
    <https://mastodon.social/kidehen#identity>  .

Test suites would be able to comment on all these things. Humans cant, and dont have the time to.

melvincarvalho commented 8 months ago

Because a recursive acronym solves the problem.

This does not resonate with me, and changes the history. Perhaps others will like it, but I see this now as personal preference.

The group can come to consensus on naming, though.

melvincarvalho commented 8 months ago

Again, I call on the "Wisdom of Solomon" to move this thing forward.

:100: agree with this. Whatever title resonates with the group we can use. No need to kill the baby, or 12 years of work, on a naming issue!

Just requires compromise on a non-blocking naming issue.

kidehen commented 8 months ago

For example, I was uncertain on:

  <ttps://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid> owl:sameAs    <https://linkedin.com/in/kidehen#identity> ,
  <https://twitter.com/kidehen#identity> ,
  <https://mastodon.social/kidehen#identity>  .

Test suites would be able to comment on all these things. Humans cant, and dont have the time to.

Let's try again.

What's wrong with the following WebID?

https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/profile.ttl#identity

Note, I am denoted by a different WebID this time around.

melvincarvalho commented 8 months ago

"wrong" is a loaded term, and a vector to create an adversarial debate

Prefer to use the word "conformant" which is less inflammatory

You are begging the question, because this issue was not about debugging a specific WebID, it was a note about D in WebID not having a meaning.

I'm saying I dont know whether or not your WebID is conformant without having access to a test suite.

melvincarvalho commented 8 months ago

If you disagree with my suggestion, please articulate your opposition on a point by point basis. That will help everyone understand the roadblock.

The solution to the naming issue is to first let the dust settle and give the chair a bit of breathing space

After this we can have a separate thread about naming and come to a consensus, everyone can have their say, and titles can be picked. To save the baby all that is needed is compromise on naming, which is something that happens all the time.

In the mean time, the current work has unblocked lots of new innovation.

kidehen commented 8 months ago

This does not resonate with me, and changes the history. Perhaps others will like it, but I see this now as personal preference.

Aren't all issues posted by contributors to this discussion, with regards to current spec issues, ultimately personal?

The current problematic spec itself is a reflection of personal preferences that reached some degree of consensus.

As I understand it, the quest for consensus is a journey through debate to common acceptance.

I don't like a recursive acronym, but I do see how it can get us out of the current problem without introducing new problems.

We need to loosely-couple the following:

  1. WebID -- an HTTP URI that names an Agent unambiguously
  2. WebID Profile Document -- a document about an Agent named unambiguously by a WebID
  3. WebID-{Whatever-Auth-Protocol} -- how credentials in a WebID Profile Document are authenticated

You can't shoehorn 1-2 or 1-3 into a document title "WebID 1.0 {Whatever}" and somehow expect to reach consensus. That will not happen, for the reasons I outlined earlier regarding:

  1. Coherence in general
  2. PR friendliness when applied to the current broken spec
  3. Coherence when applied to the alternative draft by @jacoscaz
  4. Problems with other existing specs that are loosely associated with WebID

Related

melvincarvalho commented 8 months ago

Aren't all issues posted by contributors to this discussion, with regards to current spec issues, ultimately personal?

Sometimes they are, for example

I don't like a recursive acronym

And I agree

You can't ... | That will not happen ... |

These are not subjectively worded imho, and makes it difficult to have a discussion

At this point we are drifting off-topic, and the very good points you've raised can be discussed in their own issues, and the group can come to a consensus. I dont think it's a man on the moon mission. You have to be clear on what you, subjectively will object to, and others in the group can do the same. The key is: dont speak for others, just yourself, or maybe for openlink, but let others in the group have their say.

melvincarvalho commented 8 months ago

We need to loosely-couple the following:

1. WebID -- an HTTP URI that names an Agent unambiguously

2. WebID Profile Document -- a document about an Agent named unambiguously by a WebID

I would phrase it differently. It's the responsibility of the WebID CG to define these things, under all scenarios. So we will do that, and should have years ago, which would have saved us some trouble.

Once this is done, then everything else is unblocked. From what I see we are 95% there, which a minor conversation to be had over naming.

The 2014 ED "broken" spec can be fixed after we have a clear definition of what a WebID. Or it can stay as it is. Or it can be moved to the Solid WG.

kidehen commented 8 months ago

everything else is unblocked

What does that mean?

kidehen commented 8 months ago

The key is: dont speak for others, just yourself, or maybe for openlink, but let others in the group have their say.

I am speaking for myself, and I will make it crystal clear whenever I am speaking on behalf of any other entity.

melvincarvalho commented 8 months ago

everything else is unblocked

What does that mean?

What it means is that current implementers are unblocked because they are free to use their existing systems, or fix bugs, or add things

New implementations are unblocked, for example those that want to use JSON-LD can take the agreed upon definitions of WebID which will be a common understanding across all implementations.

melvincarvalho commented 8 months ago

I think this thread can be closed anon, lots of good points raised for the historical record. And newly raised topics can be addressed in new threads.

melvincarvalho commented 8 months ago

Let's try again.

What's wrong with the following WebID?

https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/profile.ttl#identity

Note, I am denoted by a different WebID this time around.

Please ensure that a valid certificate is in place, as the current one does not meet basic verification standards. Additionally, the web IDs listed in your email profile also require attention. To optimize our time effectively, it would be best to address these issues prior to further debugging efforts.

melvincarvalho commented 8 months ago

For example, I was uncertain on:

  <ttps://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid> owl:sameAs  <https://linkedin.com/in/kidehen#identity> ,
    <https://twitter.com/kidehen#identity> ,
    <https://mastodon.social/kidehen#identity>  .

Test suites would be able to comment on all these things. Humans cant, and dont have the time to.

Let's try again.

What's wrong with the following WebID?

https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/profile.ttl#identity

Note, I am denoted by a different WebID this time around.

Someone pointed out to me that you didnt type in the scheme correctly, above. ttps should read https. That typo could break many things, though a test suite would catch it.

melvincarvalho commented 8 months ago

closing, feel free to reopen if required