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

I realized something that would unblock everything, and aos something that
the CG should have done a while ago.

And that is to clearly define a WebID, such that it is the common consensus
of the CG.

Once that is done, whether it be a W3C REC, a W3C Note, a CG Report, a Wiki
page, or a github repo, anyone that wants to can take it and build webid
based systems.  That can happen either in the CG or outside te CG.

The Turtle Spec will be an example of something that has already
implemented WebID.

Once we have clear common definitions, everyone is able to work, and I
think we are actually almost there, it just needs to be part of the Group's
shared documentation.


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