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)
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, "<Canada> is a <country>". It might be worth re-labelling the property to "is an instance of" (so, "<Canada> is an instance of <country>". 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,...) – The preceding unsigned comment was added byJanjko (talk • contribs).
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 (talk) 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.
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 Wikidata:Contact the development team. Cheers. --Zolo (talk) 06:30, 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 m: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)
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)
+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
{{delete|This property does not help with the classification of the entities in wikidata because its meaning is too ambiguous. The Property:P107 (entity type) has a much more precise meaning and follows a well established classification scheme by only allowing specific values: person, organization, event, work, term, and place. All items with this property should be changed (by a bot?) before deleting. --Yurik (talk) 05:13, 16 February 2013 (UTC)}}
(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)
Oppose 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 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)
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)
CommentOppose 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, --#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)
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, --#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.
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.)
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.) --#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.
Support 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)
Синонимы (часть, "is a", "является одним из" и т.д.) - вред при создании единой системы (типа Wikidata). Здесь возможные синонимы. Варианты, которые не попадают, можно всегда привести к варианту Множество/Подмножество(Надмножество). И в описании на ru для подмножество - "надмножества этого понятия" (про подмножества - ничего, про множество - тоже) Fractaler (talk) 10:01, 11 April 2013 (UTC)
Я бы назвал "это объект типа", тогда дальше может быть в именительном падеже. Текущее описание "это частный случай понятия" считаю неудовлетворительным по ряду причин. Оно неоднозначно, можно неправильно понять как «уточнённый тип/класс» вместо «объект класса, экземпляр типа». В английском уже определились, что это должен быть именно единичный объект. Давайте переименуем? --Nikolay Komarov (talk) 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)
Question 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)
CommentUser: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 Wikidata:Project_chat#Preparing_for_.22statements_on_properties.22 "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 (talk) 03:20, 19 November 2014 (UTC)
Comment. 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 (talk) 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 (talk) 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 (talk) 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 (talk) 22:18, 8 December 2013 (UTC)
Gut, dass neben ist eine Auspraegung von jetzt auch das verstaendlichere ist ein Exemplar von steht.
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í. --Rondador13: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?)) --#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?
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, --#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)
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.) --#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? Windows Phone 7 (Q1854343) 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 Windows Phone 7 (Q1854343) 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 (talk) 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 Dongen Formation (Q2481793) which is an "instance of = formation". And the formation belongs to the "Lower North Sea Group". Would it be better to say part of (P361) "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)
P766 (P766) to restrict the applicability to a geographical area (example: Urban planning in Shanghai (Q7900141)). I think it different from of (P642). Here Shanghai means "in the municipal area of Shanghai", while using of (P642) would rather mean "by Shanghai Municipality."
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 Wikidata:Qualifier for all properties. --Sk!d (talk) 11:25, 4 September 2013 (UTC)
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)
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 (talk) 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 (talk) 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—an irony, given that that would certainly be worse in Emw's eyes. :) --Izno (talk) 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 (talk) 05:24, 3 December 2013 (UTC)
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 (talk) 14:08, 4 March 2014 (UTC)
@NavinoEvans: I faced this problem in the past for some sports, and actually an option may be to use the item for the sport : association football (Q2736). 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 <FA Cup final matches> and <FA cup matches>' with statements like
Many thanks @TomT0m:. I think the option of creating the class items <FA Cup final matches> and <FA cup matches> 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 (talk) 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, NavinoEvans. TomT0m (talk) 22:42, 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 <FA Cup final matches> ? (e.g. '1970 FA Cup Final' is an instance of 'FA Cup Final')
Presumably we could then create the suggested class <FA Cup matches> such that
TomT0m, 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 (talk) 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 (talk) 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 (talk) 22:40, 22 May 2014 (UTC)
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 (talk) 01:05, 21 November 2014 (UTC)
@Izno: 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 (talk) 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 (talk) 21:18, 26 November 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 (talk) 02:34, 8 January 2015 (UTC)
I disagree with that removal. I don’t think that “see also” implies “the same”;
on the contrary, I think that the difference between instance of (P31) and subclass of (P279) 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.
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 (talk) 20:11, 24 January 2015 (UTC)
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.
ru:Блицзнецы and some other articles linked to twin (Q159979) 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)
As the meaning of the french translation nature de l'élément of instance of (P31) 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 <instance X> instance of (P31) <class Y> :
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à exemplar of (P1574). 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) »).
@Djiboun: 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 (talk) 19:13, 22 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 (talk) 19:44, 22 February 2015 (UTC)
@Djiboun: 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 Is-a (Q1101080). author TomT0m / talk page14: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 (talk) 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 (talk) 12:08, 10 April 2016 (UTC)
@Verdy p: 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 page13:45, 10 April 2016 (UTC)
Voir aussi la classification des atomes / éléments / hydrogène sur le dessin ci après. qui fonctionne très bien. author TomT0m / talk page13: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...
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 (talk) 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 page21:59, 10 April 2016 (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 (talk) 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. --- Jura16: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 (talk) 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. --- Jura20:41, 29 March 2015 (UTC)
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.
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 (talk) 16:27, 26 April 2016 (UTC)
@TomT0m: : 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 WikiProject Ontology.-- Chjohnson39 (talk) 19:41, 26 April 2016 (UTC)
@Chjohnson39: 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 page19:58, 26 April 2016 (UTC)
@TomT0m: : 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 (talk) 21:49, 26 April 2016 (UTC)
Please see Property talk:P569#"instance of" removal. That discussion is about whether we should say that a date of birth (P569) is a Wikidata property encoding a vCard value (Q26935994). 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 (talk) 16:05, 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 (talk) 19:50, 20 September 2016 (UTC)
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 (talk) 21:23, 24 October 2016 (UTC)
"subject has role" (e.g. Q142#P463 and Q21857434#P1651, though in my opinion the latter may better be resolved by spliting the item), which is another new property that subject has role (P2868) proposed to split to
Support ... unsure what the (see P794 above) issue is ... there is no P794 above that I can see, nor a property of that PId (?) --Tagishsimon (talk) 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:
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")
Description of the present property "instance of" began (until I changed it just now):
this item is a specific example and a member of that class.
which is actually a complete sentence (though not capitalized) and begins with the subject rather than the object. Some alternatives that follow the pattern described could include these (one of which I've gone ahead and changed it to for now):
(The object is) that class having this subject item as a specific example and member.
(The object is a) class that has this subject item as one of its specific examples or members.
(The object is) that class of which this subject item is a specific example and member.
(The object is a) class whose specific examples/members include this subject item.
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 (talk) 17:16, 8 March 2017 (UTC)
I run into this issue all the time. A tool to convert <instance of> to <subclass of> while retaining the object, even on a one-at-a-time basis, would be very helpful to me. - PKM (talk) 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 (talk) 20:15, 8 March 2017 (UTC)
Support if we had a flag marking such edits - it would be good. We have a constraint for this already. d1g (talk) 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 Wikidata: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 (talk) 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 military personnel (Q47064)? 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 (talk) 06:31, 2 September 2017 (UTC)
2018
Use as main property only, not qualifiers or references
@Deryck Chan: 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 edits12:42, 24 June 2018 (UTC)
@Pigsonthewing: 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 country (P17)/instance of (P31) and found that it was used inconsistently because of this ambiguity, e.g. [1] vs [2] which I moved to part of (P361) and country (P17)/applies to part (P518) respectively to clear up the ambiguity. Deryck Chan (talk) 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 edits15: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 country (P17) 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 (talk) 12:03, 25 June 2018 (UTC)
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 subclass of (P279) statement. However, there is also a property parent taxon (P171) which is declared to be a "subproperty" of subclass of (P279), 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 Centurion (Q3664932) (individual members of a species) have a constraint violation because Eucalyptus regnans (Q1542486) 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 organism (Q7239), or by deleting the constraint entirely (probably undesirable), or by a software change. Ghouston (talk) 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. @Succu: what do you think? --- Jura05: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 page10:44, 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 Eucalyptus regnans (Q1542486) doesn't imply being an instance of tree (Q10884), since in the real world there are instances of Eucalyptus regnans (Q1542486) which are seeds or seedlings (although I can't imagine one of these getting a Wikidata item.) So I've added tree (Q10884) to Centurion (Q3664932), but that doesn't fix the constraint violation. Actually, I can think of anything to add to Eucalyptus regnans (Q1542486) that isn't already implied by the taxon hierarchy. Ghouston (talk) 23:20, 14 December 2018 (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 tree (Q10884) 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:99220: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 (talk) 03:54, 4 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 (talk) 18:24, 17 December 2018 (UTC)
Creating eucalypt tree (Q59805407) 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 human (Q5) and ship (Q11446). Instead this should be all about proper use of "instance of" and "subclass of" (see Help:Basic membership properties). Class items (Eucalyptus regnans (Q1542486), tree (Q10884) 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".
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 (talk) 17:54, 3 January 2019 (UTC)
It'd be much simpler and clearer to indicate that Centurion (Q3664932) is an instance of Eucalyptus regnans (Q1542486), 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:99220: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 (talk) 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 instance of (P31)Eucalyptus regnans (Q1542486) 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.
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 (talk) 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 tree (Q10884) 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[3][4][5] (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.
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 (talk) 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 (talk) 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:A63621:38, 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 (talk) 04:27, 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:FB0209: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 (talk) 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 (talk) 14:07, 6 October 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 (talk) 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?
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 human (Q5) may not currently have those items as superclasses, but that's an issue with how it has been set up. Ghouston (talk) 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 human (Q5) are bit special anyways, as we generally don't use any subclasses. --- Jura06: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 (talk) 08:30, 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 subclass of (P279) relationship however these hierarchies are often noisy/incomplete. For example: Douglas Adams (Q42) should be an instance of all of the following: [instance of relations]. In this particular instance the hierarchy for human (Q5) is missing even prominent types such as organism (Q7239), omnivore (Q164509), etc. Manually asserting multiple instance of (P31) is a way of enforcing a type assertion without having to count on shifting hierarchy. Also if over classification using instance of (P31) becomes an issue we could later remove superclasses automatically leaving only the most specific versions. ---ElanHR (talk) 02:35, 7 August 2019 (UTC)
There is no guideline for not having more then one "instance of" statement per article, but instance of (P31) should not replace the other properties, in this case industry (P452).
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 Tokorokoko, 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 Tokorokoko ?
I’d have the same question for Swpb for https://www.wikidata.org/wiki/Q15783635relative to (P2210). It seems on the example to be at the origin a misuse of this qualifier by Jules78120 ( 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 page14:35, 17 August 2019 (UTC)
@Swpb: For the first example … home row (Q302009) oh my. I begun an answer but it’s like I’m pulling a fractal string of problems. First physical location (Q17334923) 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 page17: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 (talk) 19:19, 20 August 2019 (UTC)
@Swpb: It does matter. In one of the senses, take a place like the Q1174552 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 market square (Q13033698) is not one of its instances like Fischmarkt (Q1420361). 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 located inSearch 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 page10:38, 21 August 2019 (UTC)
Oppose 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)
Support--Svebert (talk) 23:31, 16 March 2013 (UTC)
Comment 
Question What are you proposing here; a new property, renaming of this property or something else? --Faux (talk) 14:55, 23 March 2013 (UTC)
. 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 (talk) 19:13, 22 February 2015 (UTC)
. author TomT0m / talk page 14:33, 10 January 2016 (UTC)
On hold until the P794 section above is resolved and we determined which properties should we replaced by.--GZWDer (talk) 14:55, 15 February 2017 (UTC)
Notified participants of WikiProject property constraints?
. It seems on the example to be at the origin a misuse of this qualifier by Jules78120 ( 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)