Re: Editing the WebID spec

On Sun, 27 Feb 2022 at 17:15, Jacopo Scazzosi <jacopo@scazzosi.com> wrote:

> Hi all,
>
> Although I never intended to originally, discussion in
> https://lists.w3.org/Archives/Public/public-webid/2022Jan/0146.html has
> brought me to consider trying my hand at editing the WebID spec into the
> next, and hopefully final, version.
>
> While I might not be the best candidate for the job, it does look like I
> am the only candidate at this point in time; I am happy to give it a try,
> if you'll have me.
>
> First question: does anyone have anything against my editing the spec?
>

+1 as new editor

Typically community groups can make structural changes with 4 approving
votes, which I believe you've had

There's a few algorithms for selecting editors and chairs, that other
groups use e.g.

https://www.w3.org/community/council/wiki/Chair_selection#Simple_Algorithm

We could also select chairs as needed, every so often (typically 6 months)


>
> As a community, we seem to be converging around something close-ish to
> what I sketched out in
> https://github.com/w3c/WebID/issues/3#issuecomment-1036034868:
>
> > It looks to me as if a good tradeoff would be a WebID Core spec that:
> >
> > 1. explicitly states that profile documents must be available in one or
> >    more RDF serialization formats (EDITED for clarification)
> > 2. has a SHOULD on a couple of suggested formats (best practices), making
> >    turtle one of them for backward compat
> > 3. explicitly suggests a mechanism for linking to extended profile
> >    documents (best practices), so that Solid can use WebID documents to
> >    find a Solid-compatible, read-write document
> > 4. explicitly mentions writability as an orthogonal concern and that
> >    implementations are not required to be read-write
> > 5. explicitly mentions conneg as an orthogonal concern and that
> >    implementations are not required to support it
> >
> > Of course, the risk with the above is that clients might end up being
> > forced to implement way too many formats for the spec to be considered
> > practical. However, that would be where the best practices come in.
> > Limiting to turtle, RDFa and JSON-LD with a context that makes it
> > parsable as standard JSON should cover most cases without being too
> > onerous to implement. Turtle is easy to parse, RDFa can be extracted
> > without parsing HTML into DOM maintaining a persistent DOM representation
> > and JSON parsing is everywhere. Full JSON-LD parsing would be an entirely
> > different beast, and thus I don't think we should look at it as a best
> > practice.
>
> Note that I'm not saying that we are all in perfect agreement on the above;
> I myself, for example, have come to prefer data islands over HTML+RDFa and
> I would prefer the proposed best practice to focus on the former rather
> than the latter. I'm also sure some would prefer leaving the choice of
> JSON-LD context up to implementors. There's still plenty of discussion to
> be
> had on the finer details.
>
> However, there seems to be a growing consensus on relaxing the current MUST
> on text/turtle into a SHOULD and on the orthogonality of read-write, conneg
> and on extended profile documents. I think this would be a good starting
> point for me to begin working on a foundational, organic PR that would lay
> the foundations for further, smaller, more focused changes.
>
> I understand that some of you may be more comfortable with smaller PRs
> right from the start. However, the extent of the changes that we are
> discussing is such that I would personally find it impossible to be even
> remotely effective without an initial revision of the entire document.
>
> Second question: does anyone have anything against this approach?
>

No objection here, thanks for asking!

I think role of Editor is to reflect consensus of the group and listen to
objections


>
> Lastly, the conversation around WebID is happening both on this mailing
> list and on GitHub. I tend to favor mailing lists but I see some being
> more active on GitHub; I am ok with trying to keep track of both.
>
> For those of you who are not following the conversation on both this list
> and GitHub and that do not agree on relaxing the MUST on text/turtle into
> a SHOULD, or any of the above, I would like to learn more about the reasons
> behind your disagreement! I kindly ask you to give your feedback (in GitHub
> or via this list) on
> https://github.com/w3c/WebID/issues/3#issuecomment-1042324477 , which I
> quote:
>
> > However, one single mandatory serialization format breaks a number of use
> > cases, from static hosting to most major CMSs. Basically, all cases that
> > require serving a profile document in a human-friendly format without an
> > easy way to enable/configure conneg.
> >
> > To this day, Wordpress still retains a huge market share as a publishing
> > platform. Adding a data island within a page or template is easy, adding
> > conneg to serve Turtle is a lot harder. [...]
> >
> > A similar argument can be made for most CMSs, for statically-generated
> > websites, for hosting files on low-power devices and more.
> >
> > **If not by relaxing the requirement on a specific serialization format,
> > how would you address these use cases?**
>
> I hope you will allow me to try pushing the spec forward but I understand
> the reservations you might have; I have never editer a spec, after all, and
> I'm relatively new on the scene. I might make mistakes, I might be either
> too pushy or not pushy enough, I might come across in ways I never
> intended.
> Most importantly, I might bite more than I can chew, considering how long
> WebID has lingered in the current draft state.
>

Thanks for putting effort into this.  I think someone fresh would actually
be an advantage as the spec has stalled for 8 years.  All previous issues
are kicked into the long grass.  So new energy could increase the chance of
progress from quite low, to quite high :)


>
> The only thing I can guarantee is that, if you'll have me, I'll give this
> my best. I am happy to answer any question you might have, publicly or
> privately.
>

Thanks again

It might be worth having two drafts.  One which tries to fix issues in the
current draft, which might have various stakeholders, with some resistance
to change,  And one new spec, that is simple and less constrained, as time
allows.

What I'd personally this webid should look like:

- A WebID is a URI that denotes an Agent
- Details of what an Agent means
- Conneg should either be an implementation detail, or left in the 1.x spec
- Example serializations that can be copy and paste
- Example serializations that can live in vanilla static hosting
- JSON-LD explicitly mentioned with examples
- A JSON-LD context to make life easy

Ideally the WebID spec could be simple and elegante, maybe as little as 1-2
pages

>
>
> Best regards,
> Jacopo.
>
> ---
>
> Jacopo Scazzosi
> https://jacoscaz.com
> https://treesandrobots.com
>
>
>
>
>