- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Mon, 5 Feb 2024 13:36:26 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: public-webid <public-webid@w3.org>
My 2 cents... It seems to me that we have a conflicting set of requirements. Some want JSON-LD, some want static files to work, etc. etc. The consensus that the group seemed to be arriving at, albeit with objections, was to mandate not only Turtle (as 1.0 did) but also JSON-LD in 2.0. As much as I disagree with Melvin (mostly about static files being a feasible Linked Data application architecture), the issue https://github.com/w3c/WebID/issues/58 that he raised is convincing to me that adding JSON-LD could create backwards compatibility issues. We illustrated this with examples. It seems to be quite quickly dismissed as a non-issue and a "reasonable breaking change". That is what doesn't sit well with me, because the whole premise of mandating a specific media type in 1.0 was a wrong one, and the proposal wants to keep adding to it, expecting to somehow result in a solution. Let me quote here: "We can't solve problems by using the same kind of thinking we used when we created them." Why was mandating a media type a mistake? Because if WebID is an RDF-based specification, and we want to see it on the W3C track (as I think most of us do), we must follow W3C best practices. Open any specification in the RDF stack -- OWL, SPARQL, SHACL, whatever -- and look for mandated RDF serialization. There are none, because serialization is a completely orthogonal matter. If this spec is not considered RDF-based or has no plans for W3C track, then I'm not interested in it. And frankly I don't care if TimBL insisted on mandating Turtle in the 1.0 draft. I do not see his name on any of the RDF specs. So my proposal, or at least thought experiment is (which I should probably have brought up earlier): what if we remove the media type requirement altogether? Whose requirements are not met then, and what breaks? And are those potential breakages really worse than the "reasonable breaking change" of adding JSON-LD? And we need concrete request/response examples illustrating them, just like we have in issue #58, so that we can compare the approaches. Otherwise it's just words, and I feel like we have had enough of them already :) Thoughts? Martynas On Sun, Feb 4, 2024 at 10:55 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > Observations on WebID definition and specification > > 1. Our collective grasp of WebID's essence is substantial, yet not absolute. There's a notable consensus (around 60%-90%) on its definition and specification, but achieving complete unanimity has been elusive. > > 2. This shared understanding has facilitated progress in certain areas while posing challenges in others. A more crystallized consensus would greatly simplify work items based on WebID. > > 3. Currently, WebID's comprehensive definition and specification are dispersed across various resources over time, including within the Solid community, leading to divergent interpretations. > > 4. The WebID CG stands as the most fitting forum for establishing a definitive and comprehensive articulation of WebID. It's incumbent upon the CG to undertake this clarification. > > 5. Efforts towards a complete definition are often hindered by minor discrepancies, notably around serialization debates, or implementation details, stalling progress for years. > > 6. Addressing this by adopting a serialization-neutral definition of WebID could be the initial step, with serialization specifics to follow. This could be as simple as one sentence following another. > > 7. Presently, the lack of a lucid, universally accepted definition of WebID impedes our collective clarity and progress. > > Suggestion: Forward movement hinges on a shared commitment to a serialization-agnostic, implementation-neutral understanding of WebID, fully specified, and free from ambiguities. > > Once established, we can then delve into serialization specifics. I suggest we do this so that everyone can get behind a shared understanding, thus making life and future consensus that much easier.
Received on Monday, 5 February 2024 12:36:45 UTC