solid
add type for Class of Product
Based on PR https://github.com/solid/specification/pull/743 And implementation experience across
- https://github.com/elf-pavlik/solid-efforts-core
- https://github.com/elf-pavlik/solid-efforts
This PR adds simple spec:ClassOfProduct class and spec:definesConformanceFor that relates it to spec:Specification.
Besides naming it doesn't collide with complementary SKOS approach. On the other hand it simplifies handing data with SHACL and tools like LDO which have convienient features to work with types/classes.
It folows the same common approach as spec:Requirement which is more heavily used by specification-tests and conformance-test-harnes. It seems that classes of product were not really used there, I'm not aware about any other consumers than Solid Efforts which I'm working on. Possibly dokie.li have some basic functionality as well.
Example of specification-tests not really using classes of products from the specificaions
- https://github.com/solid-contrib/specification-tests/pull/121
TODO
- [ ] consider different name for the class, maybe simply
spec:Productorspec:ConformanceClass. this would prevent confusing it with the SKOS concept scheme.
This issue is about classes of products as in https://www.w3.org/TR/spec-variability/#spec-cat-cop
@csarven I believe only 2 or 3 of the CG drafts you edit use this SKOS based approach, would you mind providing the full list? Also do you know about any existing conumers that use it, I guess dokie.li and solid-efforts are two examples, one of them is my code and the other one yours. Anyone else that you know of?
I would also like to support semver for each class of producs independently from the version of the draft, there are situations where they could benefit from independent versions. In that case would you still semver bare SKOS concepts?
@elf-pavlik, just to be clear: spec:requirementSubject is designed and used to include SKOS Concepts. If this does not meet your needs, I suggest creating a separate vocabulary rather than mangling Spec Terms already in use and worked through Solid QA / Solid CG Test Suite Panel.
After processing #98 independently from this one, I will just update this PR to use either one of those
-
spec:requirementRange rdfs:range [ owl:unionOf ( skos:Concept spec:ClassOfProduct ) ] . -
spec:requirementRange rdfs:range skos:Concept, spec:ClassOfProduct .
Preferably with feedback from working ontologists.
Again, Spec Terms already has a discovery for classes of products. And Spec Terms left rdfs:range unspecified (and again as I mentioned, it is not necessary). If it "needs" a range, it needs to be skos:Concept, which is why https://github.com/solid/vocab/pull/98 exists.
This PR should be closed without changes.
Maybe, just maybe, it would make sense for @elf-pavlik to extract all the RDF supplied by the RDFa-HTML composed by @csarven, and embed that in <script> islands of JSON-LD and/or Turtle (I recommend both)? No need to use (nor coin!) different vocabulary, and all the benefits RDFa delivers to RDFa-speaking tools are magically delivered to JSON-LD and/or Turtle speaking tools.
Future maintenance may well be only applied to one or (hopefully) both of the <script> islands (i.e., not to the RDFa encoding) because it's easy to edit or add to such islands, but editing or adding to the RDFa-HTML requires understanding how to read and write whichever version(s) of HTML are in use as well as whatever verion(s) of RDFa are in use. I hope that the (small) number of user-friendly HTML and RDFa-HTML composition tools makes plain that this is a non-trivial deliverable!
Thanks @TallTed I'm not sure how this issue relates to the choice of one of the standard ways of embedding RDF in HTML. I was assuming that this issue is serialization independent.
I guess I didn't understand the discussion to date. Sorry for the noise suggestion.
[adding a class to a SKOS Concept] simplifies handing data with SHACL and tools like LDO which have convienient features to work with types/classes.
I'd have to disagree on the mention of SHACL. As far as I can see, anything that can be specified in SHACL for an rdf:Class can also be specified for a skos:Concept so SHACL is not a reason to add classes. As far as I know there are cases in which defining things as both a skos:Concept and an rdf:Class is useful (see, for example, https://w3c.github.io/dpv/primer/#classes-hierarchies-and-instances) but I have not heard any discussion that those kinds of usages are relevant to the current discussion.
@TallTed , I believe the issue boils down to two facts:
- Spec Terms already covers discovery of classes of products that are defined in specifications.
- This PR attempts to change the existing definition for
spec:requirementSubjectthat directly contradicts prior agreement and established use of the term.
If a change to Spec Terms is needed, https://github.com/solid/vocab/pull/97 clarifies the intended and expected range (skos:Concept).
Again, current publications (including Solid Notifications Protocol, which elf Pavlik is a co-author of and have approved for publication) define skos:Concepts for their classes of products, and the values of spec:requirementSubjects are those concepts.
All of the following define classes of products and/or use requirement subjects with the understanding that it refers to a SKOS concept.
- https://solidproject.org/TR/protocol
- https://solidproject.org/TR/notifications-protocol
- https://solidproject.org/TR/wac
- https://solid.github.io/webid-profile/
- https://solidproject.org/ED/qa
Ditto the social understanding and use as early as in other places like specification-tests (2021), e.g., https://github.com/solid-contrib/specification-tests/commit/3c466a587166fc5e535c80b57eb81f4bbc2ea36a
The expectation for spec:requirementSubject has always been to refer to a concept.
Requirements in specifications also refer to "requirement levels" which are also concepts and are defined in Spec Terms, e.g., spec:MUST - the definitions are naturally based off BCP 14: https://github.com/solid/vocab/blob/main/spec.ttl#L134-L208 e.g.:
# Requirement Level
spec:RequirementLevel
a skos:ConceptScheme ;
skos:prefLabel "Requirement Level"@en ;
skos:hasTopConcept spec:MUST, spec:MUSTNOT, spec:REQUIRED, spec:SHALL, spec:SHALLNOT, spec:SHOULD, spec:SHOULDNOT, spec:RECOMMENDED, spec:NOTRECOMMENDED, spec:MAY, spec:OPTIONAL ;
rdfs:isDefinedBy
<https://www.rfc-editor.org/info/bcp14> ,
<https://datatracker.ietf.org/doc/html/rfc8174> ,
<https://datatracker.ietf.org/doc/html/rfc2119> .
spec:MUST
a skos:Concept ;
skos:topConceptOf spec:RequirementLevel ;
skos:prefLabel "MUST"@en ;
skos:exactMatch spec:REQUIRED, spec:SHALL .
used alongside https://github.com/solid/vocab/blob/main/spec.ttl#L46-L49
spec:requirementLevel
a rdf:Property, owl:ObjectProperty ;
rdfs:label "requirement level"@en ;
rdfs:domain spec:Requirement .
All of these concepts, whether defined in Spec Terms, in specifications, or elsewhere, are controlled and reflect how we've been organising our knowledge across specifications.
As far as I know there are cases in which defining things as both a skos:Concept and an rdf:Class is useful (see, for example, https://w3c.github.io/dpv/primer/#classes-hierarchies-and-instances) but I have not heard any discussion that those kinds of usages are relevant to the current discussion.
Actually I'm trying to make the point that there is no conflict in having
sopr:Server a skos:Concept, spec:ClassOfProduct . or whaterver we would wan to name this class.
There's noting stating skos:Concept owl:disjointWith spec:ClassOfProduct . I would be very surprised if any vocab define any of its classes as disjoint with skos:Concept.
"Actually" that wasn't at all the point you were making. Please stop moving the goal posts and red-herring.
You literally proposed setting spec:requirementSubject's range to only rdfs:Class right here :point_right: https://github.com/solid/vocab/pull/97/files#diff-04b1fe28bfc068ccff57fd68dd725848c0405386a1f2848ab107c7b5a5868f23R64 :point_left: despite being told multiple times that the range has always been expected to be a skos:Concept.
I've also explained that the range does not need to be changed, and if needed to be set, it is just skos:Concept: https://github.com/solid/vocab/pull/98 .
Again, Spec Terms already includes a way to discover classes of products. The specs are functioning correctly with skos:Concept alone.
It is entirely your decision what additional types you want to associate in your own tooling.
:point_right: https://github.com/solid/vocab/pull/97#issuecomment-3347187287 :point_left:
https://w3ctag.github.io/design-principles/#priority-of-constituencies
User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.
It is already demonstrated that, following the above order, the discovery of classes of products can be met with the current Spec Terms.
If a tool has specific requirements, it should address them on its own without introducing additional complexity into Spec Terms, which already provides the necessary knowledge. Please use what is already available.
If someone still wants to force something into Spec Terms for tool-specific needs or theoretical purity, that case is fundamentally arbitrary. In such a scenario, we can instead:
- update some specs (such as SAI) to express Spec Terms in RDFa, which is more suitable for tools that can perform read-write operations on the resource (without doing any proprietary internal management of duplicate content as in the case with
scriptblocks). That also happens to be align well with the Solid (Protocol) approach while eating our own cooking. This would also have the additional benefit of aligning specs (such as SAI) with other specs (for example, https://github.com/solid/vocab/pull/97#issuecomment-3348423458). - Implement additional or alternative discovery methods locally in tools or vocabularies (such as SAI) if needed. Tool-specific types or unions can be handled locally.
Regardless, this PR, or any variation of it, is not needed.
I am late to this discussion and there was a lot to review so I asked Claude to summarize the proposal and discussion so far. I thought it might be worth pasting here to see if this is a fair representation. I hope that using Claude to summarize might de-personalize the comments a bit:
The PR proposes adding:
- spec:ClassOfProduct as an RDF class
- spec:definesConformanceFor property with range spec:ClassOfProduct
- Range constraint on existing spec:requirementSubject
This would allow classes of products (like "Solid Server", "Solid Client") to be explicitly typed as RDF classes alongside their existing SKOS Concept representations.
Arguments Summary
elf-pavlik's Position: Pragmatic Tooling Enhancement
Main argument: Direct RDF class typing simplifies practical implementation with modern tooling (SHACL, LDO, JSON-LD framing).
Supporting points:
- Current approach requires downstream inference/transformation
- Has working implementations in solid-efforts projects using N3 rules
- SKOS Concepts and RDF classes aren't disjoint, so both can coexist
- Reduces cognitive load for spec consumers
csarven's Position: Semantic Clarity & Consistency
Main argument: The existing Spec Terms vocabulary already handles this properly; adding new types creates unnecessary duplication and semantic confusion.
Supporting points:
- SKOS Concepts are the correct model per W3C Variability in Specifications
- Specs define abstract concepts, not concrete logical classes
- Mixing SKOS Concepts with rdf:Class conflates conceptual labels with logical types
- All published Solid specs (Protocol, WAC, Notifications, WebID) use the SKOS approach
- The problem is better solved by improving tooling, not changing the vocabulary
Argument Assessment
elf-pavlik's arguments - Technically Valid but with Concerns Architecturally:
- ✅ The tooling pain points are real and well-documented
- ✅ Implementation experience demonstrates practical utility
- ⚠️ However, "convenience for my toolchain" isn't always sufficient justification for vocabulary changes
- ❌ The argument that SKOS and rdfs:Class can coexist is technically true but semantically problematic—it creates two parallel ways to express the same thing
csarven's arguments - Architecturally Strong:
- ✅ Strong alignment with W3C semantic web best practices
- ✅ Consistency with existing Solid specification ecosystem
- ✅ The conceptual vs. logical distinction is a fundamental semantic web principle
- ✅ "Specs describe concepts, not implementation classes" is architecturally sound
- ⚠️ The downside is potential friction for implementers, though this is acknowledged
The Core Issue: This is a classic tension between semantic purity vs. developer ergonomics. csarven's position is more architecturally sound from a semantic web perspective, while elf-pavlik's addresses real friction in the developer experience.
I found the summary useful and it helped me recognise the good points in both perspectives. Of course, if this is not a fair representation of the discussion then what follows may not be entirely valid.
Regarding the proposal: While I appreciate the tooling convenience arguments, I'm concerned about introducing parallel modelling approaches. Having both SKOS Concepts and rdfs:Class for the same entities creates maintenance burden and potential confusion about which to use when.
In that context, there are maybe a couple of other things to consider:
- Tooling solution: Could the SHACL/LDO friction be addressed by publishing companion transformation rules or a JSON-LD context that applications can use? This keeps the vocabulary clean while supporting the use cases.
- Documentation enhancement: If the issue is discoverability/clarity for implementers, could the documentation be improved showing how to work with the SKOS model in common toolchains?
Thanks for joining the conversation @edwardsph
That LLM summary didn't catch this comment https://github.com/solid/vocab/pull/97#issuecomment-3346992319
I would also like to support semver for each class of producs independently from the version of the draft, there are situations where they could benefit from independent versions. In that case would you still semver bare SKOS concepts?
In case where we do want to use independent semver on each class of products, I can dive deeper into reason for that in followup comments. Would you still just add semantic version of plain SKOS concept or it would become more fit to give it a proper RDFS class?
I would also like to support semver for each class of producs independently from the version of the draft, there are situations where they could benefit from independent versions. In that case would you still semver bare SKOS concepts?
In case where we do want to use independent semver on each class of products, I can dive deeper into reason for that in followup comments. Would you still just add semantic version of plain SKOS concept or it would become more fit to give it a proper RDFS class?
Each specification version already has its own URI e.g., for Solid Protocol:
- https://solidproject.org/TR/2024/protocol-20240512
- https://solidproject.org/TR/2022/protocol-20221231
- https://solidproject.org/TR/2021/protocol-20211217
The last two versions (URLs ending 20240512, 20221231) defines the classes of products, e.g., https://solidproject.org/TR/2024/protocol-20240512#Server , https://solidproject.org/TR/2022/protocol-20221231#Server
What constitutes a "version" is not particularly relevant. The key point is that the SKOS concepts for those classes of products are uniquely identifiable because their base URLs differ.
Since the classes of products are defined as RDF/SKOS concepts, they can also include additional information such as skos:notation, various *Labels, semantic relationships (like *Matchs, to other classes of products) - as we currently do on a bunch of specs! - and version information such as schema:version (as we currently do on the document level) in the specification.
Equating versioning needs with the choice between skos:Concept and rdfs:Class conflates two separate concerns: semantic modeling and version management, which are entirely unrelated to what this PR attempts to achieve.
And again, SKOS already provides rich semantics to relate classes of products, and we are taking advantage of that in the published specs in conjunction with Spec Terms.
@elf-pavlik , it'd be appreciated if we could close this PR at this point. I'm trying to avoid any back-and-forth on reopening, so I hope you can come to terms with this and agree to close. We've already discussed the matter in depth, including aspects that aren't directly relevant to the core issue.
Each specification version already has its own URI
I'm not talking about versioning specification documents but each class of products indepednently. Usually implementation doesn't implement the whole spec - all the classes of products defined in it. In case of https://solidproject.org/TR/notifications-protocol#interoperability
Each interoperable pair may need to bump their semver in sync but version of the remaining classes of product doesn't need to change and doesn't require attention from those who implement them. Even better example would be https://www.w3.org/TR/fedcm-1/ where adjustment to interop betweeen User Agent and Identity Provider doesn't need to affect Relying Party at all.
@elf-pavlik , it'd be appreciated if we could close this PR at this point.
I don't see any rush. I also don't see neither this or #98 getting required 3 approvals so we can continue discussion. We should also check both PRs against https://www.w3.org/2016/08/namespaces/#modification
Possibly terms need to be superseded with newer terms rather than changed.
I'm not talking about versioning specification documents but each class of products indepednently.
As mentioned, versioning does not require changing the RDF/SKOS modeling. The current approach already supports concept-level versioning. It is in RDF, after all.
I don't see any rush.
This PR has been open for a month and discussed in depth; we have exhausted the relevant discussion on this matter. Multiple published specs already use the current SKOS approach, and you have not acknowledged the existing discovery mechanisms or the inappropriateness of redefining a property in conflict with existing work.
Concerns about "3 approvals" misses the point. There is already a strong objection to this PR, with issues highlighted by others as well, and attempting to push it through procedural steps as if they override the technical concerns is not constructive.
Please act in good faith, as continued disregard constitutes disruption under W3C Conduct. I would rather close this PR as a brief technical oversight regarding the work we've done in Solid QA, and follow up by improving documentation as @edwardsph recommended. I can only still encourage you to align your work with existing work.
Multiple published specs already use the current SKOS approach
I would like to clarify that it's a handful of drafts and all of them authored by you, I have impression that you try to exaggerate the adoption.
I'm interested to here more points of view, until then I'm not planning to get into another dialog with you @csarven
- https://solidproject.org/TR/protocol - Editors: Sarven Capadisli, Tim Berners-Lee, Kjetil Kjernsmo
- https://solidproject.org/TR/notifications-protocol - Editors: Sarven Capadisli. Authors: Aaron Coburn, Sarven Capadisli, elf Pavlik, Rahul Gupta
- https://solidproject.org/TR/wac - Editors: Sarven Capadisli. Authors: Tim Berners-Lee, Henry Story, Sarven Capadisli
- https://solid.github.io/webid-profile/ Editors: Virginia Balseiro, Jeff Zucker, Sarven Capadisli. Authors: Tim Berners-Lee, Sarven Capadisli, Virginia Balseiro, Timea Turdean, Jeff Zucker
- https://solidproject.org/ED/qa - Editors: Sarven Capadisli. Authors: Sarven Capadisli, Pete Edwards, Michiel de Jong
As already noted in https://github.com/solid/vocab/pull/97#issuecomment-3348423458 , you're one of the authors of notificaitons-protocol.
All of these works went through multiple rounds of Solid CG reviews.
You have no argument here.
I have given the benefit of the doubt and entertained everything you've said, but you have been unable to play along with the established work and agreed practices. Dismissing existing contributions, including input from Jeff and Pete, is inappropriate.
You do not even have a specification using spec:requirementSubject (as intended!), nor have you shown relevant implementation experience for it (because we know it is going to lead to duplicating content!). Yet you continue to insist on adoption of your approach without aligning with the work already established in the CG. That is not constructive.
Yes, many editors and authors, still the one and only annotating the RDFa. I'm not going to dig into PRs to see if any other author/editor even asked a single question about spec related annotations.
The only reason I'm responding is that @edwardsph joined the conversation and I will take this opportunity to ask if he plans to continue his amazing work on conformance-test-harness
You do not even have a specification using
spec:requirementSubject(as intended!), nor have you shown relevant implementation experience for it (because we know it is going to lead to duplicating content!).
I'm taking demand driven approach and don't produce something that is not going to be consumed. For now I consume classes of products information in my prototype https://elf-pavlik.github.io/solid-efforts/#/?tab=products
I made multiple attempts of using conformance-test-harness but kept stumbling into issues:
- https://github.com/solid-contrib/conformance-test-harness/issues/673
- https://github.com/solid-contrib/conformance-test-harness/pull/661 (PR)
- https://github.com/solid-contrib/specification-tests/issues/120
- https://github.com/solid-contrib/specification-tests/issues/119
And 3 years old one that would support my style of publishing RDF in HTML using standard <script> tags
- https://github.com/solid-contrib/specification-tests/issues/76
I don't have capacity to dive deep into working on the conformance-test-harness. I did help ODI with writing a NLnet grant proposal to continue work on conformance-test-harness, if it passes ODI would look for a developer to work on it.
Focusing on who authored or annotated RDFa does not address the substance of this PR. What matters is how Spec Terms has actually been used. Treating authorship as a measure of validity distracts from the real issues in this PR.
All referenced specs, Spec Terms, and Solid QA have been reviewed. Please stop dismissing prior work.
Everything about the conformance-test-harness in your last comment is off topic. Surely Pete is already familiar! Your mention of funding is unrelated to this discussion too.
I hope we can all agree that, because of its primary focus on HTML documents, RDFa is more challenging to author or edit than Turtle, JSON-LD, or other purely RDF media types. I believe this assertion is gently supported by the fact that few editors have applied themselves to editing the referenced RDFa documents.
Further, RDFa is primarily useful when one has existing HTML to which one wants to add RDF annotations. When working with RDF on its own, Turtle, JSON-LD, and other RDF serializations are generally easier to author or edit, whether or not these serializations are intended to later be embedded in <script> elements of HTML documents.
The existing RDFa is certainly valuable and should not be discarded wholesale. However, future work might well be better approached by first extracting the RDF from the RDFa and persisting that RDF as Turtle or JSON-LD, whether in distinct documents or as <script> data islanes. One major reason is that future editors/maintainers of this RDF are much more likely to be fluent in Turtle and/or JSON-LD than in RDFa, which demands familiarity with if not fluency in the HTML that contains the RDFa.
@csarven wrote:
The proposal here is already covered in Spec Terms
Why is Spec Terms not a link? Where can we see this existing coverage?
@TallTed , as mentioned earlier, this PR has nothing to do with what concrete RDF syntax(es) to use to express stuff of interest in specifications. That topic is a distraction.
...but if of interest...
The majority, if not all, of technical specifications produced by Standards Developing Organisations are primarily published in formats like HTML intended for human-consumption (wide dissemination and accessibility). When the primary source (the human‑visible content) is marked up with RDFa, it becomes more machine‑readable without duplicating the content. Single source of referenceable truth. How far one should go, for example, duplicating content and keeping hidden data up to date, or which user‑facing tools are accessible to a wide range of authors with different skills and abilities, can be left to individual projects. People who want to do it can. We have even taken steps in Solid QA (FWIW) to avoid tying the machine‑readable part to a specific RDF syntax, so authors have flexibility.
provides classes and properties that can be used to describe any significant unit of information in technical reports
It was developed partly by the Solid QA initiative.
spec:classesOfProducts is the existing property that allows one to discover a specification's "classes of products" (terminology based on Variability in Specifications' classes of products, where defined in QA Framework: Specification Guidelines:
The generic name for the group of products or services that would implement, for the same purpose, the specification, (i.e., target of the specification). A specification may identify several classes of products.
As I've mentioned earlier, all of the following documents, edited/authored by multiple Solid CG participants, and with consensus to publish, define classes of products and/or use requirement subjects with the understanding that it refers to a SKOS concept:
- https://solidproject.org/TR/protocol
- https://solidproject.org/TR/notifications-protocol
- https://solidproject.org/TR/wac
- https://solid.github.io/webid-profile/
- https://solidproject.org/ED/qa
And those documents also further describe/link the concepts to other concepts (with the help of SKOS semantics), e.g., as the following is defined in Spec Terms and available for making SKOS *Match relationships, where the concepts refer to those in W3C Variability of Specifications:
#Classes of products
spec:ClassesOfProducts
a skos:ConceptScheme ;
skos:prefLabel "Classes of Products"@en ;
skos:hasTopConcept spec:Content, spec:ProducerOfContent, spec:Player, spec:Consumer, spec:RespondingAgent, spec:Processor, spec:Module, spec:ProducerOfInstructions, spec:Profile, spec:SpecificationGuidelines ;
rdfs:isDefinedBy <https://www.w3.org/TR/spec-variability/#cop> .
This work was sufficiently thought through to help us organise our knowledge about specifications and help make that information available to consumers (including QA).
See also SPARQL queries earlier in the thread (minding potential downtime on services) demonstrating a way to gather classes of products directly off specs. Ditto an application (dokieli) being able to detect and highlight the concepts, user checking the concepts and concept schemes in the current document and referenced documents (need to find link to screencast), as well as being able to show a table of a spec's requirements and conformance where the requirement subject's are based on the concepts defined in conformance (and additional authoring-level features using this stuff is planned) - these are not merely proof of concepts but actual things to help authoring specifications in a way that is accessible to greater number of people with different abilities.
So, yes, we have already covered discovery of classes of products as part of a specification's conformance model in Spec Terms.
Hope that answers your question.
Thanks @uvdsl
On the other hand it simplifies handing data with SHACL and tools like LDO which have convienient features to work with types/classes.
For example sh:class and sh:targetClass provide convienient ways of defining shapes around types/classes.
Another case is semver, IMO standards ecosystem still doesn't address needs of drafting specs side by side implementing them, instead of waiting for CR and hoping that crafted theory will just work :crossed_fingers: Semver and https://antfu.me/posts/epoch-semver can be very useful, and to signal changes properly it may be required to version each classes of products independently. Especially if there are more then just one pair with their interop - e,g,. FedCM with RP, User Agent and IdP. I'm not sure if specifying version numbers on instances of SKOS concepts would be the best practice.
In general it would be good to ask ontologists, when something starts getting referenced by predicates other than a label and SKOS alignments. Is it recommended to also define and rdfs:Class for it and stop treating it as pure skos:Concept.
Currently I'm using ex:conformsTo to relate implementations to classes of products they implement. For example: https://elf-pavlik.github.io/solid-efforts/#/implementation?id=https://solidproject.solidcommunity.net/catalog/data%23Solid_client_authn_browser
If we treat Solid-OIDC Client (class of products) as a class/type. Would this be a reasonable alternative?
<https://github.com/uvdsl/solid-oidc-client-browser> a <https://solidproject.org/TR/oidc#Client> .
?
EDIT: If the concern is about spec editors including or not including certain statements in their description. I think this should be handled by a shape, which could for example require to also include SKOS bits.
@elf-pavlik, unfortunately I still do not quite understand the specific use case, and why the current vocabulary is unfit to satisfy it. From your mention on SHACL I assume that one use case is about shape conformance and from your mention of LDO I assume that one is about particular tooling support. In any case, I am still unsure here.
Nonetheless, taking into account the provided examples, I assume that the issue you want to address is how to express that an instance conforms to a class of product.
That said, I am under the impression that you try to express conformance to a class of product using rdf:type relations.
This is semantically invalid; rdf:type does not express conformance to a class definition.
Asserting _:x rdf:type _:C does not imply that _:x adheres to any definition of _:C or inherits any properties from such definitions. It does also not imply that _:x SHOULD adhere to any definition of _:C.
_:x rdf:type _:C is merely an assertion that _:x is an instance of class _:C.
On the other hand, _:x dcterms:conformsTo _:C does express that _:x conforms to (the definitions that comprise) _:C.
From an ontological perspective, as you requested, using rdf:type is too generic and does thus not express what you seem to desire, whereas using dcterms:conformsTo is. dcterms:conformsTo is in my opinion also a good match to express that an RDF graph satisfies a SHACL shape -- as a shape is also one way (tool?) to define a conformance requirement. Using dcterms:conformsTo also allows for expressing partial conformance if desired. (e.g. 80% conformance or coverage, which you already do in you Solid Efforts).
Given my current understanding of the issue and PR, I politely object to this proposal. This PR does not clearly describe use case, current state insufficiency (necessity for the PR), and how the PR is sufficient to address it. It seems that this PR aims to enable usage of rdf:type to be equivalent to dcterms:conformsTo, which is invalid. I recommend usage of dcterms:conformsTo instead.
