Skip to content

add type for Class of Product #97

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.

Sign up for GitHub

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

Open
elf-pavlik wants to merge 2 commits into
base: main
Choose a base branch
from
Open

add type for Class of Product #97

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2194cab
add type for Class of Product
elf-pavlik Sep 17, 2025
1e9c1ce
[spec] add range to requirementSubject
elf-pavlik Sep 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion spec.ttl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,15 @@ spec:Specification
rdfs:label "Specification"@en ;
rdfs:isDefinedBy spec: .

spec:ClassOfProduct
a rdfs:Class ;
rdfs:label "Class of Product"@en .
Comment on lines +37 to +39
Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering spec:ClassesOfProducts exists and has been in use for sometime now, I don't think your suggestion is a great idea.

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see TODO section included in this PR when it was created.

Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that your best idea for a name is nearly the same as what has been already in place for some years now is a pretty good giveaway: duplicating existing solutions but introducing more complexity and less consistency.

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid I fail to parse the constructive part out of your last comment 🤔


spec:definesConformanceFor
a rdf:Property, owl:ObjectProperty ;
rdfs:label "defines conformance for"@en ;
rdfs:range spec:ClassOfProduct .
Comment on lines +41 to +44
Copy link
Member

@csarven csarven Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing spec:classesOfProducts is already paired with spec:ClassesOfProducts and used to indicate a spec's product classes. Also used in Solid QA: https://solidproject.org/ED/qa

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how propsed direct relation conflicts with the other possible path?
Are we in RDBS normalization space?

Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, you are unnecessarily complicating the Spec Terms instead of simply using what's already available for marking and discovery of classes of products.

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on what are you concluding it as complicating? I can argue it that you complicated it initially and this addition of a direct relation actually simplifies it.

Copy link
Member

@csarven csarven Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, you're complicating things because there is already a path to discover classes of products. You are ignoring what's already in place instead of simply reusing it.

classesOfProducts already... drum roll... helps to indicate the classes of products of a specification. I borrowed that whole concept from https://www.w3.org/TR/spec-variability/#spec-cop and introduced it into Spec Terms. Even signaled the need to give attention to Variability in Specifications right here: solid/specification#138 so that CG, authors as well as implementers improve their work.

You are only now attempting to publish like a handful of statements. Please consider the possibility that others that have been working on the vocab, specs, applications, and all related things for years now, including trying to standardise these things through Solid QA (Test Suite Panel), etc etc.. has some idea about what they're talking about.

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not ignoring those alternative paths, in the matter of fact I'm using them to infer missing statements in the specs you annotated. I'm experimenting with both N3 rules and SPARQL construct queries. https://github.com/elf-pavlik/solid-efforts-core/blob/fa3d93a5f8c4020f24bec7aef203b3fe5f1d5f9c/cli/aggregations/specifications.ts#L45-L105

I see no reason for the downstream consumer (an app) to deal with that complexity and I provide it with data that includes proposed simpler direct relation.

BTW thank you for sharing your SPARQL queries in your mailing list email and later in matrix chat, they were useful in dealing with that original complexity.

Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Been there, done that long ago.

dokieli-spec-conformance.webm

https://dokie.li/media/video/dokieli-spec-conformance.webm (also linked from the homepage)

shows how an client-side authoring application like dokieli helps authors to review / inspect spec requirements, conformance, test suite coverage, among other things.

You can be sarcastic and mock the work I've largely contributed to in the CG all you want with "thank you for sharing... useful dealing with that complexity".

As I've said elsewhere, you've just started to include like, what, 10 statements? in a script block that even duplicates the existing content. Meanwhile some of the specifications that I've helped publish include 1000s of statements (even down to the requirements), as well as how test coverage / cases linking to them. So, I'm not sure if you should be lecturing me about complexity but you do you.

The fact of the matter is that we've been working on expressing significant information in specifications as well as a user-facing applications making use of that information. When you were taking jabs at dokieli, RDFa, or whatever, we've been showing how things can be years ago!

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use JSON-LD frame to extract the 10 statements that I actually need from 1000s you included, after doing mentioned reasoning to add two missing statements: https://github.com/elf-pavlik/solid-efforts-core/blob/fa3d93a5f8c4020f24bec7aef203b3fe5f1d5f9c/cli/aggregations/specifications.ts#L11-L44

Can we agree now that we both speak with hands on implementation experience? Specifically with data using spec vocab, not the 95% of other statements you added the drafts you edit.

Copy link
Member

@csarven csarven Sep 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concrete example: my implementation experience includes incorporating spec:requirementSubject - which I authored - in multiple specifications as part of formal requirements, and also using those requirement statements in applications.

You have not done that work, yet you dismiss it as useless while at the same time offering opinions on what the range of requirementSubject is or should be, along with duplicating existing authoring / discovery of classes of products.

I find the language you continue to use comes across disingenuous, disregards the contributions while positioning yourself as an authority over them.


spec:requirement
a rdf:Property, owl:ObjectProperty ;
rdfs:label "requirement"@en ;
Expand All @@ -51,7 +60,8 @@ spec:requirementLevel
spec:requirementSubject
a rdf:Property, owl:ObjectProperty ;
rdfs:label "requirement subject"@en ;
rdfs:domain spec:Requirement .
rdfs:domain spec:Requirement ;
rdfs:range spec:ClassOfProduct .
Copy link
Member

@csarven csarven Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excuse me, but in case you're unaware, the way spec:requirementSubject is used currently out there is that its range is with the understanding that it is Concept part of spec:ClassesOfProducts. See for example:

Other specifications using spec:requirementSubject include:

https://solidproject.org/TR/wac

So, your proposed change doesn't go well with specifications that are actually indicating their requirements.

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing defines skos:Concept and proposed spec:ClassOfProduct as disjoint. The only consequence of adding this range will be that if someone runs reasoner one may get wac:Server a skos:Concept, spec:ClassOfProduct .. Could you please clarify what exacly "doesn't go well"?

Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defining the range obviously to your thing signals something completely different. If you are so interested in having a range, this would be it:

Suggested change
rdfs:range spec:ClassOfProduct .
rdfs:range skos:Concept .

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify what do you mean by signals? If we want to restrict something we would probably use a data shape (SHACL). Defining range simply entails the following https://www.w3.org/TR/owl2-profiles/#prp-rng based on https://www.w3.org/TR/rdf11-schema/#ch_range

Copy link
Member

@csarven csarven Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're deflecting. If you want a range, skos:Concept is appropriate and what was intended when I proposed requirementSubject. Sometimes it is not necessary to specify domain and/or range, so I chose not to specify it. Are we clear on what requirementSubject is or do you want to tell me I didn't know what I was doing when I initially proposed Spec Terms: #84 or when I marked and published a bunch of specifications using that property, and that we should change everything and our understanding based on your ideas in 2025 with zero track record on publishing machine-readable specifications or even actually using requirementSubject in specifications?

Copy link
Member Author

@elf-pavlik elf-pavlik Sep 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we clear on what requirementSubject is

I believe so, let's double check!

It is a property relating a spec Requirement with a Class of Product which the spec defines conformance for. In practice, implementation of that specific Class of Product, is expected to pass all test suite tests for requirements with that Class of Product as a requirementSubject. Implementations that implement other Classes of Product from the same spec, are not expected to meet requirements for any Classs of Product, that they do NOT implement, with that Class of Product as requirementSubject of a requirement.

W3C even has an excelent video taking about classes of products in Solid and beyond 😉 https://youtu.be/SomSYn0h22Q

Copy link
Member

@csarven csarven Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have already agreed in the Solid CG that what you handed over to W3C was entirely your personal view of the ecosystem. You alone chose what to include and exclude in your videos, so it was not representative of the group. Yet you continue to market it as if it reflected group consensus. 😉


spec:requirementReference
a rdf:Property, owl:ObjectProperty ;
Expand Down