DRAFT: primary spec and extension profiles

[jacoscaz]

Hi all,

As per the strategy I've enumerated in https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html , I'm opening this PR as the "root" PR for my chair / editor work in trying to get to WebID 1.0 following the superspec / subspecs approach proposed, amongst others, in https://lists.w3.org/Archives/Public/public-webid/2023Jul/0056.html .

Though there is still lots of work, I do feel it's time to condense and materialize the growing centers of consensus into a tangible starting point for further work. To that end, a copy of the primary spec that is always up to date with this PR is available at https://jacoscaz.com/WebID/primary-spec/webid.html . I invite you to have a look and provide as much feedback as you can.

This PR brings a completely new approach that profoundly diverges from that upon which the spec has been built so far while aiming to maintain backward compatibility with current implementations. As such, the first commit is much more foundational in nature than your average commit and, in a different world, would have made for the scaffolding-oriented "first commit" in a completely new repository. Looking at it purely in terms of code changes doesn't make much sense.

This PR is obviously a draft and cannot be merged as-is. On top of being incomplete and requiring significant more work and even more discussion, I've also added Tufte-style sidenotes to host my own editing notes for maximum transparency. These are only temporary and not meant to end up in the final document, should this PR ever get merged.

In terms of issues, this PR touches upon basically all of our open issues and, if and when merged, would resolve many of them.

Should this PR gather the support of enough active participants as a good starting point for further work I would build upon it through much smaller and narrowly scoped commits, easily understood by merely looking at their respective deltas.

I'm very aware that this PR is a very unorthodox one. However, as I've argued in the past, I do not believe that the extent of the changes in consensus and in the concept of WebID that have occurred in the past few months / years can be efficiently and effectively captured by a long list of micro-commits. I kindly ask you to keep an open mind and, if you can, indulge this effort for a few weeks. It only takes a few minutes to go through the primary spec as it is right now.

That said, as the group chair I ultimately serve the group. If the group believes this to be an inappropriate course of action, I'll close this PR and evaluate my options.

@namedgraph @melvincarvalho @acoburn @jonassmedegaard @kidehen @TallTed @woutermont

[melvincarvalho]

This looks great, well done!

either the document's foaf:primaryTopic or the document's schema:mainEntity

I think this is too specific. I would prefer a more general statement here, if possible.

Then have an examples section which should be in JSON. I would prefer a simple example using schema:mainEntityOfPage included, which I think is the simplest possible example, with a broadly adopted vocab. Other examples could be added too.

Otherwise looks great. I can live with any version of this spec, whatever the group decides (including wrt to IRIs, if it doesnt take too long). I'll sign off here as, from my POV WebID, is mission complete. Congrats and thanks for all the hard work!

[webr3]

Great work.

I have a slight concern that it still doesn't do anything to ensure a webid refers to an agent, if implemented as is then schema:mainEntity: {type: Book} would be a valid implementation

Personally the only bit I have any concern about is that the base spec achieves 1 thing, establishing via MUST(s) that iri is an :Agent.

[csarven]

I believe it would be best to keep the existing structure / documents in place, and carry out this approach in its own document or branch until things are actually settled. I don't find it appropriate to wipe/move/legacy stuff for a number of reasons.

The Group should consider progressing 1.0 ED and the exploration on new specifications / splitting of the specification. The core of WebID has been instrumental, and its continuity is important. There's considerable reliance on the current work; dependency by other specifications (e.g., Solid), research, and implementations. Personally, I'm inclined to support the ongoing work on 1.0 ED and am willing to contribute as an editor.

That aside, there are a number of outstanding issues / comments such that a halt on 1.0 ED, let alone a shuffling and splitting of the work, can be justified. What I see is cherry picking, and consensus is being waved without on good grounds or process.

I say this because I'm genuinely concerned about a major fragmentation ahead, and quite possibly the WebID (as we know it) falling apart.

Happy to join a audio/video meeting where we can air a bunch of intertwined concerns, and communicate better.

[kidehen]

WebID defines a standard means by which user agents and servers interact to establish a user's identity, ensuring a structured, decentralized approach for identity discovery on the web.

If find that introductory paragraph confusing, bearing in mind that a WebID is an HTTP based identifier for unambiguously naming an agent.

Since this is about the Web 1.0 Specification, how about.

This specification presents a standardized approach for naming agents unambiguously, establishing a foundation for loosely-coupled identity authenticity protocols that utilize existing Web infrastructure.

[melvincarvalho]

This specification presents a standardized approach for naming agents unambiguously, establishing a foundation for loosely-coupled identity authenticity protocols that utilize existing Web infrastructure.

Looks good! Not opposed to the term unambiguous, but FYI: I opened an issue here to try and understand its significance, or why it was important to you.

[jonassmedegaard]

I do not feel comfortable with this "clean slate"-ish approach. I fear that by rewriting from scratch there is a real risk that we miss out on wisdom of earlier progress. I cannot point at anything in specific, and that is exactly the point making me nervous about the approach: It may make it easier for us right now to make a decision, that we cannot really see what we are looking away from, only what is put on the table in front of us, but I am not convinced that ease of making a decision should be the highest priority.

I hope that we will agree to move forward with roughly what you have put forward now, but I think we would do so as well if it was redone as a series of commits each with a semantically more narrow aim.

I am hereby offering my help to try construct such reenactment-in-git of your thought+editing process. If you will allow me to pick your brain in doing that. To clarify, my intent here is not to try steer you into any other direction, but to end at the exact same point as you have presented here - I just wish for this git repository to contain a more elaborate and granular commit history, both for our more educated decision making process, and also for those coming later and curious how we ended where we did.

You have my email - please get in touch if you find it relevant. Otherwise, I will do as you requested and simply give it a few weeks to let it sink in - but I can say ahead that I doubt that I will change my mind on the powers of revision control in document editing within 14 days.

[melvincarvalho]

consensus is being waved without on good grounds or process

IMHO this is uncharitable to @jacoscaz who has gone out of his way first to establish lazy consensus, and they to carefully facilitate the will of the group. I know of no W3C chair that has done this more carefully or fairly.

[namedgraph]

I appreciate @jacoscaz work but I'm also wondering why the existing WebID specification documents are not reused?

[jacoscaz]

Lots of feedback already - thanks all! I'll address technical feedback separately and at a later date. For the time being, just a few words on process.

The reason behind the "clean slate" approach is that I believe the extent of the changes presented here, if addressed through micro-commits, would have lead to a virtually infinite amount of re-hashing of topics that we've already discussed in depth, a "distraction" that would have effectively stalled the effort. The history and interpersonal dynamics of this group are ample proof that such a thing would be very likely to happen.

Note that I'm not saying that discussion is bad! Not at all! It can become a blocker, though, if we fail to direct it and progress beyond it. Discussion alone does not get to WebID 1.0.

Additionally, and I acknowledge that this is very subjective, I'm not sure my brain would have been able to produce this PR without the clean slate approach. Tracking the conversation and adjusting the document to new consensus is, in itself, challenging. Doing so across multiple commits while trying to maintain a sane history would have been well beyond my abilities.

That said, if enough participant find this PR palatable I might be able to rework it into a sequence of much smaller commits that would get to the same exact place, as suggested by @jonassmedegaard (I think?). I would not be willing to open a PR for each of those commits but, if we all agree about the end result, I could go back to the beginning and get there in a few more steps.

As for the files, @namedgraph , given the extent of the changes and my own sensibilities towards preserving the history of this repository, I thought it best to "freeze" the current spec and its history for historical purposes and work on new files alone. I'd happy to make more invasive changes to the current documents if that's what the group wants, though.

[jonassmedegaard]

That said, if enough participant find this PR palatable I might be able to rework it into a sequence of much smaller commits that would get to the same exact place, as suggested by @jonassmedegaard (I think?). I would not be willing to open a PR for each of those commits but, if we all agree about the end result, I could go back to the beginning and get there in a few more steps.

If you could spare the energy in doing that, I indeed think it would be very helpful. Not helpful as in giving an opportunity to micromanage your work by taking it apart and discussing each commit as if it would be sensible to pick selectively - I do trust your judgement when deciding that it is an all-or-nothing proposal you want to make. Instead, helpful as in allowing us and future interested parties to better understand what this change consists of.

And in case you missed that bit, I am also offering to aid you in doing the tedious work of reding your change as multiple commits. I would be delighted for this opportunity to collaborate closely with you, if you see a possibility for that to ease the added burden.

[jonassmedegaard]

if we all agree about the end result, I could go back to the beginning and get there in a few more steps.

Oh, and to clarify: It would be helpful to me to have a more granular changeset before deciding on whether your wholesale proposal is reasonable to me, not only for posterity.

If you think that is not doable (e.g. because you want the next weeks with your family, or perhaps because you fear that providing granularity will invite for unwanted nitpicking discussions despite my optimistic view on that) then it would be helpful that you clarify that intent of yours. Because then I will spend time reverse engineering your all-at-once commit on my own, privately, to aid in my own understanding (but then wasting the potential benefit in others having access to my insights).

[kidehen]

Lots of feedback already - thanks all! I'll address technical feedback separately and at a later date. For the time being, just a few words on process.

The reason behind the "clean slate" approach is that I believe the extent of the changes presented here, if addressed through micro-commits, would have lead to a virtually infinite amount of re-hashing of topics that we've already discussed in depth, a "distraction" that would have effectively stalled the effort. The history and interpersonal dynamics of this group are ample proof that such a thing would be very likely to happen.

As far as I can recall, the current spec only has a few niggling issues to be rectified:

1. MUST for Turtle Notation
2. Tight-coupling with a specific authentication protocol i.e., WebID-TLS

Those issues don't warrant a re-write that will inevitably lose important insights from the past.

For the record, the existing spec only needs minor changes. It never required a wholesale re-write.

-1 for any kind of wholesale re-write.

[TallTed]

To be more explicit than my +1 on @kidehen's comment —

-1 for any kind of wholesale re-write; the existing ED needs only relatively minor revision to become acceptable to me.

[jacoscaz]

Hi all! Apologies for the absence, I had to tend to some unexpected personal matters during the holidays.

For the record, the existing spec only needs minor changes. It never required a wholesale re-write.

@kidehen @TallTed obviously I disagree, otherwise I would not have asked for feedback on a PR like this. If minor changes were all that is needed to finalize the existing spec, shouldn't that have happened years ago? To me, threads like https://github.com/w3c/WebID/issues/3, and that's just an example out of many, read as if the changes required to achieve substantial consensus across active participants are not that minor.

That said, this PR clearly doesn't stand a chance at gathering enough consensus, at least as it is right now. Let's see if I can do anything to make it more palatable.

If we all agree about the end result, I could go back to the beginning and get there in a few more steps.

Oh, and to clarify: It would be helpful to me to have a more granular changeset before deciding on whether your wholesale proposal is reasonable to me, not only for posterity.

@jonassmedegaard I understand, thank you for clarifying. I don't necessarily share your perspective, given that both the existing spec and what I am proposing in this PR can be fully read through in limited amounts of time, but I see the logic behind it. I also deeply appreciate your offer to help out.

So, what if I were to refactor this PR so as to split the current commit into a sequence of much smaller and more focused commits, building upon the existing spec rather than starting off of a new document? I think this would address the feedback from @namedgraph , @jonassmedegaard and maybe @melvincarvalho (I can't tell from the +1s), at least insofar as getting the PR to a point in which they would be willing to review it.

However, I would still end up rewriting most if not all of the existing spec and I am afraid this would still not be enough for @kidehen , @TallTed and @csarven to contemplate reviewing it. I am not sure as to how to address this, though, as I am honestly and whole heartedly convinced that group consensus lies well beyond any minor change we could make to the existing spec.

As for your offer to help, @jonassmedegaard, I think I'd be more efficient in doing an initial refactor on my own but perhaps I might ask you for your feedback to iterate on it before soliciting the feedback of others? Iterating as a pair would be faster than doing so with the entire group and I suspect your sensibility is shared by a few others.

[kidehen]

@kidehen @TallTed obviously I disagree, otherwise I would not have asked for feedback on a PR like this. If minor changes were all that is needed to finalize the existing spec, shouldn't that have happened years ago?

These minor changes never happened because of the process required to enact them. Once again, this spec doesn't need a wholesale rewrite.

[TallTed]

@kidehen @TallTed obviously I disagree, otherwise I would not have asked for feedback on a PR like this. If minor changes were all that is needed to finalize the existing spec, shouldn't that have happened years ago? To me, threads like https://github.com/w3c/WebID/issues/3, and that's just an example out of many, read as if the changes required to achieve substantial consensus across active participants are not that minor.

Today's "active participants" are not yesterday's nor yesteryear's.

Substantial consensus existed for the bulk of the existing draft document, but we were unable to overcome the sticking points before the previous WebID WG's charter expired. (I know this because I was an active participant in that WG.)

Regrettably, the existing draft document appeared (and to a somewhat lesser degree, still does appear) as if it were more mature than it is/was. This caused a number of people to act as if it was in full TR status, even though a bit of web digging would have revealed that it was not even CR (Candidate Recommendation), never mind PR (Proposed Recommendation) nor TR (Technical Recommendation). This has led to an indeterminate (but definitely greater than zero) number of implementations now in the wild, based on the existing draft. These include derivative works, such as WebID-TLS and WebID-OIDC.

I am typically pitiless for implementers of draft specifications, and argue that breaking changes are fine when trying to bring such drafts to full TR status. I do not feel that way about this spec because such implementers may well have relied on the existing draft in full good faith, believing its apparent visual status without researching whether that appearance was accurate.

This is why I feel that the fewer changes we make to the existing draft, the better. Some changes are necessary; these are the "minor changes" discussed above by @kidehen, @csarven, and myself, and maybe a few other "minor changes".

Again, wholesale revision is not necessary.

[woutermont]

I'm sorry, @jacoscaz, but I must agree with the majority here: this approach is not doable. Believe me, I know the appeal, I often have the urge to do the same, but there are a number of very good reasons not to.

First of all, there is no consensus about the amount of changes that need to happen. Even most recently active issues together can be incorporated with small changes to a few lines. Moreover, while a handful of very active people have reacted positively to most, in the larger scale of this spec we are outnumbered by all the clever people who came before us in reaching consensus on the current draft.

Secondly, even though I'd say you have some editorial freedom in the way you bundle changes, doing it this way no one really knows what you have changed exactly in the content. Moreover, even if we manually diff everything, so much has changed that we can not react on a granular level (or, if we did so, this PR could take another few years to work through).

Thirdly, there's the point of tracking history, which @csarven already raised. We have an obligation to present and future collaborators to keep track of what we do, based on which decisions, based on which reasoning etc. Moreover, I would say we have the obligation to do so in an accessible way. This is why I would urge you not just to split this in multiple commits, but also to treat those in separate PRs (if you ever tried to track changes through a long straight line of commits, you know why).

---

I think the above points reflect the opinions of most of the currently active members. However, I also want to address the reasons you raise for using this approach, since I believe they contain valid concerns.

[@jacoscaz:] I do not believe that the extent of the changes in consensus and in the concept of WebID that have occurred in the past few months / years can be efficiently and effectively captured by a long list of micro-commits.

Here I believe you are wrong. Other CGs clearly show that it is possible to capture and manage a lot of small changes on a one-per-PR basis. However, I think your real concern is not the management of such PRs, but rather what you say a bit later:

[@jacoscaz:] I believe the extent of the changes presented here, if addressed through micro-commits, would have lead to a virtually infinite amount of re-hashing of topics that we've already discussed in depth, a "distraction" that would have effectively stalled the effort.

This is a valid concern. PRs often become yet another place to discuss the topic their change is about, another hurdle in going from a good idea to an accepted and enacted change. However, rather than throwing away all benefits that come with PRs (see above), we could clearly communicate that the PRs are really meant to already contain the concensus (almost) reached in their corresponding issue, and will only allow for minor finetuning. Moreover, given the tremendous job you already did in manouvering towards consensus in the issues, I don't think this will turn out to be such a problem.

---

Concretely, I would propose to do the following:

1. Leave the folder structure as is. There is really no need to stuff all the work up till now in a "legacy" folder. Working with regular draft snapshots is a well known mechanism used by many CGs, so why not simply work on the existing files?

2. Open one PR to add the top-level README, where it can evolve organically to a great introductory text.

3. Open another PR to update the License dates. I know, it's super minor, but that also means that it will be done in no time.

4. Open a PR to get rid of redundant files (spec/.default-acl, spec/diff-20111123.html, spec/style.css, spec/W3C-ED.css, and possibly w3c.json).

5. Open one PR for each of the recently active issues where you feel consensus has been reached. If you feel you need help formulating that consensus in a concrete change to an existing file, a lot of us would be very willing to extend a hand.

[jacoscaz]

Today's "active participants" are not yesterday's nor yesteryear's.

May I ask you to expand on this, @TallTed ? I'm not sure I understand the underlying message. If we are to bring WebID forward, I believe it would be fair to do so with those that are active today while keeping an eye towards backward compatibility.

Again, wholesale revision is not necessary.

Once again, this spec doesn't need a wholesale rewrite.

I'm sorry, @jacoscaz, but I must agree with the majority here: this approach is not doable.

The group has spoken and the chair serves the group. Obviously, I bring my own set of experiences to the table which strongly discourage me from doing what the group is asking, given its very history, so I tried something different first. Doesn't mean I have any right to do things my way.

Here I believe you are wrong. Other CGs clearly show that it is possible to capture and manage a lot of small changes on a one-per-PR basis.

Indeed they do, although I am not aware of a CG with a history comparable to this one.

Moreover, given the tremendous job you already did in manouvering towards consensus in the issues, I don't think this will turn out to be such a problem.

This sounds exceedingly optimistic to me but, you know what? It's the end of the year, beginning of a new year - let's start with some optimism. Btw @woutermont, nothing to be sorry about. Once again, excellent feedback.

Leave the folder structure as is. There is really no need to stuff all the work up till now in a "legacy" folder. Working with regular draft snapshots is a well known mechanism used by many CGs, so why not simply work on the existing files?

Open one PR to add the top-level README, where it can evolve organically to a great introductory text.

Open another PR to update the License dates. I know, it's super minor, but that also means that it will be done in no time.

Open a PR to get rid of redundant files (spec/.default-acl, spec/diff-20111123.html, spec/style.css, spec/W3C-ED.css, and possibly w3c.json).

Open one PR for each of the recently active issues where you feel consensus has been reached. If you feel you need help formulating that consensus in a concrete change to an existing file, a lot of us would be very willing to extend a hand.

Feels like a good plan! I'll give it a try. If the discussion within each individual PR were to degenerate into endless debate as I fear it might, I will relinquish the chair as per my application as unable to achieve the goal I set out for my chairmanship.

[woutermont]

Well, I think I speak for everyone here when I say we would be extremely sad to see you go so soon, so let's all do our best to keep working towards consensus 😉

[csarven]

Not to discourage anyone but I think it is worthwhile to put some emphasis on a general understanding in the group (even if it is not unanimous). This is not particularly unique to the WebID CG but a general practise in open standards development. Incremental changes and demonstrating open discussion and decision making - essentially a clear record of decisions/understands/intents.

If I may say as an example, what happened in this PR is a very similar to the concerns that were raised in https://github.com/w3c/WebID/pull/15 . If we can isolate or distinguish between clarifications that are needed from new proposals, that'd helps us apply a process that's meaningful or most adequate.

[melvincarvalho]

There is consensus to create a superset and subset spec, and that should be completed by the group, either as a Note, or preferably as a REC.

A reason is that it allows WebID to have the much needed JSON-LD upgrade. JSON is not mentioned anywhere in the 2014 spec, and it needs to be in 2024.

The current WebID spec will not change much, and becomes the Turtle mandated spec, which gets handed over to the Solid WG, and they can have full control of it. The superset should be light and not impose too much on them, or anyone else. In essence it's just a spec that says that a WebID is a URI that denotes an agent, with some examples.

This CG becomes unblocked and can move forward with future subset specs in the future, and the main superset spec need not change for a very long time.

Everyone gets what they want.

[melvincarvalho]

@jacoscaz thank you very much for this effort. If you dont mind, we've forked this early draft, to the solid-lite project. This has completley unblocked our work and will enable us to move forward with new innovation. We will still track the work going on in the CG and aim to align with ongoing group consensus. But for now we can work without blockers, and we owe you a huge thank you for that!

[jacoscaz]

@melvincarvalho that's absolutely fine! Do try to preserve the history, though, or at least some sense of all of those who participated over the years.