Some opportunities for this, or at least to come up with cases for humans to consider -- see below. However, the number of incidences of this property is likely to be quite limited.
Motivation
The motivation for this property grew out a discussion at Project Chat about the nature and characteristics of metaclasses.
Some further current examples, which may be surprising at first glance:
Arguably some of these relations might be better expressed as properties on the underlying subclasses. However, for the moment the relations between the underlying classes of the two sets of metaclasses are expressed by subclass of (P279) -- which means that the relation between the two metaclasses is indeed currently a metasubclass relationship.
An example of where a property has been introduced, and many of the relations have been changed to use it, can be seen in
Most television series classes use genre (P136) to express their relationship to instances of television genre (Q15961987). However, as a look at the "from related items" section of the Reasonator entry for soap opera (Q23739) reveals, there are still many television series classes using subclass of (P279) -- which should probably be discouraged, given the relationship can instead be expressed by a property.
Some further notes:
The property is intended to capture relationships other than those already captured by subclass. Therefore it should not be applied if metaclass A is genuinely a subclass of metaclass B -- ie if it should be understood that all instances of metaclass A are also instances of metaclass B.
Due to the transitive nature of subclass of (P279), all subclasses of a metasubclass A are also metasubclasses of the metaclass B. So the property should be applied to the highest item for which it is valid in the class tree on the domain side.
Similarly, a metasubclass A is also a metasubclasses of all superclasses of a metaclass B. So the property's value should be the lowest item in the target class tree for which it is valid. In this way the levels on the two sides of the property should match -- engine metaclasses with engine metaclasses, generic manufactured item metaclasses with generic manufactured item metaclasses.
It is possible that in future either metaclass (Q19361238) or metaclass (Q19478619) may be used to manage a controlled vocabulary of metaclasses -- a set of metaclasses that had been 'signed off' as okayed by being made a subclass of one of these items, so that any attempt to use instance of (P31) from a class item to any item not in this 'approved' class would throw a constraint violation. If that happens, then any attempt the "metasubclass of" property on or to an item not in that class should also throw a constraint violation.
I've found the above candidates for the property using this query tinyurl.com/pazxyf4 to throw up potential matches. It could be refined, as at the moment it only has quite a low true positive rate. My main motivation for suggesting the property is therefore simply to record what of these quite curious relationships exist -- because even with the query, there's no obvious way to generate such a list algorithmically, it currently relies so much on manual validation. So given that it's hard to recreate such a list, it seems proportionate to introduce a property to be able to record it.
I should also emphasise that my intention would be for the property to be descriptive rather then prescriptive -- ie to try to identify and make accessible some relationships that are in the database currently, rather than to be proposing any relationships that should be in the database.
Of course, having identified such relationships, one can then look for gaps in them -- what classes that are instances of the metaclass on the domain side appear to be missing superclasses that are instances of the metaclass on the target side? (This is analogous to looking to see which items appear to be missing a particular property) Or, are there items that might be created to make structures more systematic -- for example, should a manufactured object family item be created, to be a superclass for aircraft family (Q15056993) and engine family (Q15057020), a "metasubclass of" target for product model (Q17444171) ?
But my main motivation is simply to identify and have a way to be able to capture these patterns, which are currently implicit in the database, but not easily accessible. I think that's worth a property.
Support (after discussion) : captures something actually. Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page10:12, 23 October 2015 (UTC) Needs a little more thinking after discussion.[reply]
@TomT0m: I hope you find the explanation above now a little more complete and detailed. :-)
The thing I should stress is this is not an attempt to replace subclass of (P279), and I see no purpose that would need a meta version of instance of (P31). The aim is simply to capture some relationships that simply can't be expressed at the moment.
I don't think it really complicates the model much, as the number of instances of the proposed property would be vanishingly few. Remember, it is not intended to be applied where subclass of (P279) can be applied. So rather than being a heavy complication, I think a better way to view the property is as simply identifying a handful of curiosities -- which already exist in the model, they're just not easy to extract.
I think it will therefore hardly impinge on contributors or practices at all, as its domain of application will be so very very limited.
But I think it does have interest, and some potential for usefulness, so I do hope you might reconsider your initial oppose. Jheald (talk) 12:15, 23 October 2015 (UTC)[reply]
(ec) One way to look at the property is to see it in some ways analogous to properties for this type (P1963). For attributes of items that are expressed as properties, P1963 indicates what properties one might expect to find on a particular class of items. Analogously, for attributes of items that are expressed through subclass relationships, the proposed property indicates what sort of "subclass of" targets one might expect to find on a particular class of items. Jheald (talk) 12:35, 23 October 2015 (UTC)[reply]
@Jheald: So a good description would be "subclasses of instances of the subject metaclass's are instances of that metaclass" ? I think I'm beginning to understand : a typical car family subclass is a car models indeed. There may be other kinds of car famylies. But what's the value added to simply say that "car model" is a subclass of "car family" ? The "likely to be" in your description ? author TomT0m / talk page12:46, 23 October 2015 (UTC)[reply]
Because "subclass of" requires that every instance of a "car model" is an instance of a "car family". But that's not true: the two are considered different things. Jheald (talk) 12:59, 23 October 2015 (UTC)[reply]
@Jheald: Sorry, but I fail to understand this proposal. Can you expand one or two of the example relation between two metaclasses: instances of this metaclass are likely to be subclasses of classes that are instances of the target metaclass wrt. say, the element example ? I can't understand the relationship beetween elements and rows in the table. author TomT0m / talk page12:32, 23 October 2015 (UTC)[reply]
But an instance of a Hydrogen is not an instance of a Period. subclass of (P279) is therefore not an appropriate way to model the connection between chemical element (Q11344) and period (Q101843). So I suggest this new property, and then the relationship could be captured.
Note that I'm not claiming that this is necessarily the right (or best) way to represent which period of the periodic table Hydrogen is found in -- I merely wish to be able to note that this appears to be how the relationship is seemingly being modelled, currently. Jheald (talk) 12:50, 23 October 2015 (UTC)[reply]
If we take the "atomic" definition of hydrogen (for simplicity) : «type of atom with number 1 atomic number», so the item may be hydrogen atom (Q6643508), then this would make period 1 (Q191936) a subclass of atom, so a class of atom. period 1 (Q191936) is then "atoms of elements in the first row of the periodic table". This would make period (Q101843) a metaclass of atoms as well.
So if we say that:
«level 0» is the instance level,
«level 1» is the class of atoms level
«level 2» is the class of class of atoms level (so the first metaclss level
It's a bit tricky. There are rather few examples, and they're not particularly easy to find.
To take the example you raise: one would be looking for instances of horse breed (Q3745054) to also be subclasses of instances of horse (Q726). That doesn't work, because instances of horse (Q726) are individual horses, which have no subclasses. It's also the case that there aren't may instances of horse breed (Q3745054) that are subclasses of anything.
@Yair rand, Jheald: I got one more example : see . "Tritium atom" is a class of atoms, as "Hydrogen atom" is. We have SubType|Tritium atom|Hydrogen atom}} because any tritium atom is an hydrogen atom. But we don't have "isotope" (defined as a metaclass of atom) subclass of "element" (defined as a metaclass of atom as well) because "Tritium atom" does not belongs to the class of elements, only "Hydrogen atom" does. With those definitions, we would have "Isotope" metasubclass of "element". author TomT0m / talk page14:42, 2 November 2015 (UTC)[reply]
@Yair rand, Jheald, TomT0m: Please read that document before supporting or not this property. The use of metaclass and all related properties have a strong impact on the type of ontology we want to have for WD. This is typically the kind of decision which will have some impact later when we will build tools to extract information (not only data) from WD or when we will build tools to check data consistency. For me the use of metaclass or not should be a choice of the community with a clear description of the consequences, advantages and drawbacks of each option. If you have time this is another document comparing both structures. Snipre (talk) 15:53, 2 November 2015 (UTC)[reply]
You're a little late, this thing talk of metaclass in (object oriented) programming. A relevant notion would be Liskov substitution principle (Q957386) is that case. But we are not doing programming, and you can read metaclass (Q19478619) to see there is a lot more documentation for metaclasses on knowledge representation. But this precise property is far from being structuring for the use or not of metaclasses and will have a very low impact. If we really don't use metaclasses, which is really not true in current situation, then this property will just stay unused. No fear to have for ... what ? author TomT0m / talk page16:09, 2 November 2015 (UTC)[reply]
The essential question is do we want to allow a more automatic way to generate relation and in that case we will go towards some programming logic. I am not a specialist but I think this is a question which will have some consequences later or even nowas we are developping some query tools.
I don't agree with you about creating metaclass structure and decide later if we will use that system: creating that kind of structure will just allow parallel structures to be used and we will have to convert later all that workbecause we were not able to ask the good question at the good time. Snipre (talk) 18:52, 2 November 2015 (UTC)[reply]
@Snipre: You don't seem to understand. That property won't have any influence on us using Metaclasses or not as we simply don't need it to do so. The project about reasoning is WikiProject Reasoning, created by Markus who always have been supportive on my views about all these. He's an expert, so if this was anything of a problem to use metaclasses, we would know (I think I saw a draft from him and/or Denny about pushing metaclass modelling possibilities on OWL2). found it see Markus' edit on the history. author TomT0m / talk page19:12, 2 November 2015 (UTC)[reply]
So IF
Class A is an instance of metaclass B AND
Class A (and most other instances of metaclass B) is a subclass of Class C AND
Class C instance of metaclass D
THEN
metaclass B is a 'metasubclass' of metaclass D.
Is that it?
The bit I don't like is the "most" in the description above and the "likely to" in the property description. How to queries spot the exceptions?
@Filceolaire: A good argument could be that it allows to represent some kind of "ordering hierarchy", for example in the case of "elements/isotope" metaclass couple, clearly isotope classes are "smaller" than their corresponding atom classes. An analog property for hierarchies of administrative division this is useful as well : regions/states whatever can be divided into smaller parts, which can be expressed by located in the administrative territorial entity (P131) more or less, but the order beetwen units type cannot (City<departement<region<country for example in france). A more convincing example could by taxons rank in biology : kingdom >...> genus> species, with taxons defined as classes of organisms. Then with "metasubclass of", we could express the rank hierachy : kingdom metasuclass of ... genus metasuclass of species. author TomT0m / talk page18:33, 8 November 2015 (UTC)[reply]
→ engine configuration (Q2576663) 
reveals, there are still many television series classes using subclass of (P279) -- which should probably be discouraged, given the relationship can instead be expressed by a property.
Support (after discussion) : captures something actually. 
Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page 10:12, 23 October 2015 (UTC)
Done and 
Archived by Josh Baumgartner (talk) 17:41, 7 January 2016 (UTC)
