In the option 2, we could add informations about "multimodal" items add statements to add the different modes. One option could be something along the lines of :
which would mean this kind of vehicle has an aircraft mode in the displacement place, and a boat mode in the stationing place.
One problem I see with this multimodal item model : it's primarily an aircraft but if we search for aircrafts instances we would not find it. Maybe it's actually wrong to think it that way in that case because basically all aircrafts have two modes, as they do not fly all the times ! author TomT0m / talk page08:37, 8 April 2024 (UTC)[reply]
@ArthurPSmith It's a possibility yes, but almost all vehicles except a few cases have a main use. Look at some image results on "water-based aircraft" on a search engines, if these stuffs are boats, then earth-landing planes are cars, and we probably do not want to classify them as cars.
I think the right solution is actually to create a property "lands on" or "can operate on" for planes, and remove the "subclass of" for boats. Maybe we can generalize for other cases of vehicles. author TomT0m / talk page15:40, 8 April 2024 (UTC)[reply]
If I look at the en description for land vehicle (Q1301433) I read "vehicle mainly meant to move on land, including wheeled, tracked, and walking vehicles".
If we take that seriously, and take the converse for watercraft (Q1229765) then their intersection is empty as no vehicle can be "mainly meant" for both.
I think we should keep in mind that they are the exception, globally. One solution that keeps disjointness could be to have distinct classes for "possible" (can operate on) and "only" (unimodal).
Unimodal items would be subclasses of their "can operate on" counterpart, "land only vehicle" subclass-of "can operate on land vehicle".
This would allow to keep the disjoint that may be useful to spot errors while creating a few new items. Hovercraft would be a subclass of multimodal vehicle naturally. Car models would just subclasses of terrestrial only vehicle so few changes actually. Having an item for multimodal vehicles make sense. author TomT0m / talk page19:15, 8 April 2024 (UTC)[reply]
de:Peripherie gives various examples of concrete usages of the abstract term: in mathematics (circumference of a circle), geography (the periphery (Q10950926) meaning), in medicine (limbs of mammals), in political science (societies around a centre of power, in marxism), sociology (opposite of hegemony (Q182034)), computer engineering (peripheral (Q178648)), physiology (something relatively far apart from the centre of a biological object such as a cell or a body), something perspective-related in philosophy I don’t quite understand, and event technology (equipment arranged around a mixing console). I’m very unsure how to subordinate all these meanings under a singe superclass. --Data Consolidation Officer (talk) 12:01, 8 April 2024 (UTC)[reply]
It's very abstract, so it's probably high in the class tree. It's also potentially used in various abstraction context, so I'd make it a subclass of variable-order class (Q23958852).
My intuition is that it's also some kind of "parametric type" (in the programming language stuff) : it's always the boundary of something. (I don't think we really have thought this kind of stuffs through in Wikidata yet). So my intuition would be that it could be used as something like
(although the "of" qualifier is deprecated, maybe a new one is required for this kind of parametric metaclass)
Using this for classes to be instances of, a true metaclass it avoid breaking barriers of abstraction, if we use as something to be a subclass of (a kind of superclass for all boundaries kind) we risk its instance of to systematically be instance of "abstract object", where seacoasts for example lives in the concrete world. author TomT0m / talk page16:37, 8 April 2024 (UTC)[reply]
I think we don't currently have a model or properties for items that are fakes or feints, forgeries or stuffs like that. I noticed the class items for this are not well structured yet.
Hi. A lot of items are both instances and subclasses of something else. I would like to know what is the current consensus on this topic. Should they be removed, or are they accepted? Cheers, Lepticed7 (talk) 11:34, 11 April 2024 (UTC)[reply]
What seems odd to me is that in tree-like representation of an ontology, the instances are generally the leaves of the tree, while the classes are branches. And what I’m looking for is to know if there are some conventions that describe those choices, which are unconventional compared to classical ontologies? Lepticed7 (talk) 12:00, 11 April 2024 (UTC)[reply]
It is partly for some technical reasons that "classical" ontologies do not use classes of classes, but this is something that have some use and is doable on Wikidata. OWL introduced a technique called "punning" to be able to do that, and considering the nature of Wikidata of course it's useful.
An example, besides the one given in the references of Help:BMP this is one example in which we need it : atoms and elements. Atoms are the real word objects, they are all instances of the "atom" class. They are of different nature of course, and "hydrogen atom" is a subclass of all atoms, as any hydrogen atom is an atom. "Tritium" is a kind of hydrogen, so it's a subclass of hydrogen of course.
All this happens in the same tree, and all instances of some class of this tree is a real world object. Now comes elements and isotopes … we did not need those concept to classify atom. And no single atom is an isotope by itself. So we would like to express that "Hydrogen is an element" but we cannot use "subclass of" … if we did we could run into absurdities such as "the atom used on that atomic clock for sync is an element", and that would make the "element concept" a synonym for "atom" (any atom would be an element).
Classical ontologies typically don't use the "element" concept, then, it could be considered useless for application (you know what kind of element it is, that's enough, so they can afford to just use "subclass of").
But if we actually want to model the "element" concept we could use the level of "classes of classes", a "meta" level. That can be seen as an analog to the concept of "rank" in taxonomy (a taxon can be ranked "species" or "reign") that we use to "tag" levels in the second tree, the "element" level is typically the level just below the "atom" class ("hydrogen" for example). The "element" metaclass is then the (meta-class) of all the classes just below "atom". And there may be other ways to classify atom that does not follow this scheme, direct subclass which are not elements, adatom (Q352687) for example, which is not an element).
This model is consistent with the definition used in the frwiki article about elements : fr:Élément_chimique, an element is an atom "kind" and no atom is an atom kind. The elements are the classes themselves.
(oh, and if the model seems not used on Wikidata it's because there is a different notion of "element" used on enwiki especially, an element is a chemical substance, and they seem to have some kind of long going on edit war on that because that was not the case in 2021). author TomT0m / talk page17:06, 11 April 2024 (UTC)[reply]
The key anatomical ontologies are uberon and FMA. Neither of those have a distinction between metaclasses and first order classes. It should be a first order class in Wikidata and has the relevant P31/P279 for that. There are however still a lot of item that use it as a metaclass that need work on them, in most of the cases where it's used there are more specific classes that would be more appropriate. anatomical structure type (Q103813670) is the relevant metaclass. ChristianKl ❪✉❫ 02:43, 24 April 2024 (UTC)[reply]
Is there a good reason to have such an "and/or" item in the tree? It seems that this item has relatively few links and if we delete it we would clean up the tree a bit. ChristianKl ❪✉❫ 18:46, 24 April 2024 (UTC)[reply]
port (Q44782)subclass of (P279)harbor (Q283202) seems questionable given that enWiki says "The term harbor is often used interchangeably with port, which is a man-made facility built for loading and unloading vessels and dropping off and picking up passengers." If two ports together can make a harbor it's a "has parts" or "has parts of the class" which should link them and not P279. ChristianKl ❪✉❫ 18:52, 24 April 2024 (UTC)[reply]
BFO uses the word material enity to mean something spatial that has no mass. One of the examples, it gives for immaterial entities is the nasal passage. Anatomically, the nasal passage is seen in FMA as physical and not material. BFO itself does not seem to use the word physical.
I think we would reduce the amount of confusion by renaming physical object (Q223557) into "material object" as I see no good reason to use "physical" in that point of the tree.
After looking a bit more into it physical substance (Q28732711) description suggests it encompases radiation but currently the radiation items at which I look don't have it in their subclass tree. Radiation seems to be another thing that's often seen as physical but not material or matter (Q35758).
ChristianKl ❪✉❫ 23:49, 24 April 2024 (UTC)[reply]
@ChristianKlIf we however see nature de l’élément (P31) as transitive over sous-classe de (P279) this would imply left biceps brachii (Q66526951) is a chiral muscle organ type (Q125984341).
I don't think so. How do you come with this conclusion ? "Transitive over" just means that if O is an instance of A and A is a subclass of B then O is an instance of B.
But if A is an instance of Meta, and B is a subclass of A … then this rule does not apply. It would apply if Meta was a subclass of some other metaclass. author TomT0m / talk page19:38, 19 May 2024 (UTC)[reply]
I've encountered many instances of machine learning (Q2539). I think that's inconsistent because there is no meaning in saying that something is a "machine learning". Si I've started to explore the several cases using the following query :
#title: List of instances SELECT?item?itemLabel?itemDescription?instance?instanceLabelWHERE{SERVICEwikibase:label{bd:serviceParamwikibase:language"[AUTO_LANGUAGE],en".}wd:Q2539^(wdt:P279*)?instance.?itemwdt:P31?instance.}LIMIT1000
⟩ has mode/has part Search ⟨ <airplane> ⟩
and water-based aircraft (Q20035742) 
