@Peter F. Patel-Schneider Hi Peter, I commented on the talk page, I proposed a way to do the exact same thing just with the current properties. I think it's not worth the effort to require new tooling. Did you see it ? If this is the case, do you agree and can we close the topic (it's been a few month now, maybe you just did not see the comment) author TomT0m / talk page10:23, 21 March 2024 (UTC)[reply]
Allow false claims due to storage space limitations and a claimed need to be pragmatic[edit]
Example: Talk:Q1402057 , a user seems to suggest to conflate a publication (identified by ISSN) and an organisation (identified by ISNI).
The user is aware of the disctinctions, claims it to be subtle: "The newspaper vs the organization can be a subtle distinction, yes, but it's important to consider that Wikidata's storage space is limited and that we need to be pragmatic re: the usefulness and maintainability of different items." CV213 (talk) 15:31, 3 March 2024 (UTC)[reply]
What is the point here?
There are indeed technical limitations that make a substantial growth of Wikidata based on today's size impossible. The Query Service operates in a difficult condition for years meanwhile, with no clear solution on the horizon. The reason is that graph databases do not scale particularly well horizontally, so all of Wikidata needs to fit into memory of a single machine for the Query Service.
The point here is that someone insists on having false claims stored in Wikidata items. Real word entities form the domains:
publication (identified by ISSN) and
organisation (identified by ISNI)
are clearly disjoint, but user insists on conflating them into one item. @Epìdosis: admin help desired, while discussion is ongoing, the pro-conflation user merged the items. CV213 (talk) 21:25, 3 March 2024 (UTC)[reply]
Currently uchiwa (Q1056134) has a disjointness violation due to widget (Q2467478) which a commercial concept, it's both a concrete and an abstract object.
The issue seems to be that a "widget" is a subclass of unit, so an abstract object, concept used in accounting. Maybe it should be an instance of unit ? author TomT0m / talk page10:28, 21 March 2024 (UTC)[reply]
this edit made by @Swpb last year makes a painting … a mathematical object (see this query (generated by the classification gadget for class disjointness violation visualisation)
The analysis is obvious, the "2D object" is intended as "2D mathematical object", so a painting is not. This makes the painting both an abstract and a concrete object. "Painting" should be a subclass of "flat object" or something like that.
We might have a class "2D object", superclass of both "2D mathematical object" and "flat object", but more generally pictures can have both a representation as an abstract object like a computer file and/or a concrete pictural physical medium. It's questionable that they are mathematical object by themselves even if they were conceived as a digital artwork ? author TomT0m / talk page16:40, 26 March 2024 (UTC)[reply]
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]
⟩ has mode/has part Search ⟨ <airplane> ⟩
and water-based aircraft (Q20035742) 
