Add rdfs:range to spec:requirementSubject

[csarven]

Supersedes / Closes #97 .

Adds skos:Concept as range for spec:requirementSubject since there seems to be confusion about its intended use. skos:Concept is used for classes of products in some published specs, e.g.:

• https://solidproject.org/TR/protocol
• https://solidproject.org/TR/notifications-protocol
• https://solidproject.org/TR/wac
• https://solidproject.org/ED/qa
• https://solid.github.io/webid-profile/

I have also provided extensive explanation about Spec Terms / Solid QA in solid/catalog#44 that covers this topic.

Lastly, note that spec:Server and spec:Client that's currently in the Spec Terms are defined to be a skos:Concept ( https://github.com/solid/vocab/blob/main/spec.ttl#L484-L490 ) . These concepts were originally used in Solid Protocol but later replaced by the Solid Protocol's own classes of products, e.g., https://solidproject.org/TR/protocol#Server , https://solidproject.org/TR/protocol#Client , which are also defined as SKOS concepts.

As already mentioned elsewhere, this property is also used in applications such as https://dokie.li/ . See for example https://dokie.li/media/video/dokieli-spec-conformance.webm showing a table of Conformance information in which the subject column is populated by the spec's classes of product.

Happy to answer any questions since I am the original author of this.

[elf-pavlik]

This PR does NOT supersedes or close #97
I doesn't even collide with it, excapt potential git conflict once both proposed ranges are added.
I'm going to prioritize conversation i #97, if you like this simple change can be processed fully independently from my original issue.

[csarven]

Regarding requirementSubject:

This PR reflects exactly what was intended for its range. I am the original author, so there is no ambiguity here. What specifically are you disputing?

I've provided concrete examples from published specs that use requirementSubject, along with the original spec:Server and spec:Client (that is still in Spec Terms) SKOS Concepts available as product classes:

https://github.com/solid/vocab/blob/main/spec.ttl#L484-L490

spec:Server
  a skos:Concept ;
  skos:prefLabel "Server"@en .

spec:Client
  a skos:Concept ;
  skos:prefLabel "Client"@en .

I also cited an application that relies on this design.

You have no basis for redefining requirementSubject. Without any published specs demonstrating your alternative usage, proposing a different range is not a good-faith contribution.

Spec Terms already defines a discovery method for classes of products.

PR #97 is not only unnecessary, it is incorrect.

[elf-pavlik]

Without any published specs demonstrating your alternative usage, proposing a different range is not a good-faith contribution.

You are well aware that this is comming: solid/specification#743
After that there will be few more: https://elf-pavlik.github.io/solid-efforts/#/person?id=https://elf-pavlik.hackers4peace.net

Spec Terms already defines a discovery method for classes of products.

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

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

Can we please treat it as a Work in Progress, testing draft which you created?

[csarven]

Please acknowledge that you are contradicting established usage. Perhaps Spec Terms is not suitable to your needs, in which case, I recommend starting your own vocabulary.

Referencing your effort diverts attention from the issues that I am highlighting.

You were already warned multiple times about the misuse. Your experiments/preferences does not legitimise ignoring document practices and prior design.

[elf-pavlik]

Please acknowledge that you are contradicting established usage.

#97 (comment)

Perhaps Spec Terms is not suitable to your needs, in which case, I recommend starting your own vocabulary.

Oh, I'm sorry, I didn't realize that this one is your own vocabluary 😨 We should probably move it from github/solid to github/csarven 🤔

[csarven]

Nonsense. I find your comment quite rude.

Spec Terms is not "mine".

Myself and others have worked extensively through Solid QA and the Solid CG Test Suite Panel.

How can you dismiss that body of work or misrepresent it to suggest otherwise? This is a clear mischaracterization of the established process and usage.

[elf-pavlik]

I'm not going to continue this dialog, let's leave some breathing room for others to contribute.
I hope you noticed that spec vocab currently states: spec: dcterms:creator <https://csarven.ca/#i> .

[csarven]

I would add that the argument - if there is one - about the status of Spec Terms still being marked as "testing" is not to be taken as a "global absolute, but only in relationship to the practices, expectations and social structures around some vocabulary." (FOAF)

Even majority of the terms in FOAF have "testing" status, including common ones like foaf:name, foaf:img, foaf:PersonalProfileDocument.

The definitions of 'stable', 'unstable', 'archaic' and 'testing' cannot be defined as global absolutes, but only in relationship to the practices, expectations and social structures around some vocabulary.

It would be inappropriate to insist on changing a definition when it directly contradicts prior agreement and established use of the terms.

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.

Ditto the social understanding and use as early as in specification-tests (2021), e.g., solid-contrib/specification-tests@3c466a5

The expectation for spec:requirementSubject has always been to refer to a concept.

Ditto spec:requirementLevel refer to concepts (see Spec Terms for example for the RFC keywords.)