Property talk:P31

From Wikidata
Jump to: navigation, search

Documentation

instance of
that class of which this subject is a particular example and member. (Subject typically an individual member with Proper Name label.) Different from P279 (subclass of).
Description This item is an instance of that other item (which represents some type or grouping of entities). Rather use a more specific type or instance of property, if one applies.
Represents instance of (Q21503252)
Data type Item
Domain Instances
Allowed values Any item that represents a class; any item that is not an instance (note: this should be moved to the property statements)
Usage notes https://www.wikidata.org/wiki/Help:Basic_membership_properties
Example Nelson Mandela (Q8023)human (Q5)
Codex Gigas (Q212180)book (Q571)
Gachalá Emerald (Q772466)emerald (Q43513)
list of cities in France (Q177866)Wikimedia list article (Q13406463)
electron (Q2225)type of quantum particle (Q22675015)
Source http://www.w3.org/TR/rdf-schema/#ch_type
Robot and gadget jobs The gadget Wikidata useful lets the user choose among some common types and store the statement in one click.
Tracking: usage Category:Pages using Wikidata property P31 (Q20117426)
See also subclass of (P279), part of (P361)
Lists
Proposal discussion Originally created without a formal discussion
Current uses 21,362,433
[create] Create a translatable help page (preferably in English) for this property to be included here


Target items of "instance of (P31)" should have a statement with "subclass of (P279)": If [item A] has this property with value [item B], [item B] is required to have property "subclass of (P279)"
Exceptions are possible as rare values may exist. Known exceptions: entity (Q35120)
List of this constraint violations: Database reports/Constraint violations/P31#Target required claim P279, SPARQL
Conflicts with “total produced (P1092): this property must not be used with listed properties and values.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P31#Conflicts with
Conflicts with “instance of (P31): man (Q8441), woman (Q467), male (Q6581097), female (Q6581072): this property must not be used with listed properties and values.
List of this constraint violations: Database reports/Constraint violations/P31#Conflicts with, hourly updated report
Conflicts with “instance of (P31): person (Q215627), Homo (Q171283): this property must not be used with listed properties and values.
List of this constraint violations: Database reports/Constraint violations/P31#Conflicts with, hourly updated report
Qualifiers “said to be the same as (P460), of (P642), start time (P580), part of (P361), end time (P582), comment (DEPRECATED) (P2315), follows (P155), followed by (P156), series ordinal (P1545): this property should be used only with listed qualifiers.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P31#Qualifiers, SPARQL
Pictogram voting comment.svg Multiple P31 claims lead to duplicate tuples
Multiple P31 claims are unnecessary in most cases with Wikimedia-related items. Consider facet of (P1269) instead of second P31 value.
Violations query: SELECT ?item # ?inspected ?itemLabel ?else WHERE { VALUES ?inspected { wd:Q4167836 wd:11266439 } VALUES ?whitelistedCombinations { wd:Q4115189 wd:Q15397819 #placeholders } ?item wdt:P31 ?inspected . ?item wdt:P31 ?else FILTER (?else != ?inspected). MINUS { ?item wdt:P31 ?whitelistedCombinations . } # SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } }
List of this constraint violations: Database reports/Complex constraint violations/P31
Pictogram voting comment.svg P31=samevalue and P279=samevalue
in most cases this is an oversight or item that needs update after child item(s) were added
Violations query: SELECT ?item # ?itemLabel ?class1 ?class2 WHERE { ?item wdt:P31 ?class1 ; wdt:P279 ?class2 . FILTER (?class1 = ?class2) MINUS { ?class1 wdt:P31?/wdt:P279* wd:Q17442446 } # any internal stuff FILTER (?class1 != wd:Q11173) FILTER (?class1 != wd:Q7187) FILTER (?class1 != wd:Q8054) FILTER (?class1 != wd:Q201448) FILTER (?class1 != wd:Q215980) FILTER (?class1 != wd:Q277338) FILTER (?class1 != wd:Q284416) FILTER (?class1 != wd:Q427087) # SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } }
List of this constraint violations: Database reports/Complex constraint violations/P31
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Usage note[edit]

Usage is detailed in Help:Basic membership properties.

Discussion[edit]

Is/was a[edit]

If I understand correctly, at some point we'll have a way to use qualifiers to specify the time that any attribute was held, so wouldn't it make sense to change the label of this to "is/was a"? --Yair rand (talk) 07:11, 5 February 2013 (UTC)

I've started a discussion about this property here. --Kolja21 (talk) 08:55, 5 February 2013 (UTC)
This is meant to be used in a very limited way for statements we want to make for which a property is inappropriate. For example, "<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[edit]

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 by Janjko (talk • contribs). Usage is detailed in Help:Basic_membership_properties.

Not localizable[edit]

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)

Problem Localizing to Persian[edit]

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

so the sentence like is a sovereign state will be

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

and not

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

how can we implement these kind of staffs. or it is not a right place! --Pouyana (talk) 20:01, 7 February 2013 (UTC)

This particular property may need to be rethought, but for this kind of problem, I would think the best solution would be to find a phrase it so that word order is ok. If that is not possible, you may want to leave a message on Wikidata:Contact the development team. Cheers. --Zolo (talk) 06:30, 8 February 2013 (UTC)
Perhaps renaming the property "type" or another noun would help. -- Ypnypn (talk) 21:24, 8 February 2013 (UTC)
You don't need an exact translation on word-level, you can use a phrase but that phrase must be unique and usable in the property parser function. Well basically, you don't want a very long phrase as it is cumbersome to type. See m:Wikidata/Notes/Inclusion syntax v0.3. Jeblad (talk) 21:54, 8 February 2013 (UTC)

Semantical nonsense[edit]

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

I think this is an eseencial property. It just filters items in the crudest way. --NaBUru38 (talk) 21:18, 8 February 2013 (UTC)
It's meant to be used for "person" or "place" or something. Anything more detailed goes in other properties. -- Ypnypn (talk) 21:25, 8 February 2013 (UTC)
This property is for define the type of the item. In your first example is a State, in the second one is a person. --β16 - (talk) 22:01, 8 February 2013 (UTC)
Then maybe we call this property a normal noun? Like "type"? Wizardist (talk) 03:41, 9 February 2013 (UTC)
Yes probably, see Wikidata:Property_proposal#Main_type_of_item_.28entity.29_.2F_Art_des_Objekts_.2F_Type_principal and Wikidata_talk:Property_proposal#is_a. --Zolo (talk) 08:34, 9 February 2013 (UTC)
What if we use this property for the "entities" of GND (person, name, corporate body, event, work, term, place)? --Sannita - not just another it.wiki sysop 12:43, 9 February 2013 (UTC)
+1. Imho "main types of items" is the better choise. This seems to be the original concept of Wikidata:Infoboxes task force. --ThorstenX1 (talk) 21:56, 10 February 2013 (UTC)
+1 to rename to 'type' or 'itemtype', or something similar with much more specific meaning than 'is a'. Now we can have object.GetType() :) --Yurik (talk) 10:36, 13 February 2013 (UTC)
There is now Property:P107 that is better defined that this one - though implementation details still remain to be worked out. I think items using this property should be changed so that they use more specific property (like Property:P106 and Property:P107) and then this property can be deleted.

Prevent or avoid "is a"[edit]

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[edit]

{{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)
Symbol oppose vote.svg 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...[edit]

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

  • Sounds good. :-) James F. (talk) 20:12, 20 February 2013 (UTC)
  • What about 'is the'? Emw (talk) 02:24, 14 March 2013 (UTC)

A related property[edit]

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

Hierarchy[edit]

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

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

is a -> instance of[edit]

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)

Symbol support vote.svg Support--Svebert (talk) 23:31, 16 March 2013 (UTC)
Yes. Espeso (talk) 01:53, 17 March 2013 (UTC)
Symbol support vote.svg Support, "is a" is ambiguous and likely to be misused --Stevenliuyi (talk) 02:21, 17 March 2013 (UTC)
Pictogram voting comment.svg Comment Symbol oppose vote.svg Oppose 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)
Good explanation, btw. --DixonD (talk) 08:32, 19 March 2013 (UTC)
I thought over about it these days, but I'm not sure and clear with everything. (Note: My contra was meant as an "stop, wait a moment", not as a real contra.) To a possible second property (about which I already thought about, too): I think we should use less properties, so I would say no to this idea. (@Silver hr: Thanks for your explanation, but I'm sorry that mathematics is not my wold, so I've to stay with programming terms. ;) I hope the rest gets along with it..)
I would like to discuss some examples, because till now I'm not really sure if we could really describe the whole world with subclasses and instances. An example that I've been thinking about: Is the video game Half-Life (or software at all) an instance of "video game" - or a subclass? If it is (as I would say) a instance, what would then a mod (e.g. GMod in past) for this game would be? Of course a "mod" (also in order of "is a"), but it should also be a part of the game. That means in order of "instance of" it would be an instance of Half-Life too. What would be "multiple inheritance" (yeah ;)), but it would be then an instance of an instance..? How to solve something like this? (I think I got another example, but now I can't remember..) I hope that I could describe good enough what I mean (and sorry for my bad English..). Best greetings, --#Reaper (talk) 20:48, 19 March 2013 (UTC)
  • see en:Class (computer programming) and en:Instance (computer science). describe the whole world with subclasses and instances I don´t see that too. I would say, that should depend on how to use the properties p31 and p279. In my view both properties could be used for internal use, for example quality management. At the moment, someone could say that the value of the "place of birth" (p19) is the color yellow. Together with "main type" (p107) we could build a system, that gives a warning to the editor if the value of the "place of birth" is not a "place"-type and not an "instance of", lets say municipality (type of administrative division (p132)) or a class in which a municipality is a "subclass of" (p279). --Goldzahn (talk) 21:08, 19 March 2013 (UTC)
  • Reaper, that's a great point. Because video games, software, books, and other such items can have instances -- e.g. a video game on a shelf, an installation of a operating system or web browser, a book in a person's hand -- I think they're best considered to be classes, and not instances. Instances are items with a unique location in space and time. Reliably-sourced classifications that use these kinds of relations, like The Software Ontology, refer to items like Java and operating system as classes, and use the 'subclass of' (really, rdfs:subClassOf) relation to define their membership in other classes like 'programming language' and 'software'. (P.S., I think your English is very understandable.) Emw (talk) 03:51, 20 March 2013 (UTC)
The thing that helped me better understand ontological concepts is experimenting in Protege OWL, a visual editor for OWL ontologies. Note that OWL has more features than Wikidata has or will have according to current plans. There's a tutorial for it here, and even if you're not interested in Protege or OWL, the tutorial has a nice visual representation of instances, classes and properties somewhere in the first few pages.
Also, to be able to describe the whole world in a structured way, another essential property we would need is "has part", which I think would solve the problem posed by your mod example.
Silver hr (talk) 23:17, 20 March 2013 (UTC)
Thanks for your answers and sorry for my late answer. I though about my example "mod of a game" from above and about Emw's answer. And I came to the result, that we should use "instance of" for software and all other digital or replicable things (like films, books, ..). But at first something general (or for this example): "GMod is a mod (of Half-Life)", but also "GMod is an instance of Half-Life" according to my last post (according to programing structure), but for sure not the other way around: It's not "GMod is a Half-Life". So "is an instance of" is on this side more than "is a". We maybe should think about this.
Now let me explain my reasons for my decision why software should be an instance: The point which I mentioned just, GMod is a mod. In order of language use we wouldn't say that "GMod is a Half-Life". The other reason is, that - likewise also in language use - a game, software, film or book would never be a subclass of something. A film, book and also software would always be an single item, even if it's nothing you could touch. I'm currently not sure how we could solve the problem (in general) that something is a "mod of" something, maybe with "has part" mentioned above. But otherwise "subclass of" would break the language use in a really hard way, and also would disrupt all other real statements like "is subclass of subclass".
But I'm also not sure what to do with like "Netbook X31" as a product, not as a single, touchable object. Hmm.. Maybe an other property for this..? And sorry, I haven't looked at the links posted above, maybe later when I've more time. (And English isn't so easy for me... makes it more difficult to read and understand.)
I always get confused when I think about this.. ;) Best regards, --#Reaper (talk) 22:06, 27 March 2013 (UTC)
GMod is a part of Half-Life, since recent :) Infovarius (talk) 10:07, 28 March 2013 (UTC)
Yes, I know this new item, but this statement would be wrong. (Question: is "has part" and "is part of" the same? I think its the opposite, but I can't translate "has part" (it seems untranslatable, but I think I know what it means).) It's more like "GMod uses Half-Life" or similar. (A map or level would be a part of Half-Life.) --#Reaper (talk) 17:51, 28 March 2013 (UTC)
First of all, "Netbook X31" would be a class, and probably a subclass of "netbook". A particular physical product identified by a serial number would be an instance of "Netbook X31". As for the relation between GMod and Half-life, I'd put it this way (just an example, doesn't necessarily correspond to Wikidata items). "GMod version x" instance of "GMod", "GMod" subclass of "mod", "GMod" modifies "Half-Life".
The reason I was originally thinking in terms of a "has part" property is because you could describe the two in the following way. "Half-Life" has part "file hl1", "Half-Life" has part "file hl2", ..., "GMod" has part "file hl1", "GMod" has part "file gmod1", ..., but I'm not sure how appropriate that would be for Wikidata.
As to the difference between "has part" and "(is) part of", they are inverses. If A has part B, then B is part of A. Also, there is now some good documentation for the differences between "instance of", "subclass of" and "part of" here, I recommend reading it.
Silver hr (talk) 00:04, 31 March 2013 (UTC)
Symbol support vote.svg Support Silver hr (talk) 01:31, 18 March 2013 (UTC)
Symbol support vote.svg Support --Don-kun (talk) 19:28, 19 March 2013 (UTC)
Symbol support vote.svg Support Yes, I believe this and the "subclass" property represent the clearest distinction yet between the two. Shawn in Montreal (talk) 14:58, 21 March 2013 (UTC)
Symbol support vote.svg 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)

"это" вместо "является одним из"[edit]

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

Достаточно было поставить двоеточие в конце :) На самом деле "это" - слишком неопределённое и, возможно, не совсем подходит, надо подумать. --Infovarius (talk) 20:19, 21 March 2013 (UTC)

Proposal: establish rdf:type as the basis for this property[edit]

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)

Symbol support vote.svg Support, at least until m:Wikidata/Data_model#InstanceOfSnak gets implemented. Silver hr (talk) 18:25, 22 March 2013 (UTC)
Symbol support vote.svg Support Tpt (talk) 14:04, 23 March 2013 (UTC)
Pictogram voting question.svg 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)

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

Proposal: establish rdf:type as the name for this property[edit]

If it now has the semantics of rdf:type, then use that as the name. Andrea Shan (talk) 03:20, 19 November 2014 (UTC)

  • Pictogram voting comment.svg Comment User:Emw's "would make this property [...] more interoperable with the rest of the Semantic Web" applies here too. The proposal was triggered by User:Jeblad's statement at 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)
  • Pictogram voting comment.svg 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[edit]

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.
Aber Mitglied einer Gruppe ist missverstaendlich: Zum Beispiel ist Sigmar Gabriel (Q160902) Mitglied der Gruppe SPD-Bundestagsfraktion (Q2207512), aber dieser Zusammenhang darf gerade nicht mit instance of (P31) modelliert werden. Ich wuerde also die Gruppe aus der deutschen Beschreibung gern loeschen. -- Juergen 62.143.196.71 12:07, 10 January 2016 (UTC)

Proposal regarding P107 and P31[edit]

Please see Wikidata_talk:Property_proposal#Proposal:_use_GND_main_type_.28P107.29_classifications_as_initial_classifications_for_P31; comments welcome. Emw (talk) 20:47, 24 March 2013 (UTC)

The definition of 'instance' and 'class'[edit]

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

Nombre en español[edit]

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

instance of terms[edit]

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[edit]

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

Examples:

Which one is the correct way? --DSGalaktos (talk)

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)
I would have thought that Windows Phone 7 (Q1854343) is a subclass of mobile operating system (Q920890), and the instances would be the actual installed OS on a given phone. Installations are instances. Danrok (talk) 14:25, 30 May 2013 (UTC)
  • Actually we handle software as an instance, because a (digital) copy (what an installation would be) would be.. um.. a bit fuzzy and "useless". (A computer is a "copy machine", everything is copied there.) --#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[edit]

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)

Your usage of instance of (P31) and part of (P361) are both correct. I corrected Dongen Formation (Q2481793). See Help:Basic membership properties that provides a pretty good summary of use. That error would have been caught in the next User:Byrial/Class-type conflict (mismatching types between two items linked by subclass of (P279)). I am not aware of a constraint identifying items with mutually exclusive properties; possibly Byrial (talkcontribslogs) has another report for this already? You may also check in Wikidata:Database reports. -- LaddΩ chat ;) 02:22, 28 July 2013 (UTC)

Qualifiers[edit]

It would be useful to write out recommendations on how to qualify properties like instance of (P31), subclass of (P279), and related properties

I would say: use

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)
If by "A qualifier should be only used to define a property. ", you were referring to my question about where to place the dates for 18th National Congress of the Communist Party of China (Q137566) , I think I agree with you.
Actually, my proposal was also may also apply for other properties, and I should probably have posted this on the project chat. I was just trying to see if we can document the use of qualifiers, as it may have a large impact on item structure. My proposal may apply to various other properties, but I found it easier to start with one or two properties rather than doing things it in a more general and abstract way. I think P31 and P279 are good starting points, as they are very important and commonly used, and they do define what the item is. --Zolo (talk) 12:41, 4 September 2013 (UTC)
Hi, I have a RfC on the pipe, unfinished so it's not published at this time, see w.wikidata.org/wiki/Wikidata:Requests_for_comment/Constraint_violation_technical_bases TomT0m (talk) 12:48, 4 September 2013 (UTC)

Inconsistency?[edit]

Template:Documentation (Q4608595) instance of Wikimedia template (Q11266439);
Category:Countries (Q4026570) instance of Wikimedia category (Q4167836);
Wikipedia:Glossary (Q1389361) instance of Wikimedia project page (Q14204246);
Signature (Q298582) instance of Wikimedia disambiguation page (Q4167410);

but

Mercury (Q308) instance of planet (Q634).

Why not

Mercury (Q308) instance of Wikipedia article?

Looks like different relation types. Why do we use same property for both cases? — Ivan A. Krestinin (talk) 19:05, 5 September 2013 (UTC)

Great question. You're right; there is an inconsistency. For several months I've argued against using P31 and P279 for classifying internal details of Wikimedia projects like templates, category pages, etc. It's not only encyclopedic navel-gazing, it also requires us to arbitrarily add an entirely different perspective to Wikidata's concept hierarchy -- we need to say "these things over here are about the external world" and "those things over there are about internal details of Wikimedia projects." I think P31 and P279 (and probably all other properties) should be confined to the respective mainspaces of the Wikimedia projects supported by Wikidata. Emw (talk) 00:34, 6 September 2013 (UTC)
I am glad someone else sees this as a problem after all! I was trying to argue that the only logical solution to this is to make the items that do not represent real-world things as a different entity type, move them from Q12345 to N123456, for example. Littledogboy (talk) 13:36, 6 September 2013 (UTC)
Except it is a real-world thing. I can trivially view a wiki page of a particular type. So your statement isn't logical at all. Would you care to amend it? --Izno (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)

Value statistics[edit]

Can we get somewhere statistics of (probably, most frequent) targets of this property? --Infovarius (talk) 13:03, 27 December 2013 (UTC)

Можно временно добавить: {{Constraint:One of|values=}} при этом бот сгенерирует статистику при очередном обновлении Wikidata:Database reports/Constraint violations/P31. — Ivan A. Krestinin (talk) 21:38, 5 January 2014 (UTC)
Отчёт сгенерился, посмотреть можно здесь (открывается долго). — Ivan A. Krestinin (talk) 23:17, 5 January 2014 (UTC)
Thanks a lot, Ivan ! To summarize, as of Jan 6, 2014, P31 was used by 5119213 items (full table is here) - LaddΩ chat ;) 00:31, 8 January 2014 (UTC)

Correct 'instance of' value for a football match?[edit]

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
< FA Cup final matches > subclass of (P279) View with SQID < FA cup matches >
while we decide if we need a new <football match> item or not for the upper levels. TomT0m (talk) 15:18, 4 March 2014 (UTC)
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)
That's brilliant, thank you for your help @TomT0m:. I'll go ahead and make those new classes. Regards, NavinoEvans (talk) 23:32, 4 March 2014 (UTC)
One more thing I've just realised - there is actually already an item in Wikidata 'FA Cup Final' (Q4484477). Should I actually use this value instead of making the class <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
< FA Cup Final > subclass of (P279) View with SQID < FA Cup matches >
) ? NavinoEvans (talk) 00:19, 5 March 2014 (UTC)
I think you got the spirit, NavinoEvans :) There might also be an item for the corresponding category no label (Q7504623) (I'll add the statements to officialise this) and even an open RfC to decide what we should do with all these kind of similar items Wikidata:Requests_for_comment/Define_lists_on_both_"Wikimedia_lists"_and_"Wikimedia_categories". One more thing : you will like the autolist tool which will help you to batch add statements on all the items on a Wikipedia category, amongst other things :) TomT0m (talk) 12:35, 5 March 2014 (UTC)
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?[edit]

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)

Ijon, no, human roles and positions should not have 'instance of: human' claims. instance of (P31) human (Q5) is for particular people, e.g. François Hollande (Q157). Emw (talk) 00:42, 23 May 2014 (UTC)
Thanks, Emw, that's what I thought. I'm removing P31 from Tuanpai (Q2761490), then. Ijon (talk) 02:11, 23 May 2014 (UTC)

Definition of 'instance of'[edit]

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)

Hatmaking is a class, so your example is flawed. --Izno (talk) 07:36, 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)
Sounds good. Andrew Gray (talk) 22:30, 26 November 2014 (UTC)
My edit was reverted by an anon IP with no explanation. Does anyone else have an opinion on it? Kaldari (talk) 18:53, 3 December 2014 (UTC)
The revert looks good. Fix the statements instead. Andrea Shan (talk) 04:22, 4 December 2014 (UTC)
I don't see how it makes sense to define hatmaking or general relativity as classes rather than instances. A class is a group of things. How is hatmaking or general relativity a group? Kaldari (talk) 02:34, 8 January 2015 (UTC)

See also: Subclass of?[edit]

Regarding @Yamaha5:’s edit of adding see also (P1659) subclass of (P279), and @Succu:’s edit of removing it with the comment “different!”:

I disagree with that removal. I don’t think that “see also” implies “the same”; on the contrary, I think that the difference between 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.

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

Usage with a twin[edit]

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)

I don't consider Q159979 as an error - it is about "one of the twins" (not both). May be in this case Q5 is superfluous but I am not sure: can twin (Q159979) be an animal or a character? --Infovarius (talk) 16:03, 28 January 2015 (UTC)
As of 27 december 2013, a twin has been declared subclass of a human, but immediately reverted and declared a set of humans, maybe because the user who did this is russian and the russian description, which I cannot see, falsely stated twin (Q159979) is the set of two twins ??
As long as that (IMHO wrong) state persists, we need both instance-of-relations, because currently twin is not subclass of a human.
But I think that revert should be reverted and twin be made a subclass of human again, and when that would be done, we would no longer need to declare a twin also a human.
Anyway, a twin cannot be an animal or character, neither in the current nor in the suggested defintion. -- Juergen 62.143.196.71 12:15, 10 January 2016 (UTC)
ru:Блицзнецы and some other articles linked to 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)
Articles like that should be moved to twins (Q14756018). --Yair rand (talk) 17:55, 10 January 2016 (UTC)

French translation of instance of (P31)[edit]

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> :

  • <instance X> exemplaire de <classe Y>
Symbol oppose vote.svg Oppose --Djiboun (talk) 19:44, 22 February 2015 (UTC)
  • <instance X> élément de <classe Y>
Pictogram voting comment.svg Comment mix-up with the french translation of item --Djiboun (talk) 17:16, 15 February 2015 (UTC)
  • <instance X> instance de <classe Y>
Pictogram voting comment.svg Comment too much abstract, but exact translation --Djiboun (talk) 17:16, 15 February 2015 (UTC)
  • <instance X> est un/une <classe Y>
Symbol support vote.svg Support good enough --Djiboun (talk) 19:44, 22 February 2015 (UTC)
  • <instance X> nature de <classe Y>
Symbol oppose vote.svg Oppose opposite meaning of the original --Djiboun (talk) 17:16, 15 February 2015 (UTC)
  • <instance X> expression de <classe Y>
Symbol oppose vote.svg Oppose not enough precise --Djiboun (talk) 17:16, 15 February 2015 (UTC)
  • <instance X> nature de l'élément <classe Y>
Symbol oppose vote.svg Oppose ok for property description, but opposite meaning of the original --Djiboun (talk) 17:16, 15 February 2015 (UTC)

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

English translation is not the reference, IMO, the wording nature de l'élément is the best translation for rdf:type as explained here, much better for humans (speaking French)… genium ⟨✉⟩ 18:33, 15 February 2015 (UTC)

Traduire c'est trahir. Il n'y a de toute façon pas de bonne réponse à ce genre de question.
Utiliser « instance » serait une traduction plus littérale mais « instance » est un mot rare en français (voir un néologisme inconnu, le sens courant d'instance dans la langue française est l'acception juridique utilisé dans « tribunal d'instance ») et c'est du jargon technique. Cela ne me semble donc clairement pas la meilleure solution (à ajouter en alias par contre). Je suis très perturbé par « exemplaire » ; j'ai tendance à voir l'adjectif avant le substantif et le substantif me semble trop restrictif (on parle de l'exemplaire d'un objet uniquement en particulier d'un livre ou d'une œuvre) et fait penser à « exemple » (dans le sens « modèle à imiter »). Sans compter qu'il y a déjà 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) »).
Cdlt, VIGNERON (talk) 19:11, 22 February 2015 (UTC)
@Djiboun: Bonjour, je vais m'exprimer en français vu qu'a priori, cette discussion ne concerne que les francophones Face-smile.svg. 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)
Hors sujet Face-smile.svg {{smiley|1}} au lieu de {{sourire}}. Eric-92 (talk) 02:28, 24 February 2015 (UTC)

Merci à vous pour vos réponses. Effectivement, pour répondre à VIGNERON, la traduction par «est un(e)» me semble en fin de compte la plus évidente. Pour répondre à Pamputt, l'origine de ma confusion est venue de «<X> nature de l'élément <Y>» dans la page Help:Basic_membership_properties/fr qui signifie en fait, si j'ai bien compris, «la nature de l'élément <X> est <Y>». En conservant la traduction de la propriété, il faudrait traduire le texte par «<Y> nature de l'élément <X>». Si on change la traduction de la propriété on pourrait avoir «<X> est un(e) <Y>». Est-ce que la traduction de la propriété doit être modifiée ? Je ne me prononcerai pas seul sur la question, mais il faudrait en tout cas adapter la traduction du texte dans Help:Basic_membership_properties/fr. --Djiboun (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) View with Reasonator View with SQID. author  TomT0m / talk page 14:33, 10 January 2016 (UTC)

Que dit le nom en anglais ? D'ailleurs je pense que chaque langue a ses difficultés. Nature de l'élément propose une simple définition de l'objet, alors pourquoi ne pas mettre objet ou bien définition de ... ou autre équivalent pour que nous comprenions quoi inscrire car il est vrai que nature de l'élément n'est pas simple à comprendre pour tout le monde qui arrive sur wikidata. — Nicolas ANCEAU

Le problème principal vient de la confusion entre "nature de" et "sous-classe de", pas évidente du tout, alors qu'elle est claire entre "instance de" et "sous-classe de" (les deux termes sont liés, une instance est une réalisation objective et unique de la classe, laquelle definit un type; une "instance" n'a pas de type dérivé, sinon c'est une sous-classe et sa réalisation n'est pas unique; une instance peut éventuellement être "clonable" mais le clone n'a alors plus aucun lien avec l'instance d'origine même si elle en partage le type, c'est-à-dire la classe; appliqué à une personne partriculière, la cloner produirait une personne particulière différente, elles seraient toutes les deux des instances de la classe "personne").

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

Quant au terme "sous-classe de", il peut aussi être traduit par "hyponyme de" en bon français, mais il est encore moins compréhensible (mais on le trouve utilisé sur le Wiktionnaire), et trop restrictif (toutes les classes et sous-classes ne sont pas des "noms" auxquels le terme "hyponyme" pourrait s'appliquer (exemple: "s'évaporer" est un verbe qui serait une sous-classe de "changer d'état" dans le cas partioculier du passage de l'état liquide à l'état gazeux, mais "s'évaporer" n'est pas un "hyponyme" de "changer d'état"; autre exemple "bleu foncé" est une sous-classe de la couleur "bleu", "bleu marine" est une sous-classe de la couleur "bleu foncé", les instances sont les nuances réelles dans une condition précise d'éclairage, y compris des composantes inobservables par le seul oeil humain ou par certaines personnnes). Verdy p (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 page 13:45, 10 April 2016 (UTC)
Voir aussi la classification des atomes / éléments / hydrogène sur le dessin ci après.
Atom classes.svg
qui fonctionne très bien. author  TomT0m / talk page 13:47, 10 April 2016 (UTC)
Ce n'est pas moi qui suis obsédé par la programmation, mais vouloir distinguer "sous-class de" et "instance de", cela vient justement de gens obsédés par ça (et justement qui ne connaissent que quelques languages qui font cette distinction ! Tout me comprend complètement à l'envers.
Ce que je dis est que cette distinction n'a PAS sa place dans Wikidata, elle rompt la notion importante de transitivité (en marquant le dernier niveau de façon bloquante), elle n'est pas stable du tout (à tout moment un concept dans Wikidata et dans les autres projets peut avoir besoin de spécialiser/instancier/sous-classer un concept).
Bref relis exactement et correctgement ce que j'ai écrit pour comprendre réellement. Cette distinction est totalement artificielle, uniquement issue des languages C++ ou Java ou similaires, alors qu'on peut tout faire avec une seule et même propriété ("sous-classe de" = "instance de" = "est un"), quitte à ajouter en plus (seulement dans quelques éléments concernés, mais ça risque d'être vite faux dans plein de pages Wikipédia ou ailleurs), une propriété "non instanciable"="non dérivable"="non spécialisable" (qui ne peut être vrai que dans une vue limitée d'un même concept et faux ailleurs, dès qu'on fouille un peu ou selon l'analyse apportée).
Ni l'une ni l'autre des deux propriétés n'a fait l'objet d'une réelle analyse formelle, elles ont été imposées de facto, sans réflexion préalable.
Fusionner les deux propriétés n'impêchera jamais de pouvoir faire un tableau des éléments chimiques.' Mieux, elle permettra de spécialiser l'uranium, par exemple en "uranium-238" ou "uranium-235"... Comme quoi ce qu'on croit non spoécialisable le devient vite: voouloir distinguer "uranium" en en faisant une instance d'élément chimique (bloquant son utilisation dans un autre concept qui en serait instance ou sou-classe), empêche d'en faire aussi une classe dérivable ou instance pour "uranium-238". On peut encore sous-classer avec les états d'excitation, les formes cristalines...
Verdy p (talk) 16:32, 10 April 2016 (UTC)
En plus ton schéma d'exemple sur les atomes est totalement faux dans les "métaclasses" (une obsession de ta part d'un programmeur C++)... Tout est déjà représenté dans la colonne centrale (classes), le reste est clairement redondant (colonne gauche), ou faux (colonne droite). Et si on part comme ça le nombre de colonnes dans ton schéma est illimité dans Wikidata alors que tu veux en fait exprimer d'autres contraintes, mais pas le classement lui-même. Verdy p (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 page 21:59, 10 April 2016 (UTC)

alias 1[edit]

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

Type "1" and enter the 1st statement. ;)
I tried "is a", but this usually gets me another property. --- Jura 16:00, 29 March 2015 (UTC)
So this is just so you can find the property easier when entering a new statement? Why not type “instance of” instead of inventing an arbitrary alias just so you can find the property easier? —DSGalaktos (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. --- Jura 16:36, 29 March 2015 (UTC)
If you want typing efficiency, type “P31”. Three characters. Having this property as the default proposal when there are no statements also seems reasonable. But what’s not at all reasonable, IMHO, is adding a completely meaningless alias to the fundamental property of Wikidata, just so you (you alone; I don’t imagine anyone else will just guess that “1” is a shortcut for “instance of”) have to type four characters less. If it came from someone with less useful edits than you (thanks for those, btw), I’d call this vandalism. —DSGalaktos (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. --- Jura 20:41, 29 March 2015 (UTC)
Someone needs to take a look at my contributions. ;) --Izno (talk) 02:56, 30 March 2015 (UTC)
Please point us to the ones you want us to look at. --- Jura 07:10, 30 March 2015 (UTC)
This one, I assume :) —DSGalaktos (talk) 12:47, 30 March 2015 (UTC)

Instance of = owl:NamedIndividual (not rdf:type!)[edit]

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

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

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

Chjohnson39 (talk) 13:35, 26 April 2016 (UTC)

@Chjohnson39: : MMmm NamedIndividual seem to be an OWL class, not a property : https://www.w3.org/2007/OWL/wiki/FullSemanticsNamedIndividuals so I don't really think what you write make any sense. But you should start the talk on WikiProject Ontology author  TomT0m / talk page 15:02, 26 April 2016 (UTC)
Right, but this shouldn't be used (except in the case of punning) as we use it (which is a divided opinion on the wiki). --Izno (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 page 19: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)
@Chjohnson39: Instance of is never transitive. End of discussion. author  TomT0m / talk page 10:52, 27 April 2016 (UTC)

label (ru)[edit]

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

Is "usually an instance of" good enough?[edit]

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)

Can't you qualify it with "according to" or whatever that property name is? --Izno (talk) 17:59, 20 September 2016 (UTC)
No. The property "instance of" is is being added to the property "birth date". So this is a claim about all birth dates. "According to" could be added to a claim about a particular person's birth date, but it doesn't make sense to add it to P569 (birth date). Jc3s5h (talk) 19:50, 20 September 2016 (UTC)

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

multiple values?[edit]

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)

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

Should I remove a P31 statement if there is already another P31 statement for a subclass?[edit]

Looking at Capra sarda (Q19621602) right now, this Sicilian goat species is expressed as an instance of mammal (Q7377) and as an instance of animal (Q729). But mammal (Q7377) is a sub-class of a sub-class of animal (Q729), so I think "instance of animal (Q729)" can be removed, right?

Thanks! Syced (talk) 06:02, 11 January 2017 (UTC)

Yes, in the general case. --Izno (talk) 12:53, 11 January 2017 (UTC)

P31 as qualifier[edit]

Moved from Wikidata:Properties for deletion instance of (P31) as qualifier usually means "object has role", which duplicates subject has role (P2868) or one new property that it proposed to split to (see P794 above). Other uses includes:

  1. "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
  2. sourcing circumstances (P1480) (e.g. Q2652443#P171). Use of instance of (P31)=statement with Gregorian date earlier than 1584 (Q26961029) and statement with mainsnak date marked as Julian that is more precise than 1 year (Q26932615) may also be replaced by sourcing circumstances (P1480)
  3. Other usages that should be replaced by another qualifier (city council of Hildesheim (Q28656255) by of (P642)), by value (e.g. Józef Badecki (Q11729889) by occupation (P106), Julienne Lusenge (Q23021435) by field of work (P101)), by reference (The second value of Q3264432#P625), or can be dropped (Q986519#P131)

I propose to:

  1. Stop using instance of (P31) as qualifier
  2. Migrate instance of (P31) as qualifier to other properties such as "subject has role" and "object has role"
  3. Add a abusefilter to prevent instance of (P31) from being used as qualifier

--GZWDer (talk) 14:50, 15 February 2017 (UTC)

Time2wait.svg 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)
  • Symbol support vote.svg Support (once the missing replacement property exists, obviously) --Swpb (talk) 16:01, 15 February 2017 (UTC)
  • Symbol support vote.svg Support (note I removed my earlier comment regarding the placement of this query - thanks for moving it.) ArthurPSmith (talk) 18:07, 15 February 2017 (UTC)
  • Symbol support vote.svg Support that this property is not used as a qualifier, other properties should qualify  — billinghurst sDrewth 00:42, 20 February 2017 (UTC)

consistent "point of view" in property descriptions?[edit]

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):

  1. (The object is) that class having this subject item as a specific example and member.
  2. (The object is a) class that has this subject item as one of its specific examples or members.
  3. (The object is) that class of which this subject item is a specific example and member.
  4. (The object is a) class whose specific examples/members include this subject item.

DavRosen (talk) 19:25, 18 February 2017 (UTC)

Massive overuse[edit]

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)
Symbol support vote.svg 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)