Re: Editing the WebID spec

On Sun, 27 Feb 2022 at 17:25, Kingsley Idehen <kidehen@openlinksw.com>
wrote:

> On 2/27/22 11:14 AM, Jacopo Scazzosi 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?
> >
> > 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?
> >
> > 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.
> >
> > 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.
> >
> > Best regards,
> > Jacopo.
> >
> > ---
> >
> > Jacopo Scazzosi
> > https://jacoscaz.com
> > https://treesandrobots.com
> >
> >
> >
> >
> Hi Jacopo,
>
> I support your generous offer to handle editing of this spec.
>
> If you can get the spec past SHOULD for "text/turtle" that would be
> wonderful, since said spec is headed nowhere without that fix.
>

It's worse than that, Turtle is currently a MUST in the 1.0 Editors Draft:

"A WebID Profile Document is a Web resource that must be available as
text/turtle"

"The server must provide a text/turtle"

"WebID requires that servers must at least be able to provide Turtle"

"The Agent requesting the WebID document must be able to parse documents in
Turtle"

https://www.w3.org/2005/Incubator/webid/spec/identity/

In the spec RDFa is mentioned 19 times, and JSON(-LD) is not mentioned once

The other way round is better

>
>
> Most ironically, Turtle is my favorite notation; used on a daily basis
> (quite naturally) for all my note-taking; but still not the basis for
> imposing it on everyone else.
>
> The WebID spec could potentially help the world move from currently
> centralized PKI to a more desired decentralized PKI.
>

+1 to PKI ... there is a big opportunity there and appetite for this in the
modern web environment


>
> Good luck!
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog:
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>                http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>          :
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
>
>