# Help talk:Basic membership properties

Active discussions

## Instance vs class

How to differ one from another? It's the main question before applying this table. For example, which relation between letter A and Latin alphabet? It seems that Alphabet and Writing system are both classes but relation "subclass of" seems inappropriate. Infovarius (talk) 07:39, 28 March 2013 (UTC)

Hi Stevenliuyi, your table is a bright synthesis, and I think that when the ontology is stabilized, we should add it to help pages. But I agree with Infovarius. Unfortunately, I think that the difference between instance and class concepts, imported from software world is not so clear in the real world, which is a continuum. Some items are clearly instances, some items are clearly classes, and some others are... in the middle. Therefore, I'm afraid that the necessity to distinguish instances and classes introduced by instance of and subclass of will cause many endless discussions with an unclear benefit (but I could be wrong, wikidata is a kind of model of the real world, so we will always have some annoying items that cannot be well captured by a given ontology...) --Gloumouth1 (talk) 08:40, 28 March 2013 (UTC)
The distinction between instance and class is imported from W3C recommendations for the Semantic Web -- the rdf:type and rdfs:subClassOf properties. It's also an important distinction in philosophy, and knowledge representation languages used in AI like CycL. While the difference often isn't made in everyday English and some cases aren't obvious, I think the added expressivity this distinction affords and its fundamental status in the Semantic Web and knowledge representation indicates that it would make sense to use in Wikidata. Emw (talk) 12:34, 28 March 2013 (UTC)
Ok. I changed my mind. I tried "instance of" and "sub class of" on several examples in the past days, and the difference is quite clear (at least on my examples). --Gloumouth1 (talk) 18:33, 1 April 2013 (UTC)

If I understand things correctly, the conceptual difference is rather clear cut: classes define the traits that all its instances have, but do not have them themselves (they are sest, not elements). In theoretical terms, they are really different things and they can be no continuum. To take a concrete example:

case 1: Assume that:

• A mammal is an animal that lactates

And:

• individual homo sapiens lactate

Then:

• homo sapiens in general is a sub-class of mammals. Individual homo sapiens are instances of mammals

case 2:

• A species is a set of individuals that can interbreed with each other, but not with individuals from other species

And:

• all individual homo sapiens can interbreed, but cannot interbreed with individuals from other species

Then:

• homo sapiens in an instance of species, individual homo sapiens are not

However, one big question remains: how well does it work when classes are not neatly defined ? My definitions of mammal and species are clearly lousy and could be substantially improved, but I am not sure we can find anything that would achieve perfect logical consistency. --Zolo (talk) 09:20, 28 March 2013 (UTC)

Zolo, Homo sapiens is a taxon that has a taxonomic rank of species. An individual person is an instance of Homo sapiens, so Homo sapiens is a class, not an instance. That means the third point in case 2 above is incorrect. See the X and Y columns of 'instance of' in Help:Basic_membership_properties; see also the 'domain' and 'range' of 'instance of' on the P31 talk page. Emw (talk) 04:40, 18 April 2013 (UTC)
Yes, Homo sapiens can be considered as a class, with instances being particular humans. It can also be considered as an instance, of the classes species and taxon. There are lots of examples of instance relationships were the instance is a class. This goes against the advice on this page, which I think should be changed, if only because it does not correspond to current usage in Wikidata. Peter F. Patel-Schneider (talk) 22:56, 21 October 2015 (UTC)

The practical difference between an 'instance' and a 'class' is that we can generally make lots of statements about an instance but not so many about a class - often all we can say is that it is a 'subclass of'. The big grey area is mass produced items - books, albums, cars, software programs. There are usually lots of statements we can make about these - launch dates, size, author, publisher. In practice we are treating each type/design/model/edition as an 'instance' of a an album/book/car/etc. even though we may also have an item related to one particular exemplar as well e.g. the Lincoln Bible (Q1816474). Filceolaire (talk) 17:14, 5 December 2013 (UTC)

As an individual, a class can have more properties than you might consider for classes. For example, Homo sapiens is an instance of species and thus has a scientific name, a history, etc. Even as a class there can be lots of things one might want to say about Homo sapiens, such as aggregate information about its instances, which here would include things like average life span in years. Peter F. Patel-Schneider (talk) 22:56, 21 October 2015 (UTC)

It's very confusing the way the distinction is used. I know coding and you never need to think "Is it my class or my Instance?? It's clear what you are using... Here it makes everything blurry. I've found another example:

That doesn't make any sense. Maybe the property made sens at first but it is so badly used than it loses all its potential.Linuxo (talk) 14:31, 5 January 2019 (UTC)

@Linuxo: There are many things needing to be cleaned up within the Wikidata ontology - medical conditions is probably a prime area. While the relations can be very straightforward for ordinary physical entities like buildings and people and places and organizations, they get quite confusing to people with regard to abstract concepts. Please join Wikidata:WikiProject Ontology and help us improve things! ArthurPSmith (talk) 15:45, 7 January 2019 (UTC)
added to the list! ;) Linuxo (talk) 16:50, 7 January 2019 (UTC)
@Linuxo: There are more concrete examples of items that are instances and classes. E.g., Honda Civic (Q216747) is a subclass of some types of car, basically a set of cars, and it's also an instance of "automobile model". accountant (Q326653) is an instance of a profession, but it's also a set of professions since there subsets (specialisations) like auditor (Q10949665). Ghouston (talk) 01:23, 8 January 2019 (UTC)
@Ghouston: Do we need to continue this discussion on https://www.wikidata.org/wiki/Wikidata:WikiProject_Ontology as

@ArthurPSmith: suggested? (But I don't know exactly where...)Linuxo (talk) 03:44, 8 January 2019 (UTC)

Not really from my point of view, because I see why items can be both instances and classes. I'm not sure that it causes any problem. Ghouston (talk) 03:50, 8 January 2019 (UTC)
See User:TomT0m/Classification on this, that I’d like to be accepted as a help page. author talk page 11:22, 8 January 2019 (UTC)
It seems to me that by "class" in Wikidata, the usual meaning is "set". There's no inheritance of properties like you find in a programming language class system. When an item is only an "instance" anything, it represents a single thing. When it's a "subclass" of anything, it represents a set of things. By "subclass" we then mean "subset". Ghouston (talk) 20:28, 8 January 2019 (UTC)
Although, mathematics does also have the concept of class, as well as conglomerate and category. I don't understand the distinctions, and have no idea if Wikidata subclassing relates to any formal definition. Ghouston (talk) 00:37, 9 January 2019 (UTC)
It does get a bit crazy, since I'd see a ship as a collection of ship parts, so ship would be a subclass of <ship part>, and an individual ship is also a collection of ship parts, so a subclass of ship. All physical objects would be subclasses from the idea that they are not just single items, but collections of fundamental particles. Perhaps there's some better way of looking at it. Ghouston (talk) 01:46, 9 January 2019 (UTC)
This occurs in no definition of « class ». We can build a class of all components of a ship if we want. It could be named « components of the USS Alabama ». This is not to be identical to the ship itself. We would have for example « bow of the USS Alabama » instance of « component of the USS Alabama ». The right property to link a component of an object to the object itself is « part of » : « bow of the USS Alabama » part of « USS Alabama ». More generally, both a ship and its components are physical objects. It does not make sense for a physical object to be an instance or a subclass of another physical object. A class is something more conceptual, which has a definition which allows to tell if something is an instance of this class or not. For example for the class « component of the USS Alabama » could have the definition « physical object that is a part of the USS Alabama ». The « USS Alabama » itself is not itself such a definition, it fits into some of these definitions (for example it fits into the « boat » or « vehicle » definitions). author talk page 12:15, 9 January 2019 (UTC)
Yes, we can accept that a ship is more than just the sum of its parts (since the same parts lying around in a factory wouldn't count as a ship). Ghouston (talk) 00:36, 10 January 2019 (UTC)
Yes, I'd agree that 'set' does not really capture the meaning of "class". We definitely need some improvement in our explanatory pages on all this, but I think the underlying modeling patterns, where used correctly, are clear enough, and we have at least a few areas where it has been done well (for example the instance/subclass hierarchy for Enola Gay (Q204424) where you'll see both instance of (P31) and subclass of (P279) statements in the hierarchy that (mostly?) make sense). In VERY general terms, saying that a class (which is abstract or has instances) is an "instance" of something else makes that something else a metaclass, and metaclasses need to be treated with caution. Most of the time the relationship should be subclass, not instance (at the abstract/class level). ArthurPSmith (talk) 17:11, 9 January 2019 (UTC)
However, I would point out there are several areas of disagreement in class modeling in Wikidata:
1. Real humans are always treated as instance of human (Q5) (no subclasses used) - this may be something that should be done more generally; it seems to work well in that case.
2. In some cases (for example the cabinets of federal governments in various countries) instance is reserved for that body at a point in time or in a limited range of time, and the body in general is designated as a class. This (time-based instantiation) feels wrong to me, but it is arguably a valid way to do things.
So - it can be complicated even for what seem like simple cases... ArthurPSmith (talk) 17:17, 9 January 2019 (UTC)
P31=only Q5 makes problematic to do most queries for humans now - they are timed out... --Infovarius (talk) 13:41, 10 January 2019 (UTC)

## Issues preventing move to more prominent location?

This document is very helpful in clarifying the nature of the basic membership properties, but noone knows about it. Others and I find ourselves having to repeatedly point it out to folks who are unfamiliar with these properties. Are there specific issues that need to be addressed with this document before it is moved to a more prominent location, e.g. a page in the 'Help' namespace linked from 'Proposed' in Wikidata:List_of_policies_and_guidelines? Emw (talk) 17:26, 31 March 2013 (UTC)

I hoped that people could find errors and offer suggestions before we move it to Help namespace, so we can make sure the document is not misleading. Now it seems very few people notice the document, so I'm ok with making it public if no one opposes. But I hope at least someone can check my grammar first since English isn't my native language. --Stevenliuyi (talk) 19:21, 31 March 2013 (UTC)
I'll do a quick check. Emw (talk) 19:23, 31 March 2013 (UTC)
I've reviewed the document and I think the grammar looks good. I wouldn't be opposed to making this public. Thanks, Emw (talk) 19:55, 31 March 2013 (UTC)
Done Thanks a lot. I have moved it to Help namespace. If there are objections, I can move it back. --Stevenliuyi (talk) 16:43, 1 April 2013 (UTC)

Can we hide this somewhere .. it might scare people away. --  Docu  at 10:49, 27 April 2013 (UTC)

If this page corresponds to Wikidata community consensus, then I think it deserves a link from Help:Contents. Is there any reason that there is no such link? Peter F. Patel-Schneider (talk) 11:38, 19 October 2015 (UTC)

Decision making is hard on WIkidata, please see Help:Basic_membership_properties. author talk page 12:47, 19 October 2015 (UTC)
It appears to me that decision-making is too easy on Wikidata. Decisions are made all over the place, e.g., how to represent diseases. What seems to be difficult is to come up with general principles and good practices, even if these principles and practices can be overridden. A related problem is the lack of information on what decisions have been made, e.g., how diseases are represented. I expected much more information, and very much more information that can be easily found, in keeping with what I think are the open principles underlying Wikidata. Peter F. Patel-Schneider (talk) 17:10, 20 October 2015 (UTC)
@Peter F. Patel-Schneider: I'll be hard, but although you're right that we lack central decisions for big principles, it's still hard to take decisions on WIkidata. The central and almost only point of real decision making is property proposals, which is made property by property. This is too low level as a consistent model involves serveral properties and classes, creating one property is hard and properties can, for some on them, stay in discussion for months if not years with no clear outcome. So decision making IS hard. And inefficient. So we valued properties with some generalities, but properties with a little gernerality needs good guidelines, and that's where the problem is : the guidelines are somewhat arbitrary and decided by a few people more or less arbitrary. Sometime if a Wikidatian is not happy with a decision taken he will propose a property to do things another way, and sometimes it will work, so we can sometime arrive to a situation where a direction have been chosen and that some other people will try hard to go on another direction, even if it's a bad one. The easiest way to take consistent decisions is to create a WikiProject dedicated to some kind of datas, take the decisions in a small group and people and be sure that you will be enough for the property you want to support your solution. With the drawback that, of course, as we don't have global project guidelines you will be inconsistent with other parts of the project. author talk page 20:47, 20 October 2015 (UTC)

## showing the two way pairs

If we are meant to be linking up and down, and in the end I have worked out that I should be using "subclass of" as per the obverse of this page. BUT I am now uncertain what I should be using to link down. It would be great if we could show the pairs on a page like this, and on the respective talk pages. So on subclass of it shows the reverse link to use.  — billinghurst sDrewth 03:01, 4 April 2013 (UTC)

I think 'has instance', 'has subclass' and 'has part' would be the most intuitive and conventional names for inverse properties of 'instance of', 'subclass of' and 'part of'. That said, having those inverse properties could make certain important items very unwieldy. For example, hundreds of thousands of items will presumably have something like a single 'instance of person' claim, which would mean the single 'person' item would have hundreds of thousands of 'has instance' claims. Similar performance-related issues are warned about in the W3C's document on part-whole relations -- see the blockquote in Property_talk:P361#Neutrons for the full note about 'has part'.
I imagine the 'subclass of' property would be the most promising candidate to have a performant inverse property, since I can't think of when there would be a huge number of items directly linking to one single other item via 'subclass of'. The fact that the Apache Jena OWL reasoner provides a 'hasSubclass()' method might indicate that a 'has subclass' property is feasible. Emw (talk) 03:32, 4 April 2013 (UTC)
My thinking is that for some terms there are a known and often prescribed subset of items, so maybe that is the trigger that we are looking for where we are talking a linear line within items, not the intersect with terms and people or locations. Ideally I would like to go to one item and add the required of subclass items, whereas I have to go to each item and say "subclass of". Now we can check by looking at WhatLinksHere but that is a technological means, rather than a clear logic of what should be a two way action. An example for the Order of Australia there are six classes of award which can be defined as static number. Now maybe there is no need for a top down approach, however, bottom up can be so tiresome compared to top down.  — billinghurst sDrewth 12:08, 4 April 2013 (UTC)

## Proposition of definition

For "instance of" I proposed the next definition: is an "instance of" an element which can not be subdivided into two or more other elements. So quark is an "instance of" and not a subclass because quark can not be sudivided into other subparticule. Doing the difference between individual quark and quark is a non-sense for classification because you will no additional properties for individual quark compared to quark. Fido the dog can be put in the middle of other dogs of the same specie and you will be able to find it even if you close your eyes during ten seconds because Fido has some individual characteristics but if you are doing the same with a quark you named Q, put it in middle of other quarks, close your eyes, you will never be able to find it again because quark has no individual characteristics (position and age are not characteristics because at the same place you can have different quarks at different times and time has no effect on quarks so age is useless to describe quarks). So the definition of "instance of" has to deal with properties definition and not with imaginable ways of distinguish elements: an element which is defined with maximum set of properties according to its nature is an "instance of".Snipre (talk) 08:53, 16 April 2013 (UTC)

I disagree. The difference between a class and an instance is fundamentally the difference between a type and a token; see type-token distinction, the Stanford Encyclopedia of Philosophy (SEP) article on Types and Tokens, etc. The simple difference between an instance and a class is that an instance has a unique location in space and time, while a class does not.
We should not muddle the difference between an instance and a class merely because instances of a subject (like quarks, or chemical compounds) will never have Wikidata items about them. In other words, the fact that Wikidata will never have an item about a single ethanol molecule with a unique location in space and time (say, a particular molecule of ethanol in an alcoholic beverage) does not mean we should say that the Wikidata item ethanol is about an instance. Section 2.3 of that SEP article -- Science and Everyday Discourse -- is relevant here; things like 'ethanol' are virtually always spoken of as types (classes), not tokens (instances). The Wikipedia article Ethanol is clearly about a type (i.e. class) of chemical compound, not an instance of a chemical compound. The current description of that Wikidata item even says ethanol is a "type of alcohol compound".
The proposed heuristic for determining whether something is a class an instance is where Snipre's suggestion falls apart. From Snipre's original post (emphasis mine):

" Fido the dog can be put in the middle of other dogs of the same specie and you will be able to find it even if you close your eyes during ten seconds because Fido has some individual characteristics but if you are doing the same with a quark you named Q, put it in middle of other quarks, close your eyes, you will never be able to find it again because quark has no individual characteristics (position and age are not characteristics because at the same place you can have different quarks at different times and time has no effect on quarks so age is useless to describe quarks)."

The central argument is the bolded statement. Figures of speech and exotic physics aside, the argument is that it is ontologically impossible to distinguish between individual quarks. Of course, this is false: the quark Q in the thought experiment has a unique time and location, and thus a being whose faculties are so sharpened that he can follow every molecule in its course could indeed find quark Q again. So quarks can indeed be instances, just like chemical compounds and other such things.
The crux of the disagreement is whether Wikidata items about things that are identical copies of each other -- like quarks, chemical compounds, etc. -- should be classified as "instances". Saying such things are instances not only contradicts straightforward conventions in philosophy as explained above, it also contradicts large ontologies like ChEBI, the largest database of small chemical compounds that uses Semantic Web properties. ChEBI uses subclass of (rdfs:subClassOf) and not instance of (rdf:type) to classify compounds like ethanol, ethylamine, etc. (If you're interested and your computer can handle opening a ~137 MB file in a browser, then you can see for yourself in http://www.berkeleybop.org/ontologies/obo-all/chebi/chebi.owl.) Emw (talk) 01:17, 17 April 2013 (UTC)
The problem is that you consider position and time as characterics of the element and this is not true: even for Fido, if you consider that position and time are characteristic from that dog, you will have an infinity of instances for Fido, each instance defiend by the characteristics of Fido plus its position and the time. If we take again the case of quark or ethanol by considering that position and time are not characteristic of those elements the distinction between one individual quark and quark concept is completly arbitrary in term of science. It is why I don't like the definition you propose because it is a mental construction which is not taking account of the physical reality especially when considering elements without individual characteristics. A classification has to rely to properties and you can create new classes and subclasses if you have properties allowing to distinguish the elements. Now the question is to know if position and time are properties of the element: for me no, that's only temporary properties allowing an temporary identification or in order words allowing a localization but not given any information about the essence/nature of the element. Again for the Fido example, it is not the position or the time which define Fido as Fido in the middle of other dogs but the property "dog name" and perhaps other properties like "weight".
And concerning wikipedia type or ChEBI classification don't compare what is not comparable: wikipedia and ChEBI don't have a corresponding concept like "instance of" in their classification. So saying that we should rely on those classifications is wrong as we are using a larger classification scheme: perhaps if ChEBI and wikipedia were considering "instance of" their classification will be different. Snipre (talk) 10:13, 17 April 2013 (UTC)
• As I understand it, instance/subclass only means element/set. If that is so, the difference is rather straightforward:
• Q6732 means "the set of all up quarks", just like Q144 means "the set of all dogs."
• "particle with a bare mass of 1.5–3.3 MeV/c2" refers to individual up quarks, like "animal that barks" refers to individual dogs. That is not the sum of the masses of all up quarks.
• if "up quark" means the the set of all particles with a bare mass of 1.5–3.3 MeV/c2, then up quark is clearly a subset (= a subclass) of particles.
But that raises a question: how do we know that "is species" refers to dogs as a set but "barks" to elemental dogs ? --Zolo (talk) 11:14, 17 April 2013 (UTC)
• Better use the porperties to define what is an instance or a class: if an element A has all properties of element B, element A is an instance of element B and B is a class, if element A has exactly the same properties of element B, element A is equal to element B and one of these two elements has to be deleted. If an element is at the same time an instance of and a class, this can be defined as a subclass. Then no question no conceptual thinking: a very simple system which can be handled by bots if necessary. Snipre (talk) 18:15, 17 April 2013 (UTC)
Support I tend to agree. This is a simple proposition, and avoids philosophical problems, I think I made similar statements on the french project page. TomT0m (talk) 13:13, 18 April 2013 (UTC)
I assure you that the proposed definition creates more philosophical problems than it solves. The criterion for a good property should not be that it enables some ho-hum PropertyAdderBot to classify items with greater convenience, while muddling the meaning of items and the expressivity of properties. Instead, we should be aiming to design properties that enable bots like Watson to intelligently reason about the information on Wikipedia. The "simple system" of the proposed definition optimizes Wikidata for PropertyAdderBot. The existing definition optimizes Wikidata for Watson-like systems, and does so in a way that, really, is not rocket science. Emw (talk) 02:59, 19 April 2013 (UTC)
• Zolo, the difference between 'instance' and 'class' is rooted in type-token distinction, which is based in ontology, not set theory. Instance = token and class = type; thus an instance is a physical object, and a class is an abstract object. Set theory has some good models of types, but moving beyond superficial comparisons between set theory and ontology vocabulary strains both. For example, if classes are sets and instances are elements, then what are parts? Emw (talk) 02:42, 18 April 2013 (UTC)
• Snipre, do you agree with statements A and B below?
A) "Ethanol" can refer to a particular molecule of ethanol; say, a specific molecule of ethanol among many other molecules of ethanol floating in a cup on a table
B) "Ethanol" can refer to all of the molecules in the cup referred to in A, and all other molecules with that exact chemical composition, wherever they may exist in space and time
Statement A refers to an instance of ethanol; statement B refers to the class ethanol. Wikidata concerns ethanol in the sense that statement B does, not statement A; thus the Wikidata item about ethanol is about a class and not an instance.
The idea that Fido could hypothetically have many, many values for hypothetical "location in space" and "location in time" properties is true: one could imagine updating information on Fido's location at many different times. But that doesn't support your argument; it doesn't mean a hypothetical "location in space and time" property is not a valid characteristic for Fido. The difference between the Wikidata items Fido and ethanol is that the 'Fido' item is concerned with the Wikidata item that could possibly have values for a "location at a time X" property, while 'ethanol' would not.
In other words, even if a "location at a time X" property did exist, it would never be applicable to the Wikidata item about ethanol (Q153). That's because the Wikidata item about ethanol is concerned about ethanol as a class (as in statement B above) and not an instance (as in statement A above). We write about ethanol as a concept (i.e. a class) that can have physical instances, like that molecule in a cup. But we don't write about any particular instance of ethanol.
The idea that an instance (i.e. token) is defined as a thing with a unique location in space and time is based on straightforward philosophical conventions explained in type-token distinction and the Stanford Encyclopedia of Philosophy article Types and Tokens. This distinction between instance and class, which is the difference between token and type, is fundamental in ontology and thus important for Wikidata. Conflating instance and class as you propose leads to claims like "the distinction between one individual quark and quark concept is completely arbitrary in terms of science", which is clearly false and rather bizarre. Emw (talk) 04:19, 18 April 2013 (UTC)
If "boat" is defined as "the set of all things designed by humans to float", then parts of boats are not elements of the set "boat". I can sort of imagine that it makes practical sense to make things different from set / element, but this is not totally clear to me. Is "1" a subclass of "real number" ? Does that mean that properties about the set of real numbers should be in a different item from properties about individual real numbers ? That seems to obscure the hierarchy. --Zolo (talk) 07:01, 18 April 2013 (UTC)
Right, 1 is a class, not an instance, because that item concerns "1" as a concept and not any particular instance or occurrence of "1". The properties of the set of real numbers would be defined in real number, and inherited by its subclasses (which includes 'natural number' and '1'). Considering another example, we would say 'heart' part of 'vertebrate', then all 'vertebrate' subclasses (e.g. 'mammal', 'human') and instances (e.g. 'Ernest Shackleton', 'Fido') would be said to have a heart. If all subclasses and instances of 'vertebrate' had to each list all the properties of vertebrate, that would be very redundant and increase maintenance costs and needed storage size, etc. immensely. So defining properties at the highest appropriate class level like that doesn't obscure the hierarchy, it makes the hierarchy -- the ontology -- clean and manageable. Emw (talk) 12:15, 18 April 2013 (UTC)
I have to say I have troubles understanding how that can work:
• Not all properties of the set of real numbers should be inherited by its subsets (clearly not the cardinality, for instance).
• If 1 and 3 are subclasses, not instances of prime numbers, how are we going to know that a list of primes should be "2, 3, 5" rather than "super-prime, Fermat prime, factorial prime" ? --Zolo (talk) 12:47, 18 April 2013 (UTC)
Zolo, those are interesting questions. Addressing them in order:
1. "Not all properties of the set of real numbers should be inherited by its subsets (clearly not the cardinality, for instance)."
I would assert that assigning things like "cardinality" (i.e. "item count") as properties is bad idea. Determining the cardinality of a set -- in more familiar terms, the number of Wikidata items that are instances or subclasses of a given Wikidata item that represents a class -- should be done through queries, not properties.
I think you did not understood his problem. Any set, in math, like ${\displaystyle \mathbb {N} }$ , the set of en:Natural number, as a property, its cardinality. The cardinality of N is en:Aleph_number:Aleph Null. It is not at all the number od results of a query in this question. Now given that N is a set, if "1" is a subclass of N, given that its should inherit its properties should be the same, so en:Aleph_number:Aleph Null, which does not make sense (even if the integer definition in set theory in which numbers are also defined by set, the cardinality of 1 (as a number, not a a token) is definitely not infinite, it is 1. TomT0m (talk) 10:31, 19 April 2013 (UTC)
2. "If 1 and 3 are subclasses, not instances of prime numbers, how are we going to know that a list of primes should be "2, 3, 5" rather than "super-prime, Fermat prime, factorial prime"
Because "2, 3, 5, ..." would be the only Wikidata items that are subclasses of primes that do not themselves have subclasses. The Wikidata items 'super-prime', 'Fermat prime' and 'factorial prime' would be subclasses of primes, and numbers like "2" would be a subclasses of some subclass of primes.
It seems like one of the underlying problems folks have with the distinction between 'instance of' and 'subclass of' is that 'subclass of' can be used on an item that does not have instances. Instances are not simply leaf nodes the bottom of the tree of knowledge; those leaf nodes can be either instances or classes. The difference between an instance and a class is the difference between a token and a type. Please scan through that article if you haven't already. Does that article or the explanation above clarify anything? Emw (talk) 02:01, 19 April 2013 (UTC)
That is assuming that we have items about everything. For empirical topics, that does not seem very realistic - we will not estimate how many lions live in the wild just by counting items that are instances of lions. For mathematical topics, it is logically impossible. The set of real numbers is uncountable; it is an important fact, and one that cannot be computed from the properties of its subsets.
I have read the Stanford Encyclopedia of Philosophy article. It sorts of explains why tokens are not the same as elements of a set, but I am not really clear why the former is a better fit to Wikidata's needs. --Zolo (talk) 06:19, 19 April 2013 (UTC)
Zolo, the problem you outline above seems to be that certain properties describe classes, but do not directly describe instances. However, I think this problem occurs both with the proposed definition of instances (where quark is an instance and a class) and the existing definition of quark (where quark is only a class, and not an instance), as well as the third definition of instances as simply elements in a set. In other words, I think this problem is legitimate but independent of the question at hand. Emw (talk) 03:59, 24 April 2013 (UTC)
Yes, actually, that seems to be a very common case. Is there any way to solve it ? --Zolo (talk) 10:45, 27 April 2013 (UTC)
@EMW Do we agree on that : Ethanol (as a concept) is both a type and an instance of something that is more abstract : Molecule types. Any molecule type have a chemical formula for example, ethanol has a defined formula so we can give a value to this property in the case of ethanol. Any ethanol molecule example shares it formula with the ethanol molecule type, but have more properties (a temperature for example). We know that ethanol molecule instances will have a numeric temperature instanciated, but for the molecule type we just know that its instances will have a temperature. By contrast we know that any molecule type will have a fusion temperature. Ethanol has a number which describe this temperature. Any ethanol molecule will be, or not, in fusion state. So in my opinion Ethanol is both an instance and a type. TomT0m (talk) 13:30, 18 April 2013 (UTC)
TomT0m, no, I don't agree; in the statement "ethanol as a concept is both a type and an instance", the assertion that "ethanol as a concept is an instance" contradicts important, straightforward philosophical conventions explained in type-token distinction and the Stanford Encyclopedia of Philosophy article Types and Tokens. Have you read any of those explanations? If not, please do, and then explain to me how a concept -- i.e. a type, an abstract object, a class -- can be an instance, i.e. a token. Emw (talk) 01:13, 19 April 2013 (UTC)
If I understand your view, as a thing there is the set of all molecules in the world, which are of type molecule, ethanol is a subtype of molecule for whose instances are all of concrete ethanol molecules. There is a problem here : there is no ethanol instances item on Wikidata at all, so absolutely no instances ... The concept which are important, for which we have datax, infoboxes and item & co, is the concept of molecule types. The characteristics, properties we will have are attached to molecule types item. The structure of these items, which is the main purpose of a type in computer science for exemple, is to describe the structure attached to its instances (note that we can iterate on that and define types of types, that is describle the structure of a family of types). So my question to your model will be: how do we define a type for molecules types, which describes that a molecule has a chemical formula, for example ? Do we need to have items for the class of all concrete ethanol molecules and a class for the ethanol molecole description ? TomT0m (talk) 12:21, 23 April 2013 (UTC)
I'll try answering your questions in order. Please let me know if I can clarify or explain anything further.
1. "how do we define a type for molecules types, which describes that a molecule has a chemical formula, for example?"
With ethanol, for example, perhaps we could say "ethanol subclass of alcohol". If we wanted to get more granular, we could say "ethanol subclass of primary alcohol" then "primary alcohol subclass of alcohol", etc. Those classifications all have implications for the subjects' chemical formula. The classifications could possibly import the ChEBI ontology. The graph view in the ChEBI entry for ethanol indicates a neat possible application.
2. "Do we need to have items for the class of all concrete ethanol molecules and a class for the ethanol molecule description?"
Nope, the Wikidata item ethanol (Q153) would represent the class. If we ever wanted to represent a particular instance of ethanol, say a molecule of ethanol in a drink, then that would be a separate Wikidata item (let's call it Qx). That separate item Qx about a particular instance of ethanol -- a token of ethanol -- would be linked to the item about the class ethanol by the 'instance of' (P31) property. The two items could look something like this:
ethanol
a molecule of ethanol in a glass
Clearly, Wikidata will never be concerned about such a particular instance (i.e. token) of ethanol, so by the existing definition of instance Wikidata would not have an item like Qx with an 'instance of ethanol' claim. Saying that ethanol is a class and not an instance doesn't imply there are no such things as instances of ethanol, it merely implies that Wikidata is concerned with ethanol as a concept and not as any one concrete molecule of ethanol. (The same applies to all chemical compounds.)
However, Wikidata is concerned with instances in other domains of knowledge -- e.g. people, towns, planets, galaxies, etc. Things like Donald Knuth, Milwaukee, Earth and the Milky Way are instances not because they are distinguishable from other instances of the same class by properties like "birth day", "state", etc., but because they each have a unique location in space and time -- because they are, ontologically, tokens. Instances in those domains are clearly within the scope of Wikidata. Instances in the domains of chemical compounds (like ethanol) and fundamental particles (like quarks) are clearly outside the scope of Wikidata. That's not to say there is no difference between an ethanol as a concrete molecule of ethanol as a class of molecule: equating the two is clearly incorrect at a fundamental level.
That simple distinction between instances and classes as the difference between tokens and types is important for knowledge representation, and should not take on different meanings depending on whether we are talking about people, cars, chemical compounds or fundamental particles. Emw (talk) 03:07, 24 April 2013 (UTC)
w:Ethanol - disambiguation. № 1 - Ethanol (as "w:State of matter")=w:liquid; № 2 - Ethanol (as "molecule")=molecule; № 3 - Ethanol (as "Color")=colorlessness. And so on. Fractaler (talk) 16:27, 18 April 2013 (UTC)
@Emw: I completely agree with your explanation. --Gloumouth1 (talk) 11:42, 13 May 2013 (UTC)
While I disagree that we claim classes of things are instances of those things, it seems there are some wider related issues to talk about. So here's my very long post about it.
I have taken a look at Types and Tokens and according to it, philosophers claim that a type is either a "set", a "kind" or a "law". A set is a mathematical concept and it is well defined (or rather what you can do with it is). What is a "kind"? The only definition in the article is that it is a "universal", and the article doesn't define what that is. What a "law" is isn't defined at all. So, it seems that if we intend to get any work done, "kind" and "law" are useless and all we're left to work with is set, which is IMO a good thing because the concept of a set is more-or-less widely known (everyone learns mathematics in school), unlike "kind" or "law" which I doubt anyone outside of philosophy has even heard of (in this sense). If anyone can provide a definition of "kind" or "law" we could work with on Wikidata, please do so.
However, we also have to consider the fact that we've aligned the meaning of instance of with rdf:type and subclass of with rdfs:subClassOf. The RDF Schema definition states:

RDF distinguishes between a class and the set of its instances. Associated with each class is a set, called the class extension of the class, which is the set of the instances of the class. Two classes may have the same set of instances but be different classes. [...] It is possible for [two] classes to have exactly the same instances, yet to have different properties.

This is an important clarification as to the relation between classes and sets: the class extension of a class is a set of its instances. This is the set subclass of and instance of operate on. So, operationally, types are sets, tokens are elements of sets, and subtypes and supertypes correspond to subsets and supersets, respectively. Then instance of means set membership, and subclass of means subset of.
Also according to RDFS, a class can be in the extension of another class (even its own), that is a class can be an instance. This is important for metamodeling--there are many cases of data that apply to a class and not to any of its instances. Examples:
• In taxonomy, Animalia is a subclass of Eukaryota, and it is also an instance of the class kingdom. Kingdom is a subclass of taxon, and it is also an instance of the class "taxonomic rank". I am an instance of Animalia, but I am not an instance of kingdom. And facts about taxa (such as who established them and when) have nothing to do with instances of those taxa.
• The set of natural numbers has the cardinality aleph-null. This is not a property of its elements, but of the set as a whole.
• Dragon Slayer is an action RPG; it is a subclass (technically) of the class "action RPG". "Action RPG" is a genre; it is an instance of the class "genre". Saying that "Action RPG" is a subclass of "genre" is wrong because it would mean that Dragon Slayer is a subclass of "genre", which it is not.
Having established the need for metamodeling, we are left with the question of how to do it on Wikidata. Specifically, how do we separate statements that apply to a class from statements that apply to the instances of a class? Presently, I see two practical options.
1. If something is a class, it is represented by one item. The item's statements apply to the class, and not to its instances. Any statement that applies to instances of this class must be stated as a qualifier of the item's "subclass of" statement. For example, let's say there is a hypothetical species of birds called Bluebird. Its item could look like the following:
• subclass of: bird
• color: blue
• established by: Linnaeus
• year: 1750
• The meaning is that all bluebirds are blue, and that the species was established by Linnaeus in 1750. No single bluebird was established by Linnaeus, and the class itself is not blue.
• This option implies the need for a special item that corresponds to rdfs:Resource, or alternatively owl:Thing, which would be the class all other classes would be subclasses of, implicitly or explicitly, and which would not be allowed to have a "subclass of" statement. The need for such an item stems from the fact that classes that are not otherwise defined as being subclasses of any class would need "subclass of" statements to be able to have qualifiers to describe their instances.
• There are some problems with this option, however. If we wanted to express that e.g. any bird of the species Blueandyellowbird is both blue and yellow, we could add two color qualifiers. But what if we wanted to express that any bird of the species Redorblackbird is either red or black (according to a single source)? A possible solution would be to have one "subclass of" statement with the qualifier "color: red", and another for black, with the implicit understanding that the logical connective between the two statements is "exclusive or".
2. If something is a class, it is represented by two items: one whose statements apply to the class, and one whose statements apply to the instances of the class. The class item would point to the instances item via a special property (e.g. has class extension). The previous example in this form would look like the following:
1. Qa - bluebird (class item)
• subclass of: bird
• established by: Linnaeus
• year: 1750
• has class extension: Qb
2. Qb - bluebird (instances item)
• color: blue
• The meaning is the same as in option 1.
• The advantage of this option over option 1 is that we could express logical connectives explicitly. For example, describing Redorblackbird could be done by stating "color: exclusive or" with the qualifiers "color: red" and "color: black", unlike in option 1 where we would have to rely on implicit meaning (and everyone knowing about it). Since Wikidata only supports one level of qualifiers (i.e. it doesn't support qualifiers for qualifiers), this would not be possible in option 1.
• However, even though this option is more expressive than option 1, it isn't ideal either because it can only be used to define relatively simple classes.
Neither of these options is entirely satisfactory. The problem is that defining classes isn't a trivial activity--it requires a formal language with a defined semantics. Wikidata has no such thing--its design seems to be suited only for describing instances. Consequently, attempting to define classes within Wikidata's current design results in meaning that is simply unclear. Take the Bluebird example that has the following item:
• subclass of: bird
• color: blue
This is about as simple a class definition as it gets, and yet this simple example can have six different possible meanings:
1. Some bluebirds, if they have a color, are entirely blue.
• bird and (color only blue) SubClassOf Bluebird
2. Some bluebirds are at least partially blue.
• bird and (color some blue) SubClassOf Bluebird
3. Some bluebirds are entirely blue.
• bird and (color some blue) and (color only blue) SubClassOf Bluebird
4. All bluebirds, if they have a color, are entirely blue.
• Bluebird EquivalentTo bird and (color only blue)
5. All bluebirds are at least partially blue.
• Bluebird EquivalentTo bird and (color some blue)
6. All bluebirds are entirely blue.
• Bluebird EquivalentTo bird and (color some blue) and (color only blue)
Below every English description I've put the corresponding formal description in OWL (Manchester syntax). Briefly, OWL is a formal language that can be used to solve exactly this kind of problem (and it has other nice properties, like supporting inference). Also, don't let the "if they have a color" part confuse you--while it may be silly to think that a bird may not have a color, that's just the specifics of the example--there are other properties and domains where this would be valid. I hope this illustrates the complexity of the problem. If you're not convinced, I've worked out that a similar class, but with two different color statements instead of one, could have at least 18 (eighteen) different meanings (if you're interested in the gory details, see here).
In conclusion, if we're going to go into the business of class definitions, it's obvious Wikidata will need to support a formal language for that. And since reinventing the wheel isn't a good thing, and using existing standards is, this language should probably be OWL. Until then, however, what do we do? Avoid class definitions entirely or support some simple ones with kluges like the ones I've described, or maybe something else?
Silver hr (talk) 19:05, 22 May 2013 (UTC)
I think we should strive to base Wikidata's language on W3C recommendations like OWL wherever possible. To a notable extent, it already is: Wikidata developers have committed to providing a way to export (translate) Wikidata to RDF, and the three basic membership properties described here are derived from W3C documents. By leveraging W3C recommendations like this, Wikidata becomes interoperable with the rest of the Semantic Web.
That said, I'd like to note that, while there are similarities between the two concepts, the ontological concepts of type and token are different from the concepts of set and element from set theory. In other words, while instance of (P31) and subclass of (P279) are similar to 'element of' (${\displaystyle \in }$ ) and 'subset of' (${\displaystyle \subset }$ ), they are not directly equivalent with those set theory relationships. For P31, the domain is 'instance' (token) and the range is 'class' (type). The domain of P31 does not include classes. In set theory, the domain of 'element of' can be either a set or some other mathematical object, like an integer. If we assume that classes are sets and instances are non-set elements, then the mismatch between P31 and ${\displaystyle \in }$  is clear.
The author of the Types and Tokens SEP article -- philosopher Linda Wetzel -- writes more extensively on the subject in Types and Tokens: On Abstract Objects (ISBN-13: 978-0262013017). On page 141 of that book, Wetzel concludes a discussion of whether to define types as sets by saying that "a type is not a set (although good models of types can be found in set theory)." Serious problems with the construal of types as sets are also given in the SEP article (see Section 4.1.1, 'A Set'). Given those explanations, I still find Wetzel's definition of types (classes) as abstract objects and tokens (instances) as spatio-temporal particulars to be the most compelling. Emw (talk) 04:02, 30 May 2013 (UTC)
First of all, congratulations on reading all that :). And I'm glad we're in agreement on the matter of following W3C recommendations, particularly OWL. However, it seems you didn't take some of my arguments into consideration. As I wrote, we've aligned the meaning of instance of with rdf:type and subclass of with rdfs:subClassOf. And according to RDFS, the extension of a class is a set. Instances of the class are elements of that set. A class can have another class in its extension.
Even supposing we haven't already aligned P31 and P279 with RDFS, we'd still need a clear formal definition of the concepts of "type" and "token" and the operations defined on them (which is something the concept of "set" provides). The definitions in the article, if you can call them that, are fuzzy and vague--that may be enough for the purposes of philosophy, but it's not enough for the purposes of formal ontology building, which I believe is what we're doing on Wikidata. I'll admit I'm not versed in philosophical literature so perhaps I'm just missing something. Is there a formal definition in the book you mention? If so, please enlighten me. Also, I've stated several examples of things which can be thought of as both classes and instances--how do you propose to model them with types and tokens if you insist that a type cannot be a token as well?
As for the problems you mention which prevent sets from serving as types, I see that the article states two.
1. "many types have no tokens and yet they are different types"
• This is not a problem because, as already mentioned, "RDF distinguishes between a class and the set of its instances. [...] Two classes may have the same set of instances but be different classes.". Since sets can be empty, it follows that two classes may have no instances but be different classes.
2. "sets, or classes, are defined extensionally, in terms of their members"
• This is trivially false. Intensional set definition is widely used in mathematics--for example, {x | x element R and x > 0} (math tag not working, sorry) is the set of all positive real numbers. And also, intensional class definition is used in OWL--one mostly defines classes in OWL by specifying the properties their individuals must have, not by explicit enumeration (although that is possible as well).
Silver hr (talk) 03:44, 31 May 2013 (UTC)
In the statement from the RDF Schema specification you cite -- "RDF distinguishes between a class and the set of its instances" -- the editors establish, like Wetzel does with types, that a class is closely related -- but not equivalent -- to a set. So types and classes are not sets. The extension of a class is a set, as you note.
Wetzel defines several properties for types and tokens in her book Types and Tokens. The key difference between types and tokens is that types are abstract objects and tokens are physical objects. In turn, physical objects are defined by being "concrete", which is shorthand for having a unique location in space in time. Another identity criterion for tokens is that "tokens are not tokens without types" (Types and Tokens, pp. 122-123). She notes: "Being a token is a relational property....The relation is instantiation" (p. 123).
Another key property of both types and tokens that Wetzel establishes is that they can be quantified over. For example, scientific literature is rife with assertions like "some genes encode transcription factors", and "none of the average human's 20-30 trillion red blood cells contains DNA." The first assertion quantifies over a type; the second quantifies over tokens. Of course, both genes and red blood cells can be considered as tokens and types: the average human contains billions and billions of gene tokens (each cell type, with some exceptions, contains two copies of each of those 20,000 genes), and one type of red blood cell. So tokens have two identity criteria: they have a unique spatiotemporal location, and they are instances of a type.
Regarding the SEP article's cited problems with construing types as sets, I think the article's point is that set theory's axiom of extensionality prevents sets from serving as types. Briefly, in set theory, if two sets have the same members, then those two sets are by definition the same set. Two sets cannot have the same members and not be considered equivalent. However, as the W3C specifications note, two classes can have the same members and be considered not equivalent. Construing classes as types and not sets avoids that problem. Emw (talk) 03:10, 21 June 2013 (UTC)
I'm sorry, but I don't think we're making progress here. It would be nice if you could address my points specifically. I'll try to restate them briefly.
1. We've aligned the meaning of instance of with rdf:type and subclass of with rdfs:subClassOf, which you yourself supported or suggested. This alignment implies that, in Wikidata, types are classes and tokens are elements of a class' extension. Since a class can be in a class extension, it follows that a type can also be a token. Since you don't allow for types to be tokens as well, this conflicts with your support of the aforementioned alignment. Can you resolve this conflict?
2. "Type" and "token" are philosophical concepts that are not formally defined. As such, we can not use them to perform operations or inference. Even if we reject rdf:type and rdfs:SubclassOf, how can we use the concepts "type" and "token" if they don't have a formal definition? Can you provide one?
3. You say that tokens must have a unique spatiotemporal location. This implies that abstract things cannot be tokens. Suppose "genre" is a type. "Action RPG" is an abstract concept so it must also be a type. We know that action RPG is a genre so it follows that "action RPG" is a subtype of "genre". But Dragon Slayer is an action RPG. If it is a subtype of "action RPG", then it follows that tokens of "Dragon Slayer" are also tokens of "genre". In other words, the game is a genre. You'll have to agree that this is false--games are not genres. How do you propose to model this situation if you claim that abstract things cannot be tokens?
4. I agree that a simple set of instances cannot serve as a type due to, as you mention, the axiom of extensionality. However, if you consider a type to be a set of the form {id, I}, where id is an identifier of the type among all types and I is the set of the type's tokens, the problem goes away. This is basically how an RDF class functions, I believe. Do you see any problems with this definition?
Silver hr (talk) 20:10, 24 June 2013 (UTC)
@EMW. A philosophical system doesn't mean it can represent the reality. Again as you define an instance by its capacity to be determined in space x and time t, I say yes you can do it once for a molecule. But if you mix it with other molecules and try to find the position at time t+dt you won't be able to find it again. Saying for an instance you can define its position at a time t means you can do it every time you want to show it as an instance. You can present Fido once and you can do it later even if Fido changes its position but you can't do it for a molecule. And this is the consequence of non different and permanent characteristics between one molecule and the whole set of molecules. Your philosophical system is doing something which not possible physically: identifying a molecule and considering it as an individual. So again philosophical systems are not interesting because they needs to be shared by all persons working with it and I proposed to stay with an abstraction level with can be used even by bots or computers without any need of translation: the instance of the lowest level of the classification and contains the maximum of properties used to describe one object. All abstractions above this object are class of or subclass of.
And this applies not in an absolute scale but in an relative scale meaning wikidata defines by the creation of properties the lowest level for the description of an object: even if there are some possibilities to describe an object in some more accurate way, if wikidata doesn't decide to reach that level we don't include these possibilities even if they exists.
Again wikidata doesn't have to manage every possibility, every object in its absolute details: wikidata fixes its own boundaries, its own framework because wikidata is not like a philosophical system which has to handle every thing in its individuality. Finally for a molecule even if you can define its position in a molecule layer or you can calculate a specific energy state for an ideal molecule this is non-sense to include this level of details in wikidata practically and physically. Snipre (talk) 20:24, 3 June 2013 (UTC)
(NB: I consider your comment above to be in reply to my previous comment to you, here, beginning "Snipre, do you agree with statements A and B below?".)
Your point about molecules has been rebutted multiple times, in multiple ways; please refer to my most recent comment to you above for the latest iteration of that. If you have a specific follow-up to one of those points I'll be happy to discuss it, but I prefer to not repeat myself when a rebutted argument is suddenly resurrected after several weeks without speaking to specific points in the most recent discussion.
Again, your proposed definition of "instance" seems to be your personal preference and detached from definitions of "instance" that have been established in knowledge modeling communities for decades. The definitions and usage examples of "instance" and "class" described in this Help page and the respective property talk pages are based on formal logics, and have existing toolchains and very prominent vocabularies that use them. Simply dismissing these precedents as "not applicable to Wikidata" is not an adequate response: these precedents constitute the most reliable sources available for how we define properties.
I have provided numerous external sources for why "instance" is defined as it is. Please provide any external sources that support your definition of "instance". Preferably these would be from people or groups that have some association with knowledgebases that borrow heavily from RDF, like Wikidata. Emw (talk) 03:48, 7 August 2013 (UTC)

After reading the linked W3C documents, I see nothing that indicates that instances should be tokens that are localizable in time and space. And really, I do not see how it would be useful. 3 is an instance of integer. A painting of a 3 is not a "3" and not an instance of integer. It depicts a number, it is not a number. I think it would be much more useful if all items could be considered an instance of something. I have made a proposal for some common types at Help talk:High-level classification. --Zolo (talk) 07:08, 20 June 2013 (UTC)

How about the Great Pyramid of Giza? Does that merely depict a pyramid, or is it an instance of a pyramid? If a subject describes multiple things that have a physical manifestation -- i.e., be localizable in space and time -- then it is a class. For example, the Bible isn't an instance of a book, it's a class of a book. (The Giant Bible of Mainz is an instance of a book -- specifically, an instance of a Bible.)
Similarly, a 1-inch brass "a" and an "a" written on a piece of paper are instances of the class of letter called "a" -- as are paintings of "3" on some canvas an instance of the class of integer called "3". Isn't describing each of the physical representations of "a" and "3" as an "individual" (a term the W3C recommendations often substitute for "instance") instead of a "depiction" preferable? And if we call them "depictions", then wouldn't that conflate the physical manifestations of "a" and "3" with actual depictions of "a" and "3" in, say, a photograph? Emw (talk) 04:24, 7 August 2013 (UTC)
Paintings (glyphs) of "a" are representations of the character (grapheme) "a", which may represent a phoneme /a/. Paintings of "3" are representations of the character "3", which may represent a numerical digit 3 (which exact meaning heavily depends on its position and the base of a used numeral system) -- or may represent something else, e.g. be part of an emoticon. 3-/
Is picture of river an instance of river? No, it's an instance of pictured river. You can't fish there. So, an individual depiction is instance of what it is, not what it depicts. Individual painings are instances of class painting, individual characters are instances of class character, individual numbers are instances of class number. And Great Pyramid of Giza is an instance of class Egyptian pyramids (subclass of building), and loosely resembles an ideal geometric shape of pyramid (subclass of polyhedron). --4th-otaku (talk) 08:20, 30 September 2013 (UTC)
@Zolo: "And really, I do not see how it would be useful"
In order to create instances of events, events should be defined as classes.
E.g. JUMP/ELECTION action in Wikidata.
For some events we would have a Wikipedia articles (elections). d1g (talk) 09:42, 17 May 2017 (UTC)

Sorry for bringing this up again, but I find the quark example really odd. "A single quark" is not even a well-defined object (like a single dog would be), and there will never be articles about instances of <quark>. Why do we confuse readers with an example that cannot be an example? What's wrong with the dog example? Fala is an instance of Dog which is a subclass of Canis. --mfb (talk) 14:50, 13 August 2014 (UTC)

And Dog and Canis are instances of Taxa. The one thing to learn from this long discussion is if you start with "Instance-Class is just like A-B" you can demonstrate whatever A-B you have in mind within good old Linnaean taxonomy but have a hard time transfering it to everyday speech. The distinction between instance and class is deeply embedded in our language and thought processes, and we switch between them all the time. The same thing is instance and class, depending on context. When you point at it with your finger, you make it an instance. When you see the shared idea, you make it a class. Stupid girl (talk) 20:03, 29 September 2014 (UTC)
Agreed. That's why no mathematical definition of these terms is ever going to work. Language is not mathematical. We will never have a perfect pyramid of properties. Our definitions must be based on the common understanding of the meaning of these terms. The best definitions I can think of would be that an 'instance' is an example of something (doesn't have to be a concrete thing), while a subclass is a category of something, in other words a group that shares some characteristic. The relationship between the two terms is fuzzy and sometime we may have a subclass of an instance of a subclass, which is fine. Kaldari (talk) 01:22, 8 October 2014 (UTC)
Kaldari, how then do you define example and category? Alcohol is commonly understood as both a specific example and category of chemical compound, yet the statements "alcohol instance of chemical compound" and "alcohol subclass of chemical compound" are widely held to be incorrect when made together. (This is so even when "subclass of chemical compound" is entailed, e.g. "alcohol subclass of organic compound" and "organic compound subclass of chemical compound", therefore "alcohol subclass of chemical compound.)
Natural language is a mess. I agree that setting the descriptions of instance of (P31) and subclass of (P279) to "A ∈ B" and "A ⊆ B" simply wouldn't work, but it is important to have understandable and formal definitions of these terms if we want to be interoperable with the rest of the Semantic Web and build interesting applications. Emw (talk) 12:00, 8 October 2014 (UTC)
@Emw: What about merging the two into a single property? Then we wouldn't have to worry about sussing out the subtle distinction between them. Kaldari (talk) 21:46, 8 October 2014 (UTC)
Kaldari, having instance of (P31) and subclass of (P279) distinct lets us be much more expressive than having a merged is a property. And it aligns us with key Semantic Web properties defined in W3C standards (rdf:type and rdfs:subClassOf), allowing us to import and export taxonomies and instance layers -- see e.g. wikidata-taxonomy.nt.gz and wikidata-instances.nt.gz in http://tools.wmflabs.org/wikidata-exports/rdf/exports/20140804/. Importantly, it also allows us to more easily plug into an ecosystem of tools, like Protege and semantic reasoning software, which answer novel kinds of queries and have been undergoing optimization predicated upon rdf:type and rdfs:subClassOf for over a decade.
Want a list of all living things? Run a transitive instance of query on organism (Q7239). Want a list of all planets, cars, physical objects? Same, respectively. With only is a available, there is no easy generic way to distinguish between instances of organism like Methuselah (Q590039), Laika (Q53662) and Coco Chanel (Q45661) and classes of organism like Taraxacum (Q30024), Yorkshire Terrier (Q39330) and silvery gibbon (Q663728). All of those things would represent leaf nodes in an is a hierarchy. With instance of and subclass of, queries can account for an essential distinguishing feature in those leaf nodes, among many other benefits. Emw (talk) 12:59, 9 October 2014 (UTC)
@Emw: Thanks for the explanation. I guess there are a lot more things to consider than I originally thought. Mainly, I just hope we avoid implementing definitions that are too artificial and don't align with natural language definitions (even if that means that our data is a bit messy). Kaldari (talk) 06:39, 10 October 2014 (UTC)
@Emw: "an instance and a class is that an instance has a unique location in space and time, while a class does not"
Where it was stated? I don't want to go in details, but:
New Year (Q34812) is a class of events, not single event.
New Year of 2015 is different from New Year of 2016. d1g (talk) 10:10, 17 May 2017 (UTC)

Human rights in North Korea is a subclass of humans rights or an instance of it? And why?

Also, why does Human rights by country or territory exist?--Hienafant (talk) 21:00, 13 November 2019 (UTC)

## Taxon ranks

Perhaps, one could comment here where we discuss if property Property:P361 "part of" should be used to encode the relationship of the taxonomic ranks (like species is part of genus is part of family). FelixReimann (talk) 15:42, 13 May 2013 (UTC)

## P463 (member of)

A page called "membership properties" should probably say a few words about the property member of (P463). Is John Lennon a part of The Beatles or a member of The Beatles? I'm pretty sure we want to use member of (P463) in this case but using part of (P361) wouldn't be unreasonable. Pichpich (talk) 23:05, 24 June 2013 (UTC)

member of (P463) is a subproperty of part of (P361). In other words, if A is a member of B, then A is thus also a part of B. I agree that using member of (P463) instead of part of (P361) is preferable for describing the part-whole relationship of John Lennon and The Beatles, although using part of (P361) wouldn't be incorrect.
The focus of this page seems about right to me: P31, P279 and P361 are basic membership properties. I think their subproperties (like P361's P463) would be best to explain more fully in a separate Help page (linked from this Help page, of course). Emw (talk) 23:56, 24 June 2013 (UTC)
Fair enough. One question though (and sort of beyond the scope of this talk page). When you say member of (P463) is a subproperty of part of (P361), do you mean that
a) you personally believe that it should be understood in that way
or b) it is treated as a subproperty by the database (through some mechanism I'm unaware of)
If the answer is a), this can lead to problems when these properties are translated as the relationship between the two properties could be affected by subtle semantic differences. If the answer is b), I'm happy to confess my ignorance but I want to know how it works! Pichpich (talk) 05:32, 25 June 2013 (UTC)
There is currently no way to recognize sub-properties built in the software, but actually, I have read in a w3c text or something (sorry, cannot find it) that the "subpart" relation is transitive. Given that "member of" is not, I do not think it is really a subproperty of "part of". --Zolo (talk) 07:07, 25 June 2013 (UTC)
ok, thanks for the clarification. Pichpich (talk) 10:20, 25 June 2013 (UTC)

## Draft

This is just an explanation of a concept of the semantic web and not an official data structure selected by the community. I put a draft template in order to avoid misunderstanding. Snipre (talk) 12:59, 6 August 2013 (UTC)

This page describes conventions for instance of (P31), subclass of (P279) and part of (P361) established by many community discussions surrounding those properties, including notably here. It has nothing to do with data structures. The page has not had substantive edits in over four months, and so does not meet the "work in progress" description of the draft template.
The only person to raise significant objections to the content of this Help page has been you -- asserting that quarks should be described as instances in the 'Proposition of definition' discussion above. One other editor agreed with you, but 4 editors (and, presumably, also the author of this Help page) disagreed with you. When considered with the community discussions like this, that 5 to 2 count against your position seems to reinforce the general consensus. So an outside observer could plausibly interpret you marking this Help page as a draft to be a conflict of interest -- you haven't garnered significant support for your point of view through conventional channels of discussion, so you want to construe the content you disagree with as a "work in progress" and "unreliable".
Given that, I propose that the draft template be removed unless someone as-yet uninvolved with the above "Proposition of definition" discussion finds this Help page to be "incomplete and/or unreliable" enough to warrant a draft template. If an outside observer finds a draft template appropriate, then that's fine, but I don't think you're such a person. Emw (talk) 02:56, 7 August 2013 (UTC)

## has part

It might due to have a few words here to talk about the inverse to part of, has part.

Notably, I think its use is appropriate say in LED has part diode. Presumably, a reciprocal used in this fashion would very nicely take care of make sure elements are relevant (odd part of as in the case of diode part of LED) and also for the purposes of inheritence (organic LED has part diode because LED has part diode). --Izno (talk) 05:30, 13 September 2013 (UTC)

Actually, just realized that's a bad example, because that can be represented through a subclass chain. A better one would be nuclear submarine (Q757554) has part (P527) nuclear reactor (Q80877). --Izno (talk) 00:43, 20 September 2013 (UTC)
Another might be brushed DC electric motor (Q588523) has part (P527) brush (Q1713927). --Izno (talk) 00:55, 20 September 2013 (UTC)

## Subclasses of an instance

Is it correct that in all cases where X is a subclass of Y and Y is an instance of Z, that X is an instance of Z? --Yair rand (talk) 20:34, 28 November 2013 (UTC)

Interesting question. It does not follow immediately from the definitions at first sight. It seems OK to state that if Y is a class, then X is also a class. But it does not seems correct in general.
Let's say Y is an instance of a classification system, eg. GND: is any subclass of a GND class also a GND class ? no, we can add our own in Wikidata if we want to. So I'll say it's not correct in general, although we might want to ensure that. TomT0m (talk) 21:09, 28 November 2013 (UTC)
I don't understand. How could something be a subclass of an individual classification system? --Yair rand (talk) 06:08, 2 December 2013 (UTC)
A subclass of a class of some classification system. For example say we want to extend the GND classification system our way, say the <geographical feature> type. Now we want to add a new subclass, say <Geographical feature in which some mammal lives>, it's a subclass of the geographical feature, but it's not a GND class. Hence we cannot say for sure that if <Geographical feature> is an instance of <GND class>, then <Geographical feature in which some mammal lives> is also a GND class. TomT0m (talk) 22:47, 2 December 2013 (UTC)
I'm not sure that really follows. If we have an item for a particular classification system, can we really make something an instance of it? Would <geographical feature> (the GND class) be the same item as <geographical feature> (the actual concept of geographical features)? The latter wouldn't be an instance of <GND class>, and the former wouldn't have <Geographical feature in which some mammal lives> as a subclass, though it might be related via part of. --Yair rand (talk) 23:17, 2 December 2013 (UTC)
They deserves a different items if they have a different definition (the GND one is a good example as its definitions can be somewhat weird). To be clearer our custom type would be<Geographical feature (GND definition) in which some mammal lives>. (<Geographical feature (GND definition) in which some mammal lives> is not a part of <Geographical feature (GND definition)> as its not a composition relation, like wheels are part of a car, but a subset relation). Tag classes with classification systems they are defined in are actually a very good application of the Y is a class and Y is an instance of Z of tour example. TomT0m (talk) 23:55, 2 December 2013 (UTC)
Hm, I was thinking more of a "mayor of New York is a subclass of mayor which is an instance of political position, implying that mayor of New York is an instance of political position"... --Yair rand (talk) 00:05, 3 December 2013 (UTC)
A mayor is not an instance of political position.... Do you have another example? --Izno (talk) 00:11, 3 December 2013 (UTC)
If all mayors were instances of political positions, that would make the relation be "subclass", not "instance". A mayor is not a political position, but mayor is, I think. --Yair rand (talk) 02:16, 3 December 2013 (UTC)
Interesting question. I'd have to say no because of the following example. w:Dragon Slayer (video game) <subclass of> action RPG, action RPG <instance of> genre. Dragon Slayer is a class of physical copies/instances of the game, but it is not a genre.
Another example that comes to mind: Norwegian <subclass of> Scandinavian <subclass of> European <subclass of> Homo Sapiens <subclass of> Homo <subclass of>... Homo Sapiens and the rest of the taxonomic tree are all instances of taxon, but Norwegian, Scandinavian, and European are not, despite being subclasses of Homo Sapiens.
So while it seems that the rule partially applies in the case of taxonomic systems, it doesn't seem to apply in general. Silver hr (talk) 02:59, 6 December 2013 (UTC)

Ok, so lets recap: We got the mayor as a person, a political position, and political mandates. A political mandate is a political position attributed to a person in a certain period of time.

1. In that sense, <mayor of New York> is a political position, defined in a text law. It's an instance of <political position>
2. <Michael Bloomberg> is <mayor of New York>. This means he has been attributed this political position. In that sense, <Mayor of New York> is a set of political mandates, which means it's a subset(class) of all the <political mandates> in the world.

Now lets say we want to classify the political positions. <mayor> is the position of somebody who rules a municipality, there is a lot of municipalities, so it's a class of political position. In that sense, <mayor of new york> is a specific mayor position which entails a set of political mandates.

labels in politics items classification level Political mandate  Political position  types of political position  (from ... to ...) instance of intance of subclass of subclass of

Does that make a little sense ? TomT0m (talk) 19:01, 3 December 2013 (UTC)

## Milky Way

I came here for guidance, but so far found only curious references to points in time and space. The case: Our galaxy the Milky Way is right now both an instance of a barred spiral galaxy and an instance of a galaxy. Should I delete the claim "instance of galaxy" since it follows from "instance of barred spiral galaxy" or not? Should every instance of "barred spiral galaxy" also have a claim "instance of galaxy"? Is there a pragmatic reason in which cases you better claim both? Stupid girl (talk) 20:25, 29 September 2014 (UTC)

I'd go ahead and delete "instance of galaxy" since it's entailed from "instance of barred spiral galaxy". There's no good reason for such redundant claims, whether it's in astronomy or other domains. Emw (talk) 02:34, 30 September 2014 (UTC)

## manifestation of

Since this property has been created to link concepts that do not really exist (works, terms) with what the concept that embodies them (concepts representing physical objects, or events, or perception of information), I am wondering if this property can be used broadly like

.--Micru (talk) 18:56, 17 October 2014 (UTC)

No, I think that C2H50H is not always physical essence but concept of pure chemical arrangement of atoms. --Infovarius (talk) 15:10, 19 October 2014 (UTC)
@Infovarius: you are right, I made an edit to my previous comment to make it more clear. However this chemical arrangement of atoms is detected somehow, and once it has been detected you can add more information about it. "Chemical compound" is a category that manifests once you have detected C2H50H. Or can "chemical compound" be manifested without detecting first something that can be categorized?--Micru (talk) 18:50, 19 October 2014 (UTC)

## Translating

This page could be translated better, for example we could use labels of properties instead of translating them in the page. The translation could then be done via editing labels and translating. Do you agree? Matěj Suchánek (talk) 18:39, 28 November 2014 (UTC)

@Ain92: This is the version. Unless marked for translation, we can revert it to the previous one. Matěj Suchánek (talk) 10:43, 22 December 2014 (UTC)

## I need some clarification in case of sciences, theories, religions, military branches etc.

What property should one use in cases like economics (Q8134) & social science (Q34749), number theory (Q12479) & mathematics (Q395), Christianity (Q5043) & Abrahamic religion (Q47280), artillery (Q64418) & military branch (Q781132)? Is there an only solution for all or each case is different from others? Ain92 (talk) 21:33, 29 November 2014 (UTC)

There are always problems with abstract things. There is a point of view that they should always be subclasses because they cannot be instantiated. I'd argue with this but for above examples P31 would lead to contradiction... As there exists mathematical economics (Q747534), economics (Q8134) cannot be an instance. Also for branches of number theory (Q12479) and Christianity (Q5043). But part of (P361) can be still applicable, and I don't know which property to prefer... --Infovarius (talk) 16:04, 30 November 2014 (UTC)

### Example

Let's think together: Shia Islam (Q9585) is part of (P361)/subclass of (P279)/else Islam (Q432)? And Islam (Q432) is instance of (P31)/subclass of (P279)/part of (P361) Abrahamic religion (Q47280)? I'd go with subclass of (P279) in 1st, but with instance of (P31) in 2nd case. --Infovarius (talk) 19:19, 16 March 2015 (UTC)

@Infovarius: Not an easy one, I'd say the concrete objects involved here are believers.
So it's easy to say <Bob> believes in <Islam> or <John> instance of <Christian>.
Being a Christian can be defined as believing in Christianism.
⟨ Muslims ⟩ subclass of (P279)   ⟨ Believers ⟩
obviously.
⟨ Souffists ⟩ subclass of (P279)   ⟨ Muslims ⟩
as well.
On another viewpoints, a religion is a dogma, or a set of statements such as God exists. In that view, all theists shares the statement there is a god. so maybe
⟨ Christianism ⟩ subclass of (P279)   ⟨ Theism ⟩
make sense.
I'd say religion is probably a metaconcept, see Help:Classification. We can say, a religion is a set of beliefs and practices. The concrete objects or events are then the last times Bob prayed. I'd say a religion is then a class of class, whose instances are Christianism and so on. Christianism is instanced every time someone acts in accordances with the dogma in conscience. This also avoids semantic distinction with sects, for example. 20:22, 16 March 2015 (UTC)

## Member of

Shouldn't this page at least makes reference to member of (P463) since that property is the one appropriate for the USS Nimitz/carrier group (which is not even on the Nimitz page, amusingly enough) and the member state/organisation relations? Circeus (talk) 14:08, 25 December 2014 (UTC)

## Another cancdidate help page Help:Classification

Hi, I started a more detailed help page about class and instances, and class of classes elsewhere. It's a draft yet, whereas this one is consensual.

What do community think about this ? Can we mention this page in this one, can we come to a consensus on this subject ? Do we need a RfC ? 11:03, 11 April 2015 (UTC)

I just also discovered also Wikidata:Item_classification and Help:Item classification created without any kind of discussion, probably to merge or just delete as the creator has proven to be not really the cooperation kind. 11:38, 11 April 2015 (UTC)
I deleted Help:Item classification. Wikidata:Item_classification can partially merge into other pages. --Pasleim (talk) 12:12, 11 April 2015 (UTC)

## Outdated sample

I had removed one of the outdated samples that one was trying to re-add yesterday as it's inconsistent with Wikidata:WikiProject Movies/Properties#film_festival.
--- Jura 08:55, 20 October 2016 (UTC)

They are indeed inconsistent but why is this an argument that the sample on this page is wrong and the one on the WikiProject is right? The sample on the WikiProject was added by you in January 2016 [1] while the sample on this page is around since March 2013. Moreover, the samples you added on the WikiProject are themselves inconsistent. You're claiming 29th Torino Film Festival (Q18530094) instance of (P31) Torino Film Festival (Q1441481) and Film Festival of Faculty of Informatics (Q15955562) instance of (P31) film festival (Q220505), i.e. Torino Film Festival (Q1441481) is a class but Film Festival of Faculty of Informatics (Q15955562) is an instance. That's a contradiction. --Pasleim (talk) 09:20, 20 October 2016 (UTC)
• This page hadn't been maintained in ages so I'm not quite sure what it status is to be. I think "outdated" did describe it well (though you removed it yesterday). If it includes samples, it should probably limit itself to generally accepted ones.
If you check Q1441481#P31, you will note that it's an instance of a film festival. It can well be a subclass of something else, e.g. an event.
--- Jura 09:54, 20 October 2016 (UTC)
I agree with Pasleim: Your notion of this seems to be incorrect. --Izno (talk) 12:02, 20 October 2016 (UTC)

I don't see any inconsistency here. There is no inherent contradiction in having film festival series be both individual items and classes. One does have to be careful in situations like this, but there is no inconsistency. Peter F. Patel-Schneider (talk) 23:17, 28 October 2016 (UTC)

What do other think about the classification of film festivals? @ValterVB, TomT0m, Peter F. Patel-Schneider, ArthurPSmith: --Pasleim (talk) 13:46, 28 October 2016 (UTC)

• It might be worth asking specialized contributors:   Notified participants of WikiProject Movies. Essentially, the question is if a "film festival" is something that has to be held repeatedly or not (e.g. every year).
--- Jura 13:58, 28 October 2016 (UTC)
Thanks @Pasleim: for the notification and for the updates to this page - I didn't have it on my watchlist but I should have! Anyway, I think the current state of the help page is much improved from what it was, the explanatory introduction is very helpful. I hope the major changes don't give the translators conniptions. On the specific issue of film festivals, I've always been a little uncomfortable with using that example as it seems confusing, though I understand its intentions. I think the main problem is film festival (Q220505) is a subclass of "recurring event" so it defines not a single festival, but one that repeats. Therefore instances of film festival (Q220505) are themselves classes that have instances (the event at a specific time). This isn't uncommon in the structure of wikidata, especially for things like this where the partitioning is date-related. That is the one thing about this Help page that I still think is wrong - a too-strong insistence that "instances" cannot be "classes". That's just not true - classes can be instances of metaclasses, and there are some metaclasses that don't have a clear meta level so there is not a real distinction between class and metaclass (and certainly not one we are enforcing in wikidata). That's why I used "non-class" and "any item" in my revision of the page, with the definitions: "In the following, "non-class" refers to any wikidata item that does not meet the definition of "class", and "any item" refers to any wikidata item, class or non-class." ArthurPSmith (talk) 14:33, 28 October 2016 (UTC)
I doubt the correctness of the claim film festival (Q220505)subclass of (P279)recurring event (Q15275719). It was added by Jura1 on the same day as they added the conflicting example to the WikiProject. I agree that an item can be subclass of a class and instance of a metaclass at the same time. But this should have different values. Metaclasses were not introduced to say Torino Film Festival (Q1441481)instance of (P31)film festival (Q220505) and Torino Film Festival (Q1441481)subclass of (P279)film festival (Q220505). --Pasleim (talk) 16:17, 28 October 2016 (UTC)
Agreed. The "Festival de Canne 2016" is an instance of festival for sure and is definitely not a periodic festival, for example, which would be entailed by
⟨ Festival de Canne ⟩ subclass of (P279)   ⟨ periodic event ⟩
. I'd definitely write
⟨ Festival de Canne ⟩ instance of (P31)   ⟨ periodic film festival ⟩
- We should think periodic film festival as the (meta)-class of all "brands" of festival. author talk page 16:38, 28 October 2016 (UTC)
When I went through cleaning up various film festival items, I had checked different language versions of "film festival" (Q220505). Most do consider a "film festival" to be a periodic event, that would mean that "Torino Film Festival" (Q1441481) instance of (P31) "film festival" (Q220505). Obviously, if you are viewing {{Q}} you might look at a language that assimilates it to an instance of a "public viewing".
Maybe a comparison with newspapers works. The Times is an instance of a newspaper.
--- Jura 17:03, 28 October 2016 (UTC)
Something more solid for your opinion : http://www.larousse.fr/dictionnaires/francais/festival_festivals/33417 - a french well-known dictionary : Série périodique de manifestations artistiques appartenant à un genre donné et qui se tient habituellement dans un lieu précis (periodic series of artistic manifestations). By "festival de cannes 2017" instance of "festival de cannes" instance of "film festival" this makes "film festival" a second-order class (Q24017414)     . "festival" (as any (instance of) film festival is a(n instance of) festival) is as well a second-order class (Q24017414)     . author talk page 17:16, 28 October 2016 (UTC)
The second definition however is Série de représentations consacrées à un art, à un artiste => sequence of manifestation . It seems that "festival de cannes 2017" fits this definition. But as this is two not equivalent definitions, there should be two distinct items for these.
• Two distinct items, one for the repeating variety and one for the single one at an identified time makes sense to me. ArthurPSmith (talk) 18:58, 28 October 2016 (UTC)
A question appears to be whether film festival (Q220505) contains as instances items like Toronto International Film Festival (Q390018), i.e., festivals that repeat; items like the 2015 Toronto International Film Festival (Q19604590), i.e., single festivals; or both.
The argument against both is that repeating festivals and single festivals have different properties. The former has event interval (P2257), inception (P571), etc. The latter has point in time (P585), specific award winners, etc. A class for both would not provide good guidance on which properties are for which kind of festival. Two different classes are needed to keep these straight, one for festival series and one for festival editions.
In [2] there is a list of properties for instances of film festival (Q220505) that includes event interval (P2257) and inception (P571), indicating that instances of film festival (Q220505) are repeating events. Similarly, film festival film festival (Q220505) is a subclass of recurring event (Q15275719), also indicating that instances of film festival (Q220505) are repeating events. So Toronto International Film Festival (Q390018) is an appropriate instance of film festival (Q220505) but 2015 Toronto International Film Festival (Q19604590) is not.
There should also be a class for individual film festivals that provides information on the properties of individual film festivals, e.g., point in time (P585). I don't see evidence of such a class.
Then there is the question of the relationship between recurring festivals and their editions. It is permissable to think of a recurring festival as both an individual item and a class, and thus allow its editions to be its instances. This can lead to problems unless care is taken to be very clear about how the properties of each are set up and related.
The status of recurring event (Q15275719) is a bit murky. This item is a subclass of event (Q1656682), which has a list of properties that mixes up properties for recurring events and single events. This is where fixup is needed, probably to move the properties out of this class into subclasses for recurring events and single events. Peter F. Patel-Schneider (talk) 23:25, 28 October 2016 (UTC)

In addition to the classical philosophical introduction (seen in #Introduction), use terminology of WD:Glossary.

• What makes an Item an instance? (relatively easy question)
• What makes an Item a class? (please mention that links can be in both directions)

d1g (talk) 12:29, 1 January 2017 (UTC)

see "There are a lot of groups, all kinds of them, on Wikidata ..." and "There is a property to link an individual ...'" at User:TomT0m/Classification
d1g (talk) 03:50, 15 January 2017 (UTC)

## Reduce from 4 to 2 examples

Please keep at least one example without expertise in field. d1g (talk) 12:36, 1 January 2017 (UTC)

I removed some examples. Keeping the remaining ones is in my opinion worth, because we want to address users with various backgrounds. For that we need examples from different fields. --Pasleim (talk) 10:12, 20 February 2017 (UTC)

## Include facet of (P1269) and has parts of the class (P2670) ?

Some of the samples are now covered by P2670. However, that property seems mostly unused.

P1269 might be worth covering as well, but personally, I hardly use it.
--- Jura 08:29, 2 January 2017 (UTC)

I tend to think that we should keep documentation about properties only at respective pages: subclass of (P279), instance of (P31)
class-class properties grouped using Wikidata property for the relationship between classes (Q28326461)
some item-item properties grouped using Wikidata property to describe the elements of identity (Q28100549) d1g (talk) 03:41, 15 January 2017 (UTC)

I second that the usage of "facet of (P1269)" should be discussed in this help page and possibly "has quality (P1552)" and "has parts of the class (P2670)" could be included as well.

As for the relationships between subclass of (P279), instance of (P31) and part of (P361) it would probably make sense to explain the difference between a class (or collection, as a generic concept) and a mere group of parts as it is done on page 4 of the Cyc] pdf-document given as a reference on the obverse page.

If I understand this correctly, any unspecific "group" can either be a "class" or an "instance" - depending on the context?

I.e. the "Greek alphabet" is an instance of the class "alphabet". But the letter "A" is a part of the instance "alphabet"?

Also maybe a different title for the page would be appropriate, e.g. "Properties defining relationships between items" or "Relationship-defining properties". For when I first read the title I wondered whether "membership" might somehow refer to the community of Wikidata-users.

best regards, KaiKemmann (talk) 13:55, 9 April 2017 (UTC)

I placed P2670 at Q28326484 and P31 at Q28326490. d1g (talk) 19:58, 23 April 2017 (UTC)

I added has parts of the class (P2670) to the page. facet of (P1269) and has quality (P1552) also need better documentation, but these can be added to their talk pages. P31/P279/P361 resp. P527/P2670 are often wrongly interchanged, that's why a common documentation page is helpful. --Pasleim (talk) 17:46, 12 May 2017 (UTC)
now we should remove example with part of (P361) about inner planets, because P2670 is more appropriate. d1g (talk) 02:09, 18 June 2017 (UTC)

## Recent changes - are they really helpful?

@D1gggg, Pasleim: I'm not sure that a Help page like this should be delving into the subtleties of Zermelo–Fraenkel set theory. Also note that all changes to the page need to be translated into the other languages it is provided in. Can we discuss what you are trying to do here on the talk page a bit before further change happens? ArthurPSmith (talk) 14:56, 17 May 2017 (UTC)

I think that "Basic membership properties" is not the best place for this remark, but it should be suggested somewhere else then.
I'm not ready to write a "Wikidata:Types or Sets"
People involved in mathematics tend to see types as sets, I was asked to keep ∈ as alias
I personally relate that with lack of exact definitions. d1g (talk) 15:05, 17 May 2017 (UTC)
I also don't think this help page is the right place for Zermelo–Fraenkel set theory. The target audience of this help page are users which don't know yet the terms instance and class. The wording was kept simple and examples were taken from everyday experience to provide a gentle introduction for new users and most importantly, to not scare them off. Comments like this show that we did this unfortunately too often in the past. So my suggestion is to move the topics set theory and axiom of extensionality to Wikidata:WikiProject Mathematics and keep the content of this page simple. --Pasleim (talk) 21:08, 17 May 2017 (UTC)

## supercarrier (Q1186981) US-centric and hard to translate

The item doesn't have labels in many languages, which is not so strange since only US (and UK?) have these ships. I have considered translating the label into Norwegian by just adding "super" to the word for carrier, but it sounds rather silly since we don't have a tradition for adding "super" in this way. Could we come up with an example which is easier to translate (and less bound to a single country)? Danmichaelo (talk) 16:32, 23 July 2017 (UTC)

## more properties?

disjoint union of (P2738) and others

...instead of P279? d1g (talk) 18:09, 6 September 2017 (UTC)

## Definitions

"instance: an individual or a single thing". instance is individual entity (Q23958946)? --Fractaler (talk) 10:19, 17 January 2018 (UTC)

## « has part of the type » and alphabets examples

See this edit : https://www.wikidata.org/w/index.php?title=Help:Basic_membership_properties&diff=639178823&oldid=615031534 As the proposer of this property I did not intended this property to be used that way. Actually I proposed it specifically to avoid some of those occurences. Per User:TomT0m/Classification if we divide items in « pure instances » (real world objects or events), (pure) « class » of these « pure instances » and (first order) « metaclasses » second-order class (Q24017414) which are classes of pure classes, part of (P361) is definitely suitable (and is used in other ontologies) to connect pure instance to pure instance, and pure class to pure class. « has part of the class » was specifically designed to link pure instances to pure class, and maybe pure class to pure first order metaclass, but never pure class to pure classes, so I stroked the ambiguous or erroneous examples.

Also the « alphabet » examples are tricky and are an example of « token type » distinction, see type–token distinction (Q175928). There is letter types and letter instances. These example deserves discussions before being used in this document or it will increase confusion greatly … author talk page 14:39, 26 February 2018 (UTC)

Is there somewhere a documententation on how to use has parts of the class (P2670)? Did I understand it right that also some of the examples on Property:P2670 are wrong? --Pasleim (talk) 10:44, 20 March 2018 (UTC)
@Pasleim: Yes, pretty much all of them except the one added in the first place. The whole point of « has part of the type » is to link specific instances (for example « me ») to classes of stuffs (like « arm ») to make statements like « I have two arms » if Wikidata has no items for concrete stuffs like « my arm ». For the usecase such as « planetary system » which is made of « planet », we should use « has part » because « planetary system » and « planet » are both classes of concrete stuffs and there is no concrete stuff item involved in the statement. author talk page 15:59, 20 March 2018 (UTC)
A rationale behind this is that we could have statements like « I have my left arm » and « I have 2 arms » in the same items, and that we should not use the same property for both, to make clear that « my left arm » is one of « my two arms », and that part of (P361) should only link concrete objects to concrete objects, or classes of concrete objects to classes of concrete object (and maybe classes of classes of concrete objects to classes of classes of concrete objects and so on), but nether concrete objects to classes of concrete objects. We can add a documentation of the property talk page, but currently the listed help page is this one so … author talk page 16:05, 20 March 2018 (UTC)

## Instances of instances

Are these in error, as instances of instances? Lincoln Bible (Q1816474), First Bible of Charles the Bald (Q847327), 42-line Gutenberg Bible, printed on vellum, and its contemporary documentary background (Q28028100). Ghouston (talk) 07:48, 23 March 2018 (UTC)

Not necessarily. It's quite sensible to refer to a specific physical copy of a book as an "instance of" that book. And in wikidata we certainly have a habit of describing a book (with a given author, title, etc.) as an "instance of" work (Q386724). There probably shouldn't be 3 layers though, as in some of your examples. ArthurPSmith (talk) 14:21, 23 March 2018 (UTC)
So an abstract concept like a book title can be an instance after all? The items above are individual physical books that are instances of a particular edition of a particular translation of something that probably comes in multiple versions in the first place. Would be possible to write a query that returned all such physical copies of some version of the underlying work? Ghouston (talk) 23:12, 23 March 2018 (UTC)
@Ghouston: In some cases it’s useful to have « meta-classes » (see User:TomT0m/Classification, the concept of a « ship class ».) But ideally we should ensure that physical objects’ items are never objects of an « instance of » claim. It’s also possible to order metaclasses by « metaclass order » if we have classes (of physical objects), first order metaclasses (classes of physical objects), second order metaclass (classes of classes of physical objects) and so on (see metaclass (Q19478619), the en or frwiki articles). author talk page 12:49, 26 March 2018 (UTC)
Perhaps the mistake is in saying that Lincoln Bible (Q1816474) is an instance of King James Version (Q623398). Lincoln Bible (Q1816474) is a physical book, and would be an instance of a class of physical books (if we had one). It also happens to contain the text of King James Version (Q623398). Ghouston (talk) 02:54, 27 March 2018 (UTC)
Physical books are quite different to book (Q571). They are objects that contain some bound pages. It's still a book even if the pages are blank (like an unused notebook or ledger), or it could be hand-written, so a physical book isn't a subclass of most of the things that book (Q571) is a subclass of. Ghouston (talk) 02:59, 27 March 2018 (UTC)
@Ghouston: The issue is that the french description of Q571 (and the associated frwiki article) is about the physical object, for example, so stuff are quite mixed up. Not sure what the best way to solve this is. author talk page 08:06, 27 March 2018 (UTC)
You should probably talk to the people in Wikidata:WikiProject Books, they have thought about this a lot. ArthurPSmith (talk) 14:14, 27 March 2018 (UTC)
Do you have some relevant discussion pointers ? Because I have this page in my watchlist and I did not have the feeling there was much progress about this. Probably raised the issue once or twice over the years, cannot remember much answers. author talk page 18:29, 27 March 2018 (UTC)
Well, there was some discussion at wikidatacon in Berlin. Wikidata adapts FRBR which has the basic concepts of a "work" - the intellectual content, an "expression" - a particular edition or translation of that work, a "manifestation" - the particular physical embodiment (eg. hard back, paperback, audio book, etc.), and an "item" - a particular concrete entity that is an instance of the manifestation. In wikidata we tend to condense "expression" and "manifestation" into a single layer, but otherwise that's the basic structure. See en:Functional Requirements for Bibliographic Records for more details on FRBR. ArthurPSmith (talk) 18:38, 27 March 2018 (UTC)
This looks good. A particular manifestation could then be a subclass of the hypothetical "physical book" item, which would have parameters like page material (paper, parchment, linen), cover type (soft, hard at least), printing method (or handwritten), binding type etc. Ghouston (talk) 23:58, 27 March 2018 (UTC)
@Ghouston: I think what you are missing is exemplar of (P1574). With it you don't need to overuse "instance of". Micru (talk) 07:25, 29 March 2018 (UTC)
Indeed, I'd never heard of it, and it's not used on any of the books above. It doesn't seem to replace "instance of", since according to the property proposal, that's still supposed to be set, but it would give a way to find physical copies of books. However, my confusion isn't restricted to books, they just formed a convenient example: I was originally trying to write a query that would return a list of occupations, but didn't make much progress because of instance / subclass confusion. TomT0m's explanation of metaclasses was quite interesting though. Ghouston (talk) 07:56, 29 March 2018 (UTC)
@Micru:I think what you are missing is exemplar of (P1574). With it you don't need to overuse "instance of" From what I feel myself, « overusing » is quite an « ad hoc » notion we don’t really have a good idea what it is. The opposite side is « why having a specific property when instance of can do the job ? ». author talk page 09:06, 29 March 2018 (UTC)
@TomT0m:Yes, of course, you could use "instance of" instead of a specific property, but it is more manageable to use specific properties, at least it allows for specific constraints that wouldn't be possible using "instance of" everywhere. Micru (talk) 11:18, 29 March 2018 (UTC)
@Micru: at least it allows for specific constraints that wouldn't be possible using "instance of" everywhere. Not convinced. For example if the only constraint is that this specific constraint is that items with this property are instances of (physical books), it’s useless as « instance of » would have been applied to stuffs that are subclasses of books, so actually nothing would have to be actually checked. If a constraint just checks some kind of redundant information, we could probably live without it and express the same information with less statements and less constraint reports, so less (not useful) constraint to correct. Also a constraint could be attached to a class (and inherited to its subclasses). author talk page 14:34, 29 March 2018 (UTC)

## Inverse of "subclass of"

Is there a property that is the inverse of subclass of (P279)? I'm thinking of year (Q577); tropical year (Q189607) is a subclass of year (Q577). Is there a property I could add to year (Q577) to indicate tropical year (Q189607) is a subclass of it? This would be useful because I could also indicate that anomalistic year (Q2735933) is another subclass of year. By having a list of things that are subclasses, and things that are different from (P1889) it gives a better indication of the meaning of the item. Jc3s5h (talk) 14:38, 23 April 2018 (UTC)

I suppose union of (P2737) could be used that way - but it expects a complete list of the subclasses and it's structured oddly. ArthurPSmith (talk) 19:39, 23 April 2018 (UTC)
You can get it by running a query for subclass of (P279) year (Q577); there are 81 so I don't think you'd really want to list them all on year (Q577). Ghouston (talk) 23:14, 23 April 2018 (UTC)
Although I don't like the very idea, but obviously one of the has parts of the class (P2670) or has part (P527) is inverse to P279. But I still don't understand which. --Infovarius (talk) 15:55, 25 April 2018 (UTC)
has parts of the class (P2670) and has part (P527) are inverse of part of (P361) --Pasleim (talk) 16:02, 25 April 2018 (UTC)

## Subclass transitivity

The page currently says that "subclass of (P279) is transitive property (Q18647515), that means if an item A is an instance of class B, and class B is a subclass of class C, item A is implicitly also an instance of class C." It is correct that subclass of (P279) is transitive property (Q18647515), and that item A being an instance of B which is a subclass of C implies being an instance of C, but the latter is not implied by the former. Being a transitive property means that A being a subclass of B which is subclass of C means A is subclass of C. The P31/P279-implies-P31 relation might be stored in Wikidata:Property proposal/property for implied values if that gets created, but it is not derived from its status as a transitive relation. --Yair rand (talk) 18:47, 13 March 2019 (UTC)

@Yair rand: This observation is over a year old, but since I agree with you and nothing has changed yet, I want to bring someone's attention to it. You or I could change the wording according to our own belief and understanding, but I prefer to raise the issue and hopefully reach consensus with concerned editors rather than fix it in silence and risk the confusion to remain out there.
What the statement describes is property value inheritance, not subclass transitivity. The crucial distinction is that while subclass of (P279) and part of (P361) (plus a few others) are transitive properties, not all property values but only a subset of them are inherited via that transitive path. Also, some property values may be inherited via non-transitive properties such as instance of (P31), the property value of class being a primary case in point: If A is an instance of B, then A will in effect be an instance of every class that B is a subclass of, all the way back to the entity (Q35120) class root.
instance of (P31) and subclass of (P279) are both what I consider parent class properties; they pass on certain property values which may end up being (virtually) assigned to the same or different properties of the child item. Other property values may be inherited via the part of (P361) rather than subclass of (P279) property path.
image (P18) is a property not likely to be inherited at all; while an image of an Ursus arctos middendorffi (Q237260) may be a suitable illustration for an animal (Q729), it may be less appropriate for a mouse (Q2751034) (a subclass of animal (Q729) without an image of its own) even as a default image (likewise with an image of a door knob vs an image of a house, of which the door knob is a part). I suppose the same could be said about numerous category or external identifier properties closely associated with their particular item alone, but not with its subitems. --SM5POR (talk) 19:03, 29 July 2020 (UTC)

## has parts of the class (P2670)

The description of has parts of the class (P2670) matches neither its documentation nor its use. Where the use is making sense it is used as "this item has a part that belongs to the class" not "this item has all instances of the class as parts". I'm changing the description to match the documentation and usage. Peter F. Patel-Schneider (talk) 08:06, 27 October 2019 (UTC) There are a number of uses of has parts of the class (P2670) that don't make sense at all. I'll probably remove the ones that I notice. Peter F. Patel-Schneider (talk) 08:06, 27 October 2019 (UTC)

@TomT0m: Any thoughts on this? ArthurPSmith (talk) 15:29, 28 October 2019 (UTC)
Yes, it was never intended as « this item has all instances of the class as parts ». I don’t know where this come from. author talk page 16:40, 28 October 2019 (UTC)

## Examples of incorrect use

I think it would be helpful if there were some examples of incorrect use. I will add some here. For any objections to specific examples please add   Oppose below them. Iwan.Aucamp (talk) 09:30, 15 March 2020 (UTC)

## "Hospital XYZ" has part "helipad"

Following edits of mine and @MottiLoui: at Q1786526, I was going to point to Help:Basic membership properties, but the samples for the difference between "has parts of the class" and "has part" might lack a nice comparable case.

One sample here suggests that "hospital" has part "helipad" is possible (e.g. the planets one), but it should also have one that points out that an instance of a hospital should use "has parts of the class", this even if it's just one part.

Maybe we could add "Albert Einstein" has "parts of the class" = "human brain". --- Jura 14:27, 29 June 2020 (UTC)

I see "has parts of class" as specifying the base type of a collection or array. So Einstein has-part human-brain, but he is not composed of many different human-brains. The class "hospital" should not have "helipad" as a part, as that would insist that all hospitals must have one. The examples in the property are confusing, as I have just noted on the talk page there. --WiseWoman (talk) 08:50, 14 July 2020 (UTC)
@WiseWoman: I don't think has parts of the class (P2670) necessarily has to be for plurals (i.e. I think single-element "collections" are valid), and that is also the impression that I get from reading the property proposal. Logically, it might make sense in some cases that it would be strictly singular or strictly plural (such as in your example about Einstein not having a single brain and it not making sense for him to have multiple brains). However, semantically, the meaning is the same (e.g. saying that an instance of room _has parts of class_ door makes sense to me whether it is a single door or multiple doors). I therefore agree with Jura1 about using has parts of the class (P2670) to describe the relationship between Albert Einstein and human brain.
I agree with you about not saying "hospital has part helipad", but I'm not sure that I would say using that property means that all instances of the subject strictly needs to have an instance of the object type (perhaps some exceptions might be allowable for some instances, without making the statement "wrong"). Some thoughts (which may admittedly be confusing):
1. We say and . Many external sources claim that bryophyte (Q29993) have no root (Q41500) (or at least no "true roots"). Does that mean that they are not plant (Q756)? They're still considered plants regardless.
2. Now consider if we instead chose to say (and removed the statement from plant (Q756)). Does the existence of a Tracheophyta (Q27133) which loses its "true roots" (based on w:en:Vascular plant saying "Vascular plants have true roots, leaves, and stems, even if some groups have secondarily lost one or more of these traits" mean that it is no longer a Tracheophyta (Q27133), or perhaps that the "has part" statement on the class is wrong? Probably not.
There is definitely room for confusion, but I imagine it's intended to cover the typical expectations than every possible reality (it's common for hospitals to not have helipads, after all). 05:08, 30 July 2020 (UTC)