-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proving that conneg is a breaking change #58
Comments
Really, @melvincarvalho? This is not an issue. @jacoscaz, I suggest moving this to Discussions, which we specifically opened for things like this. I also think that we already had this discussion good and well in issue #3 regarding the serialisation formats. Before repeating ourselves here, I would thus suggest you (re)read the past months of that issue. In particular, I explained at length during multiple comments (here, here, here, here and here), why switching to Turtle+JSON-LD using conneg would not break anything the WebID spec aims to support. In an effort to be constructive, I will try my best to summarize those points here as clear and succinct as I can (parts of the following text is copied from my aforementioned comments).
|
Thanks for this, replies inline. I dont think discussions are universally liked, so perhaps lets keep it as an issue, for a bit:
Doesnt really speak to breaking changes
Not the example I gave of We dont even have a way to test that conneg works on the servers above. Trust me, I've spent hours trying to design such a test with the "solid team". They dont even understand conneg.
Again, the proof stands.
I think you are under estimating the implementation burden here. And how do you keep the different serializations in sync? I think you are agreeing with me that it's a breaking change. And you are trying to argue it's a minor change. That is a subjective analysis, that I dont agree with. But I thank you very much for taking the time to write this all out. I do hope we can make progress. |
How would this look for a compromise:
Why dont we just agree it is a breaking change, and make that very clear, through versioning, then unblock everyone in the group that wants to make progress. Sound reasonable? |
Wading in, unhelpfully as usually. It could be suggested that there are thousands of apps and networks and software and agent classes that would benefit from WebID - and that somewhere close to 0 of them will implement rdf/turtle/conneg (see lack of existence as proof). JSON-LD stands a chance, only because it's json that happens to be LD compatible - we all know it'll likely be invalid json-ld but valid json if adopted widely most of the time. So this underlies everything - keeping WebID tied to turtle and conneg literally prohibits the adoption of the concept. The MUST turtle AND json-ld is simply an appease the beast move to facilitate moving towards an end goal of people actually having webids and the benefits on mass. I personally have a very strong preference for no rdf, and if it must, then json-ld is viable. I only agree to saying must both, because it'll basically force old implementations to be future compatible, and I work on the assumption that types like turtle will simply not be implemented by most future adopters. It's a different realm of the web, one that is far larger. If wide adoption happens, and there's a V3, I'd bet my legs and arms that a review of implementations showed <0.1% support for turtle so I'd be nixed. Just as <0.1% of every in use app service and site supports it. |
I'm not agreeing at all. What I am trying to point out is that this is de facto a minor change (which is per definition not breaking), since none of the stakeholders at which this spec is aimed would be affected. WebID is meant to provide an entry hook into the digital lives of people. To succeed in that, it will need the support of applications to become an ecosystem. That can only be achieved by being flexible on the server side. The spec is NOT meant to serve the whims of some developers who want a static file and don't want to put in 5min of effort. If you want that, you can create another CG, though I doubt you will find many interested parties. But please stop setting your own desires above the aims of this group, who have finally come closer to consensus and are glad about it. |
To shortly reply to this concern: as I said, I timed it, and it takes 5min. Keeping it in sync can be done with an automated script, which is about three lines of code. For example, as a GitHub workflow publishing to GitHub Pages, or using a tool like Soupault when running a static generator locally. |
Did you time conneging flat files, or did you implement something like a mongodb to turtle implementation with media type juggling that produces valid turtle in 5 mins? |
@webr3, what you are saying about conneg makes no sense. Did you even take the time to read the statistics I put effort in to gather?All current providers support conneg with both formats. Why? Because it is a no-brainer. So stop pulling the "conneg is a burden" card, please. As I have clarified elsewhere, I have no ties to Turtle other than backward compatibility (which, by the way, is exactly what @melvincarvalho is making such a ruckus about). I fully agree with your other point that, in some future, it is possible and probable that the spec can drop Turtle support. But it will do so with a decent deprecation strategy, and only after the ecosystem has gradually moved to JSON-LD. Moreover, since the data format landscape has historically proven to be a volatile one, having conneg present will in the even farther future be a practical once more to move from JSON-LD to whatever the majority will fancy then. This is how we build a spec that can outlive such changes. |
It's not only me: See danbri, inventor of FOAF, that got the whole WebID movement going: https://twitter.com/danbri/status/1080490927284736000
I'm going to persist here, you will have to admit it's a breaking change in the case of |
It is. You offering proof of existing rdf conneg compatible systems doing what they do as "easy", of course it is, that's what they do. Whilst completely ignoring the requirement to turn non-rdf non-conneg systems in to doing all that, in order to adopt WebID. That is big, and it's very preclusive to adoption. You cannot say that tiktok or Snapchat or FB quest Auth can just rdf-ize and conneg their systems "in 5 minutes" to adopt it. Let's keep things grounded in the reality of the web, not a niche space on it, please. |
Does it matter? The point is that those handful of people that want it can easily find ways to do it, and at least one of them is set up in a jiffy. My test in particular was aimed at individuals hosting static files. So we're talking about pushing one format to GitHub Pages, having a workflow transpile to the other format, and setting up a Cloudflare rule that redirects to either of them depending on the Accept header. For people setting up a database to host their (and presumably others) WebID data, adding conneg should even be less of a burden, relative to the time it already takes to set up the database in the first place. |
The point is being missed. Conneg = super easy |
That is not my argument. What I show is that, without the spec asking or even suggesting to do so, ALL WebID providers decided to add conneg. So either all of them happen to have massive resources on their hands, or adding conneg really isn't that hard... Which one would it be?
I fully miss what your argument is here. The services you mention do not implement WebID at all. If they would want to do so, they would have to make an investment into RDF anyway. Adding conneg to that investment will be like adding one pea to a bag full of peas. |
Oh, please explain... Edit: mind you, we are talking about the ADDED burden of conneg; anyone adopting WebID will have to produce valid RDF anyway. |
The majority of the web already does json-ld with no investment in the rdf stack, that's the point. To make it accessible to the the web, not the 0.1% of it that's rdfish. Hence the name WebID. If the goal here is for SolidID or RDFID, do that elsewhere.
People with c+p json-ld examples, or a mild wrapping template over json objects, do not have rdf stacks. That's why it's prevalent. This is clear for years. There's a huge difference between doing this and doing an rdf stack for implementations. |
What is the URL? |
Using JSON-LD without RDF stack is a thing, but unless you have numbers I don't believe for a second it is widespread. It's not like non-RDF services just happen to have JSON-LD WebID data lying around, and we're forcing them to actually treat it as RDF. Moreover, even for players that want to enter the WebID ecosystem and up till then work with "non-RDF JSON-LD", adding the few lines of code to transpile valid JSON-LD to valid Turtle can hardly be called a burden. You seem to have a grudge against Solid for some reason, but for all the years that WebID existed, they are the ones that actually put it on the map. As far as I know all WebID providers except OpenLink are primarily Solid businesses or organisations. |
I can account for 1.6bn json-ld documents over ~750 domains alone. I guess every CMS with schema.org producing plugins would account for exponentially more than this.
Not at all, I'd just like webid to be usable by the rest of the web, not a niche segment of it. This can easily be framed as rdf stacks being rest of web compatible, and then forcing the rest of the web to be rdf compatible to use a web scale identity solution. That doesn't sit well with me. Work with what exists. |
Wait, what kind of documents/domains are we talking about? Numbers mean nothing by just throwing them out without reference. These surely cannot be WebIDs or WebID-aspiring services? I also don't see where you want this to go? WebID has been an RDF standard from the start. It currently is produced as Turtle, and I agree that consuming them as JSON-LD would be a benefit for lots of applications. That is precisely why we are proposing conneg. You surely are not saying that applications preferring JSON-LD cannot add an accept header to their requests? |
To go into the only concrete example you gave: CMS's that can produce schema.org data (whatever that is). Schema.org is (or at least pretends to be) an RDF vocabulary, so services producing such output produce RDF, willing or not (just like all JSON-LD is RDF). As I explained above, there is nothing preventing these systems to use one of the widely available RDF transpilers to output any other RDF format on request. (As an aside, I would actively dissuade anyone from using a CMS to host their WebID Document. They are absolutely not secure enough for such a central target in online authentication.) |
Anyway, I'm going to wait for others to chip in. I find it deplorable, however, that you would put a hard-reached consensus, of which you yourself said it was a way forward, on the line again. |
The primary of those domains has 4-5k active users at this moment, higher during weekdays - I want to add webid auth to it, but adding an rdf stack is non compatible with scalable deployments (since 3-4x more bot requests come in than end users - too much weight). We currently run a stateless setup, but have three outstanding items which require auth at scale. We'd both publish and consume webids. Changing backend setups to handle abstract rdf and still serving 1k+ requests a second with low latency just isn't possible or viable or worth the cost and loss by reduce metrics.
Quite the opposite, that server side respecting a json-ld accept is easy, but respecting a turtle accept is hard. Conneg is easy, understanding abstract rdf, storing it in a different format in a db or quad or graph store, then outputting it in a valid concrete format that's equivalent to the others, that's the hard bit - not to mention the maintenance burden of keeping it all up to date. I, and the company I work for, cannot implement a turtle requirement. I personally agree to must and, over both types, with full openness that we'd never implement the turtle bit. |
I've stated repeatedly I'm still.open to MUST AND and find it acceptable - just giving full transparency as to the reasons why, and real world issues faced by having the turtle must. I argue very strongly that WebIDs limited adoption to date, is precisely because it's got a complex rdf requirement, as opposed to a simple view as rdf json-ld requirement. There's no argument here from me, any non preclusive way forward that allows others to implement is fine with me. |
@webr3, can I ask what the service is your client is providing? More particularly, I am curious as to why they would want to host WebIDs themselves. As to the scalability of content negotiated RDF, multiple Solid stakeholders seem to disagree with you (given that they are doing it, I assume they believe it is possible). Without clear insight into your setup, or a benchmark to prove otherwise, I therefore still find it hard to believe. |
Of course, happy to see conversation turning more amicable. To clarify, it's not my client, I am the technical lead and control all aspects of the properties. We work closely with US government agencies both publicly and privately, one of the primary areas we are looking to scale out is basically public and private contact management for various departments and agencies, at a very large scale. As such we would both be the authentication host and provider. Other use cases are more public oriented, and saas, where we'd be hosting what are perhaps best termed webid persona's, public profiles w/ auth for users, both for public publishing, and auth to utilize services. Finally, there's an ongoing web wide problems of delegated authentication, requests made by bots on behalf of other agents, which we're looking to manage - we work with multiple large advertizing agencies and would facilitate them to implement a webid-like agentid that allows the verification of bot requests with keys, ident, and also cidr ranges. This latter part is probably the most likely to scale on mass (as they'd document and roll to other consumers - it could indeed fast become a defacto approach net wide.).
Sure! We have multiple AWS global accelerators, each back on to 4 or more load balancers, which then hit 2x as many reverse haproxy setups, h2 from them over to clusters of servers in near by data centers, each of those machines run haproxy again in front of local web server and required software, behind that we run mongodb clusters, with local replicas on the same physical bare metal as the web servers. Connections are kept open between everything, leading to very low latency, our average request/response time is 23ms currently to end users - with no cacheing. If any of the stakeholders have setups which can handle ~25k db level queries per second at these kind of speeds, ~ 80% read, 20% write - anything sub 10ms for average db/graph level ops would be doable, I'd love to hear about their setups. We have multiple spare servers and can act fast to try things out. Obviously there's no learning curve for the RDF side. |
/chair hat on
@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg? |
Yes, and this can be achieved while also relegating content-negotiation to the implementation details level i.e., putting it in the implementation example (or techniques) section as one approach. I agree with where you are headed, but content-negotiation doesn't need to be a part of the spec, since its just a technique afforded by HTTP re server implementation. |
I appreciate the ongoing discussions and the commitment of everyone involved. I'd like to clarify my perspective regarding the recent propositions:
In summary, I urge us to:
@jacoscaz, your leadership is invaluable, and this isn't a reflection on your chairmanship. Steering the direction of our work requires sensitivity to the foundational elements of the spec, and significant changes demand a proportionate consensus-building effort. Changing things that have been in use for 10 years is going to be 10x more difficult than making progress on a new fresh, extensible, version of WebID for 2024, which gives everyone what they want. |
Timbl was very insistent on having at least one MUST. Basically it means that all clients and servers can ensure a consistent UX for the eco system. Let's say you dropped turlte, and then one group wanted RDF/XML another n3. End users would not know what was happening. |
/chair hat on There are a few things that I would kindly ask everyone to stop and think about before continuing this conversation. Quoting from this comment:
Quoting from this comment:
Unless anyone can refute the above, the only practical breaking change that would be introduced by a MUST on Turtle and JSON-LD for publishers would be to make statically hosted WebID Profile Documents in the form of Turtle This is, indeed, a breaking change, albeit a minor one if we weigh it against the number of occurrences of this particular hosting scenario. Nonetheless, it deserves to be called for what it is - breaking. If we were dealing with a WG aiming to push forward with the next version of a published spec, this would amply justify a version increase. However, as the 2014 ED itself reminds us, there is no such a thing as WebID 1.0:
In fact, any WG that adopted our drafts would be in charge of producing exactly that, the first published, official version of the WebID spec: Web Identity and Discovery (WebID) 1.0 . Adding a version number other than 1.0 to our drafts makes absolutely no sense, if only for the fact that the first official version of the spec would see that number decrease back to 1.0. Nonetheless, given that we are dealing with a breaking change, we do need to provide some way to easily discriminate the working draft from the 2014 ED. Luckily enough, this is how the 2014 ED looks, both in this repo and in the old incubator pages: Though it has been around for a long time, any adopter of the WebID 2014 ED who has actually taken the time to even simply glance at the spec from a distance is already aware of its nature as an ED because the document itself makes that crystal clear. There is no reason to hold back on a breaking change, if there is consensus behind it, as long as we produce a document that can be easily told apart from the 2014 ED. As the screenshot above demonstrates, that's more than easily achieved by simply changing the date. This is how I'm going to move forward, as chair. If any of you were to find it unpalatable, I invite you to a) refute any of the above in a clear, demonstrable, replicable, grounded manner and b) ask me to resign. I serve the group and, if the group deems it so, I'm happy to step down and let someone else carry things forward. |
Thank you very much for confirming this. That was the purpose of the issue. Also thank you for considering all the nuanced viewpoints and reaching that conclusion. IMHO an example of good chairing. I am saying very clearly that I do not want breaking changes to the spec that we have, no matter how slight they are considered by some, there is clearly a spectrum of views on how big a change it is. I personally feel it's the biggest breaking suggestion we've had in years.
I disagree on this completely. You do NOT have consensus to introduce a breaking change.
You cannot railroad breaking changes through to a mature, in use, 10 year stable spec, which has a eco systems built up around it, without full consensus. I simply ask you to focus on items with consensus. This is something you have always done to date. I still have confidence you will continue to do so. |
You honestly lost me completely wtth this. It clearly says WebID 1.0 on your own diagram. It was considered finished, complete and ready for production by the authors. Changing the date to shoe-horn in breaking changes is a non-starter. |
This issue can now be closed, I think we've all expressed ourselves. We can move forward having proved, and with a group consensus that introducing JSON-LD=MUST and/or conneg=MUST is a breaking change. It goes without saying that breaking changes are a high, or perhaps the highest, level of controversial changes a group can have. How we move forward I think is an orthogonal conversation. So I suggest closing in this in a bit, unless someone wants to try and argue that it's not a breaking change. Else we can move forward with a shared understanding which I think will enable progress. |
@melvincarvalho at this point I'm not going to spend any further time on arguing about whether I'm railroading anything or not. Fortunately, everything we do is on record, for everyone to see. You have the right to draw your own conclusions, of course, and I respect that. We obviously disagree on many things, which is also absolutely fine, but I do not have it in myself to continue this manner of interaction as I'm aware that I would become more adversarial than anyone ought to be in their professional (and, IMHO, personal) conduct. I'm going to move forward following the principles that I've laid out in #58 (comment) unless someone refutes them in a clear, demonstrable, replicable, grounded manner and/or the group asks me to step down. |
I'd point back to #17 here. Is there a document called WebID that says it's a specification - yes. Is WebID itself, or a WebID specified by that document: no. The document specifies one thing, a get that responds with turtle. That is not a specification of WebID. Taking this document, and making a new one that still fails to specify WebID, but now says get turtle or json-ld is totally valueless. WebID is still entirely unspecified in any way, anywhere, in any draft. |
Counter proposal. Why not do things that went through the hard multi-month, multi year process of gaining consensus such as the "superspec", which is a shared, serialization-agnostic, understanding of what WebID is, and leads extension profiles, which allow everyone to work?
Counter proposal. Why not do things that are non-breaking, or completely new work?
Counter proposal: bump the version number so that ALL can see the difference. Why cant this be done? The authors/editors of the new spec didnt write WebID 1.0, what claim do they have to it? New work should be unambiguously be made clear as new work, and changing a date is not enough. When did you ever look at a spec and say, "ah the date is different, that's significant"?
Counter proposal: why not be patient and wait for Solid WG to start up, and engage with them, ask them what they want. See if they want WebID to be a REC? Ask them what shape they would like it to be. Find out their needs. Why does it have to be so rushed through (you perhaps dont like my use of the word railroading, so i could withdraw it, and say "rushed", is that better?). Solid WG is predicted to start up early this year. This all seems rushed. How you proceed is up to you. But I will say that you have a close to perfect track record so far. I can only ask you take consensus into account with your decisions, and Im optimistic that you will. I would urge you to focus on the items where you do have consensus. IMHO you've done a fantastic job so far. You've just pivoted from the tricky task of making WebID well-defined, modular and useful, to the impossible task of trying to gain the most difficult consensus that has not been achieved in years, and proposing the biggest change. This is no failing of yours, I dont think anyone could have managed such a difficult task, because there's an inherent impossibility to find serializations that please everyone. I'd encourage you to take the low hanging fruit. EDIT: In any case, I wish you the best of luck, whatever choices you make. Also tried to make the tone a bit more neutral+constructive. |
Linked Data isn't another name for the Semantic Web. Linked Data is simply a principled approach to structured data representation that CAN manifest a Semantic Web. The rules are simple:
A Semantic Web is an entity relationship graph comprising machine-readable (or computable) entity relationship type semantics -- informed by an Ontology. Thus, you can create a basic "Web of Data" using Linked Data principles without links that denote terms in an Ontology (the key to machine-readable entity relationship type semantics). |
Examples can be provided in the specs too, without the need for profiles. +1 for you comments, but noting the view expressed above. |
Agree, though there is perhaps some merit in being able to factor out media-type specific nuances to isolated documents, and allow new ones to be organically created independently.
Couldn't agree more, it's probably clear that personally I'd just leave it where it is, part of history from a different generation and clean slate write something for now. Any consideration to b.c. should be with software that currently exists which has high usage and technical reasons why it cannot be modified easily. There's no point inventing blocks and assuming they are real when perhaps they exist in the realms of thought only. |
Ive suggested this as a possible direction to take. https://lists.w3.org/Archives/Public/public-webid/2024Feb/0002.html |
Your leadership as chair has been nothing short of remarkable, propelling us to unprecedented achievements this quarter. Your ability to discern and address legitimate concerns has been a key factor in our success. However, I would much rather suggest slowing down or pausing, rather than anything more drastic. In order to allow the soon-to-form Solid WG to shape, and they can inform us with vital new information. Taking a well-deserved break might be far preferable to resigning or prematurely tackling highly controversial items. The problems then start to fix themselves in Q2 of 2024 when there will be clarity, where before there was none. The progress we've made under your guidance is undeniable, and what is needed is a serialization and implementation neutral way to define and specify WebID. Conversely, without that shared understanding of what a WebID is, we stand almost no chance of creating a consensus based specification. So the only thing needed here is to do things in the right order (namely defining and specifying WebID first, then picking serializations), and if in doubt, to slow down. I appreciate that is easier said than done, and that you take pride in your work. But let's build on success in a low-risk way, rather than taking the (unnecessary) high risk path to premature failure. EDIT: text clarity improved after feedback |
Indeed. 65 comments on one new issue over a weekend. Plus at least two significant email threads. And other (long!) issue discussions besides. It's great that some people are able to devote all their waking time to such. I am not one of those people. Slowing down, giving time for readers to consider and respond to comments/posts, would not only be a good idea, I think it a necessity. Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC. |
Discussions are fine, as they refine understanding. For example it was unclear before this issue, that proposed changes to add JSON-LD and conneg as a MUST were a breaking change. This issue has established that the proposed changes are indeed a breaking change What should be slowed or paused is breaking changes being applied to WebID. I have advocated for a freeze for some time, until we can, as a group, come up with a serialization and implementation neutral way to define and specify WebID. Something that we as a group should have done years ago. If that can be achieved in Q1 of 2023, or even Q2 (there is no rush). It would be a valuable documentation that lives on its own merits. Then, and only then, is it logical to discuss serialization preferences. |
@TallTed please, be respectful. Your tone is inappropriate. Passive aggressive micro-aggressions add nothing constructive to the conversation. |
I dont mind at this point if this is converted to a discussion, or even better, closed (as there are some external links to it), having established the main premise to reasonable satisfaction. |
/chair hat on
@TallTed and all: we do have a process in place that guarantees review times of up to 4 weeks for breaking changes and I remain steadfast in my quest for unanimity first and, if that cannot be achieved, as large a consensus as we can muster. While conversation can happen in bursts and evolve quickly, this doesn't automatically extend to how changes are made. There's really no risk of this happening as long as we stick to the process we have in place. While I do share a certain frustration with how parts of the conversation are being brought forward, at the present moment there's no risk of anything being decided against general consensus. |
In response to your message, I'd like to express my concerns with utmost respect but with necessary candor. The current approach to implementing substantial changes in a well-established, decade-old project raises significant apprehensions. Introducing major modifications without a more inclusive timeline for feedback disregards the extensive ecosystems and toolings that have matured over the years. Such a brief window for feedback, especially when it risks overlooking substantial objections, seems incongruous with the collaborative spirit and technical stability we've cherished. Moreover, the decision to not revise the version number amidst these changes is perplexing. Maintaining the version as 1.0, despite fundamental alterations, not only confuses but also undermines the integrity of the project's evolution. Crucially, the prioritization of this fork over the foundational task of defining WebID in a serialization-neutral manner contradicts the collective wisdom of the group. This leapfrogs the essential step of establishing a common understanding of WebID, crucial for ensuring compatibility and coherence across the board. Additionally, the timing of these changes is particularly troubling. Forcing this transition in the narrow timeframe before the inception of the Solid WG deprives a significant stakeholder of their rightful input, potentially alienating a key segment of our community. While change is inevitable and often necessary, the manner and sequence in which it is executed bear profound implications. The convergence of these concerns – the haste of implementation, disregard for versioning semantics, inversion of priority over serialization neutrality, and the ill-timed scheduling – collectively signify a departure from the principles of inclusivity, foresight, and respect for the community's legacy and future. It is with a sense of responsibility towards the project's long-term health and community cohesion that I voice these objections. In the spirit of constructive dialogue and shared commitment to the project's success, I urge a reconsideration of the approach to ensure that it aligns with our collective aspirations and principles. |
/chair hat on @melvincarvalho I don't like to ignore people but I can't keep addressing the same points ad infinitum. I will do so once again, here, and then stop answering to any further mention of these specific issues from you.
So far, the only actual changes I've merged in since I became chair are:
Other than this, the only thing I've done is trying to foster and locate consensus (see #37). I can't see how any of this classifies as haste (or implementation!). If you believe that 4 weeks are not enough for major PRs to be adequately discussed, why don't you adopt a more proactive stance and propose a change to our process?
I've already made my point in #58 (comment) . The 2014 ED states very clearly its own nature as an ED. You disagree, and I respect that, but I'm not going to change my mind just because you keep making these accusations.
At some point you will have to accept that not everyone believes in serialization neutrality. I can't do much more than quote a couple of recent posts to make you understand that, as chair, I can't just go with what you (or I, for that matter) want.
Solid people are welcome to join in the conversation here. Nobody is blocking them from doing so. In fact, I've been actively trying to reach out to them but, if I had to guess, they do not believe participation in this group to be a productive endeavor - and that is on all of us. I would like to prove them wrong and have them join the conversation once again but I can't do that on my own. If you find any of my answers to be unacceptable, I beg you to please make the case for my resignation rather than continuing this manner of interaction. I understand disagreement and I would not think any less of you if you were to do so. I've said this many times: I'm happy to step down if the group would rather have someone else. |
I am asking you to prioritize things in the right order.
Its simply an ordering problem. Build the house then build the bathroom. Dont build the bathroom then build the house. The failure here is to understand that serializations can be selected after WebID is defined. Just as SPARQL can be defined then used with any number of serializations. But SPARQL cant be used with any serializations, before it is specified. I need you to acknowledge the logic of the two step approach being consistent with everyone's needs. Arguing that Turtle=MUST PRECLUDES defining defining WebID just is not a serious argument. Defining and specifying WebID ENABLES the serialization conversation. We just have to avoid putting the cart before the horse. Specify WebID and everything else follows. |
@woutermont I'll note you've not yet provided a URL for the implementation that you outlined. Does it still exist? |
Let me add the mail list comments from Ruben Taelman: https://lists.w3.org/Archives/Public/public-webid/2024Feb/0047.html
emphasis mine. |
This issue can now be closed, having proved sufficiently, that mandating conneg (e.g. via JSON-LD AND Turtle = MUST), is a breaking-change. |
You're severely mistaken. All, if not, vast majority (perhaps except you) of the active/substantial contributors here are literally involved in Solid and in general have been driving the RWW space forward. I for one helped to get the work continue in this repository so that the stalled work in the WebID CG can continue. You can read a brief background at #5 (comment) . I've also put in effort to work to continue even further in a W3C Recommendation track through the Solid WG charter proposal ( see proposal: solid/solid-wg-charter#39 (comment) solid/solid-wg-charter#39 (comment) ) and efforts to unify communities. I've created/connected various issues/PRs, did all the open "grunt" editorial work (when no one even approached it for years.) And I can refer to numerous other contributions from "Solid people" if that doesn't suffice. Your assertions are not only significantly mistaken, but I find it impolite. It is not you that needs to welcome "Solid people". "Solid people" have been active participants in this community long before your arrival, and if anyhting, it is they who welcomed you. Start by speaking for yourself ( see WebID CG communication guidelines borrowed from Solid CG's contribution guidelines) instead of chalking up a whole set of participants as to what they think or don't about the current state of affairs. Consider reading your statements again after perhaps considering the possibility that you may be in fact ignoring or downplaying recommendations that are spelled out from the start; clearly demonstrating "NIH"; anything and everything from chairing to editing.. |
Wishing to address this. We have new information, the Solid WG is delayed and changing to the PUMPKIN WG. That means that the original consideration of waiting for clarity on that. We now have that clarity. We need not be too heavily held up by PUMPKIN WG as it is unclear that they are near forming a WG, let alone taking WebID to REC.
For the record, yes I think I could live with that, at this point. Removing blockers to new work. |
@csarven please be respectful, and operate in good faith. The tone here is not the best. @jacoscaz has worked very hard to be inclusive.
This is off-topic, and inappropriate.
Again tone could be better. Obviously there's quite an overlap with RWW, WebID and Solid (now PUMPKIN). IMHO your ambition to be chair of the Solid WG was one more issue that it needed to handle. You could achieve everything you wanted as an IE rather than a chair. There wasnt a need to push for objections on the Solid WG based on chairs, when there were two perfectly good ones. Let's put the animosity to one side and work together to make a better web. |
There are two Webid Specs, WebID 1.0 and WebID 2.0.
WebID 1.0 mandates a serialization, say Turtle.
WebID 2.0 mandates conneg, with Turlte and JSON-LD
Alice has a WebID
alice.ttl
which has been her webid for 10 years. She uses it with all her solid Apps.One day Apps switch to WebID 2.0 and the newer JSON-LD becomes the preferred serialization
Alice's WebID is now broken. Furthermore it's hosted on her own home page using Apache, and she has no ability to fix her webid. This breaking change, makes all of Alice's work over the last 10 years potentially broken.
QED
The text was updated successfully, but these errors were encountered: