Property talk:P31

Usage note
Usage is detailed in Help:Basic membership properties.

=Discussion=

Is/was a
If I understand correctly, at some point we'll have a way to use qualifiers to specify the time that any attribute was held, so wouldn't it make sense to change the label of this to "is/was a"? --Yair rand (talk) 07:11, 5 February 2013 (UTC)
 * I've started a discussion about this property here. --Kolja21 (talk) 08:55, 5 February 2013 (UTC)
 * This is meant to be used in a very limited way for statements we want to make for which a property is inappropriate. For example, " is a ". It might be worth re-labelling the property to "is an instance of" (so, " is an instance of ". It is not meant for wide-spread use. Note that Property:P107 exists for a sub-set of this property (stating that the subject is an instance of "person", "name", "organisation", "event", "work", "term" or "place"), and should be used instead of this property for those. James F. (talk) 21:44, 18 February 2013 (UTC)

Usage
How is this supposed to be used? Should it be used only for describing an item in it's entirety (Marie Curie "is a" person) or describing every aspect of it (Marie Curie "is a" person, spouse, mother, child, woman, Nobel winner, chemist,...)
 * It seems that the first variant is preferred - see https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=565112041#Is_it_OK_to_note_that_somebody_is_an_artist_using_P31.3F Mateusz Konieczny 18:48, 24 September 2017 (UTC)

Not localizable
This property is not very easy to translate/localize. For languages that have genders (e.g. German), there is no one translation for "one". I also share the concerns of Janjko above. Jon Harald Søby (talk) 18:47, 5 February 2013 (UTC)

+1 the Chinese shows "分类" (means "Category" in English), but a apparently "instance_of" is quite different from "Category" and is a common mistake to confuse them two. Xinbenlv 00:59, 22 March 2018 (UTC)

Problem Localizing to Persian
"is a" is in Persian "می‌باشد" and the verbs are coming in Persian after the nouns.

so the sentence like is a sovereign state will be

کشور مستقل می‌باشد

and not

می‌باشد کشور مستقل

how can we implement these kind of staffs. or it is not a right place! --Pouyana (talk) 20:01, 7 February 2013 (UTC)
 * This particular property may need to be rethought, but for this kind of problem, I would think the best solution would be to find a phrase it so that word order is ok. If that is not possible, you may want to leave a message on Contact the development team. Cheers. --Zolo (talk) 06:30, 8 February 2013 (UTC)


 * Perhaps renaming the property "type" or another noun would help. -- Ypnypn (talk) 21:24, 8 February 2013 (UTC)


 * You don't need an exact translation on word-level, you can use a phrase but that phrase must be unique and usable in the property parser function. Well basically, you don't want a very long phrase as it is cumbersome to type. See Wikidata/Notes/Inclusion syntax v0.3. Jeblad (talk) 21:54, 8 February 2013 (UTC)

Semantical nonsense
The way this property is used seems like nonsense. Where we mean that the item is a republic, we should use property "state system". Where the item is a person and we tell Wikidata that this person is a scientist, we should use propert "occupation". And so on. Wizardist (talk) 20:56, 8 February 2013 (UTC)


 * I think this is an eseencial property. It just filters items in the crudest way. --NaBUru38 (talk) 21:18, 8 February 2013 (UTC)


 * It's meant to be used for "person" or "place" or something. Anything more detailed goes in other properties. -- Ypnypn (talk) 21:25, 8 February 2013 (UTC)
 * This property is for define the type of the item. In your first example is a State, in the second one is a person. --β16 - (talk) 22:01, 8 February 2013 (UTC)
 * Then maybe we call this property a normal noun? Like "type"? Wizardist (talk) 03:41, 9 February 2013 (UTC)
 * Yes probably, see Property_proposal and Wikidata_talk:Property_proposal. --Zolo (talk) 08:34, 9 February 2013 (UTC)


 * What if we use this property for the "entities" of GND (person, name, corporate body, event, work, term, place)? --Sannita - not just another it.wiki sysop 12:43, 9 February 2013 (UTC)
 * +1. Imho "main types of items" is the better choise. This seems to be the original concept of Infoboxes task force. --ThorstenX1 (talk) 21:56, 10 February 2013 (UTC)


 * +1 to rename to 'type' or 'itemtype', or something similar with much more specific meaning than 'is a'. Now we can have object.GetType :) --Yurik (talk) 10:36, 13 February 2013 (UTC)
 * There is now Property:P107 that is better defined that this one - though implementation details still remain to be worked out. I think items using this property should be changed so that they use more specific property (like Property:P106 and Property:P107) and then this property can be deleted.

Prevent or avoid "is a"
I think this property should never be used for people. A person could be anything. "Occupation", "Title", "sex", etc, are more specific. Is it possible to prevent it from beeing used for main type p?

Everytime a more specific property is available "is a" should be avoided. Organisations and works, the "type" property might be used instead.

A similar vague property, suggested by the wikidata developers, was "is in", for example for places, but until now, more specific properties (e.g. "continent") has been used. Mange01 (talk) 22:46, 14 February 2013 (UTC)
 * This property should really be deleted all together. There is a entity type property (the name is under discussion, vote on the talk page), that should specify person/object/event/etc. --Yurik (talk) 22:51, 14 February 2013 (UTC)
 * I'm agree to delete this property (is too much generic), but it is very useful for astronomic object, to distinguish stars, planets, satellites, galaxies... For example templates of Italian Wikipedia (astronomical object and non stellar objects), need a parameter to distinguish the different types of objects managed by them. Is it possible, after discussion, to undelete the property astronomical object? Its deletion was caused for the existence of this property! --Paperoastro (talk) 08:51, 16 February 2013 (UTC)

Delete or rename
(Please see description in the box above, and comment here)

Please don't put deletion template to a talk page, as talk pages are not to be deleted. This template is for deletions that are not likely to be questioned. You should list the property page itself on RfD where it may be discussed. Bináris (talk) 16:40, 16 February 2013 (UTC)


 * The aim of this property is to reflect relationships in an ontology, typically a hierarchical system such as a library classification system, making it possible for computers to inteprete knowledge base. But there are many alternative ontologies and competing standards. So I think that it should be supplemented by several of ontology specific properties. We may start with changing name of P31 from "is a" to "[is an ]instance of (GND entity)" or "GND ontology instance of". See http://d-nb.info/standards/elementset/gnd# for an authoritative source. A (temporary?) problem is that some of the GND entities have no Wikipedia article yet, and it is not allowed to created the item at Wikidata. (A similar discussion is ongoing at Property talk:P107 - "Wikidata main type of item"="GND ontology high level entity".) Mange01 (talk) 20:25, 17 February 2013 (UTC)


 * We renamed P107 already a couple of times. Now to start mixing different ways of classification can't work. --Kolja21 (talk) 21:33, 17 February 2013 (UTC)
 * I think is-a is a “good“ property, we just have to invoke some rules. E.g. I added the property is-a elementary particle and is-a fermion to Q2225 (electron). I think this is helpful for queries in future like „List all elementary particles“ or „List all fermions“ etc.
 * I heard from a thing called „InstanceOfSnack“. I don't really understand the difference between this instance and the is-a-property. Is it only a technical difference?
 * We should invoke the rule “If there exists a more specific relation property than is-a, this specific relation property must be used“. Example: Marie Curie is-a mother and is-a spouse. But instead of using these properties we should use Marie Curie is-mother-of/father-of (Property:P40) Irène Curie and is-spouse-of (Property:P26) Pierre Curie.
 * The properties itself then get the generalized property: is-mother-of is-a is-a or something like that (if technical possible).
 * In general this “is-a“ properties will lead to the same insane discussions and problems what we all face for categories in the Wikipedia. Because is-a is nothing else than categorisation.--Svebert (talk) 11:07, 14 March 2013 (UTC)

While everyone else debates more important things...
I've renamed this to "is a(n)", since sometimes this was causing grammatically incorrect phrasings (e.g. "is a asteroid"). — PinkAmpers  &#38;  ( Je vous invite à me parler )  02:53, 20 February 2013 (UTC)


 * Sounds good. :-) James F. (talk) 20:12, 20 February 2013 (UTC)


 * What about 'is the'? Emw (talk) 02:24, 14 March 2013 (UTC)

A related property
is a : instance :: generalization : class. See Property_talk:P279 for more. Emw (talk) 02:18, 14 March 2013 (UTC)

Hierarchy
I added is-an elementary particle and is-a lepton to electron. But every lepton is an elementary particle. Do we have to consider such things? Meaning one adds only the most specific group and by back-tracing one gets the full hierarchy electron->lepton->elementary particle->concept in physics->...--Svebert (talk) 11:36, 14 March 2013 (UTC)


 * A short reply without writing a history of the debate about P31/P107/etc: One level of "hierarchy" is enough. Espeso (talk) 15:02, 14 March 2013 (UTC)
 * The deepest I suggest, right?
 * Is there some template or comparable to define such “rules“ for a property?--Svebert (talk) 15:45, 14 March 2013 (UTC)
 * Yes, the deepest.
 * No, there are no (extended) templates describing properties. Some of the simpler properties have the template row from WD:P copied to the property talk page. But with this particular property, any attempt to formalize some usage would probably be met with resistance by... someone else who favors a different property. My own opinion is that since this is a wiki, and barely starting at that, let competition among properties prevail and see what happens. Espeso (talk) 17:11, 14 March 2013 (UTC)

is a -> instance of
This property's current description is "this item is an instance of this other item". The distinction between an instance and a class is an important idea that has meaning in not only Semantic Web languages from the W3C like RDFS and OWL, but also in philosophy, software modeling languages like UML, and languages used in AI like CycL. All of those languages have two separate relations for defining that an instance is an element of a class and that a class is an element of a class. The latest draft of the Wikidata data model even separates the two membership relations into 'InstanceOfSnak' and 'SubclassOfSnak'.

Given that built-in support for 'InstanceOfSnak' and 'SubclassOfSnak' isn't coming soon -- and may never come -- it seems like the next best option is to use two different entries in the Property namespace to act as corresponding membership relations. A new property -- P279 -- exists specifically for 'subclass of' relations. However, the current name of this property is ambiguous: does 'is a' mean 'instance of' like it does in the popular CycL language for structured data, or does it mean both 'instance of' and 'subclass of'? Because of that and the reasons outlined above, I think it would be best have two properties to describe the two different kinds of membership relations, and change the name of this property to 'instance of'. What are others' thoughts? Emw (talk) 22:52, 16 March 2013 (UTC)
 * --Svebert (talk) 23:31, 16 March 2013 (UTC)
 * Yes. Espeso (talk) 01:53, 17 March 2013 (UTC)
 * , "is a" is ambiguous and likely to be misused --Stevenliuyi (talk) 02:21, 17 March 2013 (UTC)
 * at this moment . Frist: In language use "is a" means both, instance and subclass. I've a problem with the meaning (in this case) of "instance". In programming an instance would be _one_ object of an (sub)class, for example the "netbook Thinkpad x123 of person Xyz" would be an instance, "Thinkpad x123" itself would be a subclass of netbook, netbook an subclass of computer. But actually - as I understand - you mean with an instance only the "Thinkpad x123" as instance of netbook, or not? Even if in practice you can't create another subclass of "Thinkpad x123", in theory it would be possible. In Wikipedia we mostly describe only subclasses, but sometimes also an instance. I've an similar idea posted in the GND property P107. Best regards, --&#35;Reaper (talk) 12:53, 17 March 2013 (UTC)
 * "Instance" has the same underlying meaning in programming, philosophy, and knowledge representation. To answer your question, if "Thinkpad x123" was a kind of computer, then it would not be an instance; it would be a class.  All articles about particular people, places, organizations, events and other unique, particular things are about instances, not classes.  While I haven't researched it, I would guess that the proportion of Wikipedia articles for instances is not overwhelmingly different than that for classes.
 * Whether one thinks this property should be called "is a" or "instance of" -- and whether "subclass of" (P279) should exist -- depends on whether one thinks that W3C standards for describing structured data are worth applying to Wikidata. I think it would be good for Wikipedia and the wider Semantic Web if Wikidata used widely accepted, standards-based properties for these kinds of important relations. Emw (talk) 14:06, 17 March 2013 (UTC)
 * Maybe we could work with qualifiers? Keep it "is a" and add one of the two qualifiers "instance of" and "subclass of". In this way, we don´t have to delete lots of those 32.403 statements where "is a" is used so far. --Goldzahn (talk) 17:01, 17 March 2013 (UTC)
 * Or equivalent: Add a new property called “is class“ with a boolean value.
 * I checked some of the items using is-a and I didn't find any wrong usage. All is-a are used as “instance-of“ (i checkd about 10 items)--Svebert (talk) 21:04, 17 March 2013 (UTC)
 * Reaper, think of it this way. A class is the equivalent of a set in mathematics. An instance is the equivalent of a set element. Just as in mathematics there is the "subset" concept and the "element of" concept which mean different things, so too we need to have "subclass of" (subset) and "instance of" (element). They cannot be one property because they mean different things. Silver hr (talk) 01:31, 18 March 2013 (UTC)
 * Good explanation, btw. --DixonD (talk) 08:32, 19 March 2013 (UTC)
 * I thought over about it these days, but I'm not sure and clear with everything. (Note: My contra was meant as an "stop, wait a moment", not as a real contra.) To a possible second property (about which I already thought about, too): I think we should use less properties, so I would say no to this idea. (@Silver hr: Thanks for your explanation, but I'm sorry that mathematics is not my wold, so I've to stay with programming terms. ;) I hope the rest gets along with it..)
 * I would like to discuss some examples, because till now I'm not really sure if we could really describe the whole world with subclasses and instances. An example that I've been thinking about: Is the video game Half-Life (or software at all) an instance of "video game" - or a subclass? If it is (as I would say) a instance, what would then a mod (e.g. GMod in past) for this game would be? Of course a "mod" (also in order of "is a"), but it should also be a part of the game. That means in order of "instance of" it would be an instance of Half-Life too. What would be "multiple inheritance" (yeah ;)), but it would be then an instance of an instance..? How to solve something like this? (I think I got another example, but now I can't remember..) I hope that I could describe good enough what I mean (and sorry for my bad English..). Best greetings, --&#35;Reaper (talk) 20:48, 19 March 2013 (UTC)
 * see en:Class (computer programming) and en:Instance (computer science). describe the whole world with subclasses and instances I don´t see that too. I would say, that should depend on how to use the properties p31 and p279. In my view both properties could be used for internal use, for example quality management. At the moment, someone could say that the value of the "place of birth" (p19) is the color yellow. Together with "main type" (p107) we could build a system, that gives a warning to the editor if the value of the "place of birth" is not a "place"-type and not an "instance of", lets say municipality (type of administrative division (p132)) or a class in which a municipality is a "subclass of" (p279). --Goldzahn (talk) 21:08, 19 March 2013 (UTC)
 * Reaper, that's a great point. Because video games, software, books, and other such items can have instances -- e.g. a video game on a shelf, an installation of a operating system or web browser, a book in a person's hand -- I think they're best considered to be classes, and not instances.  Instances are items with a unique location in space and time.  Reliably-sourced classifications that use these kinds of relations, like The Software Ontology, refer to items like Java and operating system as classes, and use the 'subclass of' (really, rdfs:subClassOf) relation to define their membership in other classes like 'programming language' and 'software'.  (P.S., I think your English is very understandable.) Emw (talk) 03:51, 20 March 2013 (UTC)
 * The thing that helped me better understand ontological concepts is experimenting in Protege OWL, a visual editor for OWL ontologies. Note that OWL has more features than Wikidata has or will have according to current plans. There's a tutorial for it here, and even if you're not interested in Protege or OWL, the tutorial has a nice visual representation of instances, classes and properties somewhere in the first few pages.
 * Also, to be able to describe the whole world in a structured way, another essential property we would need is "has part", which I think would solve the problem posed by your mod example.
 * Silver hr (talk) 23:17, 20 March 2013 (UTC)
 * Thanks for your answers and sorry for my late answer. I though about my example "mod of a game" from above and about Emw's answer. And I came to the result, that we should use "instance of" for software and all other digital or replicable things (like films, books, ..). But at first something general (or for this example): "GMod is a mod (of Half-Life)", but also "GMod is an instance of Half-Life" according to my last post (according to programing structure), but for sure not the other way around: It's not "GMod is a Half-Life". So "is an instance of" is on this side more than "is a". We maybe should think about this.
 * Now let me explain my reasons for my decision why software should be an instance: The point which I mentioned just, GMod is a mod. In order of language use we wouldn't say that "GMod is a Half-Life". The other reason is, that - likewise also in language use - a game, software, film or book would never be a subclass of something. A film, book and also software would always be an single item, even if it's nothing you could touch. I'm currently not sure how we could solve the problem (in general) that something is a "mod of" something, maybe with "has part" mentioned above. But otherwise "subclass of" would break the language use in a really hard way, and also would disrupt all other real statements like "is subclass of subclass".
 * But I'm also not sure what to do with like "Netbook X31" as a product, not as a single, touchable object. Hmm.. Maybe an other property for this..? And sorry, I haven't looked at the links posted above, maybe later when I've more time. (And English isn't so easy for me... makes it more difficult to read and understand.)
 * I always get confused when I think about this.. ;) Best regards, --&#35;Reaper (talk) 22:06, 27 March 2013 (UTC)
 * GMod is a part of Half-Life, since recent :) Infovarius (talk) 10:07, 28 March 2013 (UTC)
 * Yes, I know this new item, but this statement would be wrong. (Question: is "has part" and "is part of" the same? I think its the opposite, but I can't translate "has part" (it seems untranslatable, but I think I know what it means).) It's more like "GMod uses Half-Life" or similar. (A map or level would be a part of Half-Life.) --&#35;Reaper (talk) 17:51, 28 March 2013 (UTC)
 * First of all, "Netbook X31" would be a class, and probably a subclass of "netbook". A particular physical product identified by a serial number would be an instance of "Netbook X31". As for the relation between GMod and Half-life, I'd put it this way (just an example, doesn't necessarily correspond to Wikidata items). "GMod version x" instance of "GMod", "GMod" subclass of "mod", "GMod" modifies "Half-Life".
 * The reason I was originally thinking in terms of a "has part" property is because you could describe the two in the following way. "Half-Life" has part "file hl1", "Half-Life" has part "file hl2", ..., "GMod" has part "file hl1", "GMod" has part "file gmod1", ..., but I'm not sure how appropriate that would be for Wikidata.
 * As to the difference between "has part" and "(is) part of", they are inverses. If A has part B, then B is part of A. Also, there is now some good documentation for the differences between "instance of", "subclass of" and "part of" here, I recommend reading it.
 * Silver hr (talk) 00:04, 31 March 2013 (UTC)


 * Silver hr (talk) 01:31, 18 March 2013 (UTC)
 * --Don-kun (talk) 19:28, 19 March 2013 (UTC)
 * Yes, I believe this and the "subclass" property represent the clearest distinction yet between the two. Shawn in Montreal (talk) 14:58, 21 March 2013 (UTC)
 * Yes, this is what was intended when I created the Property; I chose the simpler 'is a' language after discussion with fellow editors suggested that it was better for them, but of course I'm very happy for it to be wider. James F. (talk) 10:59, 13 April 2013 (UTC)

"это" вместо "является одним из"
Вернул название "это" вместо "является одним из", т. к. второй вариант требует после себя родительного падежа, а у нас айтемы названы в именительном. А то получается "Африка является одним из континент". — Ivan A. Krestinin (talk) 17:56, 20 March 2013 (UTC)
 * Достаточно было поставить двоеточие в конце :) На самом деле "это" - слишком неопределённое и, возможно, не совсем подходит, надо подумать. --Infovarius (talk) 20:19, 21 March 2013 (UTC)


 * Отсутствуют варианты "подмножество множества", "элемент множества" (символьно: ⊂, ⊆, ∈, ->). Например, "Восточная Африка:Территория" ⊂ (подмножество множества, ->, ⊆) "Африка:Территория" (грубо - "Африка") ⊂ "Континенты" ⊂ "Земля:По территориям". "Африка" ∈ (элемент множества) "Континенты". Fractaler (talk) 07:14, 11 April 2013 (UTC)
 * Есть: подмножество. На самом деле Восточная Африка" часть "Африка". Infovarius (talk) 08:33, 11 April 2013 (UTC)
 * Синонимы (часть, "is a", "является одним из" и т.д.) - вред при создании единой системы (типа Wikidata). Здесь возможные синонимы. Варианты, которые не попадают, можно всегда привести к варианту Множество/Подмножество(Надмножество). И в описании на ru для подмножество - "надмножества этого понятия" (про подмножества - ничего, про множество - тоже) Fractaler (talk) 10:01, 11 April 2013 (UTC)
 * Я бы назвал "это объект типа", тогда дальше может быть в именительном падеже. Текущее описание "это частный случай понятия" считаю неудовлетворительным по ряду причин. Оно неоднозначно, можно неправильно понять как «уточнённый тип/класс» вместо «объект класса, экземпляр типа». В английском уже определились, что это должен быть именно единичный объект. Давайте переименуем? --Nikolay Komarov 10:52, 9 September 2020 (UTC)

Proposal: establish rdf:type as the basis for this property
From the discussion above, there seems to be general agreement that "instance of" is a better name for this property than "is a". This makes the property less ambiguous, and has the benefit of bringing it closer in line with common standards for how to represent knowledge in a structured way. To further that end, I think it would be a good idea to establish the RDF 'type' property -- rdf:type -- as the basis for this property. RDF is the foundation of the W3C's recommendation for a language of the Semantic Web. To my understanding rdf:type has all the semantics that this property has. This would help resolve questions like "what does this property mean?", "what is an instance?", etc. It would also make this property, and thus Wikidata as a whole, more interoperable with the rest of the Semantic Web. Emw (talk) 04:05, 22 March 2013 (UTC)
 * , at least until Wikidata/Data_model gets implemented. Silver hr (talk) 18:25, 22 March 2013 (UTC)
 * Tpt (talk) 14:04, 23 March 2013 (UTC)
 * What are you proposing here; a new property, renaming of this property or something else? --Faux (talk) 14:55, 23 March 2013 (UTC)
 * This proposal isn't about a new property or renaming this property, it's about clarifying the nature of this property. Based on the general agreement from the is a -> instance of discussion above, this property already behaves like rdf:type.  This proposal would add rdf:type to the 'Source' field at the top of this page, and establish a mapping between this property and that property from the RDFS W3C recommendation. Emw (talk) 13:21, 24 March 2013 (UTC)

I've gone ahead and made the proposed change (diff). Emw (talk) 12:06, 30 March 2013 (UTC)

Proposal: establish rdf:type as the name for this property
If it now has the semantics of rdf:type, then use that as the name. Andrea Shan 03:20, 19 November 2014 (UTC)
 * User:Emw's "would make this property [...] more interoperable with the rest of the Semantic Web" applies here too. The proposal was triggered by User:Jeblad's statement at Project_chat "the statements (and the properties we are using to formulate them) are not grounded in external common concepts from semantic data", which might have been an error, but having the same names, reduces the likelihood for future misunderstandings about the semantics, for those that understand RDF and OWL. Andrea Shan 03:20, 19 November 2014 (UTC)


 * . Labeling this property rdf:type would make the mapping clearer, but at the cost of making on-wiki references to it too technical and awkward. rdf:type is already an alias of this property, so it appears prominently on Property:P31, and the mapping of instance of to rdf:type is made clear in the Wikidata RDF export, the paper Introducing Wikidata to the Linked Data Web, and in the 'Source' parameter currently atop this Talk page.


 * The label "rdf:type" is also unfortunate because it was cast before the Semantic Web talked in terms of classes and instances. The labels "instance of" and "subclass of" make the ontological status of the subject clear.  "Instance of" is also the label used for this property in the Relation Ontology, which is based on the Basic Formal Ontology (BFO), the most widely-used upper ontology in the sciences.  The current names of P31 and P279 also closely align with those in the originally proposed Wikidata data model, InstanceOfSnak and SubclassOfSnak.


 * That said, I do think more could be done to make the mapping of instance of to rdf:type even clearer. Perhaps appending "Mapped to rdf:type" or "Has semantics of rdf:type" to the property description would be good.  And as User:Jeblad mentions in the linked Project chat discussion, we do need a better machine-readable way to declare that one property is mapped to another.  (Technical cavaet: we should make it clear that such a way would not use OWL semantics, because built-in vocabulary like rdf:type cannot be the object of a property in any OWL 2 DL ontology.) Emw  14:03, 19 November 2014 (UTC)


 * I agree with Emw - please don't. "rdf:type" is very opaque to anyone who doesn't understand RDF modelling. Making it clear that this is "rdf:type" for someone who wants to think of it that way is fine, but renaming it will confuse everyone else... Andrew Gray 17:57, 19 November 2014 (UTC)


 * Please do not rename. This essential information must be readily understandable to anyne not familiar with ontology. The alias and the field "Source" above do make it clear to more technical people.  --  LaddΩ   chat ;) 02:45, 20 November 2014 (UTC)


 * Renaming does not solve the grounding problem, but the present solution isn't satisfactory either. And please avoid using the modeling of snaks as an argument for what to call the properties, those are from the code domain and doesn't belong here. Jeblad 02:02, 23 November 2014 (UTC)

German translation of this property
Zur Zeit heißt diese Eigenschaft "ist eine Instanz von", im Englischen lediglich "instance of". Was haltet ihr davon die deutsche Übersetzung auf "Instanz von" zu kürzen? Wie ist hier generell die Devise? --Faux (talk) 14:59, 23 March 2013 (UTC)
 * Das Problem ist, dass es gar keine "Instanz" ist. Die gibt es nämlich nur bei Gericht/Behörden. Im Allgemeinen würde man es wohl übersetzen "ist ein Beispiel für" oder "ist ein Fall von" oder den Instance-Quatsch ganz weglassen: "ist ein". -- HvW (talk) 17:25, 26 March 2013 (UTC)
 * Das stimmt so nicht, das es Instanzen nur bei Behörden gäbe; die gibt es auch in der Informatik (de:Instanz (Informatik)), worauf sich der Begriff hier auch bezieht. "Ist ein" enthält gerade die Doppeldeutigkeit die man vermeiden will: es kann sich sowohl auf konkrete Exemplare (Snoopy ist ein Hund) als auch auf Unterbegriffe (Hund ist ein Säugetier) beziehen kann, was zwei vollkommen verschiedene Sachen sind. --Mps (talk) 19:19, 26 March 2013 (UTC)
 * Ich hab’s jetzt wieder auf „Instanz von“ reverted, war „ist ein(e)“ (was ja eben so uneindeutig ist). Was haltet ihr von „Ausprägung“? --DSGalaktos (User talk:DSGalaktos) 22:18, 8 December 2013 (UTC)
 * Gut, dass neben ist eine Auspraegung von jetzt auch das verstaendlichere ist ein Exemplar von steht.
 * Aber Mitglied einer Gruppe ist missverstaendlich: Zum Beispiel ist Mitglied der Gruppe, aber dieser Zusammenhang darf gerade nicht mit  modelliert werden. Ich wuerde also die Gruppe aus der deutschen Beschreibung gern loeschen.  -- Juergen 62.143.196.71 12:07, 10 January 2016 (UTC)

Proposal regarding P107 and P31
Please see Wikidata_talk:Property_proposal; comments welcome. Emw (talk) 20:47, 24 March 2013 (UTC)

The definition of 'instance' and 'class'
There's an active discussion at Help_talk:Basic_membership_properties about the definitions of 'instance' and 'class' that's relevant to this property. Input is welcome! Emw (talk) 02:08, 19 April 2013 (UTC)

Nombre en español
Aunque no me acaba de convencer (¡ojalá alguien encuentre uno mejor!) he cambiado el nombre en español de esta propiedad a «ejemplar de», porque «instancia de» es un falso amigo como una casa. Instancia en español es jerga administrativa que significa varias cosas (memorial, solicitud, nivel de la administración, institución...) pero nada de lo que se quería decir aquí. --Rondador 13:08, 19 April 2013 (UTC)

instance of terms
Hi there,

how to handle with terms and "instance of"? I used sometimes "instance of term" for words like "physics" or "math" or similar, top-level items in a hierarchy. But someone has changed it to "subclass of" what is wrong in my opinion, because it indicates the word/item would be a subtype of term, which it isn't it. In the sense of terms a word could only be a instance. Of course, the using it this way is a redundant to "GND=term", but it would be a good statement to say "there is nothing else to describe this item". What do you think? (This is similar/the same as the problem with "profession", which has this been discussed somewhere. (But where?)) --&#35;Reaper (talk) 11:14, 27 April 2013 (UTC)

Instance of + Subclass
If A is an instance of B, which is a subclass of C, it can be inferred that A is also an instance of C. Should this be explicitly added or not?

Examples: Which one is the correct way? --DSGalaktos (talk)
 * Windows Phone 7 is an instance of Mobile operating system, which is a subclass of operating system. However, Windows Phone 7 is not directly listed as an instance of operating system.
 * Porto Alegre is an instance of city with millions of inhabitants, which is a subclass of city. However, Porto Alegre is also explicitly listed as an instance of city.


 * Hi. You should only add the lowest item of the hierarchy. So "mobile operating system" as single value would be correct, the same for "city with millions of inhabitants". (They might be only sometimes exceptions, but don't be afraid, the lowest item would ok and could be checked easily.) Greetings, --&#35;Reaper (talk) 13:25, 27 April 2013 (UTC)


 * An attribute with "city with millions of inhabitants" seems stupid to me ... city is a static value while the number of inhabitants is not. That number should be a value. GerardM (talk) 13:12, 6 May 2013 (UTC)
 * Yes, we should probably have guidelines to prevent "instance of city with millions of inhabitants", but not sure how. "City" does not seem very useful either as it is a rather fuzzy word. For Portro Algera, I think it should be an instance of municipality of Brazil (and perhaps also an "instance of state capital" though that seems rather odd to me). --Zolo (talk) 13:59, 6 May 2013 (UTC)


 * I would have thought that is a subclass of, and the instances would be the actual installed OS on a given phone. Installations are instances. Danrok (talk) 14:25, 30 May 2013 (UTC)
 * Actually we handle software as an instance, because a (digital) copy (what an installation would be) would be.. um.. a bit fuzzy and "useless". (A computer is a "copy machine", everything is copied there.) --&#35;Reaper (talk) 17:03, 2 June 2013 (UTC)
 * Danrok, your interpretation is correct: Wikidata items about software concern classes, not instances. To Reaper's point: how would handling software as an instance be more useful than handling it as a class?   is not a particular, concrete thing in space and time (i.e., it is not an instance); so classifying it with 'instance of' is not correct.  Instances of  would be particular installations of it; the item itself concerns the class of such things. Emw (talk) 18:14, 2 June 2013 (UTC)
 * For mass produced items like software, cars, books, movies, etc. our practice is to use 'instance of' for each model/type/novel rather than for individual dvds/books/cars. We justify this to ourselves by saying the item is for a particular design/copyright/brand rather for a particular expression of that copyright. Filceolaire (User talk:Filceolaire) 21:23, 4 December 2013 (UTC)

Both instance and subclass
I'm still having a little trouble with the instance/subclass usage. Is it really not possible to have both for one item? I have for example an item about a stratigraphic formation which is an "instance of = formation". And the formation belongs to the "Lower North Sea Group". Would it be better to say "Lower North Sea Group". I was also wondering why there isn't a constraint-template that says that items with "instance of" should not hold any "subclass of" statements. --Tobias1984 (talk) 07:29, 26 July 2013 (UTC)
 * Your usage of and  are both correct.  I corrected .  See Help:Basic membership properties that provides a pretty good summary of use.  That error would have been caught in the next User:Byrial/Class-type conflict (mismatching types between two items linked by ).  I am not aware of a constraint identifying items with mutually exclusive properties; possibly  has another report for this already?  You may also check in Database reports. --  LaddΩ   chat ;) 02:22, 28 July 2013 (UTC)

Qualifiers
It would be useful to write out recommendations on how to qualify properties like, , and related properties

I would say: use
 * to restrict the applicability of an item in a general manner (example: )
 * to restrict the applicability to a geographical area (example: ). I think it different from . Here Shanghai means "in the municipal area of Shanghai", while using  would rather mean "by Shanghai Municipality."
 * and when the item is part of a series (example: )
 * Date qualifiers when they apply specifically to the statement. For example the dates when Stubbs was mayor in . I am not quite sure for other cases. Should we have date qualifiers in in instance of National Congress of the Communist Party, or should the dates be in an indepedent statement ? --Zolo (talk) 07:03, 4 September 2013 (UTC)

Maybe we I should start a RfC, but there are already so many of them, that it may more efficient if we can agree on a basic structure withou t going though that. --Zolo (talk) 07:03, 4 September 2013 (UTC)
 * A qualifier should be only used to define a property. It should not be used to define the Item. Then we should not use it as a qualifier then as claim of the item. I don't know why there should be recommendations for these properties different then for all properties, can you explain this? We have Qualifier for all properties. --Sk!d (talk) 11:25, 4 September 2013 (UTC)
 * If by "A qualifier should be only used to define a property. ", you were referring to my question about where to place the dates for , I think I agree with you.
 * Actually, my proposal was also may also apply for other properties, and I should probably have posted this on the project chat. I was just trying to see if we can document the use of qualifiers, as it may have a large impact on item structure. My proposal may apply to various other properties, but I found it easier to start with one or two properties rather than doing things it in a more general and abstract way. I think P31 and P279 are good starting points, as they are very important and commonly used, and they do define what the item is. --Zolo (talk) 12:41, 4 September 2013 (UTC)
 * Hi, I have a RfC on the pipe, unfinished so it's not published at this time, see w.wikidata.org/wiki/Wikidata:Requests_for_comment/Constraint_violation_technical_bases TomT0m (talk) 12:48, 4 September 2013 (UTC)

Inconsistency?

 * instance of ;
 * instance of ;
 * instance of ;
 * instance of ;

but
 * instance of.

Why not
 * instance of Wikipedia article?

Looks like different relation types. Why do we use same property for both cases? — Ivan A. Krestinin (talk) 19:05, 5 September 2013 (UTC)
 * Great question. You're right; there is an inconsistency.  For several months I've argued against using P31 and P279 for classifying internal details of Wikimedia projects like templates, category pages, etc.  It's not only encyclopedic navel-gazing, it also requires us to arbitrarily add an entirely different perspective to Wikidata's concept hierarchy -- we need to say "these things over here are about the external world" and "those things over there are about internal details of Wikimedia projects."  I think P31 and P279 (and probably all other properties) should be confined to the respective mainspaces of the Wikimedia projects supported by Wikidata. Emw (talk) 00:34, 6 September 2013 (UTC)
 * I am glad someone else sees this as a problem after all! I was trying to argue that the only logical solution to this is to make the items that do not represent real-world things as a different entity type, move them from Q12345 to N123456, for example. Littledogboy (talk) 13:36, 6 September 2013 (UTC)
 * Except it is a real-world thing. I can trivially view a wiki page of a particular type. So your statement isn't logical at all. Would you care to amend it? --Izno (User talk:Izno) 03:52, 8 October 2013 (UTC)
 * It's hardly navel-gazing for us (in this case) to minimally categorize the pages on the wikis, not least because our secondary users among others include the wikis themselves (and the researchers interested in those wikis). It aids in constraint checking for the main category topic claim (and its inverse, among others), and there will be secondary users of the data. Your solution is radical given the practical situation. P31 and P279 (and a handful of others specifically meant to tie Wikipedia to what LDB calls "real-world things") are probably the few claims which in fact can be meaningfully used on such pages. --Izno (User talk:Izno) 03:52, 8 October 2013 (UTC)
 * You could, but there's no reason to except that you're concerned about the inconsistency (on an aside, I would agree, there is an inconsistency). It's a compromise between "let's describe what we should care about" and "let's make it easy to figure out how many templates etc. we have". It also decreases the need for a new (or several new) properties meant to describe those pages&mdash;an irony, given that that would certainly be worse in Emw's eyes. :) --Izno (User talk:Izno) 03:52, 8 October 2013 (UTC)


 * I agree with Emw. References to our own internal structure are not typical subclasses or instances. (And if we treated them like real-world things, as Izno suggests, then I would nominate most of them for deletion as non-notable, because we don't have all of the internal categorization pages of other websites.) I think it would be reasonable to create one new property called "type of wikimedia page" so that these pages could remain sorted but they wouldn't be mixed in with actual content. --Arctic.gnome (User talk:Arctic.gnome) 05:24, 3 December 2013 (UTC)

Value statistics
Can we get somewhere statistics of (probably, most frequent) targets of this property? --Infovarius (User talk:Infovarius) 13:03, 27 December 2013 (UTC)
 * Можно временно добавить: { {Constraint:One of|values=}} при этом бот сгенерирует статистику при очередном обновлении Database reports/Constraint violations/P31. — Ivan A. Krestinin (talk) 21:38, 5 January 2014 (UTC)
 * Отчёт сгенерился, посмотреть можно здесь (открывается долго). — Ivan A. Krestinin (talk) 23:17, 5 January 2014 (UTC)
 * Thanks a lot, Ivan ! To summarize, as of Jan 6, 2014, P31 was used by 5119213 items (full table is here) -  LaddΩ   chat ;) 00:31, 8 January 2014 (UTC)

Correct 'instance of' value for a football match?
I have been adding statements to all of the FA Cup final matches, and there doesn't seem to be any value I can meaningfully use for the 'instance of' property. One would imagine that 'football match' would be the appropriate value, but as there are no articles in any of the Wikipedias with this title, it doesn't appear in Wikidata. Any ideas about what to do for this? NavinoEvans (User talk:NavinoEvans) 14:08, 4 March 2014 (UTC)
 * I faced this problem in the past for some sports, and actually an option may be to use the item for the sport : . This item define the game, the goal of the games, the rule … and a football match is actually a concretisation of this abstract concept that is thu rules of the game. A safest way is to create a class item like  and ' with statements like while we decide if we need a new item or not for the upper levels. TomT0m (User talk:TomT0m) 15:18, 4 March 2014 (UTC)


 * Many thanks . I think the option of creating the class items  and  sounds like the best bet. I haven't actually created any new items yet, and I'm aware that there is a guideline stating that no new items should be created unless they contain at least one valid sitelink to a Wikipedia, Wikivoyage, Wikisource, or Wikimedia Commons page. Do you know if this restriction applies to items that are only intended to be classes? NavinoEvans (User talk:NavinoEvans) 22:03, 4 March 2014 (UTC)
 * see WD:N, it is not required to have a sitelink if the item is needed to make a statement about another notable item. It's fine (and legitimate) in that case, . TomT0m (User talk:TomT0m) 22:42, 4 March 2014 (UTC)
 * see WD:N, it is not required to have a sitelink if the item is needed to make a statement about another notable item. It's fine (and legitimate) in that case, . TomT0m (User talk:TomT0m) 22:42, 4 March 2014 (UTC)


 * That's brilliant, thank you for your help . I'll go ahead and make those new classes. Regards, NavinoEvans (User talk:NavinoEvans) 23:32, 4 March 2014 (UTC)


 * One more thing I've just realised - there is actually already an item in Wikidata 'FA Cup Final' (Q4484477). Should I actually use this value instead of making the class  ? (e.g. '1970 FA Cup Final' is an instance of 'FA Cup Final')
 * Presumably we could then create the suggested class  such that ) ? NavinoEvans (User talk:NavinoEvans) 00:19, 5 March 2014 (UTC)
 * I think you got the spirit, :) There might also be an item for the corresponding category  (I'll add the statements to officialise this) and even an open RfC to decide what we should do with all these kind of similar items Requests_for_comment/Define_lists_on_both_"Wikimedia_lists"_and_"Wikimedia_categories". One more thing : you will like the autolist tool which will help you to batch add statements on all the items on a Wikipedia category, amongst other things :) TomT0m (User talk:TomT0m) 12:35, 5 March 2014 (UTC)


 * , thank you so much your help with this! - Autolist is absolutely amazing :) an extremely powerful tool which will help me no end with my editing efforts. I'll do some more learning about it and then have a go at using the batch statement adding to update all of the FA Cup Finals (and hopefully many more things in the future!). All the best, NavinoEvans (User talk:NavinoEvans) 15:05, 5 March 2014 (UTC)
 * Well, that's my first hour of time saved by using Autolist - added 'instance of' property to the whole lot in less than 5 minutes :) NavinoEvans (User talk:NavinoEvans) 15:33, 5 March 2014 (UTC)

are human roles and positions an instance-of human?
I'm sure this was asked before, but didn't know where else to look, so I'll ask here: are items describing roles or positions (e.g. President of France) to be classified as instance-of human? In other words, are humans only specific, concrete humans, or are they also roles held by humans? Thanks. Ijon (User talk:Ijon) 22:40, 22 May 2014 (UTC)
 * Ijon, no, human roles and positions should not have 'instance of: human' claims.   is for particular people, e.g. . Emw (User talk:Emw) 00:42, 23 May 2014 (UTC)
 * Thanks, Emw, that's what I thought. I'm removing P31 from, then. Ijon (User talk:Ijon) 02:11, 23 May 2014 (UTC)

Definition of 'instance of'
Right now the description for this property is 'this item is a concrete example and a member of that class'. However there are countless examples of instances that are not concrete. For example, hatmaking is an instance of craft, but hatmaking is not a concrete thing. Can we change 'concrete' to 'specific'? Kaldari 01:05, 21 November 2014 (UTC)
 * Hatmaking is a class, so your example is flawed. --Izno 07:36, 21 November 2014 (UTC)
 * It is currently defined as an instance, so I'm not sure what you mean. Regardless, there are countless possible examples. Another is: general relativity is an instance of theory. There is no reason an instance should be limited to concrete items. Kaldari 01:04, 24 November 2014 (UTC)
 * I changed the wording from 'concrete' to 'specific' since no one had objected to the idea. Feel free to revert if you disagree. Kaldari 21:18, 26 November 2014 (UTC)
 * Sounds good. Andrew Gray 22:30, 26 November 2014 (UTC)
 * My edit was reverted by an anon IP with no explanation. Does anyone else have an opinion on it? Kaldari 18:53, 3 December 2014 (UTC)
 * The revert looks good. Fix the statements instead. Andrea Shan 04:22, 4 December 2014 (UTC)
 * I don't see how it makes sense to define hatmaking or general relativity as classes rather than instances. A class is a group of things. How is hatmaking or general relativity a group? Kaldari 02:34, 8 January 2015 (UTC)

See also: Subclass of?
Regarding ’s edit of adding , and ’s edit of removing it with the comment “different!”:

I disagree with that removal. I don’t think that “see also” implies “the same”; on the contrary, I think that the difference between and  might become clearer to people, especially those who aren’t familiar with these concepts, if they are immediately shown that there is a separate property for the related concept which intuitively they might have assumed to be the same.

Because of this, I suggest that the revert should be reverted again, i. e., the statement  re-added. Comments? —DSGalaktos 02:14, 17 January 2015 (UTC)

Usage with a twin
For example, Q5622183 has two entries Q5 (human) and Q159979 (twin). It does not seem right to me that P31 has two entries even though the description on twin states "Use with P31 on items for one twin". Is it the correct usage to include twin alongside human? Periglio 20:11, 24 January 2015 (UTC)
 * I don't consider Q159979 as an error - it is about "one of the twins" (not both). May be in this case Q5 is superfluous but I am not sure: can be an animal or a character? --Infovarius  16:03, 28 January 2015 (UTC)
 * As of 27 december 2013, a twin has been declared subclass of a human, but immediately reverted and declared a set of humans, maybe because the user who did this is russian and the russian description, which I cannot see, falsely stated is the set of two twins ??
 * As long as that (IMHO wrong) state persists, we need both instance-of-relations, because currently twin is not subclass of a human.
 * But I think that revert should be reverted and twin be made a subclass of human again, and when that would be done, we would no longer need to declare a twin also a human.
 * Anyway, a twin cannot be an animal or character, neither in the current nor in the suggested defintion.  -- Juergen 62.143.196.71 12:15, 10 January 2016 (UTC)
 * ru:Блицзнецы and some other articles linked to describe twin set, not the single twin. Russian term близнецы (twins) is applicable for fictional characters. Also it is applicable for mammal and some other animals. Maybe the best way is excluding Q159979 from P31/P279 classes tree because the term has different meaning in different languages. — Ivan A. Krestinin (talk) 12:41, 10 January 2016 (UTC)
 * Articles like that should be moved to . --Yair rand 17:55, 10 January 2016 (UTC)

French translation of
As the meaning of the french translation nature de l'élément of is not as clear as the english instance of, especially on the page Help:Basic membership properties, I suggest several possibilities compatible with the expression    :
 *  exemplaire de 
 * --Djiboun 19:44, 22 February 2015 (UTC)


 *  élément de 
 * mix-up with the french translation of item --Djiboun 17:16, 15 February 2015 (UTC)


 *  instance de <classe Y>
 * too much abstract, but exact translation --Djiboun 17:16, 15 February 2015 (UTC)


 * <instance X> est un/une <classe Y>
 * good enough --Djiboun 19:44, 22 February 2015 (UTC)


 * <instance X> nature de <classe Y>
 * opposite meaning of the original --Djiboun 17:16, 15 February 2015 (UTC)


 * <instance X> expression de <classe Y>
 * not enough precise --Djiboun 17:16, 15 February 2015 (UTC)


 * <instance X> nature de l'élément <classe Y>
 * ok for property description, but opposite meaning of the original --Djiboun 17:16, 15 February 2015 (UTC)

If any french wikidatar, as Genium, can give his opinion, we could take a collective decision. Sorry for my hasty modifications today. --Djiboun 17:16, 15 February 2015 (UTC)

English translation is not the reference, IMO, the wording nature de l'élément is the best translation for rdf:type as explained here, much better for humans (speaking French)… genium    ⟨✉⟩   18:33, 15 February 2015 (UTC)
 * Traduire c'est trahir. Il n'y a de toute façon pas de bonne réponse à ce genre de question.
 * Utiliser « instance » serait une traduction plus littérale mais « instance » est un mot rare en français (voir un néologisme inconnu, le sens courant d'instance dans la langue française est l'acception juridique utilisé dans « tribunal d'instance ») et c'est du jargon technique. Cela ne me semble donc clairement pas la meilleure solution (à ajouter en alias par contre). Je suis très perturbé par « exemplaire » ; j'ai tendance à voir l'adjectif avant le substantif et le substantif me semble trop restrictif (on parle de l'exemplaire d'un objet uniquement en particulier d'un livre ou d'une œuvre) et fait penser à « exemple » (dans le sens « modèle à imiter »). Sans compter qu'il y a déjà . En français « nature » est un synonyme de « type », je ne vois pas en quoi ce serait un “opposite meaning”. « est un(e) » me semble une solution simple et intéressante (ce que font plusieurs autres langues dont les germanophones avec « ist ein(e) »).
 * Cdlt, VIGNERON 19:11, 22 February 2015 (UTC)


 * Bonjour, je vais m'exprimer en français vu qu'a priori, cette discussion ne concerne que les francophones . Bref, je n'ai pas très bien compris ce qui ne te plait pas avec nature de l'élément. Pour moi ça veut bien dire « qu'est ce que c'est que cet élément ? ». L'alias « est un/est une » me parait aussi une bonne idée même si je vois que ça ne te plait pas. Bref, je ne comprends pas ton problème. Quel exemple précis dans Help:Basic_membership_properties/fr te pose problème ? Pamputt 19:13, 22 February 2015 (UTC)
 * Hors sujet  au lieu de  . Eric-92  02:28, 24 February 2015 (UTC)

Merci à vous pour vos réponses. Effectivement, pour répondre à VIGNERON, la traduction par «est un(e)» me semble en fin de compte la plus évidente. Pour répondre à Pamputt, l'origine de ma confusion est venue de «<X> nature de l'élément <Y>» dans la page Help:Basic_membership_properties/fr qui signifie en fait, si j'ai bien compris, «la nature de l'élément <X> est <Y>». En conservant la traduction de la propriété, il faudrait traduire le texte par «<Y> nature de l'élément <X>». Si on change la traduction de la propriété on pourrait avoir «<X> est un(e) <Y>». Est-ce que la traduction de la propriété doit être modifiée ? Je ne me prononcerai pas seul sur la question, mais il faudrait en tout cas adapter la traduction du texte dans Help:Basic_membership_properties/fr. --Djiboun 19:44, 22 February 2015 (UTC)
 * Le soucis avec "est un", c'est que ça marche aussi avec sous classe de. On a "Lassie est un chien" qui marche aussi bien que "un chien est un animal". Or dans le premier cas, on veut dire "Lassie appartient à l'ensemble des chien", et dans l'autre "Tout chien est aussi un animal", ou, en maths "l'ensemble des chiens est un sous ensemble de l'ensemble des animaux". Du coup on introduit une ambiguité en utilisant "est un" qui n'est pas souhaitable parce que cette distinction est fondamentale. cf. l'article de enwiki pour . author TomT0m / talk page 14:33, 10 January 2016 (UTC)

Que dit le nom en anglais ? D'ailleurs je pense que chaque langue a ses difficultés. Nature de l'élément propose une simple définition de l'objet, alors pourquoi ne pas mettre objet ou bien définition de ... ou autre équivalent pour que nous comprenions quoi inscrire car il est vrai que nature de l'élément n'est pas simple à comprendre pour tout le monde qui arrive sur wikidata. — Nicolas ANCEAU
 * Le problème principal vient de la confusion entre "nature de" et "sous-classe de", pas évidente du tout, alors qu'elle est claire entre "instance de" et "sous-classe de" (les deux termes sont liés, une instance est une réalisation objective et unique de la classe, laquelle definit un type; une "instance" n'a pas de type dérivé, sinon c'est une sous-classe et sa réalisation n'est pas unique; une instance peut éventuellement être "clonable" mais le clone n'a alors plus aucun lien avec l'instance d'origine même si elle en partage le type, c'est-à-dire la classe; appliqué à une personne partriculière, la cloner produirait une personne particulière différente, elles seraient toutes les deux des instances de la classe "personne").

Si "instance de" n'est pas assez clair, alors l'autre terme sera "est un" ou "est une". (probleme: lequel des deux genres afficher: "est un(e)" ?) "Nature de" est trop ambigu entre les deux usages, la classe étant plus abstraite que l'instance, mais "nature de" en donne une vision concrète.

Quant au terme "sous-classe de", il peut aussi être traduit par "hyponyme de" en bon français, mais il est encore moins compréhensible (mais on le trouve utilisé sur le Wiktionnaire), et trop restrictif (toutes les classes et sous-classes ne sont pas des "noms" auxquels le terme "hyponyme" pourrait s'appliquer (exemple: "s'évaporer" est un verbe qui serait une sous-classe de "changer d'état" dans le cas partioculier du passage de l'état liquide à l'état gazeux, mais "s'évaporer" n'est pas un "hyponyme" de "changer d'état"; autre exemple "bleu foncé" est une sous-classe de la couleur "bleu", "bleu marine" est une sous-classe de la couleur "bleu foncé", les instances sont les nuances réelles dans une condition précise d'éclairage, y compris des composantes inobservables par le seul oeil humain ou par certaines personnnes). Verdy p 09:21, 10 February 2016 (UTC)


 * D'ailleurs je suis persuadé que le mêm débat existe au sein de la norme RDF, particulièrement pour la modélisation de connaissances dans le domaine général (au delà de la distinction qui est faite dans certains languages de programmation... mais pas tous). X rdf:isA Y n'est rien d'autre qu'un raccourci pour dire que X est une sous-classe de Y et qu'il n'existe aucune sous-classe de X. Bref rdf:isA est une simple restriction qui interdit de réinstancier.
 * Dans Wikidata, on ne code pas comme dans C++ ou Java, toutes nos connaissances dont à tout moment réinstanciables pour les spécialiser. Bref la distinction (qui pose aussi des problèmes pour traduire nature de ou est un, dans toutes les langues, et qui contredit en fait totalement le sens usuel en voulant apporter une distinction totalement artificielle inutile) n'est pas justifiée du tout.
 * Pour moi 'nature de' (rdf:isA) ne sert à rien dans Wikidata et ce devrait être la même chose que 'sous-classe de'. Si on veut indiquer qu'il ne peut pas exister d'instances, il vaudrait mieux coder une autre propriété non instanciable (en Java ça s'appelle aussi final pour indiquer qu'une classe n'est pas dérivable, mais elle peut avoir des instances donc ce n'est pas tout à fait la même chose), et que donc elle ne peut être associée qu'à un unique élément de Wikidata (Qnnnn) qui ne peut donc avoir aucun autre élément dérivé (mais pour affirmer qu'il ne peut y en avoir aucun, c'est très délicat, en fait c'est même totalement indémontrable)
 * D'où des tonnes de violations de contraintes avec nature de et le besoin permanent de transformer des objets créés initialement comme instances de X pour en faire des sous-classes de X...
 * Je l'ai déjà dit dans d'autres dicussions, distinguer 'nature de' (intance de, est un) et 'sous-classe de' ne peut que produire des tonnes de problèmes inutiles.
 * En dehors de Java et C++ qui font ces distinctions articificielles (uniquement pour des raisons propres à l'implémentation concrète de ces langages et la façon dont ils prennent en charge les classes et les compilent ou les rendent exécutables), d'autres langages de programmation ne font jamais cette distinction, car ils s'appuie sur le bon sens et l'usage courant: dans ces derniers, tout objet est en lui même aussi une classe, on peut toujours à tout moment en créer une nouvelle instance (qui sera aussi une nouvelle sous-classe): c'est le cas par exemple de Javascript qui lui n'a absolument pas besoin de cette distinction entre "classe" et "objet" ni entre "instance de" et "sous-classe de". RDF et OWL feraient bien s'en inspirer et ne pas chercher à calquer C++ ou Java (si RDF veut représenter les objets C++ ou Java, il ferait mieux de modéliser les contraintes "final", ou "non instanciable" spécifiques à ces langages; pour le reste (et notamment l'immensité des connaissances de Wikidata) ces contraintes sont beaucoup plus une gêne inutile qu'autre chose, qui ne fait que créer des violations de contraintes et polluer Wikidata réellement pour rien Les données de Wikidata n'ont pas à être spécifiquement conçues pour être "mappées" sur des objets et classes C++ ou Java.
 * Bref simplifions et ne mettons plus dans Wikidata qu'une seule et même propriété pour "nature de" (est un) et "sous-classe de". On ne pourra jamais prouver que n'importe quel élément Wikidata ne peut jamais être réinstancié/dérivé/spécialisé et dans la pratique cela se produit dans tous les domaines abordés par Wikipédia, Commons, ou la quasi-totalité des autres projets hors Wikimedia (y compris dans les schéma de classification "systématique" tels que Wikipecies), la seule exception étant les modèles de données pour C++ ou Java ou les vieux languages de programmation "objet" qui distinguent encore (à cause de limitations techniques internes) classes et objets, instances et sous-classes: ces limites techniques (qui sont encore très gênantes dans ces languages pour modéliser des tas de choses) sont révolues, on se passe totalement de ces distinctions et les nouveaux langages objets savent pourtant obtenir un code exécutable, et permettent une modélisation bien plus simple des concepts. Voir à ce sujet les notes qui existent aussi dans UML (où C++ et Java sont critiqués pour leurs vieilles limitations, ces langages ne sont même plus réellement considérés comme de véritables langages objets pour la POO et plus du tout utilisés pour la modélisation; UML a lui aussi levé cette vielle limite technique, qui sont également de très grands freins pour l'évolutivité des modèles conceptuels et compliquent énormément les déploiements ou la compatibilité ascendante, et qui ont aussi un effet nuisible sur la maintenance des systèmes installés en multipliant la quantité de code "dupliqué" à chaque évolution).
 * Réfléchissez-y. On n'a pas besoin d'amener dans Wikidata cette surcharge inutile de travail et de maintenance. Les difficultés dans C++ et Java ne sont pas du tout le problème de Wikidata, et d'ailleurs il existe maintenant aussi en C++ et Java des bibliothèques toutes prètes pour pouvoir utiliser directement (sans aucune réécriture) un modèle de données générique qui ne dinstingue pas classes et objets (c'est une acrobatie, mais ce n'est pas moins efficace, c'est même en fin de compte moins lourd à gérer même dans ces langages, et même si pour cela on ne doit plus mapper directement une classe UML/RDF/OWL en classe Java ou C++ mais utiliser un framework avec une bibliothèque assurant l'interface; mais grace à elle on améliore grandement l'évolutivité des modèles, et la maintenance des systèmes déployés).
 * Conséquence: je reste pour la fusion de "nature de" (P31) et "sous-classe de" (P279) en une unique propriété dans Wikidata (quitte, dans des cas très exceptionnels qu'il sera en fait très difficile de justifier, à avoir besoin d'ajouter une propriété "non instanciable"="non dérivable"). Dès lors qu'on aura fait ce choix, il n'y a plus aucune difficulté de traduction: "nature de", "sous-classe de", "est un" sont synonymes conformément à leur signification habituelle, et cette propriété unique s'appliquera à tous les cas. Verdy p 12:08, 10 April 2016 (UTC)
 * C'set marrant tout ces gens obsédés par la programmation, mais c'est pas de ça qu'il s'agit, c'est de représentation des connaissances. Et pour ça on a un principe philosophique qui marche pas trop mal, cf. https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction Après on peut / doit monter en abstractions pour les choses plus abstraites comme la description de la structure des entités administrative d'un pays : Bretagne -> région -> type d'entité administratives. Et là, pour dire que "région" est un type, tu est obligé d'avoir un axe classe -> métaclasse et pas simplement un axe de sous-classement parce que ça ne représente pas du tout la même chose. Cf. en:metaclass (Semantic Web) et en particulier le papier sur l'ontologie Cyc et ses niveau de métaclasses qui set passé il y a quelques jours sur le bistro et que j'ai intégré dans l'article. author TomT0m / talk page 13:45, 10 April 2016 (UTC)
 * Voir aussi la classification des atomes / éléments / hydrogène sur le dessin ci après. [[file:atom classes.svg|thumb]] qui fonctionne très bien. author TomT0m / talk page 13:47, 10 April 2016 (UTC)
 * Ce n'est pas moi qui suis obsédé par la programmation, mais vouloir distinguer "sous-class de" et "instance de", cela vient justement de gens obsédés par ça (et justement qui ne connaissent que quelques languages qui font cette distinction ! Tout me comprend complètement à l'envers.
 * Ce que je dis est que cette distinction n'a PAS sa place dans Wikidata, elle rompt la notion importante de transitivité (en marquant le dernier niveau de façon bloquante), elle n'est pas stable du tout (à tout moment un concept dans Wikidata et dans les autres projets peut avoir besoin de spécialiser/instancier/sous-classer un concept).
 * Bref relis exactement et correctgement ce que j'ai écrit pour comprendre réellement. Cette distinction est totalement artificielle, uniquement issue des languages C++ ou Java ou similaires, alors qu'on peut tout faire avec une seule et même propriété ("sous-classe de" = "instance de" = "est un"), quitte à ajouter en plus (seulement dans quelques éléments concernés, mais ça risque d'être vite faux dans plein de pages Wikipédia ou ailleurs), une propriété "non instanciable"="non dérivable"="non spécialisable" (qui ne peut être vrai que dans une vue limitée d'un même concept et faux ailleurs, dès qu'on fouille un peu ou selon l'analyse apportée).
 * Ni l'une ni l'autre des deux propriétés n'a fait l'objet d'une réelle analyse formelle, elles ont été imposées de facto, sans réflexion préalable.
 * Fusionner les deux propriétés n'impêchera jamais de pouvoir faire un tableau des éléments chimiques.' Mieux, elle permettra de spécialiser l'uranium, par exemple en "uranium-238" ou "uranium-235"... Comme quoi ce qu'on croit non spoécialisable le devient vite: voouloir distinguer "uranium" en en faisant une instance d'élément chimique (bloquant son utilisation dans un autre concept qui en serait instance ou sou-classe), empêche d'en faire aussi une classe dérivable ou instance pour "uranium-238". On peut encore sous-classer avec les états d'excitation, les formes cristalines...
 * Verdy p 16:32, 10 April 2016 (UTC)
 * En plus ton schéma d'exemple sur les atomes est totalement faux dans les "métaclasses" (une obsession de ta part d'un programmeur C++)... Tout est déjà représenté dans la colonne centrale (classes), le reste est clairement redondant (colonne gauche), ou faux (colonne droite). Et si on part comme ça le nombre de colonnes dans ton schéma est illimité dans Wikidata alors que tu veux en fait exprimer d'autres contraintes, mais pas le classement lui-même. Verdy p 16:34, 10 April 2016 (UTC)
 * Excuse moi mais mon schéma n'a rien d'incompatible avec ce que tu racontes. T'es sur que tu lis les liens ? author TomT0m / talk page 21:59, 10 April 2016 (UTC)

alias 1
can you please explain this edit? I have no idea what “1 to start” is supposed to mean, sorry… —DSGalaktos 15:52, 29 March 2015 (UTC)


 * Type "1" and enter the 1st statement. ;)
 * I tried "is a", but this usually gets me another property. --- Jura 16:00, 29 March 2015 (UTC)


 * So this is just so you can find the property easier when entering a new statement? Why not type “instance of” instead of inventing an arbitrary alias just so you can find the property easier? —DSGalaktos 16:25, 29 March 2015 (UTC)
 * I'd have to type "insta" until "instance of" appears. BTW it seems that they will fix MediaWiki to make P31 appear as choice when there is no statement on an item. --- Jura 16:36, 29 March 2015 (UTC)
 * If you want typing efficiency, type “P31”. Three characters. Having this property as the default proposal when there are no statements also seems reasonable. But what’s not at all reasonable, IMHO, is adding a completely meaningless alias to the fundamental property of Wikidata, just so you (you alone; I don’t imagine anyone else will just guess that “1” is a shortcut for “instance of”) have to type four characters less. If it came from someone with less useful edits than you (thanks for those, btw), I’d call this vandalism. —DSGalaktos 17:21, 29 March 2015 (UTC)
 * Now that you now what it is, you could start using it. Oh, if one doesn't contribute by editing anyways, one could just revert and say iznogood. --- Jura 20:41, 29 March 2015 (UTC)
 * Someone needs to take a look at my contributions. ;) --Izno 02:56, 30 March 2015 (UTC)
 * Please point us to the ones you want us to look at. --- Jura 07:10, 30 March 2015 (UTC)
 * This one, I assume :) —DSGalaktos 12:47, 30 March 2015 (UTC)

Instance of = owl:NamedIndividual (not rdf:type!)
The misuse of P31 "instance of" rather than "subclass" is a big problem issue for transitive queries. This may be the most used property in Wikidata, making well over 16M truthy statements. This is likely because the definition for the property is conceptually wrong. Rather than rdf:type which is a very broad semantic concept, "instance of" should be defined by its domain → owl:NamedIndividual.

The semantics of a "named individual" are different from a "type", and more closely align with the functional intent of this property, which is to terminate (or fork) a transitive property path. In fact, most "types" (i.e. categories) are simply subclasses and not individuals. Applying a "derivative name" as a "type group" to a concept class does not instantiate it, but rather "clones" it as a subclass. For example, "Italian Women's Fashion" is not an instance of "fashion", but a subclass. Categorization by type is not distinct from subclassing!!! This may be hard for many people to grasp because of the application of a proper name to a class, so it is not surprising why it is so often done incorrectly.

NamedIndividuals are easily recognized in English, as they usually have a distinct proper name, like people, plant/animal (sub)species, films, books and places. I therefore feel that this property definition needs to be clarified. And many inappropriate uses of this property should be rectified. It should be noted that it is possible for a NamedIndividual to also be a subclass (i.e. "metaclass") depending on its usage. But clearly, many NamedIndividuals are not subclasses, and these are the ones that need to be instantiated with P31.

Chjohnson39 13:35, 26 April 2016 (UTC)
 * : MMmm NamedIndividual seem to be an OWL class, not a property : https://www.w3.org/2007/OWL/wiki/FullSemanticsNamedIndividuals so I don't really think what you write make any sense. But you should start the talk on  author TomT0m / talk page 15:02, 26 April 2016 (UTC)
 * Right, but this shouldn't be used (except in the case of punning) as we use it (which is a divided opinion on the wiki). --Izno 16:27, 26 April 2016 (UTC)
 * : See clarification above: P31 "instance of" should be defined by its domain → owl:NamedIndividual. And actually, an rdf property is an instance of an rdfs:Class. https://www.w3.org/TR/rdf-schema/#ch_property Furthermore, P31 "instance of" has an rdf:type of its own, which is owl:ObjectProperty, so it is definitely not correct say that "instance of" is equivalent to rdf:type. I will join the discussion on .-- Chjohnson39  19:41, 26 April 2016 (UTC)
 * And actually, an rdf property is an instance of an rdfs:Class No. According to your link "rdfs:Property" is a class. This does not mean that each instance of rdfs:Property is an instance of "Class", because instance of is not transitive. author TomT0m / talk page 19:58, 26 April 2016 (UTC)
 * : There is no such thing as an rdfs:Property. rdf:Property is an instance of rdfs:Class, that is exactly what it says in the link.  When instantiating an rdf:Property as an rdfs:Class by using P31 in a statement, this has no relation with the meaning and function of P31 "instance of" in the statement itself.  The domain of P31 should be a NamedIndividual and the Range should be a class, it is quite simple.  In theory, "instance of" should only be transitive if the entity is a metaclass, meaning both a NamedIndividual and a Class.  As a NamedIndividual, there should be no further subclass property path.  It is basically the end of the entailment chain.  In practice, P31 as it is used now creates a black hole for many abstract groups (i.e. Q28640:profession) whose NamedIndividual member aggregation cannot be reasoned (with subclass transitivity) if they are nested inside of "instances".  For example, Q1028181 "painter" is both a subclass of "visual artist" and an "instance of" profession.  Correctly stated, a painter is a subclass of visual artist and a subclass of profession, and is certainly not a NamedIndividual (in that context).--Chjohnson39  21:49, 26 April 2016 (UTC)
 * Instance of is never transitive. End of discussion. author TomT0m / talk page 10:52, 27 April 2016 (UTC)

label (ru)
это частный случай понятия - понятия существуют в пространстве мозга. Здесь - термины (словаря) --Fractaler 12:33, 2 September 2016 (UTC)

Is "usually an instance of" good enough?
Please see Property talk:P569. That discussion is about whether we should say that a is a. Wikidata encodes birth dates. Gregorian birth dates can be encoded as a vCard value. But Wikidata also has Julian birth dates, which can't be encoded as vCard values unless they're converted first. In addition, Wikidata does not provide any facility to input or output vCard values. Sure, quite a few Wikidata properties could be transformed to or from vCard values, but any such transformation is outside the scope of Wikidata. Jc3s5h 16:05, 20 September 2016 (UTC)
 * Can't you qualify it with "according to" or whatever that property name is? --Izno 17:59, 20 September 2016 (UTC)
 * No. The property "instance of" is is being added to the property "birth date". So this is a claim about all birth dates. "According to" could be added to a claim about a particular person's birth date, but it doesn't make sense to add it to P569 (birth date). Jc3s5h 19:50, 20 September 2016 (UTC)

--Succu 19:59, 20 September 2016 (UTC)

multiple values?
Can "instance of" have multiple values associated (e.g. "human" and "footballer")? If not, which should I prefer, the most specific or the most general?--Malore 21:23, 24 October 2016 (UTC)


 * a) Yes, it can have multiple values associated with it. b) For people, you should just use ; everything else should go in a different field (eg, for "footballer"). Andrew Gray 22:55, 24 October 2016 (UTC)

Should I remove a P31 statement if there is already another P31 statement for a subclass?
Looking at right now, this Sicilian goat species is expressed as an instance of  and as an instance of. But is a sub-class of a sub-class of, so I think "instance of " can be removed, right?

Thanks! Syced 06:02, 11 January 2017 (UTC)
 * Yes, in the general case. --Izno 12:53, 11 January 2017 (UTC)

P31 as qualifier
Moved from Properties for deletion as qualifier usually means "object has role", which duplicates or one new property that it proposed to split to (see P794 above). Other uses includes:
 * 1) "subject has role" (e.g. Q142 and Q21857434, though in my opinion the latter may better be resolved by spliting the item), which is another new property that  proposed to split to
 * 2)  (e.g. Q2652443). Use of = and  may also be replaced by
 * 3) Other usages that should be replaced by another qualifier ( by ), by value (e.g.  by,  by ), by reference (The second value of Q3264432), or can be dropped (Q986519)

I propose to: --GZWDer 14:50, 15 February 2017 (UTC)
 * 1) Stop using  as qualifier
 * 2) Migrate  as qualifier to other properties such as "subject has role" and "object has role"
 * 3) Add a abusefilter to prevent  from being used as qualifier
 * until the P794 section above is resolved and we determined which properties should we replaced by.--GZWDer 14:55, 15 February 2017 (UTC)


 * (once the missing replacement property exists, obviously) --Swpb 16:01, 15 February 2017 (UTC)
 * (note I removed my earlier comment regarding the placement of this query - thanks for moving it.) ArthurPSmith 18:07, 15 February 2017 (UTC)
 * that this property is not used as a qualifier, other properties should qualify — billinghurst  sDrewth  00:42, 20 February 2017 (UTC)
 * ... unsure what the (see P794 above) issue is ... there is no P794 above that I can see, nor a property of that PId (?) --Tagishsimon 13:19, 25 April 2018 (UTC)

consistent "point of view" in property descriptions?
I've noticed that many/most properties have a description that begins from a certain consistent point of view: they could be said to be phrased as completions of a sentence of the form "The object is [a] ...." or a variation of it, and then refer later to the subject where needed. (Sometimes then it is followed by a separate, complete sentence.) Some examples are: Description of the present property "instance of" began (until I changed it just now): which is actually a complete sentence (though not capitalized) and begins with the subject rather than the object.<br >Some alternatives that follow the pattern described could include these (one of which I've gone ahead and changed it to for now): DavRosen 19:25, 18 February 2017 (UTC)
 * opposite of (The object is an) item that is the opposite of this item.  --- (doesn't say "opposite of this item is that item")
 * student of (The object is a) person who has taught this person.  ---  (doesn't say "this person was taught by that person")
 * participant of (The object is an) event a person or an organization was a participant in,... --- (doesn't say "this person or organization was a participant in that event")
 * this item is a specific example and a member of that class.
 * 1) (The object is) that class having this subject item as a specific example and member.
 * 2) (The object is a) class that has this subject item as one of its specific examples or members.
 * 3) (The object is) that class of which this subject item is a specific example and member.
 * 4) (The object is a) class whose specific examples/members include this subject item.


 * You might be looking for Help:Description or its talk page. This is for only. --- Jura 13:59, 2 March 2017 (UTC)

Massive overuse
Half of the "instance of" properties I see in items should really be "subclass of". 1) Can anything be done with the name or description of this property to help decrease the overuse? 2) Would it be possible to make a user script to help correct an item by "converting" the properties with one click? When an item has several "instance of" properties which should all be "subclass of", and this item is only one of dozens in these subclasses that have the wrong property, correcting everything manually by deleting "instance of" properties one by one and adding corresponding "subclass of" properties one by one, quickly becomes a chore. - Soulkeeper 17:16, 8 March 2017 (UTC)
 * I run into this issue all the time. A tool to convert   to   while retaining the object, even on a one-at-a-time basis, would be very helpful to me. - PKM  18:49, 8 March 2017 (UTC)
 * Also how about something to discourage use of instance-of, e.g. warn the user if trying to add "instance of" to an subject item that appears to be a class itself (e.g. already has its own subclasses or instances), unless user is adding "instance of" with a metaclass as target object (identified as first-level metaclass for example). DavRosen 20:15, 8 March 2017 (UTC)
 * if we had a flag marking such edits - it would be good. We have a constraint for this already. d1g 10:47, 15 May 2017 (UTC)
 * Well I don't see "massive" overuse, but I do occasionally run into incorrect usages. There was an attempt to sort out some of this over at WikiProject Ontology - maybe the discussion should be taken there? Of course tool requests are another thing, that does sound useful, maybe something generic that can change a property while keeping the values, references, etc? ArthurPSmith  21:13, 8 March 2017 (UTC)
 * I simply think that it is difficult to intellectually fully understand and embrace this model. I myself often feel lost when I go outside of the field I normally edit in here. I therefor do not think more discussions solves this. Maybe the property itself should be cleaned up. Many aliases here makes the property fuzzier and harder to distinguish from other properties. Another problem is that some items looks very fuzzy themselves. For example: What the is ? Ok, it makes sense to use it when I read the English label. But I cannot find any translation into Swedish that still makes sense as "an instance of profession". -- Innocent bystander  06:31, 2 September 2017 (UTC)

Use as main property only, not qualifiers or references
Hi folks, I've added to the property constraints of P31. If you want to use a similar logical relationship as a qualifier, you should use or  (or a more specific property) depending on whether the item subject or the main object is an instance of the qualifier object. Deryck Chan 17:02, 16 May 2018 (UTC)


 * I have tried to generate some detailed constraint violation statistics using SPARQL and PAWS, but the number of violations to this new constraint is too large. For now we can work from Database_reports/Constraint_violations/P31 and try to deal with each property as it floats up beyond the truncation point. Deryck Chan 17:23, 21 May 2018 (UTC)
 * I have started Property_proposal/reference_has_role to take over uses where P31 is currently being used in references. Jheald 15:06, 10 June 2018 (UTC)
 * Why have you done that? In what way is the use of - for example - P31 at Q192912 not valid? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:06, 16 June 2018 (UTC)
 * This is because an uninformed reader (human or machine) cannot distinguish whether that qualifier means "Stephen Fry is an instance of verified account as far as Twitter is concerned", "Twitter @stephenfry is an instance of verified account", or "The fact that Stephen Fry's Twitter handle is @stephenfry is an instance of verified account". The first and third sentences may make no sense to an informed human reader because is quite constrained in its meaning, but other properties aren't so good. We already have  and  to clarify this (or,  and  for more specialised uses). The appropriate property to migrate / to is /. I also see that / is already being used for . Deryck Chan  12:04, 24 June 2018 (UTC)
 * I'm not sure that your claim about "uninformed readers" is true; but I think we should concentrate on developing a data model in Wikidata that works for informed readers. And while you offer alternatives to the model used in my example, you have not said why that model is not valid. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:42, 24 June 2018 (UTC)
 * As I wrote in my previous comment, P31 shouldn't be used as a qualifier because qualifying things with "being an instance of" is ambiguous. (I wouldn't use the word "invalid" because Wikidata models are a matter of definition, not pure truth.) For example, I have just gone through the uses of / and found that it was used inconsistently because of this ambiguity, e.g. vs  which I moved to  and / respectively to clear up the ambiguity. Deryck Chan  13:48, 24 June 2018 (UTC)
 * You wrote that it was ambiguous to "an uninformed reader". Please see my previous response for a rebuttal of that argument. You made no case that there is ambiguity to an informed reader. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:18, 24 June 2018 (UTC)
 * A fully informed reader does not need Wikidata to inform them. A partially informed reader will see ambiguity in the use of P31 as a qualifier for many other properties, such as the examples with I pointed out above - I only managed to resolve them using information I obtained outside the Wikidata items. We shouldn't decide on the scope of P31 depending on the reader to be informed about all the other properties that may be used with it. Deryck Chan  12:03, 25 June 2018 (UTC)

I cannot resolve the conflict
I've tried to add "center of excellence" to the appropriate item at, but I cannot figure out resolve the conflicts. I welcome any advice. Thanks. -Trilotat 06:51, 27 September 2018 (UTC)
 * A statement should be added to, but I have no idea exactly what; it seems to me that COE is such a broad concept that it’s quite hard to classify. —Tacsipacsi  16:14, 27 September 2018 (UTC)
 * "organisation" or "institution" might work - if in doubt go broad and it can be narrowed down later. Andrew Gray 17:03, 27 September 2018 (UTC)
 * Most centers of excellence are typically ; sometimes "soft" research as in collecting good practices; sometimes "hard" research as in test and evaluation themselves. --Izno 17:33, 28 September 2018 (UTC)

Unclear description
The description contains "...this is deprecated...". Which property is "this" referring to?

"subclass of" constraint fails for taxon items
There's a constraint that the value of a P31 statement should have a statement. However, there is also a property which is declared to be a "subproperty" of, so that items using P171 don't need a duplicate P279. This was pointed out to me in the middle of a discussion about related things at Project chat by Yair rand, and 99of9 then edited the constraint to attempt to allow P171 as well as P279 on this item. However, Tacsipacsi reverted this change, since it apparently doens't work and simply breaks the constraint entirely. Tacsipacsi has also pointed out that the software doesn't support creating this kind of constraint, where the value can have either a P279 OR P171 statement.

The result is that items like (individual members of a species) have a constraint violation because  in this case has no P279, even though it has a P171 which is supposed to be just as good. Some users, such as Brya do not approve of adding duplicate P279 statements to fix the constraint violation.

It seems the constraint violations can only be fixed by adding P279 statements, either duplicating the P171 or with some other value, like, or by deleting the constraint entirely (probably undesirable), or by a software change. Ghouston 03:03, 14 December 2018 (UTC)
 * Maybe a P279 with a fairly general subclass could do (e.g. plant for the sample above). This would also solve some other metaphysical problemy some people have with the taxon system. what do you think? --- Jura 05:59, 14 December 2018 (UTC)
 * A mean to fix the constraint certainly, a solution for conceptual question (and even other technical one) definitely not. author TomT0m / talk page 10:44, 14 December 2018 (UTC)


 * as an individual is notable because it's known as an individual said to belong to a species concept called .  is related to  and an instance of . Is it an ? --Succu  22:33, 14 December 2018 (UTC)
 * I suppose you can always find something else to add as a subclass. In some cases, it will be redundant with the taxon, so is just a work-around for the inability to express it in the constraint. In this case, being an instance of doesn't imply being an instance of, since in the real world there are instances of  which are seeds or seedlings (although I can't imagine one of these getting a Wikidata item.) So I've added  to , but that doesn't fix the constraint violation. Actually, I can think of anything to add to  that isn't already implied by the taxon hierarchy. Ghouston  23:20, 14 December 2018 (UTC)
 * I don't see a problem with indicating that certain taxon is a subclass of . The latter isn't an adult tree or tree in some other strict sense. 2001:7D0:81F7:B580:50BC:9F95:3656:C200 13:29, 3 January 2019 (UTC)
 * If a tree is not a tree, then anything goes ... - Brya 18:09, 3 January 2019 (UTC)
 * Not anything, but certain woody plants (including certain subclasses of it, like certain taxons) that can reach certain height. For instance, there is this BBC news story about 60,000 tree species. There is no indication that is about trees in some other strict sense. If species is a tree species then it's probably appropriate to say that this species is a subclass of trees. 2001:7D0:81F7:B580:A807:ECD1:9E6B:992 20:58, 3 January 2019 (UTC)
 * Right a species of which the individuals magically start life at a "certain height". BTW, no such thing as "taxons". - Brya 03:54, 4 January 2019 (UTC)
 * I did not say anything about starting life at certain height. See below. 2001:7D0:81F7:B580:8D3A:14FC:7ABB:57ED 09:13, 4 January 2019 (UTC)

yet another heading

 * As it has, I don't think it should have P31 with the same value. --- Jura 01:03, 18 December 2018 (UTC)
 * Yes, Bo is a dog. This is indicated as Bo is an instance of a subclass of class item . I don't quite get it what this question is about. 2001:7D0:81F7:B580:50BC:9F95:3656:C200 13:29, 3 January 2019 (UTC)
 * Can we bring in some of the people who work on constraint violations to discuss why this can't be done? It seems perfectly reasonable - or that it should even be automatic based on P1647 relations? ArthurPSmith 18:24, 17 December 2018 (UTC)

?
 * I notice that Brya has updated to avoid the constraint violation, although it looks a bit contrived to me and makes it harder to write queries that get instances of . Should that be the standard way of associating individuals with their taxon? Ghouston  00:51, 18 December 2018 (UTC)
 * Creating for the purpose of classifying individual trees seems unnecessary and otherwise a bad idea. Then you should similarly create something like "individual human" and "individual ship" in addition to existing class items  and . Instead this should be all about proper use of "instance of" and "subclass of" (see Help:Basic membership properties). Class items (,  etc.) should be indicated as being subclasses of other class items (hence this constraint), and individual objects (like individual trees) should be indicated as being instances of relevant class items. Not using "subclass of" for class items (in this case taxon items) seems to be against general classification principles, this property seems to be required regardless what the branch of knowledge is or what other properties are used. As for fixing constraint violations it seems quite obvious that it's needed to add uses of "subclass of".
 * So, as for the separate issue of two statements having duplicate values, I'd say that the issue isn't that much of whether or  should be used, but rather whether  should be used in addition to . I think having duplicate values is OK at the time being as  simplifies some queries a little bit and so having it makes at least some sense. What'd be the procedure to replace a few remaining non-standard classification properties (like ) with standard  entirely (has been suggested in previous discussions) and when to do so can be discussed separately. 2001:7D0:81F7:B580:50BC:9F95:3656:C200 13:29, 3 January 2019 (UTC)
 * The item "eucalypt tree" was not created for the purpose of classifying individual trees, although it can be used for that. It is an independent concept. There are many such cases.
 * I suppose it would be possible to entirely replace "parent taxon" by "subclass of", although it seems to me to have huge disadvantages. - Brya 17:54, 3 January 2019 (UTC)
 * It'd be much simpler and clearer to indicate that is an instance of, which it is. Since "Eucalyptus regnans" was replaced with "eucalypt tree" I got an impression that eucalypt tree as a sufficient replacement is supposed to be a class of trees of that species. So, I misunderstood, it isn't a sufficent replacement and primary relationship between species and its istance just got lost. If Eucalyptus and Corymbia are collectively known as eucalypts (or eucalypt trees) then these taxons can be subclasses of it, instead of adding "instance of eucalypt tree" for every instance (cf. tree species above).
 * In comparison with general classification practises all sorts of inconsistencies and confusion arise from "subclass of" not being used for taxons. For instance, certain taxons are subclasses of trees, evergreen plants or fiber plants, but current insufficient classification approach misses all these relationships. And as a result you look for utterly poor workarounds like adding all these relationships separately to every instance. Unlike usual classification approach where only the most specific class is added (see subsumption). 2001:7D0:81F7:B580:A807:ECD1:9E6B:992 20:58, 3 January 2019 (UTC)
 * Again, no such things a "taxons". And, obviously taxa could only be subclasses of "tree" in a magical world, in which individuals magically reproduce, starting life as individuals of a "certain height."
 * And for Centurion the most specific class available is "eucalypt tree", unless an item "individual tree of the species Eucalyptus regnans" would be created, which you have already opposed. The prime feature of Centurion is that it is a whopping big tree. If at the same location there were a tree of a different species, but at the same size, it would be just as notable. The species is secondary. - Brya 04:04, 4 January 2019 (UTC)
 * They don't start life at certain height, as said, instead they are woody plants that can reach certain height. In this sense some species are considered tree species, again see e.g. this. As with "tree" in some other more or less strict sense we might argue whether some plant is a tree or not, but this probably isn't a question as for Eucalyptus regnans which is a class of one the biggest trees.
 * All taxa are classes of living organisms, Eucalyptus regnans is too. And is the usual way to indicate that object is an instance of a class. Species is more specific than "eucalypt tree" for Centurion. Very well, no point arguing whether characteristic is primary or secondary, either ways species is an important (defining) characteristic for an individual tree.
 * Fair enough, it's "taxa", not "taxons", thanks for the English lesson. :) 2001:7D0:81F7:B580:8D3A:14FC:7ABB:57ED 09:13, 4 January 2019 (UTC)
 * Nope, trees have a certain height, otherwise they are not trees. A woody plant that can reach a certain height is something different, like a sapling. You try to introduce a new concept, a "tree species", which so far was not involved here. The BBC site does not really support that: what it means is that the trees on this world belong to some sixty thousand species. A "tree species" is a pretty fuzzy concept, since not all individuals of a "tree species" become trees (even when they become old), and some individuals of non-tree species do sometimes become trees. Or something like that (it is a slippery concept).
 * It is not meaningful to say that "Eucalyptus regnans is more specific than "eucalypt tree" ": these two classes overlap, but not all Eucalyptus regnans are "eucalypt trees" and not all "eucalypt trees" are Eucalyptus regnans.
 * And to emphasize the point, I don't know anybody who after eating some walnuts will say "ah, I have eaten a grove of trees". - Brya 17:48, 4 January 2019 (UTC)
 * You may use "tree" in sense that it's a large landscape element or a growth stage, but this does not make other more or less strict senses invalid. As said, there is no indication that is about "tree" in strict sense that you imply, neither does en:tree indicate that, say, young tree isn't a tree, contrarily it defines "sapling" as a young tree (similarly to several other sources). Some species being considered either tree species or shrub species is actually a common concept, in addition to this recent research effort to count tree species, there are many other sources (you can Google yourself). I don't think it's fuzzy concept, or at least it isn't fuzzier than "tree" in some other strict sense that you imply (whatever it is exactly).
 * As long as Eucalyptus regnans is a subclass of eucalypt trees then all instances of Eucalyptus regnans are eucalypt trees.
 * I'm not sure what point you emphasize with this walnut example, other than plant, group of plants, and product of a plant being different. 2001:7D0:81F7:B580:F42D:2BAD:619D:F5A0 19:40, 4 January 2019 (UTC)
 * Natural language is loose and contradicts itself frequently. en:tree does that by saying "In botany, a tree is a perennial plant with an elongated stem, or trunk, supporting branches and leaves in most species." as well as "A sapling is a young tree." You can also say that a tadpole is a larval frog, does that mean it's a frog? A walnut is a tree seed, does that mean it's a tree? That leaves the definition of these items in Wikidata somewhat vague, statements will also end up contradictory, and set memberships illogical, unless the definitions can be pinned down somehow by consensus. Ghouston 21:22, 4 January 2019 (UTC)
 * Like Ghouston says "a tadpole is a larval frog" does not mean it's a frog. If a parent says a baby is a "born pilot", this does not mean the baby is qualified to fly an aircraft. A "born pilot" is not really a contradiction, but creating an expression by combining words.
 * The idea of "tree" as a plant of a certain height (etc) is not unclear at all, but is one of the most firmly established concepts worldwide. Children pick it up very soon.
 * And sure, there are many sources that use "tree species" in counting the number of species that trees belong to. That does not mean it is not a fuzzy concept, if used in a different context. It is also a concept that is not involved here.
 * And obviously, and as stated already, Eucalyptus regnans is by no means a subclass of "eucalypt tree": the overwhelming majority of all individuals of Eucalyptus regnans that ever lived never grew up to become a tree.
 * And the fact that walnuts are a tradeable products does not mean they are not alive. Trees can be traded also. Any walnut belongs to a species, as much as any seedling, sapling or tree does. - Brya 04:18, 5 January 2019 (UTC)
 * Saying that "tree is a perennial plant with an elongated stem" and "sapling is a young tree" doesn't seem contradictory to me. Young tree or old tree, either ways it's a plant that forms an elongated stem (typical to this subclass of plants). Similarly, general descriptons of animal taxa often include characteristics like length or heigth or wingspan, but you probably wouldn't say that young specimen isn't of given species merely because it doesn't meet this average morphology yet or maybe it never will.
 * This question of seed (walnut) being a plant (tree) is about whether you apply taxonomic classification to whole living organisms or to elements of living organisms. I'm not sure why you'd like to apply it to an element of living oganism (a seed) instead of applying it to whole living organism (a plant). Similarly, if we classify an individual plant as tree, then do you have less reason ask whether seed of this individual tree is a tree?
 * Tadpole example seems to be about edge cases that most classifications could consider. For instance, we may have a ship being built and then wonder about at what point it's ready enough to classify it as a ship. However, it's more of a philosophical problem, classification-wise that sort of edge cases would be usually just ignored (e.g. ship is classified later when it's in use, or it's classified as per what it's designed to be). Or, it probably isn't necessarily wrong to consider a human being growing in the womb, but classification-wise we would likely deal with instances of humans that have been born.
 * I don't think that tree species is about "tree" in some loose sense. This is a widely used concept in scientific papers and especially in forestry. Here is an article that provides some overview of tree definitions, among other things it explicitly finds it useful to classify a species (or sub-species class) as tree instead of an individual tree as tree. Sure, there are edge cases where we aren't sure or where sources are in contradiction regarding some species, but I don't see how it'd be less so when classifing individual trees and by height (first of all, there is probably no certain height). Also, as already said, nothing about "tree" item on Wikidata indicates that it is restricted to classifying non-taxa.
 * I'd find it unusual if someone'd say that young speciemen of a tree species would not be consider a tree or that someone would say that, say, tree nursery is place where shrubs or other sorts of non-trees are propagated. Also, take for example banana tree (class), for which it's quite common knowledge that it isn't a tree in strict sense, even if called a tree, and regardless of its height. 2001:7D0:81F7:B580:CD04:763E:6768:A636 21:38, 5 January 2019 (UTC)
 * Known as or more specialized in this case as . So what exactly how should we handle this  or  here? --Succu  22:14, 5 January 2019 (UTC)
 * As Succu points out, for plants there are recognized plant life forms, and recognized life stages. A seed, once mature, is complete unto itself, not part of anything. Some seeds can survive, as a seed, for thousands of years, and can then germinate.
 * And yes, if one attaches value to a very precise, or easily quantifiable definition, it is possible to come up with multiple definitions of tree. In the paper you link to, there is a definition that clearly treats trees as individuals. It even accepts individual trees within an individual organism (Fig. 9). Still, in spite of there being multiple definitions, by and large, most everybody is pretty clear on what a "tree" is.
 * For things other than plants, there are no doubt appropriate recognized states. I would say that most people would accept a ship as being a ship after it has been launched and christened. They hold a ceremony and everything to mark the transition. "Sometimes a cigar is just a cigar." - Brya 04:27, 6 January 2019 (UTC)
 * I'm not sure that this digression is really helping solve the original problem. I think it's fine that is an instance of, etc., but I think it should also be an instance of . Ghouston  08:13, 6 January 2019 (UTC)
 * I agree that this digression does not solve anything. It would not be terrible to have be an instance of, but the original problem was an unhappyness with the constrained violations this causes. - Brya  08:51, 6 January 2019 (UTC)
 * Well, this digression illustrates that taxonomy classification being cut off from rest of Wikidata classification system (taxa are not only subclasses of their parent taxa) is yet another reason why not using "subclass of" for taxa is a bad approach (also root of this constraints issue). I now find this recent discussion that summarizes some other inconsistencies and confusion caused by this approach. There have been several other discussions on the same topic over the years, though, if held at taxonomy wikiproject then run down by Brya/Succu tandem using digressive questions just like some of those above. The problem however persists, though it doesn't seem that hard to fix. 2001:7D0:81F7:B580:184A:7BA3:7C9D:FB02 09:26, 6 January 2019 (UTC)
 * Obviously, if taxons used "subclass of" then this constraint problem wouldn't exist. If there's a chance that Wikidata is going to switch to that model, then there's no point in worrying about this constraint issue at present. It was User:Succu arguing in that discussion against using subclass statements, although I don't understand the argument against. It seems like anything expressed by "parent taxon" could alternatively be expressed with "subclass of", so maybe I'm missing something. Ghouston 01:29, 22 January 2019 (UTC)

This problem has not been fixed and it should. There is a lot of notable plants and animals that are an instance of their species. The obvious fix should be accept as P31 any taxon.--Pere prlpz 14:07, 6 October 2019 (UTC)

GA: "sampla de"
Cén fáth a bhfuil séimhiú ann? Ní gá, dar liom: "sampla de". Marcas.oduinn 00:44, 19 March 2019 (UTC)

usage as a descriptive meaning
Hi! I learned that instance of (P31 should be used only at the root. Nevertheless I fel the request to have / use something underlining the descriptive meaning of this property. Examples: at Robert Domes (Q2156901) I used instance of author reading (Q788526) as a qualifier inside  YouTube video ID (P1651). What could be done there and at similar situations? Best regards no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn talk contribs 22:15, 28 July 2019 (UTC)

Multiple "instance of" statements in a single article
Is there a guideline somewhere about not having more then one "instance of" statement per article? I ask because a certain user removed some "instance of business" entries, along with "instance of financial institution", from articles about banks that also had "instance of commercial bank" because supposedly it's over categorization. At least that's the reason the user gave for doing it. Commercial Bank doesn't seem to be a subclass of either instance though. Especially "instance of business" IMHO. There isn't a subclass warning about it either. So, I'm wondering if it's actually an issue to label articles with both "instance of commercial bank" and "instance of business" at the same time as the user claims. I'd like to know what the guideline about such things are more generally also. Since I couldn't find one and I rather not get in edit wars with other users over it. --Adamant1 04:09, 4 August 2019 (UTC)
 * No. "overcategorization" sounds like something at Wikipedia. This is not here. "instance of" is applied to items, not articles. Articles are what is linked from matching items.
 * That being said, not all combinations of P31 are useful. I don't see the point of adding "financial institution" in addition to "commercial bank".
 * Not quite sure about "business". What does the relevant WikiProject suggest?
 * In any case, P31 can change over time. --- Jura 05:36, 4 August 2019 (UTC)
 * Adding instances to an item which are superclasses is redundant. E.g., it would be undesirable to add instances "primate", "mammal", "animal", "organism" etc., to every person, even though they'd be correct. Although, in this case technically may not currently have those items as superclasses, but that's an issue with how it has been set up. Ghouston  06:06, 4 August 2019 (UTC)
 * I think it's not necessarily redundant. You could easily have a specimen where some suggest it's a primate, other it's a human, so you will have two different statements. Items with are bit special anyways, as we generally don't use any subclasses. --- Jura 06:15, 4 August 2019 (UTC)
 * Thanks for the information. I agree that some combinations of P31 aren't useful. It's hard to tell which are or not though. Maybe "financial institution" with "commercial bank" is useless at least. WikiProject Companies suggests using "instance of business." Although, it doesn't say if it has to be the only instance used. Whereas, with other suggestions it says if they can have multiple entries or not. Maybe more specific business details are better stated with P452. P452 doesn't impart what type of bank it is though. On the example of humans, it could be either primate or human depending on the person and use case IMHO. Like academic compared to informal usage. Q489927 and other bog body articles have both instances of "human" and "bog body." Even though "bog body" is a subclass of "human." So, I think there are places where multiple "instance of" statements work. Including when one of them is a subclass of the other. "Business" and "commercial bank" aren't sub-classes though. So, I'd think it would be fine to use both. Especially if "overcategorization" isn't a thing. --Adamant1 08:30, 5 August 2019 (UTC)
 * It depends. I think you are referring to and . If every instance of the former is an instance of the later, then  should be a direct or indirect subclass of . That's easier than add finding all the instances of  and making them instances of  too. On the other hand, if some instances of  are not instances of, then it can't be done that way. Ghouston  09:11, 5 August 2019 (UTC)
 * In response to "adding all possible instances" (e.g. "primate", "mammal", "animal", "organism"), eventually we should be able to depend on the type hierarchy induced by relationship however these hierarchies are often noisy/incomplete. For example:  should be an instance of all of the following: [instance of relations]. In this particular instance the hierarchy for  is missing even prominent types such as, , etc. Manually asserting multiple  is a way of enforcing a type assertion without having to count on shifting hierarchy. Also if over classification using  becomes an issue we could later remove superclasses automatically leaving only the most specific versions. ---ElanHR  02:35, 7 August 2019 (UTC)
 * Yeah, I know is broken, but even there, I don't think adding additional  statements to every human would be very useful. Ghouston  08:11, 7 August 2019 (UTC)
 * There is no guideline for not having more then one "instance of" statement per article, but should not replace the other properties, in this case.
 * But the case of banks is a bit different, as there is needed a special authorisation/licence to perform these activities. I am not sure, that is the best way to record this neither . Maybe new property ("has authorisation for") with qualifiers (like  ) seems to be the best solution.--Jklamo  16:52, 7 August 2019 (UTC)

Allowed qualifiers madness ?
This property seems to be used for a number of purposes, it allows a lot of qualifiers, but it seems all but obvious to guess the usecase from the qualifier list.

For example the last addition by, language of work, leads to find items like this one. I’m pretty sure the language should be a plain statement and I don’t see a reason on why it should become a qualifier. Why did you added this ?

I’d have the same question for for https://www.wikidata.org/wiki/Q15783635. It seems on the example to be at the origin a misuse of this qualifier by ( the addition). But it have nothing to do with a reference point, it’s to express that this expression is a name given to the object. It makes sense in french (hey Jules _o/) but we should correct this and find a solution, not allow this misuse. author TomT0m / talk page 14:35, 17 August 2019 (UTC)


 * I've never edited https://www.wikidata.org/wiki/Q15783635 and it has no English labels, so I don't know what you're asking of me. Swpb 10:20, 18 August 2019 (UTC)
 * No, it’s jules who edited this item, but you allowed the corresponding qualifier. Why ? I found the item by searching for a usecase. author TomT0m / talk page 10:48, 18 August 2019 (UTC)
 * I added it for . also seems like a reasonable use. I'm sure it could have many others. Swpb  14:54, 20 August 2019 (UTC)
 * For the first example … oh my. I begun an answer but it’s like I’m pulling a fractal string of problems. First  seems to be a mixup of concepts : places, as objects, and localizations, as the result of describing the position of some place in some coordinate system. If you look at the history of the article you’ll see that this « conflict » between the two senses is long going. Did you know that France, as a state, was a Q302009 ?
 * I’ll stop here for today because this is by itself depressing enough and makes me pessimistic /o\ We definitely would need something like an upper ontology to sort out this mess out of a solid ground. author TomT0m / talk page 17:41, 20 August 2019 (UTC)
 * If you want to create new entities for different senses of "location", go ahead, but it has nothing to do with whether P2210 can be a valid qualifier for P31. Swpb 19:19, 20 August 2019 (UTC)
 * It does matter. In one of the senses, take a place like the in Paris, it’s a specific location which is a portion of the Earth. It exists by itself. In the sense I decypher you want to use the qualifier, there is not ONE place like this, there is … one per keyboard – it’s as different as a type like  is not one of its instances like . One is a specific portion of space, the other one is a kind of portion of spate. This is very different. This item is used for both it seems.
 * In our case, if it’s indeed a location, it’s a location type as there is many concrete instances, like « the rest position on the keyboard where I’m typing those lines ». It’s not an instance of location, it’s a subclass of location, then.
 * Second, let’s come to the qualifier meaning by itself. The initial purpose was to state a reference point of measures : you take the height of a mountain relative to the height of the see. There is a reference point, a measure … Here this is really really different, I think. You’ve got no reference point, you’ve got a whole object, you’ve got no measure at all … you clearly stepped out of the usecase of the qualifier, on your own initiative, without discussion. If we take the example of the mountain, the equivalent would be that the position of the mountain is relative to the earth. This does not make any sense. The mountain is located « on » the earth. Something that would make sense, if we take into account the « relative position » meaning, would be « that city is located 200km South of New-York on the earth ». Here it’s not like that at all, to be faithful to this application we would have something like « it’s two rows above the lowest line of some keyboard ». I think that would be a closest match to express that it’s a location on some keyboard (just as the mountain is located on earth, this position is supposed to be on a keyboard), and I don’t really see any reason why to put it as a qualifier and not as a plain statement. I’d think of a way to express that this is supposed to be the fingers that are supposed to be positioned.  author TomT0m / talk page 10:38, 21 August 2019 (UTC)

(qualifierSnak proposal) Statements of Instance Of should be treated more generally and loosely as Events themselves
Context Item: https://www.wikidata.org/wiki/Q91629492

Context: Governments and other authorities often state that some things are instances of other things. This is universally known. This is most often treated as a set of statements themselves in other Graph systems.

I want to bring something up that is going to spin a few minds of folks. In other Graph systems, the very act of me or someone at some time saying something is an "instance of" is a complete Event itself (Event based graphs were recently highlighted in "CS520 Knowledge Graph Seminar Session 1" video on YouTube at 34:00) (with all the metadata that any Event could possibly contain, who,what,when,where,etc. said this thing was an instance of some other thing). However, in Wikidata, we don't treat Statements, for example the act of saying something is an "instance of", as an Event itself. We do have in the data model however a wrapper through qualifierSnak, to store additional information, but it lacks treatment as an entire Event.

This causes a number of issues:
 * 1) Each individual qualifier would need an attached reference, instead of only once for the single Event (the set of qualifiers, a qualifierSnak).
 * 2) Constraints and Rules become harder to maintain because there is not a single wrapper for the entire metadata of a statement (that I am aware of).

I offer an alternative design: Allow a set of qualifierSnaks to be treated in whole as an entire Event type (and possibly other types as needed).

qualifierSnak =
 * Who
 * What (we have this)
 * When
 * Where
 * How (not sure we have this)

This allows a few nice things:
 * 1) We can easily give a single reference for the entire qualiferSnak Event, or multiple references if we desire, saving us from having to add a reference on each individual qualifier assertion.
 * 2) Constraints and Rules can be applied on the whole qualifierSnak Event (or additional Snak types other than Event types if they are out there and needed).
 * 3) Since all Events share a common set of properties, these can be maintained at a datatype level, or perhaps somehow allowing a flexible datatype that can use Wikidata itself and just maintaining an agreed set of  statements on Event  which qualifierSnak's would be typed as.

I welcome disagreement, head spinning, and "we already thought about that, see this..." comments. ;-)

(and perhaps this is all entirely possible via API and programmatically, but just not exposed in this way in the UI currently)

Thadguidry 18:28, 23 April 2020 (UTC)

Suitability of as value
If Commons has a category, it would either go on an item with or the related topical item, not one with  in P31. As I don't see what other uses there could be for the above in P31, there could be, I added a "none of" constraint. --- Jura 09:02, 25 October 2020 (UTC)

Suitability of as value
In most cases, I think one should the sitelink to an item about the topic covered by the article, not an item for "Wikipedia articles". As I don't see what other uses in P31, there could be, I added a "none of" constraint. --- Jura 09:02, 25 October 2020 (UTC)
 * Well, based on items currently having P31=Q15138389 statement, the idea seems to be that these items are for Wikipedia articles that are not about single topic (or single clear-cut concept), but rather are arbitrarily split from some other article, or that combine several topics. For example currently having this P31 value seems more straightforwad than  claimed to be an instance of some pseudo-class called "climate of geographic location". See also  (a subclass of this item). Though, indeed the distinction between items about Wikimedia article pages and normal topic items should be made more clear. 2001:7D0:81F7:B580:9587:D3CB:74EF:6AF3 18:46, 29 November 2020 (UTC)


 * There are academic articles that cite Wikipedia articles. In those cases it's useful to have an item for the Wikipedia article.
 * When it comes to https://en.wikipedia.org/wiki/Geology_of_Israel is not a page about a Wikipedia article and thus shouldn't be linked to an item with  .  ChristianKl  ❪✉❫ 00:18, 11 December 2020 (UTC)


 * All or almost all current uses of P31 Q15138389 are incorrect, but there could theoretically be an item for which the statement would be correct, similar to how Q42395533 is correctly described as an instance of Wikidata item. (There should really be a help page describing the potential mistakes relating to mixing up an item/article and its topic.) --Yair rand 02:04, 21 December 2020 (UTC)
 * As far as I can see items like compare with items that are instances of Wikimedia category page or Wikimedia list page, rather than with normal concept items. This example item exists because country article on Wikipedia has been split, not because "geology of Israel" is its own thing, special kind of geology, or whatever. So it seems reosonable to make this distinction clear, one way or another, instead of inventing various and dubious ways to fit such items into concept hierarchy. In case of "climate of Israel" mentioned above, setting it as both instance of and subclss of "climate" is just meaningless. Take another example  which per subclass tree is currently set as instance of "information", instead of frankly indicating that item is for a Wikipedia article. 2001:7D0:81F7:B580:9C67:F3D6:A94A:A88D 09:22, 5 February 2021 (UTC)
 * Isn't it fairly common in geography and its various aspects to study it for some area? It's possibly that one hasn't come across studies of that specific country, but I don't see that as a problem. I don't think it really matters what Wikipedia does or doesn't do. We can just link its articles if there are some. --- Jura 09:37, 5 February 2021 (UTC)
 * The study subject can be delimited in whatever arbitrary way (as is the case for splitting a long Wikipedia article), e.g. one can specify further and study "geology of the Permian and Triassic in the territory of Israel". Which does't make any such arbitary subject into a new concept, does it. Surely Wikidata can and does link to any existing Wikipedia article. The problem is how to classify resulting items meaningfully. Based on most items currently having P31=Q15138389 (or more specifially P31=Q21484471) it is at least evident that the statement isn't used for random items with Wikipedia sitelinks and there's an intent to make it clear that these items aren't about individual clear-cut concepts. 2001:7D0:81F7:B580:298C:2394:42D3:C4D1 12:05, 5 February 2021 (UTC)
 * I'm sure we can find a meaningful way to classify and describe "geology of " topics. --- Jura 12:14, 5 February 2021 (UTC)
 * I also don't think it's an impossible task, neither in regard to other similar examples cited above. Though, out of options I've encountered, P31=Q15138389 or similar statements for reasons outlined above to me make the most sense. I again admit it's an imperfect solution and needs further refinement, so that it was clear that the statement shouldn't be used for all items with Wikipedia sitelinks. The second best option I can think of is to leave such items without any P31/P279 statement, and rely on, and alike, but then users probably eventually add P31/P279 anyway with some "close enough" value (i.e. more or less meaningless value). 2001:7D0:81F7:B580:298C:2394:42D3:C4D1 12:41, 5 February 2021 (UTC)

Removing as qualifier
It seems to me like many qualifiers get currently used on that have no good business being mixed up in. at the top of the list seem without good footing and gets mostly used in taxonomy. ChristianKl ❪✉❫ 00:30, 11 December 2020 (UTC)
 * Seems reasonable to me. --Yair rand 02:10, 21 December 2020 (UTC)

Removing as qualifier
This finds current uses. They seem to be of two types: I'd remove (1) and move (2) where possible. If nothing is left, P407 can be removed. --- Jura 17:14, 18 March 2021 (UTC)
 * (1) Items where contributors try to describe a Wikipedia page connected to the item, but irrelevant for the P31-statement
 * (2) Items where the statement would better be a main statement (or already is)

None-Of Constraints: Why?
Several none-of constraints such as "None of audio podcast (Q24633474), video podcast (Q3276244), podcasting (Q20899), podcasting (Q33212151)" or "None of VR video game (Q87741364), console game (Q6561427), PC game (Q4485157), mobile game (Q1121542)" seem arbitrary. What are the reasons for these? –
 * We use and  instead.  --Trade  21:20, 7 November 2021 (UTC)

None-of constraint: book?
You added "book" (Q571) to none-of constraint (Q52558054) twice (see this and this), and I reverted them (see this and this). The reasons you gave were "use more precise value (most of the case: Q47461344, written work)" and "too general value ; use a more specific values, see [[Wikidata:WikiProject_Books] ]". But book (Q571) is a subclass of, and more specific than, written work (Q47461344). If book (Q571) is "too general", written work (Q47461344) is even more general. So, in my view, "book" (Q571) is as specific as "article" (Q191067) and "chapter" (Q1980247), and can be the value of instance of (Property:P31). --Neo-Jay 04:50, 19 October 2021 (UTC)
 * oh, I didn't noticed (and that explains why I was surprised the constraint was not already here).
 * Yes, book should no be used as a value of P31. And also yes, is too general and problematic. Subclass of  changes a lot and right now I see it's a sublclass of work (so intangible) and of document/publication/object (tangible) which is contradictory and illogical. I think the adding of sublclass of work is the mistake here (I'll ask on Talk:Q571 again...). Anyway, many people clean books and remove the value Q571 to P31 since the beggining of Wikidata, removing the constraints will only make our job harder. Cheers, VIGNERON  06:39, 19 October 2021 (UTC)

Add type constraint to be mutually exclusive with
I'd like to suggest adding a type constraint that prevents something from being both (synonym "is") and  (synonym "is not"). After all, X is Y and X is not Y cannot be simultaneously true. -Thunderforge 21:38, 1 November 2021 (UTC)
 * Any use case to see more what you'd like ? Bouzinac   💬●✒️●💛 21:56, 1 November 2021 (UTC)
 * @Bouzinac I'm not quite understanding what you are saying. Are you asking for an example? Here's one: for a brief time, simultaneously had both  and  with values of "emulator". This means that ScummVM is an emulator and ScummVM is not an emulator were simultaneously listed. This is of course nonsensical, but there was no constraint on either property pointing out the issue. Thunderforge  18:38, 2 November 2021 (UTC)
 * Okay, I get what you are saying : you'd like to alert when there is same value both in P31 and in P1889. Bouzinac   💬●✒️●💛 19:48, 2 November 2021 (UTC)
 * Yes, that is what I am looking for. Thunderforge 01:29, 3 November 2021 (UTC)
 * I don't see a problem with stating that a jeep is an instance of an off-road vehicle and different from that. This as they can be considered synonyms. --- <span style="display:inline-block;transform:rotate(-8deg);-moz-transform:rotate(-8deg);-webkit-transform:rotate(-8deg);-o-transform:rotate(-8deg);">Jura 01:58, 21 December 2021 (UTC)

Finding those without it set
Is there a query for finding humans without P31 set and optionally lets people filter on labels that end with a particular string (so they could work on everyone in a family they were researching for example) Back ache 09:13, 21 December 2021 (UTC)


 * You need to find another way to determine if an item is about a person. This could be:
 * a category on Wikipedia
 * a property generally found on items about people (sample: date of birth).
 * infobox or text of the article at Wikipedia
 * The label alone generally doesn't allow to determine it.
 * Special:Search/inlabel:"Miller" -haswbstatement:P31 -haswbstatement:P279 finds items with "Miller" in the label, but no P31 or P279 statement. It currently includes Ron Miller and G.A. Miller. You could then check the items or linked articles to see if its about a person. --- <span style="display:inline-block;transform:rotate(-8deg);-moz-transform:rotate(-8deg);-webkit-transform:rotate(-8deg);-o-transform:rotate(-8deg);">Jura  10:48, 21 December 2021 (UTC)

简体中文 标签 的翻译
有原来的“隶属于”改为“（以类型分）属于”，原因如下：

1，隶属于 并没有表达“属于某一类别”的意思，更多是“首. . . . . . 管辖”的意思

2，（以类型分）属于 有明确的类型概念 如：

--Bangbang.S 11:52, 8 January 2022 (UTC)