Re: How to move forward

pá 5. 1. 2024 v 16:52 odesílatel Wouter Termont <woutermont@gmail.com>
napsal:

> 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.
>

Hi Wouter, whole heartedly agree on finding common ground, as a means to
make progress.

It strikes me that the real value here is in extension profiles.  Once we
get the ball rolling there, and use it in the wild, the utility will
quickly become apparent.

That in turn, will inform future CG decisions based on rough consensus and
running code.

Each milestone completed, then makes future, and longer-term, decisions
that much easier to reach consensus, because there will be fewer moving
parts, and implementation feedback.

In short, let's try and get the ball rolling with WebID extension profiles,
and build things using them.  How does that sound, to you?


>
> 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.
>>
>