- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 27 Feb 2022 11:24:39 -0500
- To: public-webid@w3.org
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. 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. 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
Received on Sunday, 27 February 2022 16:24:54 UTC