publish SAI v0.1

[elf-pavlik]

The main goal is to create cannonical URSs and include RDF as JSON-LD in <script> tags.
I already have code for https://elf-pavlik.github.io/solid-efforts/#/ that gets those descriptions from either <script> tag or RDFa and aggregates it to be presented by the application.

Since it uses semver, I added snapshot permalinks like /TR/tag/sai-v0.1. I don't see any reason to create confusion by including artificial year and date versioning in the URL.

preview

• sai
• sai-primer-application
• sai-primer-authorization-agent

TODO

• get real WebID from @ericprud 👋
• update index with new links once we approve them

[elf-pavlik]

Main example of embedded RDF description

[csarven]

Congrats on work to publish SAI under TR/ as a CG-DRAFT.

---

I don't see any reason to create confusion by including artificial year and date versioning in the URL.

Could it be because you are either:

• unaware of the publication guidelines as outlined in https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#publishing-a-technical-report , how they came to materialise over the years, or the fact that they are very similar to W3C PubRules: https://www.w3.org/pubrules/ - hint: we (CG) adopted that practice to provide something consistent with what people in the W3C space would be familiar with
• or simply not interested in following the guidelines because your needs are stronger than the CG's established practice.

It takes less energy to stay consistent with what's already in place (e.g., URI naming) than to come up with a completely different pattern to serve your own interest.

There is evidently a distinction between date and document versioning. The following use CG-DRAFT as the status, and Version 0.11.0. Neither piece of information has anything to do with the date pattern in the URI used in the majority of W3C specs:

• https://solidproject.org/TR/protocol
• https://solidproject.org/TR/2024/protocol-20240512

Again, see PubRules, if in doubt. Some specs do use the version in the URI but the general expectation is that a snapshot has some form of a date in there (not to be conflated with the "version" of the document). It is just that we (CG) simply followed an existing practice in W3C.

It is not that you're forbidden from introducing a new pattern but perhaps acknowledge that it is just making a mess with no particular benefit.

---

Regarding the hidden metadata in the script block:

• it is unnecessarily repeating some of the existing content in the human-readable body
• it is squatting terms in spec: which do not exist - and the reasons why they are not in Spec Terms were already explained to you in Solid chats (but you're not listening any way.. 🤷 )

[elf-pavlik]

Thanks for sharing your points of view!

Regarding the hidden metadata in the script block:

it is unnecessarily repeating some of the existing content in the human-readable body

Yes, I'm aware of that and I see this trade off as a better than trade offs of RDFa. I'm happy to discuss it in a dedicated discussion, issue or during one of CG meetings.

it is squatting terms in spec: which do not exist - and the reasons why they are not in Spec Terms were already explained to you in Solid chats (but you're not listening any way.. 🤷 )

I'm aware of that, I plan to make a PR to spec/vocab and use this spec as an example of how proposed terms are being used. If we reach a different consensus I will simply update the snippet and code which consumes it.
As for the reasons I only recall you explaining your reasons, I hope you can tell the difference. Let's have a reasons based discussion, hopefully with few more reasonable participants, in an issue I will create in solid/vocab.

---

It is not that you're forbidden from introducing a new pattern but perhaps acknowledge that it is just making a mess with no particular benefit.

I'm happy to explain how I see benefits and trade-offs, again just because you can't see benefits (at this moment) it doesn't mean that there are none. As a general note, after years of collaboration I would encourage you to take a look at General semantics
and related E-prime. There is an interest to preserve some of the water cooler chat format we used for CG meetings during the summer brake. This could be a fun topic to bring up during one of those.

Again, see PubRules, if in doubt. Some specs do use the version in the URI but the general expectation is that a snapshot has some form of a date in there (not to be conflated with the "version" of the document). It is just that we (CG) simply followed an existing practice in W3C.

I understand that you suggest change to follow this W3C publication rule:

§ The syntax of a “this version” URI must be https://www.w3.org/TR/YYYY/WD-shortname-YYYYMMDD/. If the document introduces a new shortname, it must use lowercase letters.
(I used WD specific list of rules as a reference here)

I'm happy to discuss it, especially following requests from the owners of the namespace, who are represented by two of the people I requested a review from.

@csarven I just want to clarify procedural detail of you using 'requested changes' feature. Are you using it wearing some specific hat that gives you some special authority, or you are using it as a regular CG participant who wants to offer their suggestions backed by references?

---

EDIT I think we should be careful not to behave like monkeys in this folk tale
https://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu

[csarven]

Thanks for sharing your points of view!

As for the reasons I only recall you explaining your reasons

I am pointing out, with references, how your approach differs from established CG practice that came about through group consensus. Please stop framing this feedback as personal opinion. Chairs, like all participants, are expected to follow the same processes and guidelines rather than introducing patterns based on individual preference.

Please state whether you agree, disagree, or need clarification on any of the points above.

Yes, I am aware of that and I see this trade off as a better than trade offs of RDFa.

To be clear, I didn't ask you to switch to RDFa (certainly am no longer suggesting that you should consider in our timeline). Please explain what trade offs you believe justify putting duplicate content in the script block, specifically for the ones you've decided to include (and omitted a whole lot of knowledge).

I don't see your approach scaling: it duplicates duplicate information and requires requires tooling or human labour to maintain multiple sources of truth.

Some of the existing specs using RDFa include hundreds or thousands of statements with a single source of truth that is both human- and machine-readable. I've already shared code, query examples, application use, and how this fits with the Solid QA work: https://solidproject.org/ED/qa and tests/tooling.

You don't seem to be acknowledging prior CG work here. If you want a debate, we can have one.

I'm happy to explain how I see benefits and trade-offs

Good. The onus is on you to explain why you are not following the guidelines and why your approach should diverge from existing deployed work.

@csarven I just want to clarify procedural detail of you using 'requested changes' feature. Are you using it wearing some specific hat that gives you some special authority, or you are using it as a regular CG participant who wants to offer their suggestions backed by references?

Your paragraph reads like an emotional reaction to a routine review. That does not alter the procedural or technical points raised. Do you believe you have authority to ignore CG processes and guidelines?

I acted as a regular CG participant. You opened the PR, I reviewed it, and I cited CG guidelines. Those guidelines apply to all contributors, and as far as I know there is no need for a special authority status to request changes on a pull request.

Regarding the illustration you shared:

That's how things are done around here

That anology does not apply. Our practice is based on W3C precedent (e.g., W3C QA Activity -> Solid QA). The monkey-and-banana story trivializes the real costs and consistency requirements behind decades of W3C work that shaped the Web developer community.

You are working with ~10 statements. Myself and others have been working on expressing 1000s of statements in specifications. That scale difference matters.

https://solidproject.org/ED/protocol#graph-view=true

While I recognise that it is not always easy to maintain a helpful and patient tone, I find your "we should not" phrasing sarcastic. By "we" you seem to mean me, rather than engaging in self-reflection about the many times you have acted in a non-constructive way toward others because you believed your idea was the best one including in discussions with me. Instead of relying on "should" statements, I think it would be more effective to lead by example. Posting a semi-offensive illustration, however, is certainly not a model of constructiveness.

[elf-pavlik]

By "we" you seem to mean me

When I mean you I simply state you, I meant we as the CG and broader Solid community. I hope that clarifies it!

I acted as a regular CG participant.

Thank you, I wanted to clarify it since you have special permissions on this repo and your change request is handled differently by Github.

Do you believe you have authority to ignore CG processes and guidelines?

No, I'm making this PR as CG-DRAFT co-editor, CG chair hat off.

You don't seem to be acknowledging prior CG work here. If you want a debate, we can have one.

I'm open to discussing pros and cons of various standard approaches of embedding RDF in HTML. I don't think this PR is an appropriate venue for it. I would suggest to pause further and let give other reviewers chance to chime in. I will also bring it up during CG call in 20 min.

[csarven]

Mentioning "special permissions" is a red herring and is completely irrelevant to the discussion. A review requesting changes is valid based on the evidence and references provided, not the reviewer's "authority" / title / role they might hold, and not what button they pressed in this particular tool/service, or even the exact wording they used in the comment. Your comment deflects from the substantive points I raised.

[elf-pavlik]

A review requesting changes is valid based on the evidence and references provided

To clarify, your change request is for the URIs to follow the same template as other published drafts?

[elf-pavlik]

Followup PRs

• add semver version of publishing w3c-cg/solid#24
• add type for Class of Product vocab#97

To avoid being blocked by this PR during my planned working session on solid-efforts this weekend. I'm simply going to publish EDs using the github IRIs as temporary ones and later swap IRIs to cannonical ones when this PR gets merged. I already have cli command to replace temporary IRIs with permanent ones so not a huge deal.