Re: Editing the WebID spec

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