add type for Class of Product #97
Conversation
There was a problem hiding this comment.
The proposal here is already covered in Spec Terms, and see how they are used in some Solid specifications.
There is also quite a bit of a background on Solid QA:
I left some inline comments FWIW.
| rdfs:label "requirement subject"@en ; | ||
| rdfs:domain spec:Requirement . | ||
| rdfs:domain spec:Requirement ; | ||
| rdfs:range spec:ClassOfProduct . |
There was a problem hiding this comment.
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:
- https://solidproject.org/TR/protocol
- https://solidproject.org/TR/notifications-protocol
- https://solid.github.io/webid-profile/
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.
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
Defining the range obviously to your thing signals something completely different. If you are so interested in having a range, this would be it:
| rdfs:range spec:ClassOfProduct . | |
| rdfs:range skos:Concept . |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:ClassOfProduct | ||
| a rdfs:Class ; | ||
| rdfs:label "Class of Product"@en . |
There was a problem hiding this comment.
Considering spec:ClassesOfProducts exists and has been in use for sometime now, I don't think your suggestion is a great idea.
There was a problem hiding this comment.
Please see TODO section included in this PR when it was created.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 . |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I don't see how propsed direct relation conflicts with the other possible path?
Are we in RDBS normalization space?
There was a problem hiding this comment.
Again, you are unnecessarily complicating the Spec Terms instead of simply using what's already available for marking and discovery of classes of products.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
csarven
left a comment
csarven
left a comment
There was a problem hiding this comment.
Here is another review. Pardon me as I quote myself since I've already explained why Spec Terms uses SKOS in a number of areas (including for classes of products) as well as the Solid QA context in the Solid CG, and so I'm recycling it for this PR:
Source: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$PzblvzK4ioO61w2v8FBLRDVm5dZXbe_xbKQsNzC5hOI
SKOS is not "ergonomic to work with" how or compared to what? As I see it, SKOS does a lot of the heavy lifting that is well tested and deployed.
In a nutshell, the specification merely defines all sorts of concepts (in the most general sense) and how they are internally or externally related.
In https://lists.w3.org/Archives/Public/public-solid/2024Jun/0007.html there is an example showing how classes of products (concepts) can be pulled out specs. And see also querying for requirements as well as the connections between test cases and requirements: https://lists.w3.org/Archives/Public/public-solid/2024Jun/0002.html . I've posted other examples queries in that thread, e.g., changelog that eventually relates to concepts: https://lists.w3.org/Archives/Public/public-solid/2024Jun/0011.html .
If there is a simpler or better or "ergonomic" (or whatever is the concrete criteria one is after), it'd be interesting to have a closer look but I wonder whether the energy invested towards can justify any major changes. IMO, Spec Terms and SKOS (and a bunch of other well tested / known things without boiling the ocean) work really well together.
I use
doap:implementto refer to the whole specification. Note that there is a difference between what an implementation may claim about itself vs. what a test report claims. For the former, DOAP may be sufficient ordcterms:conformsTo(as mentioned above) .. and for the latter, EARL would be as part of its test result - and it would be far more specific. I think an implementation can also make those claims if it wants but it comes down to whether the consumer should trust either the implementation's statements about what it conforms to or test results or various possibilities in/around it. Just saying that it is not entirely interchangeable. For example, https://linkedresearch.org/ldn/tests/summary is a summary based on each implementation report (i.e., a notification that was submitted to test suite's inbox) - IIRC, majority of the reports listed there are generated by the test suite itself and submitted to its own inbox - authoritative as it gets - but it can be submitted independently as long as the report follows the same shape/form.. (I didn't write a processor to automatically check the reports' validity or something to verify a report's statements... left it as homework for later if there was any major need, and there was none to date.)
I added an example at the end of below for Specification Categories.
Classes of Products
PREFIX spec: <http://www.w3.org/ns/spec#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?document ?productClass ?relatedProductClass ?broaderProductClass
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fprotocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fwac&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fnotifications-protocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FED%2Fqa&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolid.github.io%2Fwebid-profile%2F&raw>
WHERE{
OPTIONAL {
?document spec:classesOfProducts [
skos:hasTopConcept ?productClass
] .
}
OPTIONAL {
?productClass skos:relatedMatch ?relatedProductClass .
}
OPTIONAL {
?productClass skos:broadMatch ?broaderProductClass .
}
}
Requirements
PREFIX spec: <http://www.w3.org/ns/spec#>
SELECT ?requirement ?requirementSubject ?requirementLevel ?statement
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fprotocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fwac&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fnotifications-protocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FED%2Fqa&raw>
WHERE {
?s spec:requirement ?requirement .
?requirement spec:requirementSubject ?requirementSubject .
?requirement spec:requirementLevel ?requirementLevel .
?requirement spec:statement ?statement .
}
ORDER BY ?requirement
Requirements and Test Cases
PREFIX spec: <http://www.w3.org/ns/spec#>
SELECT ?requirement ?testCase
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fprotocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolid-contrib.github.io%2Fspecification-tests%2Fcoverage&raw>
WHERE {
?s spec:requirement ?requirement .
?testCase spec:requirementReference ?requirement .
}
ORDER BY ?requirement
Bonus:
Specification Categories
PREFIX spec: <http://www.w3.org/ns/spec#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?document ?specificationCategoryConcept
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fprotocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fwac&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FTR%2Fnotifications-protocol&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolidproject.org%2FED%2Fqa&raw>
FROM <http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fsolid.github.io%2Fwebid-profile%2F&raw>
WHERE {
OPTIONAL {
?document spec:specificationCategory [
skos:hasTopConcept ?specificationCategoryConcept
] .
}
}
Source: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$Qs1NbeD1nYSoouDLpxo7ySCJD94Lu6c9SqlroV1ezGc
I borrowed "classes of products" from https://www.w3.org/TR/spec-variability/#spec-cat-cop (that document was produced by the W3C QA Activity). The Spec Terms tries to model that document or stay as close to as possible by also filling in the blanks. IMO, the Spec Terms not only helps to express useful units of information in specifications, but also helps to write them (At some point early on, IIRC, Solid Protocol used spec:Server but later on I moved away to Solid Protocol's own Server because it became clear that Spec Terms wasn't the place to define anything specific to any specification. This is why each spec should define its own classes of products and there is also the benefit of making relationships to other concepts (e.g. as mentioned in that query from earlier re concepts and related concepts..)
<https://solidproject.org/TR/protocol#Server>
skos:relatedMatch spec:RespondingAgent .
<https://solidproject.org/TR/notifications-protocol#NotificationSender>
skos:broaderMatch spec:ProducerOfContent .
Again, concepts like RespondingAgent and ProducerofContent etc (see Spec Terms...) are from Variability in Specifications.
Specs can be very detailed. For example, Solid Protocol only mentions Server and Client but I believe there is more to the story:
Spec Terms partly models W3C's Variability in Specifications which was developed through the W3C QA Activity, RFCs 2119, 8174 for requirement levels, and inspired by INFRA's Conformance for advisements levels. And generally many other things that helps to express specifications (documents).
Specs define abstract roles, features or behaviours, not real-world instances.
Using
skos:Conceptfor requirement levels, advisement levels, categories, classes of products, interoperability various subvisions (dimensions of variability), among many other significant things - which I won't bother to hash out - is appropriate and intentional in this context. These are conceptual labels, not RDF/OWL classes in the type-system sense. Modeling them asrdf:Class/owl:Classwould conflate conceptual labels with logical classes, which is a category error. For example,#Serverin a specification denotes the idea of a server role, not any specific software instance. That makes it a good fit forskos:Concept- something you can classify, label, and describe in human-readable and machine-processable ways.
An identifiable software often implements various specifications with various features described within. They take on different roles in different contexts. This is the reality.
It is far more accurate and flexible to be able to express that software "implements" or "conforms to" (whether by the software itself, test results, or implementation reports) multiple concepts and requirements that are defined in specifications, rather than limiting that software to just one product class in one specification in a logical type-system or even blindly typing it to multiple classes which may in fact be conflicting.
What guarantees that only classes of products are top concepts in the spec?
Because there are specific properties that lead to the discovery of concepts or concept schemes, e.g., classes of products (
spec:classesOfProducts), specification categories (spec:specificationCategory), terminology (spec:terminology).
(I think I missed including
spec:terminologyin Solid Protocol but the property is in Spec Terms and all of the terms are marked as Concepts as part of the Terminology ConceptScheme already in the spec.)
The example you've quoted was specifically for specification categories. See classes of products SPARQL query.
That chains through each requirement in the spec, will have multiple (duplicate) subjects (product), and each subject is not guaranteed to be defined by spec's conformance model - although that may or may not be a concern depending on what needs to be communicated.
What might be more precise is
?document spec:classesOfProducts/skos:hasTopConcept ?productClass .where you can get the definitive and exact list defined by spec's conformance.
Other specs have other concept schemes, each with their own topConcepts. The only list of topConcepts that applies accross specs is the one in spec: which defines abstract classes like spec:RespondingAgent which are in a broader relationship to the classes of products define in the specs. I don't see the broader relationships as critical to the catalog but you may have a use for those relationships.
That's generally right and what's intended. I don't know what's critical to the catalog but I would just clarify this:
Various SKOS matches (broadMatch, closeMatch, exactMatch, narrowMatch, relatedMatch) provide useful knowledge about the specs and how they may be related (such as the product classes), and consequently the implementations. Essentially, it can help to navigate all that controlled knowledge from different directions, and I think that can be very valuable for something like the catalog you're working on. The SKOS matches also provide a useful bridge to inspect the whole ecosystem, e.g., what may be compatible with what or what could be extended and so on. And, I can only suggest that specs should take time to include these different kinds of matches (and not only for product classes) to organise its knowledge.
This kind of information feeds into understanding adoption: solid/specification#402
|
You might want to look into GoodRelations. |
|
This issue is about classes of products as in https://www.w3.org/TR/spec-variability/#spec-cat-cop |
csarven
left a comment
csarven
left a comment
There was a problem hiding this comment.
I propose that this PR is closed in favour of #98 since that clarifies and minimises potential misuse of spec:requirementSubject. And as already explained numerous times, Spec Terms already includes a way to discover classes of products.
|
@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? 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: |
|
After processing #98 independently from this one, I will just update this PR to use either one of those
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 #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 Future maintenance may well be only applied to one or (hopefully) both of the |
|
Thanks @TallTed |
|
I guess I didn't understand the discussion to date. Sorry for the noise suggestion. |
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:
If a change to Spec Terms is needed, #97 clarifies the intended and expected range ( Again, current publications (including Solid Notifications Protocol, which elf Pavlik is a co-author of and have approved for publication) define All of the following define classes of products and/or use requirement subjects with the understanding that it refers to a SKOS concept.
Ditto the social understanding and use as early as in other places like The expectation for Requirements in specifications also refer to "requirement levels" which are also concepts and are defined in Spec Terms, 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. |
Actually I'm trying to make the point that there is no conflict in having
There's noting stating |
|
"Actually" that wasn't at all the point you were making. Please stop moving the goal posts and red-herring. You literally proposed setting I've also explained that the range does not need to be changed, and if needed to be set, it is just Again, Spec Terms already includes a way to discover classes of products. The specs are functioning correctly with It is entirely your decision what additional types you want to associate in your own tooling. |
|
👉 #97 (comment) 👈 |
|
Spec Terms already defines the discovery of classes of products. |
|
https://w3ctag.github.io/design-principles/#priority-of-constituencies
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:
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:
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:
|
|
Thanks for joining the conversation @edwardsph That LLM summary didn't catch this comment #97 (comment)
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:
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 Equating versioning needs with the choice between 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. |
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 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.
I don't see any rush. I also don't see neither this or #98 getting required 3 approvals so we can continue discussion. Possibly terms need to be superseded with newer terms rather than changed. |
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.
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. |
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 |
As already noted in #97 (comment) , 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 |
|
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
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:
And 3 years old one that would support my style of publishing RDF in HTML using standard 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 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
Why is |
|
@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.
It was developed partly by the Solid QA initiative.
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: 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 #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. |
5 participants
Based on PR solid/specification#743
And implementation experience across
This PR adds simple
spec:ClassOfProductclass andspec:definesConformanceForthat relates it tospec: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:Requirementwhich 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
TODO
spec:Productorspec:ConformanceClass. this would prevent confusing it with the SKOS concept scheme.