Property talk:P2738

Documentation

• Start a query
• Current uses
• Statistics by class
• List of values
• List of qualifiers
• Count

disjoint union of
every instance of this class is an instance of exactly one class in that list of classes. Use "list item" P11260 as qualifiers to specify the list of classes

Represents	disjoint union (Q842620)
Data type	Item
Domain	class, or metaclass (note: this should be moved to the property statements)
Allowed values	According to this template: class list, or metaclass list (resp) According to statements in the property: list of values as qualifiers (Q23766486) When possible, data should only be stored as statements
Usage notes	Simpler way to state that A, B, C and D are disjoint using one statement and one item. Multiple statements mean different disjoint relations, thus usage of qualifiers: set value Q23766486, then use P11260 as qualifier with disjoint sets as values in P11260
Example	nucleon (Q102165) → list of values as qualifiers (Q23766486) Platonic solid (Q188745) → list of values as qualifiers (Q23766486)
See also	union of (P2737), has part(s) of the class (P2670)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties By value of property Most statements Fewest statements Most sitelinks Most linked wikis Total of sitelinks on items Most identifiers Fewest identifiers Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Database reports/Complex constraint violations/P2738 Database reports/Constraint violations/P2738 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 857 Main statement 848 98.9% of uses Qualifier 9 1.1% of uses
Search for values

Explanations [Edit]

Disjoint union and union

As the cases are similar, this page documents both the properties union of (P2737) and disjoint union of (P2738). Both properties are properties for classes or metaclasses, see Classification and Basic membership properties. Disjoint union and union are relationships between a class (say C for example) and a list of its subclasses (say L for the list).

Their purpose is to represent two different but related things:

1. the union one states that and instance of C is an instance of at least one of the class listed in L.
2. the disjoint union has the first property but add the constraint that every instance of C is instance of exactly one class in L.

In both cases, all the values in L are listed in a single statement, as qualifiers, using the qualifier list item (P11260), and the main value statement list of values as qualifiers (Q23766486) as a placeholder.

Examples

union of

Radio and TV programs. Some media programs can be both TV programs and Radio programs, like Spelling Bee (Q7575891)    is an example of on Wikidata. But it can be assumed that all broadcasting program (Q11578774)    are at least one of them. (or on the web also ?)

⟨ broadcasting program (Q11578774)    ⟩ union of (P2737) ⟨ list of values as qualifiers (Q23766486)    ⟩
list item (P11260) ⟨ television program (Q15416)    ⟩
list item (P11260) ⟨ radio program (Q1555508)    ⟩

disjoint union of

Take the particles that a atomic nucleus (Q37147) are made of. These particles are called the nucleon (Q102165)   . There is exactly two kinds of nucleons : the proton (Q2294)    and the neutron (Q2348)   . Moreother, one specific nucleon (Q102165)    can either be a proton or a neutron, but nether a proton and a neutron. Nucleons, protons and neutrons are all classes of real world objects, because there is many nucleons instances in nature (see Help:Classification and Help:Basic membership properties for more explanations)

Then the following statement

⟨ nucleon (Q102165)    ⟩ disjoint union of (P2738) ⟨ list of values as qualifiers (Q23766486)    ⟩
list item (P11260) ⟨ list of values as qualifiers (Q23766486)    ⟩
list item (P11260) ⟨ proton (Q2294)    ⟩
list item (P11260) ⟨ neutron (Q2348)    ⟩

means exactly that.

Rationale and usage instructions

It's very common that we regroup objects or concepts into similar classes of object or concepts in broad classes, then that we further divide this broad classes into smaller classes that don't overlap and such that any instance of the broad class is an instance of exactly one of the smaller one. For example we can define people that belongs to a sport club into age based categories (junior, senior, ...)

But in sport, it's also very common to divide people into unrelated sex based categories, or weight based categories.

More generally, there is often several useful ways to partition of a set (Q381060) a class of instances. To reflect that on Wikidata we need a way to regroup the classes that divide the class in one way, to regroup the classes that partition into another way, and not to mix things up. This is how we achieve this : we use one statements per way to partition our main class. Each of these statement uses a dummy value (list of values as qualifiers (Q23766486)) as a main statement value, because what's meaningful and useful is the values for qualifier. The set of classes that partitions the set is indicated by the set of qualifiers built with list item (P11260) .

Constraints

It can be checked with a sparql query that no instances of the subject of parent class is instance of none of the classes in a union of statement. The Lua Module Module:Requests/union_of has functions to generate such queries that find the items that do not fit and could be used in some kind of constraint report. They are included in Template:Class reports.

One of list of values as qualifiers (Q23766486): value must be one of the specified items. Please expand list if needed. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#One of, values statistics, search, SPARQL

Required qualifier “list item (P11260)”: this property should be used with the listed qualifier. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#mandatory qualifier, SPARQL

Qualifiers “list item (P11260), criterion used (P1013), nature of statement (P5102), sourcing circumstances (P1480), applies to part, aspect, or form (P518)”: this property should be used only with the listed qualifiers. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#allowed qualifiers, SPARQL

Scope is as main value (Q54828448): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Scope, SPARQL

Property “instance of (P31): Wikidata internal entity (Q21281405)” declared by target items of “disjoint union of (P2738)”: If [item A] has this property with value [item B], [item B] is required to have property “instance of (P31): Wikidata internal entity (Q21281405)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Target required claim P31, SPARQL

Property “Wikidata usage instructions (P2559)” declared by target items of “disjoint union of (P2738)”: If [item A] has this property with value [item B], [item B] is required to have property “Wikidata usage instructions (P2559)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Target required claim P2559, SPARQL, SPARQL (by value)

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Entity types

Property “instance of (P31): Wikibase value (Q19798642)” declared by target items of “disjoint union of (P2738)”: If [item A] has this property with value [item B], [item B] is required to have property “instance of (P31): Wikibase value (Q19798642)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Target required claim P31, SPARQL

Property “equivalent class (P1709)” declared by target items of “disjoint union of (P2738)”: If [item A] has this property with value [item B], [item B] is required to have property “equivalent class (P1709)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2738#Target required claim P1709, SPARQL, SPARQL (by value)

Overlapping subclasses
Class which is a subclass of two classes listed as disjoint (Help)
Violations query: SELECT DISTINCT ?item ?overlap WHERE { ?item p:P2738 ?m . ?m pq:P11260 ?a, ?b . FILTER ( ?a != ?b ) . ?overlap wdt:P279 ?a, ?b . } order by ?item ?overlap
List of this constraint violations: Database reports/Complex constraint violations/P2738#Overlapping subclasses

Missing subclass link
Disjoint union of classes which are not listed as subclasses of the item (Help)
Violations query: SELECT distinct ?item ?sub WHERE { ?item p:P2738 / pq:P11260 ?sub . FILTER NOT EXISTS { ?sub wdt:P279 / wdt:P279? / wdt:P279? ?item . } } order by ?item ?sub
List of this constraint violations: Database reports/Complex constraint violations/P2738#Missing subclass link

Deprecation of P642
Replace of (P642) with list item (P11260) (Help)
Violations query: SELECT DISTINCT ?item ?itemLabel ?itemvalLabel ?ofLabel WHERE { { ?item p:P2738 ?stm . ?stm ps:P2738 ?itemval . ?stm pq:P642 ?of . } }
List of this constraint violations: Database reports/Complex constraint violations/P2738#Deprecation of P642

Unused?

I added a list at Property talk:P2738/list to monitor the use of this property. It seems it's not being used.
--- Jura 18:49, 13 April 2016 (UTC)

This property is four days old. Please stop being ridiculous. --Srittau (talk) 19:08, 13 April 2016 (UTC)

Let's see how it evolves.
--- Jura 19:13, 13 April 2016 (UTC)

What's your point ? author  TomT0m / talk page 20:02, 13 April 2016 (UTC)

Classes only?

Do all values of this property need to be classes? Erroneous statements like inner planet of the Solar System (Q3504248) has part(s) (P527) Mercury (Q308) are still causing problems, and I was hoping that this property might be able to deal with some of the misuses of P527 in classes. --Yair rand (talk) 08:36, 3 May 2016 (UTC)

@Yair rand: Which misuse are you talking of ? If you have some relevant queries, you can add them to : https://www.wikidata.org/wiki/Wikidata:WikiProject_Ontology/Problems . author  TomT0m / talk page 09:47, 8 May 2016 (UTC)

Good idea, bad implementation

The intent of this property is to assert that at least two disjoint subclasses can inherit from the subject parent class.

This is a very, very common occurrence in taxonomy. What is much more important for reasoning is to assert that a class x is a disjoint with class y, so that the constraint axiom "no individuals of class x can be members of class y" is available. Somehow, the essential property owl:disjointWith has been overlooked in this discussion.

OWL offers clear guidelines for here. See https://www.w3.org/TR/owl-ref/#appD where it states:

"daml:disjointUnionOf was removed from the language, since it can be effected using owl:unionOf or rdfs:subClassOf and owl:disjointWith."

To find disjointedness with SPARQL is much easier than the overly complex constraint algorithm that has proposed above. For example, we are looking find only related parent taxons and only know the descendant, then a property path that uses wdt:P171*/owl:disjointWith* finds them. Or, if we want to find the disjoint relata of any given class, just check directly for the owl:disjointWith assertion. A common use case is the need to find a generic subclass and exclude disjointed parents from from the query results. For example, "find all Carnivora species except for Felidae". The query (in a properly constructed system that has applied a disjoint property on the family Felidae) would look like this:

SELECT ?species ?label WHERE {?species wdt:P105 wd:Q7432; rdfs:label ?label FILTER (lang(?label) = "en") . 
?species wdt:P171* wd:Q25306 FILTER NOT EXISTS {?species wdt:P171* ?parent . 
?parent owl:disjointWith ?disjoint FILTER (?disjoint in (wd:Q25324))}}

I have proposed the property "disjoint with" here that will serve this function much better. @TomT0m:

Chjohnson39 (talk) 09:01, 8 May 2016 (UTC)

@Chjohnson39: It may be a little bit harder to write queries, but it's a lot easier to use to model stufss. See the discussion with Markus on the property creation about this. For example it's probably possible to get all classes (directly) disjoint with a class with a scheme like "?class wdt:subclass_of ?parent . ?parent wdc:disjoint_union_with ?claim. ?claim qualifier:of ?value1 . ?claim qualifier:of ?value2 filter (?value1 != ?value2) . is a practicable substitute for ?value1 disjoint ?value2. Moreother it's way easier to maintain because we are forced to find a parent, and won't have to create good practice rules such as "don't assert that "a species of plant" is disjoint with "animals", you just have to say that "animal" is disjoint with "plants". author  TomT0m / talk page 09:34, 8 May 2016 (UTC)

We now just have to make the code I presented work and wrap in into a Category:Partial query like (not) {{Disjoint with}} to spare the pain to write this sparql. author  TomT0m / talk page 09:36, 8 May 2016 (UTC)

@TomT0m: Enforcing good practice is another question entirely. I do see the issue that you raise about the possibility of infinite parent disjoint assertions without a constraint that it can only occur on a member class. disjointWith is a "pairwise" assertion and should never be used on a non-member, so a constraint that says "?subject disjointWith ?object requires ?object to have ?subject subclassOf ?parent" seems relatively straightforward.

I do not see the utility of disjointUnionOf being in any way better, and in practice it is much more complicated. Your approach must start with a subclass criteria, in order to find a disjoint sibling. Here is the actual query for reference.

SELECT ?q ?label WHERE { VALUES(?s) {(wd:Q2294)} {?s wdt:P279 ?parent . 
?parent p:P2738 ?o . ?o pq:P642 ?q . ?q rdfs:label ?label FILTER (lang(?label) = "en")}. FILTER (!sameTerm(?q,wd:Q2294))}

I believe that disjointUnionOf is creating more hierarchical complexity, where none is needed. If the "qualifier nodes" are already asserted as subclassOf in their own context, this UnionOf just a duplication of the subclass assertion within the context of the parent class entity. With owl:disjointWith, only one assertion against another sibling is necessary to segment the property path. Not all siblings have to be asserted as disjoint with each other. Just the presence of the axiom one time is enough for the subclass inference to be blocked along that entailment path. Chjohnson39 (talk) 12:17, 8 May 2016 (UTC)

@Chjohnson39: Nonsense. You'll have to choose wether to add a statement from C1 to C2 ; to C2 to C1, or worse. If A, B, C and D are disjoint, this become worse. You'll have to state that A and B are disjoint, A and C; A and D; B and C; B and D ; D and C. That's a lot of statements, and for each you can duplicate them and choose an item in which you put the statement for each of those couples. It's fastidious and makes the verification that all cases are covered kind of fastidious. author  TomT0m / talk page 12:24, 8 May 2016 (UTC)

@TomT0m: Clearly you do not understand the mechanics of SPARQL or the query at the top of this topic. owl:disjointWith acts like a NOT tag for the FILTER on that class and all of its descendants. The query is checking for "at least one" instance of the property in the result set. What is nonsense to you is an OWL standard implementation. The "experts" have decided that disjointUnionOf is not necessary a long time ago. Regarding verification, you cannot validate much with just 1 step of transitivity and that is all disjointUnionOf will give you.

Exactly as C is not necessary for someone who knows assembly language ? Oh, by the way, the nonsense was definitely not a critic of your implementation. Care for consistency ? author  TomT0m / talk page 14:32, 8 May 2016 (UTC)

Maybe I try to explain the query in more simple terms, because it is somewhat complicated. The query first targets species from the Carnivora order (487 total) then it applies a FILTER that only returns results that do not match the criteria. The criteria is defined as "match all species whose ancestors have owl:disjointWith to class X" (in the example class X = Canidae (dog)). So, the criteria matches all species who are descendants of "Felidae", because there is an axiom that states "Felidae is disjoint with Canidae". The FILTER then subtracts (because of the negation "NOT EXISTS") the matching criteria and returns the remainder (403 total). The ability to target an exclusion class is then only dependent on the application of "at least one" disjoint axiom to it. Basically, the mechanism works by identifying the thing by what it is NOT. Of course, a thing is not a million other things, but it is not necessary to assert that. Only one disjoint statement is required. The functional problem exists in that a thing is not self-referential (i.e. there is no statement that says "thing is a thing", so there must be a way to target it in the query with some concrete assertion, and pairwise opposition one method for doing this. I believe that the problem of multiple member discrimination (saying "A is disjoint with B and C and D") is not a typical query problem and I cannot think of a question where this would be necessary. In fact all entity classes are inferred to be distinct (which is not the same as disjoint, btw), unless they are explicitly declared to be the same.Chjohnson39 (talk) 05:39, 9 May 2016 (UTC)

Why would not it be possible to rewrite the ?parent owl:disjointWith ?disjoint in your query with (sketch ?superclass wds:"disjoint union of" ?statement . ?statement qualifier:of ?parent . ?statement qualifier:of ?disjoint filter(!sameTerm(?parent,?disjoint). This is semantically the same. author  TomT0m / talk page 06:31, 9 May 2016 (UTC)

@TomT0m: It is not the same. Your query does not work, and as I said above already, it is not possible to reason inheritance with your implementation. If fact, the use of the "dummy class" statement is actually quite dumb, because it is impossible to reason the entailment path between the superclass and the disjointed children without another subclass property. Chjohnson39 (talk) 07:02, 13 May 2016 (UTC)

@Chjohnson39: Nope, you can do exactly the same thing. author  TomT0m / talk page 10:04, 13 May 2016 (UTC)

What about P279 claims at each item in disjoint relation?

d1g (talk) 16:08, 7 September 2017 (UTC)

impractical

There's an unnecessary restriction for most common cases: The way this is defined is that the parent class must be "virtual" so that elements can only be one and only one of the listed subclasses. But this is too restrictive: this should be at most one of the lsited subclasses, so that there can still be instances created from the parent class that do not belong to any one of the listed exclusive subclasses.

But if an item is been classified as of one of the subclasses, they cannot belong to any other subclass (but may still belong to the parent class).

This is important for various definitions, notably in administrative geography, where there's a "generic" type, which has some specific exclusive subtypes for specific status and specific requirements that are not enforced for all items of the generic type.

Note also that the list of specific subtypes (subclasses) may be extensible over time. And for this it would be simpler to specify such disjunction NOT in the parent type, but inside each subtype that are exclusive and disjoint with other subtypes from the same parent.

So it would be preferable to have a property named "subclasses" for the item describing the parent class (in values, we would give each possible subtype, but not necessarily all of them) and then add "excluding" qualifiers if necessary (the qualifier values would specify the other subtypes listed that are excluded, to form the disjunctions between): listing "subclasses" for a given class item is generally not necessary, except exactly to mark their exclusion. The alternative is to not add this "subclasses" property at all, but define these exclusions only in the properties of the item describing eachsubclass.

Say we have "A mayBeOfSubclass B" and "A mayBeOfSubclass C"; this is currently defined by these RDF triples:

• "B isSubclassOf A." (we could also add the reverse "A mayBeOfSubclass B." for the symetry, but for now we can't)
• "C isSubclassOf A." (we could also add the reverse "A mayBeOfSubclass C." for the symetry, but for now we can't)

So we can have items:

• "A1 isInstanceOf A.": we don't know if A1 is an instance of B or C (it could, and could even be both).
• "B1 isInstanceOf B.": we know that B1 is also an instance of A, but don't know if it is also an instance of C (it could be).
• "C1 isInstanceOf C.": we know that B1 is also an instance of A, but don't know if it is also an instance of B (it could be).

Now in the definitions of subclasses B and C we can just add these (edit the wikipages for B and C and add one property to each):

• "B isNotA C."
• "C isNotA B."

This is enough to define the exclusions (no need to modify the parent class to add properties to it, only add exclusions between subtypes in the definition of subtypes themselves). This does not remove the possibility of define items A1, B1, and C1, but now we can conclude that B1 is an instance of A and B but not C, and that C1 is an instance instance of A and C but not B, and that A is an instance of A, and possibly of B or C (but not both). And we don't need the "union" because we can instantiate items of parent type A directly !

The alternative to the last 2 triples (created by editing separate pages) is to define them in the parent class (this is equalivent semantically, but made on editing only the wikipage for the parent type A):

• "A mayBeOfSubclass B." qualified with "except C." (we could add multiple "except values." qualifiers if needed)
• "A mayBeOfSubclass C." qualified with "except B."

The "mayBeOfSubclass" property can also be named "exemplarSubtype" or "hasSubtype". The qualifiers above are optional, and can be added easily when we've determined the exact disjunctions (somthing that is not easy to assert, except by temporary tests that may be made on the existing full datasets of relations between classes and subclasses or classes and instances; if we find errors, this indicates we need a few more subclasses for separating those that are really mutually exclusive).

The concept of "union" (of subtypes) to define a parent class is too restrictive for practical cases, as there are lot of data where we know they are of some parent class with common properties but we have still not define specific subclasses for specific exclusive properties (because we are not sure these properties are distinctive enough): it's impossible to create the union from a *complete* list of subtypes (because we don't know how many we need. We may want to create an additional "catchall" subclass to collect all other cases not covered by the exclusive types needed for the union, but we don't always know that this "catchall" remainder subtype is exclusive of the other subtypes. And generally we should not need to define this "catchall" remainder subtype to create a valid union.

So it's just best to allow items to be created of an instanciable parent class and determine later if we can reassign it later to a more precise (and exclusive) subtype.

With my model, P2737 and P2738 are not needed at all, because they are too much inflexible, impractical for most needs (except in rare datasets that are completely closed and not extensible... and this almost never occurs in Wikidata!). Verdy p (talk) 04:02, 27 March 2020 (UTC)

@Verdy p There still are cases where this works kind of well, actually. And you forgot one important stuff, all classes in Wikidata are not meant to be implemented. Those statements are meaningful by themselves, for example saying that concrete objects and abstract object adds information in the database even if the classes are not meant to be instanciated directly because too abstract. And there are many such cases. How to handle exceptions is a valid point however, I’d prefer community have a little concrete experience over that before choosing a mechanism. It may be that exceptions are not so common and it’s practical to just add a few "mixed-case" items should do the trick. author  TomT0m / talk page 10:08, 13 December 2023 (UTC)

Adding exception can also potentially make the whole thing impractical. Like "this statement is true except for this list of <almost everything>" … Ok so it’s just not true and we should change the model, except people may go to adding another exception instead of bothering fixing the model. Handling exceptions is a thing that can be hard for a tool to do correctly. author  TomT0m / talk page 10:25, 13 December 2023 (UTC)

use for name without diacritical marks (Q89410507)

With @נדב_ס:, we were wondering if this property should apply or if it would just be a normal intersection. Maybe if it's a matter of POV, is a misspelling of a name also a name or not?--- Jura 10:16, 8 February 2021 (UTC)

@Jura1 Yes this is a modelling issue, I think. Conceptually a name does not really "is" a sequence of letters, the prefered form for using a name is to call someone orally, linguists tends to argue that the main form of language is oral, the writing is "just" an encoding of it. So different spelling that maps to the same should be considered the same name. But administratively the name is usually written and its writing matters. Also different spelling may need to be pronounced differently according to the name owner, so this is a complicated matter :)

This cannot be decided here. author  TomT0m / talk page 10:18, 13 December 2023 (UTC)

For Hebrew and Arabic abjads, the pointless names make an alternate/simplified orthographic system because the vocalic point diacritics are optional (for most of them, except sin/shin dots in Hebrew and some consonant modifier diacritics in Arabic). This should not be used for other scripts (notably not Latin or Cyrillic alphabets). Hebrew also has a third orthographic convention where pointed orthography can also have cantillation marks (not used in most texts; note that a few alphabets also have their own cantillation marks for similar usage; but in most cases they are not semantic and not part of names, but are annotations added in the context of specific texts). So I wound not use the current terminology defined in name without diacritical marks (Q89410507), but something specific to Hebrew (or Arabic), like "unpointed Hebrew" and "pointed Hebrew" seen as linguistic variant (with its own language code, however I don't see which BCP47 code would apply to use "translated labels", so this would mean separate properties instead, with their own specific rules based on Hebrew/Arabic collation data from CLDR: the validity would be a simplification that preserves at least the primary or secondary differences, ignoring ternary differences, meaning that they are specific to a collation rule for a specific language). Verdy p (talk) 17:21, 13 December 2023 (UTC)

Relabel to "disjoint union of classes"

Otherwise you could also say e.g. European Standardization Organization (Q51885731)disjoint union of (P2738)list of values as qualifiers (Q23766486)list item (P11260)European Telecommunications Standards Institute (Q899383)list item (P11260)European Committee for Standardization (Q648403)list item (P11260)European Committee for Electrotechnical Standardization (Q1378146) ... but these are individual instances ... not classes.

--Push-f (talk) 14:52, 15 December 2022 (UTC)

It’s uselessly verbose in my opinion, the constraints on qualifier values should prevent that, and I think it’s not something would really in good faith try. There is indeed a few use where the value is not a subclass of something. Most of them seems to be math related, quite logically as the terminology matches.

Some others seems like adding a "subclass of" statement would be the solution, even in the math case (the ontology of maths is still not easy to define :) ) author  TomT0m / talk page 21:02, 15 December 2022 (UTC)