First phrase, 'a' protocol

[michielbdejong]

This resolves my informal objection (https://lists.w3.org/Archives/Public/public-new-work/2023Oct/0003.html) in which I argued the name of the WG should be a question and not an answer.

Let's keep the short name "Solid WG" as it is, but read it as a question instead of reading it as an answer. The first phrase of the charter then explains the title. In this case, by saying "a protocol" instead of "the protocol", it explains that "Solid WG" means "the WG about Social-Linked-Data as a question that need answering" and not "the WG about the specific pre-selected answer that we developed so far".

As crafted in our meeting this morning @pchampin

[michielbdejong]

Decided to leave this as a "comment" because I didn't feel it was quite either "approve" or "request changes".

Thanks @csarven - let's merge this PR as a small step that already has two other approvals and then continue the work!

[melvincarvalho]

In this case, by saying "a protocol" instead of "the protocol"

+1 good point. It is IMHO objectively correct, and a serious reviewer would likely see that solid is "a protocol" not "the protocol"

Anecdotally: about 10 years ago I met a web dev and said I was working on Solid. First response was "another web framework, why do we need one more". At the time Solid was much more a universal single way to enhance the web in a modular way. By 2023 there has been "idea drift", is much more an agreed upon set of rules to do things in a certain way. It's great for the charter to reflect hat.

[melvincarvalho]

To emphasize the point we had a discussion on the WebID mail list about how well the protocol adheres to principles of design:

https://www.w3.org/DesignIssues/Principles.html

Here was my subjective rating for WebID:

WebID subset / superset proposal

Simplicity: 9/10
Modular Design: 9/10
Being Part of a Modular Design: 9/10
Tolerance: 9/10
Principle of Least Power: 10/10
Test of Independent Invention: 7/10
Decentralization*: 9/10

Score: 64/70

The current version of solid I would give:

"The" Solid Protocol (current version Sarven et. al)

Simplicity: 0/10
Modular Design: 2/10
Being Part of a Modular Design: 4/10
Tolerance: 3/10
Principle of Least Power: 0/10
Test of Independent Invention: 0/10
Decentralization: 4/10

Score: 13/70

Unhosted / RemoteStorage

Simplicity: 5/10
Modular Design: 5/10
Being Part of a Modular Design: 5/10
Tolerance: 4/10
Principle of Least Power: 4/10
Test of Independent Invention: 3/10
Decentralization: 3/10

Score: 28 / 70

Now these scores are completely subjective. You can insert the values that you prefer. However it illustrates the point that the current version of solid is not "The" way of doing things, just "a" way of doing things. It's not necessary to say this in the charter, but we can guide our own thinking with some earnest self-reflection, and also plot a path to broader adoption and utility, rather than this just being a bureaucratic exercise of rubber stamping 2 implementations and a test-suite.

[csarven]

Now these scores are completely subjective.

Thank goodness! :sweat_smile: You almost had me going.

---

What argument is being refuted here exactly?

The original proposal is literally "to standardize the Solid Protocol". The proposal is not "is to standardize the protocol for all things personal and solid web under the sun for all eternity". It is a logical fallacy to argue against the latter.

---

I'm fine with this PR either way. Michiel (and Tantek) raise fair points in their reviews, and if we are to tackle them properly, we need to approach it in terms of not necessarily as "a" protocol or even a particular approach (e.g., taking on linked data as one of the important or relevant bits), but potentially as a set of specifications needed to accomplish x,y,z. To be clear, I'm not suggesting that this charter should open up so much! But, if the proposal is about "Solid" than whatever is incubated under Solid CG is applicable here. However, if it is not about "Solid", than the solution space is pretty wide open and need to incorporate incubated work from everywhere else. So, no need to beat around the bush. Which is why I don't find the minor change in wording makes a big difference because the fundamental points being raised in the reviews remains technically unresolved - so, expect formal objection or change request along the lines of the original =)

@pchampin , assigning this PR to you.

[melvincarvalho]

Which is why I don't find the minor change in wording makes a big difference because the fundamental points being raised in the reviews remains technically unresolved - so, expect formal objection or change request along the lines of the original

Trying to parse the wider context of this better. Would you mind linking to the Tantek review?

Edit: found the review for those interested. Would be great to include hyperlinks in future, if time allows. Still trying to parse this sentence, to figure out where formal objections might come from ... [after reading Tantek's review, it makes more sense]

[michielbdejong]

I commited @csarven's suggestion. @pchampin I think this is ready to merge now?

[timbl]

I think this is not so helpful, as we do require someone to update and extend specifically the protocol which the CG has developed and updated and extended. If the WG can produce any protocol, with no reference to the CG's spec, then should the CG then actually continue the work itself until it has verified that the WG has a back-compatible version of The Solid Procol? This affects the work of the CG a lot.

[timbl]

I guess this PR is OK so long as there still is still a mention of the soldi protocol TR in the mission on line 95

[melvincarvalho]

Could write:

"loosely based on" or "inspired by" ... or words to that effect

Perhaps, it's up to the CG how tightly aligned it wants to be to the WG? But it would make sense to be completely aligned for a 2 year period. Divergence would be counter productive.

[pchampin]

I guess this PR is OK so long as there still is still a mention of the soldi protocol TR in the mission on line 95

Actually, I think that it might be better to not include it in the mission statement. This fuels the suspicions about rubber-stamping (for good or bad reasons).

In any case, the CG's Solid Protocol spec is mentioned as the input document for the WG's Rec-track deliverable.