Re: How to move forward

Hi Jacopo,

I'm not one for mailing lists; I must say I find them rather old-school and
difficult to work with, especially to keep track of them parallel to
similar discussions in other channels. However, with the purpose of moving
forward, I find myself making an exception.

Characterizing the active participants as 'split' between two options is
i.m.o. neither productive nor correct. Both 'options' you list are, in
fact, achievable together: we can (re)iterate over the current spec, with
the introduction of profiles being one of those iterations (and the
possible adoption of a second RDF syntax another). This is, I believe, how
the vast majority of participants sees us moving forward: iteratively (not
in one big PR) _and_ introducing profiles, at least for the
authentication mechanism (TLS, OIDC ...). Any other way forward is
therefore, i.m.o., not acceptable.

Of course, there is a lot of disagreement between participants on a lot of
different issues, but those can all be handled in time _within_ the
iterative and profiled way summarized above. Whether profiles should also
differentiate between RDF syntaxes or not, and which vocabulary the spec
should employ, can all be resolved in further (later) iterations. Let's
thus focus on the common ground we already have, and process that into a
well-supported PR, before we tackle the next hot potatoes. If the group
should desire, I am more than willing to write a minimal change request for
the above as a first iteration.

WIth the best intentions,
Kind regards,

Wouter Termont

On Fri, Jan 5, 2024 at 3:23 PM Jacopo Scazzosi <jacopo@scazzosi.com> wrote:

> Hi all,
>
> Insofar as I can see, we seem to be split across two different ways to
> move forward:
>
> 1. Primary WebID spec accompanied by feature-based Extension Profiles
> (WebID-TLS, WebID-OIDC, ...), which evolved from the superspec/subspec
> proposal
> 2. Iterating on the current specification by clarifying and/or narrowing
> scope and/or disambiguating
>
> As summarized by Melvin, option 1. has received some positive feedback:
>
> > Proposal:
> > https://lists.w3.org/Archives/Public/public-webid/2023Jul/0056.html
> >
> > Multiple +1s:
> > https://lists.w3.org/Archives/Public/public-webid/2023Jul/0065.html
> > https://lists.w3.org/Archives/Public/public-webid/2023Jul/0057.html
> > https://lists.w3.org/Archives/Public/public-webid/2023Jul/0058.html
> > https://lists.w3.org/Archives/Public/public-webid/2023Jul/0061.html
>
> Further positive feedback for option 1. stems from my presentation as
> chair in
> https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html .
>
> Given the positive feedback to option 1., I took a stab at it in
> https://github.com/w3c/WebID/pull/27 . That PR ultimately got rejected
> but producing it was very instructive nonetheless. In particular, there
> were two main kinds of objections:
>
> - Process: many of us would rather see changes made through small,
> individual PRs
> - Merit: some of us believe that the existing ED only needs minor
> revisions to become acceptable
>
> When it comes to process, I remain personally unconvinced that small PRs
> are a good way forward, particularly given the last few days of activity,
> but as chair I’m happy to switch gear.
>
> As for merit, though, this is where option 2. comes in. I’m not the best
> person to summarize it as it does not lead to a spec I could actually use
> but I think Kingsley does it well, at least for one possible version of it:
>
> > 1. Rename the current specification e.g., "WebID Profile Document
> Specification for {Specific Content-Type} using {Specific Vocab Terms}
> > 2. Fix content of the current specification by incorporating JSON-LD as
> an alternative content-type option alongside Turtle; while also
> incorporating equivalent Schema.org term -- thereby allowing implementers
> pick their preference
>
>
> Now, regardless of how much work is needed to get to the final results and
> how such work should be organized and carried out, option 1. and 2. are
> mutually exclusive. We can’t do both at the same time.
>
> So, my questions to you all:
>
> 1. Which option do you prefer?
> 2. Would you still consider the other option acceptable?
>
> Note that this is not a call for a vote, formal or otherwise. It is just
> an attempt to figure out whether we can converge towards a shared end goal
> and where that might be.
>
> Best,
> J.
>