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.

[michielbdejong]

Regarding Sarven's objections to the use of RDF in a script tag instead of as RDFa, as long as you're aware of the value of linking from the test suite to spec paragraphs in a machine readable way, and PAC is OK with it then I am too.

[elf-pavlik]

Based on input from participants in today's CG meeting. I'm going to update URLs to stick to the timestamp based pattern. I believe after that this PR can be merged.

[csarven]

The Guidelines ( https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#publication-rules ) leaves a lot of flexibility to authors/editors:

Follow the Linked Data design principles. Give all significant units of information, e.g., concepts, requirements, an identifier, and provide a description using a concrete RDF syntax (see also Spec Terms).

if some folks want to use script blocks and duplicate the content, that's okay. Others use RDFa to mark single source of truth to make it human- and machine-processable.

All of these approaches are also okay by the Solid QA https://solidproject.org/ED/qa .

---

That said, the only concern with respect to the script block is the content that misuses the Spec Terms. So, I suggest updating that information to play along with Spec Terms. But if the SAI authors still want to force it in here and argue about it as "published" implementation experience, I suppose we can deal with those objections separately (in case the review / change requests on the vocab PR wasn't clear enough).

[elf-pavlik]

This one should be ready to go!

[csarven]

@elf-pavlik, thanks for applying the change request to follow the Solid Contributing Guidelines for the URL pattern.

I just want to make sure you acknowledge the points in this PR review, as well as in PR reviews for solid/vocab and other related discussions on Spec Terms and Solid QA.

Specifically in this PR:

• using non-existing or squatting terms
• not using existing methods to discover classes of products

Do you want to proceed with including RDF content expressed as such despite these concerns, or would you like to update it?

I hope you'll reconsider so we can align with existing work and ensure a net benefit for everyone.

[elf-pavlik]

I just want to make sure you acknowledge the points in this PR review, as well as in PR reviews for solid/vocab and other related discussions on Spec Terms and Solid QA.

I created solid/vocab#97 and linked to it in a comment abover. I'm happy to create more tracking issues to provide my implementer feedback and help with improving further the spec vocab.

Noting: https://github.com/solid/vocab/blob/main/spec.ttl#L14-L30

spec:
  a owl:Ontology ;
  # [...]
  vann:usageNote "Work in Progress!"@en ;
  vs:term_status "testing"@en ;
  dcterms:creator <https://csarven.ca/#i> .

Do you want to proceed with including RDF content expressed as such despite these concerns, or would you like to update it?

I would like to merge this PR and keep iterating as we advance related issues.

[michielbdejong]

@csarven we discussed this in the CG call and unanimously agreed that we wan to allow Pavlik to publish this, with the only caveat that he would use the dates-based format for versioning the doc URL. I would like to approve and merge this, so that SAI v0.1 can be published as something that is coming out of the CG, but merging is blocked because your review status is still on 'requested changes' and I don't want to bypass the mechanics of our PR review process. I understand your concerns about choice of predicate may be preventing you from making it an 'approve', but can you maybe change the status of your review to 'comment' so this work can move forward?

[csarven]

For the record:

@elf-pavlik (co-chair) ignored the Solid Contribution Guidelines and pushed their approach to the CG meeting despite prior warnings. The group reaffirmed that the Guidelines should be followed.

@michieldejong (co-chair), the PR has been open less than 10 business days, which is the minimum expectation per W3C practice and generally the CG Guidelines ( https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#decisions ). All CG participants have the right to review and raise concerns.

@elf-pavlik is also insisting on Spec Terms changes that ignore existing discovery methods and prior SKOS-based specs, despite repeated explanations. This includes attempting to hijack a term, e.g., spec:requirementSubject was always referring to a concept.

I have created a PR to clarify and minimise potential misuse: solid/vocab#98 . If a Spec Terms change is needed, that would be it.

I have removed my change requests from this PR because my concern is not about SAI itself. I support its publication, without implying endorsement. The review focused on ensuring that all CG participants follow processes, guidelines, and prior work so we achieve a net benefit. If the author chooses to continue ignoring prior work and the intended use of Spec Terms, I will not block them.

#743 (comment)

I have removed my change requests from this PR because my concern is not about SAI itself. I support its publication, without implying endorsement. The review focused on ensuring that all CG participants follow processes, guidelines, and prior work so we achieve a net benefit. If the author chooses to continue ignoring prior work and the intended use of Spec Terms, I will not block them.

[elf-pavlik]

the PR has been open less than 10 business days

I opened this PR on Sep 16th and @csarven requested changes on Sep 17th.
Today is Sep 29th So this PR stayed opened practically two full weeks. I also brought it up twice during CG meetings:

• https://github.com/solid/specification/blob/main/meetings/2025-09-17.md#publish-sai-v01
• https://github.com/solid/specification/blob/main/meetings/2025-09-24.md#publish-sai-v01

@elf-pavlik (co-chair) ignored the Solid Contribution Guidelines and pushed their approach to the CG meeting despite prior warnings. The group reaffirmed that the Guidelines should be followed.

I wouldn't call proposing a change ignoring something, I also brought it up during the meeting

• add semver version of publishing w3c-cg/solid#24
• https://github.com/solid/specification/blob/main/meetings/2025-09-24.md#add-semver-version-of-publishing

@elf-pavlik is also insisting on Spec Terms changes that ignore existing discovery methods and prior SKOS-based specs, despite repeated explanations. This includes attempting to hijack a term, e.g., spec:requirementSubject was always referring to a concept.

I find all those clickbaity terms like ignoring hijacking counterproductive for the attempt to resolve those issues.
One day after creating this PR, and right after @csarven requested chanegs I submited this issue:

• add type for Class of Product vocab#97
• https://github.com/solid/specification/blob/main/meetings/2025-09-24.md#add-type-for-class-of-product

Currently CG doesn't seem to have enough active onotologists to properly process such issues. Via ODI channels I proposed that we will try to invite few ontologists from the academic community. So far had short exchange with @jeswr about it.

I have removed my change requests from this PR because my concern is not about SAI itself.

Thank you @csarven, please don't feel discouraged from continuing to put effort in resolving all the concerns you raised, I'm not going to ignore them. While personally I sometimes find the way you engage in conversation inflamatory, I still appreciate your passion about the common work and welcome your rich expertise 🙇

BTW when I did original demo of Solid Efforts over a year ago your main critique was about me starting prototyping using a local dataset. Currently im putting my work into pretty much adding functionality which your requested back then. This PR is also part of that work. While I can see why you have reasons to criticise aspects of this PR. I hope it will not distract you from noticing that at the same time it addresses some of your older critiques and overall it contributes to progress even by your own definition of it.