Property talk:P107

{{Property documentation |description=The six main types of items (+ disambiguation) used by GND, German Wikipedia, and Wikimedia Commons (called "entities" by librarians): person, corporate body, event, work, term, and place.<br/> ::* Relevant community discussions: :::* First deletion request: [[Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P107]] :::* Second deletion request: [[Wikidata:Requests_for_deletions/Archive/2013/Properties/2#main_type_.28GND.29_.28P107.29]] :::* [[Wikidata:Requests_for_comment/Primary_sorting_property|RFC: Primary sorting property]] :::* [[Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type|RFC: Migrating away from GND main type]] |infobox parameter=[[:de:Vorlage:Normdaten]] (Parameter TYP), [[:commons:Template:Authority control]] |datatype=item |domain=Any item |allowed values=<br> *#person ([[Q215627]]) {{label|Q215627}} *#organization ([[Q43229]]) {{label|Q43229}} *#event ([[Q1656682]]) {{label|Q1656682}} *#creative work ([[Q386724]]) {{label|Q386724}} *#term ([[Q1969448]]) {{label|Q1969448}} *#place, geographical feature ([[Q618123]]) {{label|Q618123}} *#disambiguation page ([[Q11651459]]) {{label|Q11651459}} see [[Wikidata:Requests for comment/Non-article items for property:p107]] |suggested values= |source=[[Q36578|Integrated Authority File]] (GND) {{label|Q36578}} |example=see [[#Examples]] |filter=[[Special:AbuseFilter/14]] |robot and gadget jobs=<br> **The gadget ''[[Wikidata:Tools#Wikidata useful|Wikidata useful]]'' lets the user select and save main type in one click. **[[User:Sk!dbot|Sk!dbot]] corrects false values, conflicts get reported to [[User:Sk!dbot/GND-conflict]]. **[[User:HobofanBot|HobofanBot]] lists entities with missing values : [[User:HobofanBot/GND List]] |proposed by=1 }}

{{Constraint:One of}} {{Constraint:Single value}}

See also: oc:Categoria:Tipe principal absent sus Wikidata

Table

This is the list of entities (also known as domains, or high level entities) used by the Integrated Authority File (Q36578) (GND).

• The "type" parameter is also used by the German and Polish Wikipedia Template:Authority control (Q3907614) templates.
• The Wikidata:WikiProject Infoboxes is based on these entities.
• Till summer 2013 they were used as Wikidata main types of item (Property:P107).

Type	German	Item
p	Person (individualisiert)	person (Q215627)
k	Körperschaft	organization (Q43229)
v	Veranstaltung	event (Q1656682)
w	Werk	work (Q386724)
s	Sachbegriff	term (Q1969448)
g	Geografikum	geographical feature (Q618123)
n	Name (nicht individualisiert)	don't use: ambiguity (Q1140419)

Note: The terms "person", "term" etc. are meant to generalize. Please don't take them literally. (Examples)

Stats

This is collection of manually updated datapoints as to how many items (Qxxx) have a P107 assigned.

Date	has entity type	total	%
2013-03-13			6.5
2013-03-15	515200	6937138	7.4
2013-03-18	726546	7253936	10.0
2013-03-20	770110	7378544	10.43
2013-03-22	785876	7602715	10.33
2013-03-26	878151	7955505	11.0
2013-04-01	970833	8722113	11.1
2013-04-08	1353517	10261328	13.2
2013-04-14	1440261	10413613	13.8
2013-04-28	1856340	11394530	16.3
2013-05-10	2554244	12247102	20.9
2013-05-28	3009743	12566951	24.0
2013-06-10	3243914	12562839	25.8
2013-06-17	3266308	12590619	25.94
2013-06-25	3306871	12651161	26.14
2013-07-25	3947211	13298051	29.7
2013-08-18	4220888	13613399	31.0

Relevant toolserver SQL queries:

select count(*) from page,pagelinks where pl_from=page_id and page_namespace=0 and pl_title="P107" and pl_namespace=120; 
select count(*) from page where page_namespace=0;

Archived creation discussion

Domain: Authority control / Normdaten / Autorité

Main type of item (entity) / Art des Objekts / Type principal

The entities are already marked in about 230.000 Wikipedia articles. With their help we can see at first glance what the item is about, even if descriptions and links are in a non-latin language. --Kolja21 (talk) 01:29, 1 February 2013 (UTC)

• The InstanceOf snak type will do the same thing. So, we have to decide if create this property to move it with a bot to the InstanceOf snak when this snack type with available or wait for it.

  I'm not sure that the "entity" name is the good one. Something like "Main type" may be better if we want to restrict the range of this property to a small set of types. Tpt (talk) 15:50, 1 February 2013 (UTC)

  +1. I personally prefer "main type" as well. "Entity" is the technical term used by librarians. --Kolja21 (talk) 18:09, 1 February 2013 (UTC)

  Changed the description. --Kolja21 (talk) 05:03, 2 February 2013 (UTC)

   Support Especially "person" is urgently needed. --ThorstenX1 (talk) 06:21, 10 February 2013 (UTC)

 Done Needed for templates and might help to solve the "is a" problem. --ThorstenX1 (talk) 10:52, 11 February 2013 (UTC)

Place

For the place type isn't it better this item Q2221906 than Q618123. I started a discussion here. --Viscontino ^talk 19:22, 11 February 2013 (UTC)

I think Q618123 is more accurate, as the other one sounds to have a more narrow sense, somewhat akin to "coordinates". There are not many Wikipedia articles, but that may be because there is not that much to say at such a general level. --Zolo (talk) 21:07, 12 February 2013 (UTC)

Galaxy/Earth is place, but not a geographical place. We should deal something with that. Infovarius (talk) 20:03, 13 March 2013 (UTC)

+1. We urgently need separate items for the GND main types. --Kolja21 (talk) 01:09, 14 March 2013 (UTC)

Guideline proposal

It does not appear to be possible to add detailed documentation on the property page itself, but as this property is supposed to help in sorting out items, we need to have clear guidelines about it.

This property seems to be inspired by (GND), so I have try to translate the first-level classification provided in Universal Authority File into Wikidata items. Note I could not find it on the official website (I just found "short list" that provides names for more specific subjects, but not for the main categories. Also, note that for such general concepts Wikipedia articles may not always be exactly equivalent in all languages.

So:

• Q215627 for human individuals
• Q43229 for organizations (except territorials entities)
• Q1190554 for events
• Q386724 for works
• Q618123 for places (including territorial entites)
• Q4167410 for diambiguation page
• Q151885 for everything else

Is that ok, or do we need to be more specific (especially for the "everything else") ?

We should also add one or more types for more "back-office" items (disambiguation pages, Wikipedia namespace pages...).

Thoughts ? --Zolo (talk) 21:08, 12 February 2013 (UTC)

The items we are using right now are just a compromise solution. Imho the six entities + disambiguation (type n) should get their own items. --Kolja21 (talk) 23:02, 12 February 2013 (UTC)

We shouldn't take Q151885 (concept / Begriff) for everything else, otherwise the property wouldn't fit to the authority templates. (Term / Begriff = Q1969448, see: Wikidata:List of properties.) But we can complement the list with a type x for everything else. --Kolja21 (talk) 23:24, 12 February 2013 (UTC)

Yes, creating special items may be better, we just need to adapt the notability policy. --Zolo (talk) 09:14, 13 February 2013 (UTC)

I updated Wikidata:Infoboxes task force tab intros, and the Template:Entities, to reflect the above discussion. I wrote that "term" (or "concept") implies everything else, but I am not sure on if this was the concensus. Are historical events and periods, e.g. murders, wars and centuries, events or terms? Term might be very common, and events uncommon. Mange01 (talk) 23:47, 14 February 2013 (UTC)

Hi Mange, it's a good idea to add the properties to the Template:Entities, but they differs from Wikidata:List of properties. I've changed Q1656682 (event as philosophical term) back to Q1190554 (event, like sport event). Q574288 (creative work) has been deleted and mixed with Q386724 (Œuvre: disambiguation) and we need to fix this (see: User talk:Hazard-SJ). --Kolja21 (talk) 01:32, 15 February 2013 (UTC)

BTW: Historic events, like the Battle of Marignano, are type s (terms).[1] It's a translation problem: "Veranstaltung" (event) is not the same as "Ereignis" (event). --Kolja21 (talk) 01:40, 15 February 2013 (UTC)

Update: Q574288 (creative work) is still deleted, and the new item Q4489340 now as well. For disambiguating we now got Q4649332. This pages: Special:WhatLinksHere/Q574288 have wrong links, and thanks to a bug, editors can't even see the deletion note. Wikidata, a place where you can go nuts ;) --Kolja21 (talk) 14:24, 15 February 2013 (UTC)

This proves that it is dangerous to only allow certain items for a property - they may be deleted, for example if they have no Wikipedia article. When other datatypes are made possible, should we assign it a letter (p,n, etc) instead? Another approach, using Wikipedia categoriy items might be possible. Anyway, we should create a property that indicates a relationship between the property (P22) and the allowed items. For exampel Q215627 "is a" P107, or P107 "has options" Q21627, Q43229, etc. Mange01 (talk) 17:41, 15 February 2013 (UTC)

Giving a list of possible/allowed answers is a basic function of a database. Unfortunately Wikidata has no such feature yet and when we discussed it on the project chat the developers said, they hope that they can skip this work and leave the clean up to the community. When we will have lists (phase 3) this clean up will be easier. --Kolja21 (talk) 19:06, 15 February 2013 (UTC)

Wikipedia internal pages

Eventually we will have (or already have) many items for internal Wikipedia pages. (Per Wikidata:Requests for comment/Inclusion of non-article pages.) This is partially reflected above with the suggestion "disambiguation page" (the item for which I created). However, we will also have (I assume) the following namespaces: Category:, Wikipedia:, Template:, etc. Therefore, I would propose that one item be available under this property for those namespace pages also. A couple of them already exist, and are linked above. It's a way to separate the real-world articles from all the Wikipedia internal stuff for which we will have site links. Espeso (talk) 17:55, 15 February 2013 (UTC)

We had a talk about this earlier. I think adding a "type x" for those pages would be helpful. --Kolja21 (talk) 19:08, 15 February 2013 (UTC)

Clarifications for automobiles, boats, etc

I have some clarifications what are the GND for the following: 1. Cars, Car-Type, actual car like a ferrari - is this a concept? 2. Boats or Plane 3. How about train line - is this geographic feature? --Napoleon.tan (talk) 11:15, 23 February 2013 (UTC)

1. = Term (including brands)

2. = Term

3. = Borders, paths, lines (Grenzen, Wege, Linien) = type giw = geographic feature (example: Bonn-Berlin-Express)

--Kolja21 (talk) 05:05, 24 February 2013 (UTC)

ok thanks--Napoleon.tan (talk) 00:01, 26 February 2013 (UTC)

Vote for the best name (en)

Since this is the property that almost every wikidata item will have, I think we should give it a very clean and concise name. main type of item seems a bit verbose.

item type

 Support Yurik (talk) 03:46, 14 February 2013 (UTC)

 Oppose The item types are gib, gik, gio etc.[2] We only use the main type g. --Kolja21 (talk) 11:26, 14 February 2013 (UTC)

We are not bound by GND classification as we are not using completely. 141.6.11.19 14:39, 25 February 2013 (UTC)

 Support Snipre (talk) 14:43, 25 February 2013 (UTC)

main item type

 Support -- Mange01 (talk) 12:19, 25 February 2013 (UTC)

 Oppose If there is a "main", what are the sublevels of item type ? Snipre (talk) 14:43, 25 February 2013 (UTC)

Anything that is a(n) or all the various "type" properties points at. For example GND ontology subclasses, Geoname feature classes, Library subject classification, or used Wikipedia infobox type, such as Geobox, or Wikipedia category?Mange01 (talk) 15:16, 25 February 2013 (UTC)

If this property is restricted to the GND main types, then most subjects will have to be classified under the "term" (subject heading) GND main type, which is effectively not a type or classification. Another, more significant problem of using a property restricted to main types (whether GND main types or those of some other ontology) is that it implies the need for different properties for different levels of classification for a subject, which entails much more work to maintain. These problems are described in detail in Property_talk:P107#type. Emw (talk) 00:30, 8 March 2013 (UTC)

entity type

 Support Yurik (talk) 13:39, 14 February 2013 (UTC)

 Support, sounds the clearest wording for casual readers. --Zolo (talk) 13:52, 14 February 2013 (UTC) Bsside I think it is more accurate. This property is really about the entity, defined as " real-life subject (or abstract concept) a page in Wikidata is about". It does not set any constraint on the item itself, contrary to what "item type" seems to imply. --Zolo (talk) 21:25, 14 February 2013 (UTC)

support. Question, if this mostly follows GND, shouldn't the description at least say that. Or the label: "Entity type (GND)". Needs to be easy to access this property with few keystrokes because it's so fundamental (per OP). Espeso (talk) 17:41, 15 February 2013 (UTC)

I would say yes, in the description, but not in the label: if we do not exactly follow GND, that would be misleading. --Zolo (talk) 19:17, 15 February 2013 (UTC)

 Oppose Actually there are three types of Wikidata entities: Property, Item and Query. Mange01 (talk) 14:54, 24 February 2013 (UTC)

+1. already used Snipre (talk) 14:43, 25 February 2013 (UTC)

 Oppose 'type' would be a more succinct name. Emw (talk) 15:18, 3 March 2013 (UTC)

class

Classes and sub-classes are terms used in the GND ontology, where class also is called "high level entity type".

domain

In the GND ontology, domain is the allowed types of entities that a property may link to. The term is also currently used in Property proposals based on the preload.

 Oppose As the description immediately above explains, "domain" is different than "type". If Wikidata's support for knowledge representation continues to collapse higher-level ontology properties like "type" into the generic Properties namespace, then I would support adding "domain" (and relatedly "range"), but as a different property. Emw (talk) 13:04, 2 March 2013 (UTC)

main type of item

 Oppose Yurik (talk) 15:29, 14 February 2013 (UTC)

 Support -- Mange01 (talk) 12:19, 25 February 2013 (UTC)

 Oppose Emw (talk) 02:48, 26 February 2013 (UTC)

 Oppose Far too vague. --Avenue (talk) 20:47, 28 February 2013 (UTC)

 Support We can add "(GND)" to eliminate ambiguities. (Why "main type"? See: type.) --Kolja21 (talk) 18:00, 2 March 2013 (UTC)

 Oppose. An awkward phrase that would have some excuse if it reflected any formal terminology in use, but it apparently doesn't. Biases GND without mentioning GND: "main type of item according to who" etc. Espeso (talk) 15:48, 8 March 2013 (UTC)

entity type (GND)

Aliases: "GND entity type"

support Differentiates this entity type from any future classification systems; still brief. Espeso (talk) 02:48, 17 February 2013 (UTC)

 oppose as label but  Support as alias -- GND is the reference in case of discussion on classification, but we do not follow it strictly since additional types (n and perhaps x) are not part of GND. Mange01 (talk) 16:57, 24 February 2013 (UTC)

 Support --Napoleon.tan (talk) 00:03, 26 February 2013 (UTC)

 Support Maybe "extended GND entity type" would be more accurate, but this is good enough. --Avenue (talk) 20:47, 28 February 2013 (UTC)

 Support: if that's what it is. The current name "entity type" is just confusing. -- --  Docu  at 18:17, 1 March 2013 (UTC)

 Oppose the word "entity" in "entity type (GND)" is superfluous. Whether entity means "item, property or query" or just "item", properties only link entities. In other words, saying "entity type (GND)" is like saying "entity author", "entity birth date", "entity country", etc.: the word entity can be dropped without any change in meaning. More succinct titles are better. Emw (talk) 12:51, 2 March 2013 (UTC)

 Support if it has to be any of these it should make direct reference to the GND model from which it is based.

type

This label matches that of the 'type' property in RDF Schema, the W3C recommendation "for describing groups of related resources and the relationships between these resources." It is also the most succinct label.

 Support Emw (talk) 02:41, 26 February 2013 (UTC)

 Comment Please note that the type for Manet's Olympia is "wit", the main type, that we use, is "w". --Kolja21 (talk) 02:58, 26 February 2013 (UTC)

Kolja, I don't see how your comment relates to whether 'type' is the best label for this property. Could you explain? Thanks, Emw (talk) 03:11, 26 February 2013 (UTC)

Type is incorrect, since the types used by GND have three letters. We only use the main type. --Kolja21 (talk) 03:18, 26 February 2013 (UTC)

No, GND uses the word "type" (German: Typ) to refer to both these so-called main types and other types. See for example Anne Appelbaum, where there is only one 'type' entry, and Nauru, where there are two. Also, note that both so-called main types and other types have three-letter (MARC 21 equivalent) codes in GND: e.g. the so-called "main type" place or geographic name and a class that inherits it, country. Emw (talk) 12:15, 2 March 2013 (UTC)

Anne Appelbaum = type: piz, we use main type: p. Nauru = types: gik and gil, we use main type = g. --Kolja21 (talk)

piz = p. The GND uses the word type to describe so-called main types. If the GND groups both "main type" classes and non-"main type" classes into a property labeled "type", then why shouldn't we? This restriction seems superficial and unnecessary. Why limit the community-designated "type" property to seven classes used to categorize library holdings? Emw (talk) 19:12, 2 March 2013 (UTC)

"piz" stands for "Personennamen, die keinem anderen speziellen Entitätentyp zugehören"[3]. There are also tpyes like "pxg" or "pip" that are part of the main type p. The main tpyes are used in the authority control templates, that why we added them as a property. Adding more specific (three letter) types is imho not important, since the three letter code is only for internal use and not a classification system like Dewey. --Kolja21 (talk) 19:28, 2 March 2013 (UTC)

The distinction between "main type" classes and non-"main type" classes is an internal detail that the GND ontology intentionally obscures. The GND ontology groups both levels of classes into one property named "type". Wikidata should do similarly.

The likely reason that the GND doesn't classify subjects with a property named "main type" (and the reason Wikidata shouldn't either) is that it would entail using different properties for different levels of hierarchical classification. And that does not scale. Limiting this property to the seven GND high level entity types will require a new property to be applied if a more granular classification is desired. With the "main type" approach you could have many classification properties to specify what kind of thing a subject is; with the "type" approach you only need one.

For example, want to specifically classify Nauru? If this property is restricted to the seven "main type" classes, then you'll need to add "main type: Place or geographic name" and "type: Territorial corporate body or administrative unit". If this property is named "type" then you could just use "type: Territorial corporate body or administrative unit" (as GND does) and be done with it. The higher-level classifications would be automatically deducible. In subjects for which only a general classification is available, you could use the same "type" property. This is what GND does with Anne Appelbaum, for example. Emw (talk) 20:18, 2 March 2013 (UTC)

While I have stopped following the discussion here because this property doesn't interest me 50% of the time, I have to say that I strongly support your position to allow as specific a classification as the GND system supports. (It would help if a translation of the German document on GND subclasses was available.) This property as it stands now is exceedingly generic for at least one or two of its potential values. Espeso (talk) 22:02, 2 March 2013 (UTC)

The generic use is exactly the reason why we have this property. If we would split P107 in the three letter code, we 1. have a lot of work and 2. have to revise it once a while, because, as I said before, it's just for internal use and the code is getting improved. But of cause it would be helpful if we would translate the list, since a lot of people haven't read it jet. --Kolja21 (talk) 01:26, 3 March 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'll speak to each concern in order:

1. "Wouldn't using this 'type' property for specific classification and general classification result in a lot more work?" No, it would actually result in much less work. That's because it can be used for any level of classification: the most specific, the most general, and resolutions in between. How the current general-classification-only approach results in more effort and classification kruft -- and how this proposed alternative fixes that -- is explained immediately above in my previous reply.
2. "Wouldn't that mean a subject's classification would need to be revised much more frequently than if we restricted this property to the few most general types?" The subject's classification will change just as frequently with either proposal. The particular values of this one property would change less if it were restricted to highest-level types, but that approach implies a subject's classification would need one property per classification level: one property for the most general type, one property for the most specific type, and one property for each level of classification in between. Rather than requiring one edit on the page of each affected subject as with the proposed alternative, using the current approach would mean one edit per classification level per affected subject. Thus, restricting this property to only the highest-level types would make it much more expensive to modify Wikidata's ontology.

The GND uses this alternative approach. The lower-level GND types are not just for internal use. They are included in the ontology that was publicly announced on the W3C mailing list, and the document describing the GND ontology says it is "providing a format specification for the usage in the semantic web." Yes, that ontology is a work in progress, but so is Wikidata's. Allowing this property to describe both high- and low-level types -- like it does in GND and RDF -- would enable a Wikidata ontology to have the flexibility it would need. Emw (talk) 14:59, 3 March 2013 (UTC)

 Oppose - May be confused with variable type/data type, and other types. And this is not the GND type/subclass, but the GND class/domain/high-level type of entity. Signature, see history: Mange01 (talk) 22:09, 1 March 2013 (UTC)

I don't think there's much risk for confusion; people speak in context. And I don't think there's consensus to restrict the values of this property to the seven GND high level entities. Emw (talk) 19:30, 2 March 2013 (UTC)

 Oppose --Kolja21 (talk) 18:04, 2 March 2013 (UTC)

 Oppose This ("lower-level GND types") would be an other property. --ThorstenX1 (talk) 16:18, 3 March 2013 (UTC)

How does this address the problems I describe above with that approach? Emw (talk) 16:50, 3 March 2013 (UTC)

main type

 Support Mange01 (talk) 22:09, 1 March 2013 (UTC)

 Conditional support We should add "(GND)" to eliminate ambiguities. --Kolja21 (talk) 01:00, 8 March 2013 (UTC)

main type (GND)

 Conditional support only if this property is restricted to GND main types. Emw (talk) 13:22, 8 March 2013 (UTC)

 Support --Kolja21 (talk) 01:22, 9 March 2013 (UTC)

type (GND)

A more succinct version of 'entity type (GND)'

 Conditional support only if this property is property is restricted to GND types, both main types and non-main types. Emw (talk) 00:42, 8 March 2013 (UTC)

 Oppose As you said, this would include non-main types. --Kolja21 (talk) 00:57, 8 March 2013 (UTC)

 Support per Emw (vote moved from my "entity type (GND)" option of a few... weeks ago). Espeso (talk) 15:41, 8 March 2013 (UTC)

Discussion

 Comment. Is "main type", an official term ? If so, I would support it if we exactly follow the DNB's terminology. Otherwise, I do not think it is a good idea, as it is a bit obscure, and rather irrelevant if we do not use lower-level types. --Zolo (talk) 11:29, 14 February 2013 (UTC)

The official term is "entity" (German: Entität), but Wikidata is using it in a different way (Wikidata:Glossary). --Kolja21 (talk) 13:11, 14 February 2013 (UTC)

I don't think 'entity' applies here - google gives "A thing with distinct and independent existence", which is not the same as the type of that thing. --Yurik (talk) 13:19, 14 February 2013 (UTC)

"An entity is something that exists by itself, although it need not be of material existence. In particular, abstractions and legal fictions are usually regarded as entities" (Wikipedia). --Kolja21 (talk) 13:36, 14 February 2013 (UTC)

Exactly! Entity is the thing itself, whereas this property is the type of that entity. Adding "entity type" to the list above :) --Yurik (talk) 13:39, 14 February 2013 (UTC)

No Entity is something else. There are three types of Wikidata entities: Property, Item and Query. At least according to meta:Wikidata/development pages. (The glossary said something else, but I just changed it. I hope my change was ok.)

In the German Wikipedia version of the infobox authority control, the infobox parameter "TYP" is used for main type of item (p/k/v/w/s/g). Which is an argument for "type". However, type can be confused with data type (until today "type" was defined as datatype in the glossary), or GND sub-class. Mange01 (talk) 12:31, 25 February 2013 (UTC)

Where does the GND define "entity" as the official term for this property? I see GND using the word "type" (German: Typ) as their user-facing name for this property (e.g. here, here), and "class" as the more official term in the GND ontology namespace document and the GND ontology definition in RDF. Emw (talk) 12:28, 2 March 2013 (UTC)

The english version of the GND ontology does not talk about "entity" or "type" in this sense, but about seven "high level entities" under the title "examples". Later under the headline "Detailed Information - Classes" , these are called "subclasses" of the "Authority Resosource" (which is the root class). (Actually, undifferentiated and differentiated persons are are grouped into the same class "person", and one extra class called "Name of the person" is not subclass of anything.) The englissh translation seems a little bit stiff. Is there a German version of this document? Mange01 (talk) 18:45, 2 March 2013 (UTC)

Two properties ?

There is some ambiguity betwen GND types, and homemade Wikidata type. What about splitting it into 2 properties:

• "GND type", that would be directly copied from the DNB with as little human intervention as possible. It could be the 1-letter code, or the 3 letter code, but in any case a simple (and somewhat obscure) string. When the item as no GND ID, it should be left empty
• "entity type", that could use GND for guidance but would be adapted to Wikidata's needs. It could include types like "Wikidedia help page", and it would be of the "item or "multilingual string" datatype to make it more intuitive for readers. --Zolo (talk) 08:40, 15 February 2013 (UTC)

Ha, ha, you really like to complicate things. The good thing about the main type of item is, that we can use the systematic of GND, what is - in 286 languages - difficult enough. If we would now start our own systematic, we can stop the rest of the work and discuss the next two or three years, if the name of an animal is a term and what the term "event" should mean. So please let's solve the existing problems like "creative work" (Q574288/Q386724). --Kolja21 (talk) 14:09, 15 February 2013 (UTC)

The additional "GND type"property would be pure copy-paste, while this one needs some discussion anyway, even if we make it as similar to GND as possible. --Zolo (talk) 14:38, 15 February 2013 (UTC)

Why exactly is GND useful? How do we know that the GND creators have got their type system right? Nobody seems to have answered why exactly GND is useful other than simply saying "well, German Wikipedia use it". Which doesn't really answer the question. —Tom Morris (talk) 22:16, 11 March 2013 (UTC)

Tom Morris? You dead since 1908. Or are you en:Tom Morris (footballer)? A name is just a name unless we have reliable sources to identify a person. On of the best sources is the en:Integrated Authority File. That's why Wikipedia - not only these strange Germans - uses GND in more than 200.000 articles. --Kolja21 (talk) 20:04, 15 March 2013 (UTC)

• Full  Support. Due to counter-intuitive, too restrictive (but amazingly: not linked now with GND-site!) nature of this property, it distracts community powers. Wikidata needs its own consensus-based ontology. Infovarius (talk) 12:11, 9 April 2013 (UTC)
•  Oppose Please read Wikidata:Requests_for_deletions/Archive/2013/04/05#Property:P107 where you have voted to delete this property. We don't need to start this discussion again. --Kolja21 (talk) 20:48, 9 April 2013 (UTC)

Purpose of 7 main types?

What is the main reason for dividing everything into only seven main types of items - but no well-defined sub-types? Is it that certain properties only should be allowed for certain main types, and the property definitions may differ?

The chosen GND approach makes me a little bit worried, since the intuitive understanding of the main types is different in many languages, as seen in the discussion above. The "terms" main type will be huge, and should be divede into many sub-types with a limited set of allowed properties, while the events sub-type will be very small. We have already seen that people use properties for other types of entities than they were intended for, resulting in confusing definitions.

There are several possible options to defining main-types and sub-types. For example:

• en:Dewey Decimal Classification is used in libraries in an increasing number of countries.
• The Wikipedia infoboxes may be used as sub-types, for example "settlement", "taxonomy", "royalty", etc. This approach would make Wikidata a useful help-project to Wikipedia. All items with the same infobox share a similar set of parameters (corresponding to Wikidata properties), and parameter definitions for this context are provided in the infobox documentation. Also, several infoboxes may "inherit" parameters from one "generic" infobox. E.g. ":en:template:Infobox country" and many other geographical infoboxes are based on en:template:geobox. A suggestion is that articles sharing the same "generic" infobox should belong to the same main type, and articles sharing the same infobox should belong to the same sub-type. If differences between languages, the enwp structure may be the main map.Mange01 (talk) 18:15, 15 February 2013 (UTC)

I am not against additional classifications, but I would like something siimilar to GND as a first step for sorting items. There can be controversy as to what items we should use as property values, but once we have settled for it, determining the type of individual pages should be rather straightforward. Thematic systems like Dewey have a different purpose and are a lot more blurry, with considerable overlap. I have myself often looked for, say, a book in the economy section when it was actually in history. And they do not provide any clean way to tell if the item is a person, or a concept, while it sounds really important for Wikidata --Zolo (talk) 19:12, 15 February 2013 (UTC)

Clean distinctions can be useful, but ambiguity is often necessary too. Some of our items are quite explicitly about multiple concepts, e.g. both a town and the surrounding district, or both a district and the governing local authority for that district. So Masterton should have entity types of "organisation" and "geographical feature", for instance. For many other items, the overlaps are more implicit. For example, books can easily cover a range of subjects, or a single subject from multiple perspectives. We need processes that are flexible enough to deal with such items sensibly. --Avenue (talk) 00:59, 28 February 2013 (UTC)

Well the first purpose is to serve the templates (Commons and German Wikipedia) that are using the six main types. Adding the disambiguation (type n), and maybe a type x for category pages etc. (see above) helps Wikidata. Later, if the software is ready, we can think about sub-types and adding other systems like Dewey. --Kolja21 (talk) 19:20, 15 February 2013 (UTC)

Ok, I suppose I should be more patient and wait for future sprints... Will certain properties be prohibited to use for a certain main type, for example by some bot job? Or does the main type have any other purpose? Mange01 (talk) 00:58, 16 February 2013 (UTC)

The software itself does not seem to be conceived for this sort of task, but I bet bots and tools will be used for that, yes, and also to find incomplete items (say a person without a birth date, or a place without coordinates). It could conceivably also help for "phase 3" (lists). --Zolo (talk) 09:03, 16 February 2013 (UTC)

It's the same in the German Wikipedia: Knowing the type of item helps finding errors. There are bots, lists, and Wikipedia maintenance categories using them. --Kolja21 (talk) 14:03, 16 February 2013 (UTC)

I think part of the problem here is inflated expectations about the relevance of this property for most items. It seems useful in a library context, e.g. for broadly classifying creators of works, hence its use on Commons. But Wikidata is not a library. The very general "term" value won't help much with the bulk of our items, e.g. it makes no distinction between a species, a movie, or an economic theory. So I agree that another more broadly useful classification (or classifications) is much needed. --Avenue (talk) 00:59, 28 February 2013 (UTC)

Of course six, seven or even twenty main types can't serve as a classification like Dewey etc. They just let you now, what the item is about: A person, a place or disambiguation page. That's all but a lot if you don't know what "ปารีส" stands for. My ideal would be a Wikidata where every reader can see a the first glance what an item is about, using for example colors for the main types of items. But I think Wikidata is going an other way where humans are only need as technicians and readers stay with Wikipedia. Wikidata will work in the background, and the regular editor don't care much about it. --Kolja21 (talk) 02:44, 28 February 2013 (UTC)

Yes, this property will give useful information for some items. My point is that knowing the entity type is "term" tells us almost nothing, so this property is essentially irrelevant for many of our items. We can do better.

I'm sure some Wikipedia editors will have no interest in Wikidata. I hope more will want to engage with particular data values that affect the articles they edit, and there will be a few more technically minded ones who get more fully involved. Not so dissimilar to how Commons works already, or templates within Wikipedia. Perhaps the main difference is that bots could be more important in Wikidata, with more scope for them to either improve data or to mess it up. --Avenue (talk) 12:06, 28 February 2013 (UTC)

I strongly agree with Avenue. Wikidata exists to structure all knowledge. The GND ontology only covers a small subset of knowledge: persons, places, organizations, works and events. Everything else is called a "term", which is not an actual type or classification. This 'type' property needs to be able to classify subjects in GND's domain and all those outside it (which is most subjects). We need an ontology that can also classify things like inertia, carbon, DNA, Alzheimer's disease and dog. The GND ontology is not big enough for Wikidata. Emw (talk) 21:01, 3 March 2013 (UTC)

Ha, ha you never will like the main type property. Use "is a" and be happy. --Kolja21 (talk) 22:14, 3 March 2013 (UTC)

The problems with a 'main type' property are outlined in Property_talk:P107#type; 'is a' doesn't solve them. Emw (talk) 22:46, 3 March 2013 (UTC)

P107 is used in authority templates. There is no problem to be solved, apart imho there should be separate items like "place" instead of "geographical feature". The property might not meet your expectations, but it's not meant to replace a complete system of categories or similar. --Kolja21 (talk) 04:15, 4 March 2013 (UTC)

It would be helpful to have specific responses to the multiple issues that contributors have noted about this property. There is at least one significant unaddressed problem with this property raised by Avenue and supported by me immediately above, and several other significant unaddressed problems described in detail in Property_talk:P107#type that I have raised and Espeso has supported. Emw (talk) 02:44, 6 March 2013 (UTC)

Auto-translated table

Old version of table: The main types of items ("entities"; Property:P107) of the Universal Authority File (GND) as used in the template de:Vorlage:Normdaten:

Type	Item	English	Deutsch	Français	Español	Italiano	한국어
p	Q215627	person (individualized)	Person (individualisiert)	personne	persona (individualizado)	persona (individualizzato)	사람 (개인)
n	Q4167410	name (disambiguation)	Name (nicht individualisiert)	nom	nombre (desambiguación)	nome (disambiguazione)	이름 (동음이의)
k	Q43229	corporate body, organization	Körperschaft, Organisation	société, organisation	corporación, organización	società, persona giuridica	조직, 단체
v	Q1656682	event	Veranstaltung	évènement	evento	evento	사건
w	Q386724	work	Werk	œuvre	obra	opera	창작물
s	Q1969448	term	Sachbegriff	terme	término	termine	용어
g	Q618123	place	Geografikum	lieu	nombre geográfico, lugar	luogo	장소

Note: The terms "person", "place" etc. are meant to generalize. Please don't take them literally. (Version from 16 Febr 2013.)

There is no room fore more columns. I made the following auto-translated template for some languages.

This is the list of entities (also known as domains, or high level entities) used by the Integrated Authority File (Q36578) (GND).

• The "type" parameter is also used by the German and Polish Wikipedia Template:Authority control (Q3907614) templates.
• The Wikidata:WikiProject Infoboxes is based on these entities.
• Till summer 2013 they were used as Wikidata main types of item (Property:P107).

Type	German	Item
p	Person (individualisiert)	person (Q215627)
k	Körperschaft	organization (Q43229)
v	Veranstaltung	event (Q1656682)
w	Werk	work (Q386724)
s	Sachbegriff	term (Q1969448)
g	Geografikum	geographical feature (Q618123)
n	Name (nicht individualisiert)	don't use: ambiguity (Q1140419)

Note: The terms "person", "term" etc. are meant to generalize. Please don't take them literally. (Examples)

Should we use template:Main types instead of template:Entities? Mange01 (talk) 00:11, 16 February 2013 (UTC)

Is it possible to show - beside the own language - always English and German? We need both as a reference, since English is international and German the source, where the terms are translated from. (Even if I don't speak German I can see the connection between "Type g" and "Geografikum".) If there is a bad translation and no reference shown it will get pretty messy. --Kolja21 (talk) 14:27, 16 February 2013 (UTC)

I have added that. The table is multilingual (depending on user language settings), but is still only translated to a few languages.Mange01 (talk) 12:35, 25 February 2013 (UTC)

Entity names - and items

To avoid confusion, I suggest that either the items should be changed, or the main type names should be changed in the above table to the item names. For example, the English names would be changed to "organization", "geographical feature", "person" and "creative work". Mange01 (talk) 00:11, 16 February 2013 (UTC)

The current items are only a compromise solution and of cause, viewed strictly, wrong, since for example type p is about "persons (including pseudonyms), families, literary and mythical figures", while Q215627 is only about a person as an individual. We have to adapt WD:N for phase 2 (Wikidata talk:Notability) and create an item for each entity. --Kolja21 (talk) 14:11, 16 February 2013 (UTC)

Curios - where does w:en:dog belong to? How about the w:en:Krypto the Superdog? or the Belka_and_Strelka, the dogs that were the first dogs in space? --Yurik (talk) 14:27, 16 February 2013 (UTC)

Wikidata:Infoboxes task force: "dog" is a (biological) term and "Krypto the Superdog" is an animated television series = work. --Kolja21 (talk) 14:38, 16 February 2013 (UTC)

Difficult is the question about the famous space dogs. In this case the easiest way is to look in the GND database (instead of studying the rules). en:Knut (polar bear) is categorized as "Sachbegriff mit Individualnamen (siz)", that means type s = term. --Kolja21 (talk) 14:46, 16 February 2013 (UTC)

Bleh, not sure I agree with the last one. By your/GND logic, w:en:Koko_(gorilla) is a term, even though it is as close to a "person" in a broad sense of the word as an animal could be. I mean, when we have to debate how many signs a gorilla may express, and the exact meaning, that's very close to intelligence as we define it. I think the division should be - species vs individuals --Yurik (talk) 14:56, 16 February 2013 (UTC)

I have to agree that it sounds strange to classify an individual animal as a "term". It would really have thought it would be classified as "person", especially when gods (including animal headed ones are classified as "person". --Zolo (talk) 17:25, 16 February 2013 (UTC)

The real question then is whether GND should be used (and I'm not sure how useful GND is to Wikidata; but Wikidata will incorporate many things of use to different users; it could have properties for x different classification systems). I am not asking whether GND is appropriate, I simply wanted to state that as long as this particular property uses the GND system, then we have to follow that system. To me, the number of items that are simply called a "term" renders it a poor fit for Wikidata. Everything from "sociology" to "helium" to "Pythagoras' theorem" is simply a "term"... how informative! We are not a library. //

I visited this talk page because someone changed the English property name to "GND ontology high level entity", which I don't see discussed here and oppose as very wordy. There is a vote going on higher up (still open?). Espeso (talk) 02:44, 17 February 2013 (UTC)

I don't like the type s (term) ether since it is too generic. On the other side, these are the main type of items. If we want to go into detail, using the three letter code (sie = ethnographic; sis = languages etc.)[4], it's getting pretty complex. If an item has no label in Latin letters, the six types are nevertheless helpful. --Kolja21 (talk) 03:23, 17 February 2013 (UTC)

I wasn't aware of the subtypes. [I have seen that document before, but can't read it. :-)] I actually think that the three-letter subtypes could be helpful, but I'd need to see them translated. I am not suggesting another property, but simply making them "allowed choices" for this property (and put an alias on allowed items like "gnd:sis" for convenience). I agree that it's more complicated, but complexity needs to be measured against usefulness. As to your last sentence, a label cannot provide the structured information that an entity type does, whether the label exists or not, so I didn't understand it. Espeso (talk) 03:47, 17 February 2013 (UTC)

What is 太田牛一? Can I eat it? Is it a metro station? No, because the main type of item is "person". Knowing nothing or having this basic info, makes a huge difference. Of cause it would be nice if it was possible to add subtypes, but since there is no item "gnd:sis", it's not possible. The software is not ready yet. If Wikidata will be a fully functional database one day, it will be no problem to add "type sis" and list it under "main type s" at the same time. As far as I know the 1.3 million Euros will be gone in a few weeks, and the only thing sure is, that the system will not be ready by then. --Kolja21 (talk) 17:21, 17 February 2013 (UTC)

Subtypes (or instances) can be linked to higher level items using the property Property:P31 "Is a", which is suggested for deletion. See its talk page. I suggest that it should be renamed "Instance of (GND entity)" or "GND ontology instance of". Mange01 (talk) 20:31, 17 February 2013 (UTC)

 Oppose Please don't mix different systems. --Kolja21 (talk) 02:03, 18 February 2013 (UTC)

You are right. Instead of renaming it is better to create a new "instance of" property specifically for GND sub-categories. Is it any idea to suggest it now, or should we wait for the text data type? Mange01 (talk) 10:18, 18 February 2013 (UTC)

I'm afraid it's to early. The easiest way would be to implement it together with the GND. --Kolja21 (talk)

"Classification"

The purpose of the main types of items is to get a quick overview. If someone is only interested in biographies, he can skip the other items. VIAF, for example, has integrate them in its search box. For a detailed classification there are other systems like en:Dewey Decimal Classification (DCC). Historically there have been different authority files for persons, corporate bodies (organizations), and subject headings (terms). The en:Universal Authority File (GND) has integrated their content to one single authority file. --Kolja21 (talk) 02:27, 18 February 2013 (UTC)

Can we avoid ontology jargon?

If this is to be a property that's added to a very large number of items, it would be nice to have a less jargon-y name for it than "GND ontology high level entity". While it's important to be technically precise, it's also important for property names to be intuitively understandable.--Eloquence (talk) 23:43, 18 February 2013 (UTC)

+1. I still favor the original description "main type of item". (Later there was entity, than ontology.) --Kolja21 (talk) 23:53, 18 February 2013 (UTC)

Q4630597 : merge to Q1969448

Q1969448 (term) links to de:Begriff which links to en:Representation term associated with Q4630597.

OK to merge Q4630597 into Q1969448 ? Thank you. --Eric-92 (talk) 03:26, 20 February 2013 (UTC)

en:Term in the meaning of:

• Q1969448: (regular) term, like a word or a phrase.
• Q4630597: A representation term is commonly referred to as a class word by those familiar with data dictionaries.

I wouldn't merge the items. --ThorstenX1 (talk) 11:13, 20 February 2013 (UTC)

More types

Because on Wikidata are stored data not only for articles, there might be any type for tagging non-articles. I think in ideal case every item on Wikidata should have this property.

articles

• Six main types
• Disambiguation

non-articles

• Category (Q4989342)
• Project (Q2944611)
• Template (Q4989363)
• Portal (Q4663903)
• Help (Q914807)
• Other

Any opinions? JAn Dudík (talk) 07:22, 20 February 2013 (UTC)

I think there was a suggestion to create a type x for all non-article item. --ThorstenX1 (talk) 11:16, 20 February 2013 (UTC)

 Support Type x, but we need separate items (only for GND types) which do not interfere with "real" life. --Kolja21 (talk) 15:10, 20 February 2013 (UTC)

What about list (very frequent type of "articles")? Infovarius (talk) 11:13, 13 March 2013 (UTC)

If we start to go into details (we could make Type x1 = category; x2 = project etc.), than we have to split the six main types too. That would change this property into a "real" classification system, that is hard to manage and should not be base on the GND types. --Kolja21 (talk) 13:42, 13 March 2013 (UTC)

 Oppose. This property is not the place for more types. The proposal above should use Property:P31, "instance of". I also think it is time to remove "disambiguation" as a valid option for this property, since it is a "retrofit" and not part of GND. Disambiguation, like the others above, should be moved to P31. All of the items we have about these internal Wikipedia pages describe "instances of" Wikipedia categories/disambiguation pages/templates/etc and are suitably described by P31. Espeso (talk) 17:21, 19 March 2013 (UTC)

Type n (Name = disambiguation) has always been part of the GND. We really shouldn't have started this P31 stuff. "Is a" is an experiment and in the RFD there have been been strong arguments against it. Probably at a later point (when there will be sources) it will be useful. Right now it only produces endless discussions and interfere with the infobox properties. --Kolja21 (talk) 19:50, 19 March 2013 (UTC)

Type n isn't "Wikipedia disambiguation". I suppose if you want to call it what the GND calls it, then do so. I don't know if you've noticed, but this property has produced endless discussions and you seem to be about the only one supporting it. I for one am deprecating the use of this property in my editing and would support deletion of it. Espeso (talk) 19:53, 19 March 2013 (UTC)

Well I'm the only one left who takes time to answer the same questions from you and Emw repeated two or three times a day. You've tried to rename this property and it didn't work. You've tried to change it's use and it didn't work. But every few days you find a user that haven't read your threats and the discussion starts again. --Kolja21 (talk) 20:21, 19 March 2013 (UTC)

Excuse me Kolja21? Your observation skills need improvement. I've done nothing here but comment over the course of a month. The comments started out implicitly supporting the property and trying to figure out what it meant; participating in a vote for the name, and so on. My opinions happen to have changed during that time. Espeso (talk) 03:31, 20 March 2013 (UTC)

Relevant WMDE blog post by Denny

http://blog.wikimedia.de/2013/02/22/restricting-the-world/ is a post by Denny from WMDE in which he discusses an opinion of his about Wikidata's data model. It's very relevant to this property and its implications. I thought I'd note the post here in case folks haven't been aware it. Cheers, Emw (talk) 01:25, 1 March 2013 (UTC)

Vote for the nature of this property

The current vote for the best name for this property seems to largely split along people's preference for what the nature of this property should be, rather than its name per se. This vote attempts to measure preferences more precisely by dividing options into combinations of two primary features: A) whether this property should be based on the GND ontology, and B) whether it should be limited to a small number of main types.

Only GND

This property should be based on the GND ontology.

GND main types

This property should be confined to the GND main types: person, place, organization, event, creative work, and term.

•  Support--Svebert (talk) 20:22, 15 March 2013 (UTC) -> But this property should not be any important. We need a better root-categorization (=ontology). I would start with a new type proeprty with the controlled vocabulary “class/group“, “instance/element” and “none/other/undecidable”--Svebert (talk) 20:30, 15 March 2013 (UTC)
•  Support --Kolja21 (talk) 20:54, 15 March 2013 (UTC)
  •  Comment The name "Wikidata main type of item" based on GND should be kept. (See structure of Wikidata:Infoboxes task force.) --Kolja21 (talk) 16:22, 18 June 2013 (UTC)

• "Wikidata main type of item" is not the name of this property. The styling you refer to was inserted on that page in January (diff), more than a month before the discussions about this property's name began. The name of this property is "main type (GND)"; aliases include "GND type", "entity type (GND)" and "item type (GND)", all of which explicitly include "GND" in the name. As is clear from the lop-sided vote in this RfC, the overwhelming majority of voting contributors agree that this property should be confined to GND main types person, place, organization, event, creative work, and term -- as you voted above. Emw (talk) 16:03, 30 June 2013 (UTC)

• Support. --Izno (talk) 13:12, 19 March 2013 (UTC)
• Support. So for "Wikidata main type" we need a new, unlinked with German libraries, property. Infovarius (talk) 16:26, 1 July 2013 (UTC)

GND but not only main types

This property should be based on the GND ontology, but also allow GND non-main types, e.g. place, country; work, musical work, etc.

Not only GND

This property should not be based on only the GND ontology.

Only main types

This property should be confined to a small number of well-defined, high-level types, but not just those defined by GND.

•  Support – as per Infovarius above. Littledogboy (talk) 16:54, 1 July 2013 (UTC)

Not only main types

This property should allow well-defined types of any level of classification, e.g. place, country, disease, neurological disease, etc.

 Support for two reasons:

1. Wikidata exists to structure all knowledge. The GND ontology only covers a small subset of knowledge: persons, places, organizations, works and events. Everything else with GND is called a "term", which is not an informative type for classification. This property should be able to classify subjects in GND's domain and all those outside it (which is a huge set of subjects). We need to be able to classify things like gravity, carbon, DNA, cancer, clarinet, Twelver Shia Islam, fashion boot, dog and potato as more than simply "terms". The GND ontology is not big enough for Wikidata.
2. Only allowing main types implies that additional properties should be used for lower-level types, which would entail more work to create and update classifications. For example, want to specifically classify Nauru? If this property is restricted to main type, then you'll need to add "main type: Place" and "subtype: Administrative unit". The problem gets worse for subjects with more levels of classification, like organisms, instruments, molecules, illnesses, towns, etc. Using another property like is a for sub-main-type classification would not be a solution. Doing that would still require at least twice as much work to classify subjects, and it wouldn't deal with the problem that the six GND main types arbitrarily de-emphasize many domains of knowledge, among other problems.

Previous discussions in Property_talk:P107#type and Property_talk:P107#Purpose_of_7_main_types.3F contain more background and detail. Emw (talk) 03:14, 8 March 2013 (UTC)

 Oppose for multiple reasons:

1. This property has never been meant "to be big enough" for replacing a classification system like Dewey.

• If this property is based on the GND Ontology, then it positions itself as a replacement for the Dewey Decimal System -- at least in terms of breadth. Both are classification systems that claim a universal breadth, or domain. In terms of depth of classification, as I describe above and below, limiting this property to only main types seems like an is-ought fallacy to keep things just as they are in authority templates, which would lead to much less valuable classifications, or at least double the work needed to create and update classifications. Emw (talk) 03:21, 9 March 2013 (UTC)

Tell this the DNB. They have developed the GND and guess what classification system they use: Not ontology-domain-type Heidegger but good old Dewey. --Kolja21 (talk) 04:05, 9 March 2013 (UTC)

The GND Ontology has equivalence relations to the Dewey Decimal Classification, namely http://d-nb.info/standards/elementset/gnd#relatedDdcWithDegreeOfDeterminacy3. This means that the GND Ontology has (or could have) identical classes to all of the DDC, and thus be used as a replacement to the DDC. Emw (talk) 03:39, 12 March 2013 (UTC)

2. If you want to delete this property, use RFD.

3. This property is used by authority templates. It's needed and there is no reason why it would do harm to other properties that will meet your high expectations.

• The fact that the 'type' (Typ) parameter is used in authority templates one way now is not a cogent argument that it ought to be so in the future. They certainly don't "need" to be that way. In fact, I think most would agree that allowing more specific reliable 'type' values would be a good thing, not a bad thing, for German Wikipedia's Normdaten template and Wikimedia Commons's authority control template. Emw (talk) 03:21, 9 March 2013 (UTC)

Ha, ha, now you not only what to change this property, but also tell Wikimedia Commons and German Wikipedia they should change there templates? Only because you don't want to create a new property that fits your expectation? --Kolja21 (talk) 03:58, 9 March 2013 (UTC)

Why shouldn't the authority templates be changed if they're using a property that has significant flaws? As can be seen from reading the objections that many other contributors have raised, it's not only me that thinks this property has issues that need to be addressed. Emw (talk) 03:28, 12 March 2013 (UTC)

4. The main types are controlled by bots (Wikipedia templates <-> GND). Even if we would use the three letter code for useful types like "snz" (nomenclature biology - chemistry), it will be far from the "neurological disease" you are talking about. Other types like "sxz" (fictitious subject terms), "szz" (all doubtful cases) or "wie" ("use still unclear") are no help for Wikidata at all.

• I agree that the GND ontology's non-main types are often not a good fit for Wikidata. However, this does not mean that restricting this property to main types is a good idea; it means that other reliable ontologies should be included where the GND is not optimal. Emw (talk) 03:21, 9 March 2013 (UTC)

5. We had this discussion again, again and again (see above).

• That's correct. Issues raised by several editors have been dismissed or left unaddressed. Emw (talk) 03:21, 9 March 2013 (UTC)

6. The items we use for the GND main types are still a compromise solution and don't fit one hundred percent. (Type p, called "person" also includes families etc. Imho we need seperate items for the GND main types.) On this basis we can't start with "lower-level types".

• As I explain in my reply to your reason #4 above, this is reasonable argument against GND lower-level types, but not lower-level types from reliable ontologies in general. Emw (talk) 03:21, 9 March 2013 (UTC)

7. Wikidata has no qualifiers yet. If they will be implemented, we might can make more of this property, but it will never replace a complete classification system.

--Kolja21 (talk) 05:23, 8 March 2013 (UTC)

"Type p, called "person" also includes families etc." Really? That sounds like a very good reason to completely ignore the GND. —Tom Morris (talk) 12:22, 11 March 2013 (UTC)

 Oppose There should be some general types, and them, create subclasses from that type. We can't create any types we want. That would be a disaster. - Sarilho1 (talk) 11:36, 10 March 2013 (UTC)

• If the use of the type is ambiguous, then we should delete it or not use it, not attempt to shoehorn into it parameters which differ from well established parameters. --Izno (talk) 13:11, 19 March 2013 (UTC)

Having separate properties for controlled ontologies is silly

I come at this discussion as a Wikipedian and as someone with experience of working on Semantic Web projects. It seems to me that the need of a specific GND-based type property is unnecessary and slightly ridiculous.

We do not need such the "entity type" property. We need one simple property called "type". The use case for the property "type" covers all situations where one wishes to say that some thing is an instance of a general type, that there is a relation of instantiation between a specific thing with numerical distinctness and some abstract type. If we wish to define this in terms of a prototypical example, we can say that it is the relation that exists between a particular person and the general class of 'human'. The type relationship also links types into higher orders of types (such as the relation in the biological taxonomy of species).

We can also define it linguistically: there is a class of phrases in English of the form "x is a T" ("Tom is a human") and a similarly related class of phrases of the form "T₁s are a/an T₂" ("butterflies are an insect"). A type property in Wikidata would simply relate the instances to the type.

But what of the precious GND? The GND is not a special case of the type relation. I am a GND person (a http://d-nb.info/standards/elementset/gnd#Person in Semantic Web speak). But I'm also a man, a software developer, a philosophy graduate, a British citizen, a homosexual, a vegetarian, a tequila-drinker, a cynic, a commuter, a single person, a drum'n'bass fan and any number of other types one cares to think about. Some of these things will probably end up being types of things on Wikidata, others won't. The ones that do can be used in a type relation. The ones that don't, won't. And if the types that get created on Wikidata line up with existing types in other ontologies/vocabularies, we create a "same as" relation between the Wikidata object and the ontology.

We ought not to bless GND as the be-all-and-end-all of ontologies. It's useful for some things, and not useful for others. There are things that don't exist in GND. Simply declaring relationships between the Wikidata terms and the GND terms does the job just fine. GND uses RDF, and RDF supports this relationship by using the owl:sameAs property. GND Person is related to FOAF and FRBR equivalents. There are other existing ontologies including DBpedia, Schema.org, FOAF, SIOC, Freebase and so on. If we reserve "entity type" for GND, should we reserve "FOAF type" for FOAF? And "SIOC type" for SIOC? And "Schema.org type" for Schema? No, no, no, that way lies madness. Use a generic type relation, and express the restraints that the types give us in the Wikidata type system. Just say that an individual person is of type Q215627 and be done with it.

We also have some other absurd type-subproperties (and many more proposals for them daily on Wikidata:Property proposal). With my Semantic Web hat on, I can see absolutely no point in doing that. It makes querying more complicated. Instead of saying "find all objects that have the 'type' of 'Person'", one has to say "find all objects that have the GND type of Person". It makes no sense from a relationship-modelling perspective either. In English, we don't reserve "is a" for specific type relations and use other words for other specific type relations. With my wiki-politics hat on, I know why we have specific subproperties of the fundamental type relation: because it allows little groups of WikiProject denizens to stamp their ownership on particular areas.

If we are hoping that Wikidata is going to be part of the wider world of RDF-based linked data, know that this kind of thing is basically us condemning ourselves from the get-go to irrelevance. Because people will look at Wikidata's type system and say "what on earth were they smoking?" —Tom Morris (talk) 18:08, 10 March 2013 (UTC)

Yes, this specific property is unnecessary and perhaps slightly ridiculous in itself. Much more ridiculous are the efforts to stamp every item with a type using this property. I'd urge anyone doing so to reconsider whether that is the best use of their time here. These types are useful in some cases, just not in most cases. --Avenue (talk) 21:11, 10 March 2013 (UTC)

Aren't they useful to start a data tree, being this property the foundation? I admit that Wikidata is a bit confusing, so I don't know if I'm right or not. - Sarilho1 (talk) 22:01, 10 March 2013 (UTC)

The type property shouldn't be the foundation for "a data tree" (whatever one of those is: I'm presuming you mean a tree of classes that inherit from one another with something like Liskov's principle). The type property is just the fundamental metaphysical tie from instance to class. Building the type property around one particular metadata use case like GND simply means that one hasn't understood the point of class-object relations in a fairly fundamental way. The class objects themselves can express inheritance relations and other such things (disjointness, property cardinality etc.) rather than the type relation. —Tom Morris (talk) 22:15, 10 March 2013 (UTC)

I don't see a problem with adding types for every object. Almost every object should probably have a type, and most things will have many types (as I said: a person will have types around profession, citizenship and so on). Doesn't have to be one from a constrained vocabulary of types like GND, but a huge chunk of Wikipedia entries would have a type in a broader sense. The idea that there needs to be only one type is stupid. The idea that we need to have a controlled hierarchy of top-level types is also silly and pointless. Modelling Wikidata after something like GND is foolish. —Tom Morris (talk) 22:10, 10 March 2013 (UTC)

I wasn't arguing against types in general, just the idea that we must classify every item as being one of these particular 7 types. (Maybe my reference to "using this property" above should have been more specific.) --Avenue (talk) 22:25, 10 March 2013 (UTC)

For example: the term person can't be given by others proprieties (more specified ones)? In that way we wouldn't spent so much time categorizing. - Sarilho1 (talk) 10:45, 11 March 2013 (UTC)

You don't need a GND-specific type relation to use a GND-based type. If some entities fall within the remit of a particular GND type, tag it as such with a generic type relation. —Tom Morris (talk) 12:15, 11 March 2013 (UTC)

Tom Morris, you may be interested in the deletion discussion for property "is a", which thankfully wasn't deleted. I agree with you (and your wiki-politics hat also seems well-tuned). I have been rather concerned with the proliferation of "type of this" and "type of that" properties. However, this project is nascent and numbers, I think, tend to win debates (to the extent there are any), rather than knowledgeable design perspectives. What is a constructive way forward, given what Wikidata does and does not actually support in software?—that is the question. Espeso (talk) 23:04, 10 March 2013 (UTC)

Hi Tom, I'm sure you know Wikipedia infoboxes and templates. One of the aims of Wikidata is providing infos for infoboxes and templates. The GND main types (aka "entity types") are used in templates (see for example: de:Vorlage:NORMDATENCOUNT). They have a clear function. Unfortunately, some authors interpret extravagant expectations into this property because it's listed under generic properties. Expressions like "ontology" gave them a thrill. This property is not meant to help creating a semantic web. --Kolja21 (talk) 23:27, 10 March 2013 (UTC)

What bothers me most with this property is that it uses a concept from GND but also applies it to things that do not have any GND entry. To me, we should either restrict if to items with a GND link, and in this case import it from GND, or extend it to all items, and in this case choose a different name and do something more in line with Wikidata's needs. --Zolo (talk) 07:16, 11 March 2013 (UTC)

Yes, I agree that restricting it to things that have a GND entry would be sensible. This may be easier to enforce once sources are supported. If the statement isn't sourced within an agreed timeframe, it could be removed automatically. --Avenue (talk) 02:05, 13 March 2013 (UTC)

Note: In Wikipedia (authority contol templates) it is use also without GND. It helps finding persons in other databases and is used by tracking categories. --Kolja21 (talk) 03:58, 13 March 2013 (UTC)

Kolja21, I don't see how that changes the argument. Use of GND types doesn't need a special property, it just needs the objects of the statements to be marked as having GND equivalences. I'd like to think I'm not bringing "extravagant expectations" to it, but I just don't understand why one set of types, used for the rather niche use case of categorising German books, should be a special kind of type relation compared to other type relations? I can't see any good reason for that. The same effect can be achieved by having a generic type relation and having the types themselves marked as having GND equivalences. It looks to me as if people who don't really understand the underlying principles of this kind of data modelling are designing a system around the bizarre preferences of German Wikipedia rather than understanding the broader principles that are at work. —Tom Morris (talk) 08:22, 11 March 2013 (UTC)

Hi Tom, I totally agree with you that the GND main type should not be overestimated. On the other hand it's not only used for categorising books. There are more than 10 millions GNDs for all kind of subjects, more than Wikidata has items. (It's used by archives, museums etc.) When we started Wikidata:Infoboxes task force it was a great help, otherwise we would have no structure at all. If I see a Korean item and know this item is about a person, it helps me with the translation. It's a question of the label and description that editors understand what this property is used for. The only thing I dislike about property 107 is, that it's doesn't use separate items. A GND type p is called "person", but of cause it's not always a single person; type s is called "term", but again this should not be taken literally. So what you are calling a "bizarre preferences" is only due to the fact that Wikidata properties have started with the infoboxes and templates, what was imho not a bad choice. Whatever system will be developed, it can use this properties or ignore them. --Kolja21 (talk) 16:53, 11 March 2013 (UTC)

Yes, but that doesn't answer the question. Why do we need a GND-specific type relation to use GND types? There is nothing distinctive qua the type relation to say that something is a person per the GND than to say that it is some other type of thing which isn't defined by the GND. We might want to say that objects in Wikidata ought to have at least and at most one GND type. Great. Let a bot enforce that. But you don't need a specific type relation for that. —Tom Morris (talk) 22:22, 11 March 2013 (UTC)

I'm glad that yet another contributor is noting significant flaws in this property's proposed usage. The main argument for restricting this property to the six GND main types is a basic fallacy: that it ought to be so, because it currently is so in the German Wikipedia and Wikimedia Commons. Emw (talk) 23:35, 11 March 2013 (UTC)

That's a very peculiar interpretation. As far as I understand Tom's objections he is strictly against developing the GND main type property into a ontology-type-general-system. ("Modelling Wikidata after something like GND is foolish.") You really should go to Wikidata:Property proposal instead of trying to conquer the most used property. --Kolja21 (talk) 00:35, 12 March 2013 (UTC)

Tom's objection seems simple: this property should not exist, or at least not be tied to the GND. I'm not sure if I agree, but I do agree that the current approach is quite flawed. I think it would be helpful to specifically address these issues. Emw (talk) 01:25, 12 March 2013 (UTC)

The most used property of Wikidata (404.203 times) should not exist? The "approach" of this property is easy to understand. It has a clear function. In a few weeks we will start to connect it with the authority templates, where it is used without problems. --Kolja21 (talk) 01:43, 12 March 2013 (UTC)

Again, your response doesn't answer the problems raised. I see the fact that this property is so widely used as a reason to address its problems more urgently, to avoid Wikidata from becoming the PHP of the Semantic Web. Emw (talk) 02:01, 12 March 2013 (UTC)

Terms

The only thing that I thing is confusing is the term. What is that? Everything has a term or more to designate an object. A geographical object also has a term to designate it, a name to designate that particular object. For example: Hydrogen, the chemical element is not a term, the term of hydrogen is the word hydrogen, hidrogénio... The classification in terms is useful for a dictionary because they are leading with words and names of things. Here we are leading we concrete things that receive a code to designate them, and a term in every language. If this is not respected, Wikidata will become ambiguous. - Sarilho1 (talk) 12:27, 11 March 2013 (UTC)

You'll get no argument from me about Wikidata being about things not terms. The terms don't matter except in as much as we use them to refer to the things. —Tom Morris (talk) 12:35, 11 March 2013 (UTC)

I'm just trying to understand this property. I really don't know this can be used properly, neither what type of category are terms and how can we identified them. - Sarilho1 (talk) 12:52, 11 March 2013 (UTC)

Hi Sarilho1, the expressions "term", "person", "place" etc. are meant to generalize. "Please don't take them literally" (Wikidata:Infoboxes task force). What we call "term" is GND type s, which includes biology and chemistry (type snz), brands (sip), software products (siw), and historic events (sih). --Kolja21 (talk) 17:59, 11 March 2013 (UTC)

The "term" type should be deprecated. It is not a useful classification or type, and is probably the GND Ontology's biggest flaw. It squeezes all knowledge that does not fit into the GND ontology's narrow domain into a catch-all class that is essentially a traditional library classification system. I don't see how not taking the type labels literally relates to these problems. Emw (talk) 23:44, 11 March 2013 (UTC)

Forget about "ontology", "domains" and other stuff. This property is only about the GND main types. Otherwise all hell is breaking loose, and we will discuss the next months what kind of GND-Emw mix will be suitable for Wikidata. The biggest advantage of this property is, that we have a list and a database we can look up the GND main types. In Wiki terms you could call it "NOR". P107 does not publish original thought. --Kolja21 (talk) 00:54, 12 March 2013 (UTC)

How does that address the problems with the "term" type? Emw (talk) 01:12, 12 March 2013 (UTC)

As I said above: We don't "invent" the main types, we take them from the GND. If you found errors or inconsistencies in their work, you have to write the GND editors. --Kolja21 (talk) 01:48, 12 March 2013 (UTC)

That doesn't address the problems with the "term" type. If there's a problem with an element of some imported ontology then it should be addressed, not ignored. I think the best way to address the problem is to deprecate the use of "term", since it has no value as a classification. Do you think "term" has value as a classification? If so, how, specifically? Otherwise, do you have a different suggestion for how to fix that problem? Emw (talk) 02:12, 12 March 2013 (UTC)

"How does that address the problems with the "term" type?" - "That doesn't address the problems with the "term" type." Could it be that you repeat yourself? Could this be the problem? Wikidata:Infoboxes task force will solve your problems. There you can suggest a special property that fits your needs. --Kolja21 (talk) 02:20, 12 March 2013 (UTC)

I repeat myself because the responses given so far have evaded addressing the issues many contributors have raised with this property. I know where to go if I want to suggest a new property. Laughing at and dismissing the issues people raise, telling them to go away, and introducing red herrings to the discussion is not helping. Emw (talk) 02:54, 12 March 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Let me reply to the response that "We don't invent the main types" again. "We don't invent the main types" seems to suggest that we should unquestioningly apply classes from third-party ontologies even if they seem clearly and significantly flawed. If problems are shown to exist in the GND or any other third-party ontology, then why should Wikidata need to apply them? Why not simply avoid using those flawed types -- like GND's uninformative "term" type -- in classifying items? Emw (talk) 03:11, 12 March 2013 (UTC)

Why not simply accept a property that is widely accepted and used in Wikipedia? Your proposal ("Why shouldn't the authority templates be changed") and your criticism of the GND should be addressed to the person concerned. --Kolja21 (talk) 04:12, 12 March 2013 (UTC)

Because part of the point of a centralisation project like Wikidata or Wikimedia Commons is to step back and find better ways of doing things. Just saying "well, German Wikipedia are using it" doesn't answer the technical objection that having controlled-vocabulary-specific type relations is profoundly odd and slightly perverse. There's plenty of stupid things English Wikipedia does, and I'm not in a hurry to export them all to Wikidata.

The problem with controlled vocabularies is that they don't actually let you say what the thing is very well. Should the Mafia be categorised as 'k', a corporate body, organization? Is it a corporate body? No. It's probably ten thousand shell corporations, front groups and so on. Should the fictional city of Atlantis be considered a place (g)? I don't know. Let's have a twenty page argument about it rather than just tagging it with a generic type relation as "fictional place". Should Lady Macbeth be tagged as a person (p)? Oh wait, "The terms "person", "place" etc. are meant to generalize. Please don't take them literally." So, is Lady Macbeth a person? Is the Mafia a corporate body? Is Atlantis a place? How am I supposed to know how literally or non-literally I should take the controlled vocabulary?

Oh, but without this, there will be "anarchy". Oh yeah? I'd rather have a little anarchy than an enormous amount of stupidity when we realise sometime between now and the four millionth tagging that the semantics of 'person' or 'place' or whatever are such that something ought to not be in there.

Uncontrolled vocabularies don't leave one with "anarchy". What ends up happening is that there becomes a set of common tagging practices that are common to all, and the semantics of such tags are emergent. It's worked pretty well for OpenStreetMap. You can tag anything with any combination of key-value pairs. The more common things get rendered onto the map (amenity=pub means that it gets a pint glass, amenity=bar means it gets a cocktail glass) while new tags have to prove themselves before being rolled out on the map. If you use crazy wackaloon tags, the things you've entered just won't appear on the map properly. A feedback loop grows between the tagging practices and the rendering practices.

How does this work with Wikidata? Well, the infobox usage on-wiki will determine the properties used by Wikidata. If, say, "infobox author" on English Wikipedia decides to start picking up some property like "net worth", then it'll be used. Infobox usage sort of gives us a Darwinian form of duck typing. Over-reliance on controlled vocabularies seems to be, to quote the famous attack on the Semantic Web: "An attempt to apply the Dewey Decimal system to an orgy." —Tom Morris (talk) 07:31, 12 March 2013 (UTC)

If you favour uncontrolled vocabularies you now have two properties: "is a" (Property:P31) and "generalization" (Property:P279). There you can enter whatever you want, even without sources. We probably also will have "hashtags" (Wikidata:Property proposal). --Kolja21 (talk) 04:07, 13 March 2013 (UTC)

Could someone explain to me the difference between P107 tand Property:P31? Why we don't use P31 instead of P107. It is more general in my opinion. Marie Curie is-a Person instead of Marie Curie type-identity Person. To be honest I don't bother about the exact term, but I think P31 and P107 are dupes. I started a discussion here: Wikidata_talk:List_of_properties#is-a_vs._entity-type_vs._generalization and was informed about the discussion on this page. Also I like to point to two proposals of rules (Property_talk:P31#Delete or rename and Property_talk:P31#Hierarchy) for the application of P31.--Svebert (talk) 14:34, 14 March 2013 (UTC)

It's not only more general, in P31 ("ia a") you can enter whatever you associate with the item. --Kolja21 (talk) 04:01, 15 March 2013 (UTC)

I did change the name to GND type entity. This property is not a root categorization. It just reflects the GND-template in german Wikipedia.--Svebert (talk) 07:37, 15 March 2013 (UTC)

If we call it "GND entity type“, does it make sense that there is a type (wikipedia disambiguation page) that GND doesn't have?

no, of course not. Because its not a GND entity type.

Also I think it is not good to mix this “weird” GND-entity-type with other possible categorizations/types like disambiguation.

I suggest it would be better to implement another property called “type“ which may have the following values: “concept”, “instance of concept”, “disambiguation”, (“other/none”).

So my full suggestion for a concept of these three overlapping properties (is-a, generalized-by and GND-entity-type) would be

1. Merge is-a and generalized-by to is-a
2. Use GND-entity-type only for the template GND and possible GND property-values, dont mix this with other possible values
3. Add a new property called “type” which may have the value “concept”, “instance of concept”, “disambiguation”, “other/none/undecidable”;

Reasons:

• We should not confuse some sort of categorization with one parameter of some “weird“ template of the german wikipedia or even mix it.
• We should denote if an item is a class/concept or an instance of a class/concept, see the difference between “is-a” and “generalized-by” (see Property_talk:P279#Archived creation discussion)
• We should not use properties which are applied in a false way, see is-a which is applied much much more than generalized-by but in fact most of times the latter would be the right property.

--Svebert (talk) 11:20, 15 March 2013 (UTC)

We have already a discussion above "Vote for the best name (en)". --Kolja21 (talk) 20:12, 15 March 2013 (UTC)

The problem with using the GND is not just a matter of choosing an appropriate name. The GND is oriented towards the bibliographic data constructed with the current European-American (actually, mainly American at least in origin) mind-set. This may be very useful as a way of facilitating the understanding and interchange of bibliographic data,but it does not apply to the universe in general. The scope of Wikipedia is much broader: everything that can be talked about in human language. The clearest example of this to me is the high-level entity "subject heading" , a term of art in libraries and indexing systems with a meaning very difficult to pin down, and typically based on ad-hoc inspiration. Another one is our personal-name structure, which is based on the naming conventions in Euro-American library catalogs, and accommodates other cultures only by ad-hoc add-ons.

What I believe we are trying to do in wikidata is several things, and they are of only limited compatibility. The first is the only one actually applied at present, the trivial but achievable one of coding interlanguage links, which conveniently uses an international standard code that we have already adopted. The second, also fairly simple, is code matching with other outside standard codes, such as geodata. To do this, we need to accept the existing standards. To code for bibliographic records, we need to use something the the GND, which however arbitrary, is a known standard in the external world. The third is provide a vocabulary for infoboxes, which either has to fit into the way we currently use infoboxes or requires reworking them in some more rigourously logical manner. The next is to provide for converting infoboxes into articles, and handling the translation of article data. This requires a more serious effort at ontology than we have currently adopted, and is what can transition into a semantic wiki. I am not sure this is an undertaking within our present abilities: Library methods can offer only limited help here. DGG (talk) 17:29, 16 March 2013 (UTC)

Note: For ontology questions please see the generic properties "is a" (Property:P31) and "generalized by" (Property:P279). --Kolja21 (talk) 02:45, 17 March 2013 (UTC)

Without separate properties, how could we use different controlled ontologies?

While I think the current usage of this property has significant flaws, I'm not convinced that a 'type (GND)' property or other 'type (ontology identifier)' properties shouldn't exist. Classes like 'Person' in third-party ontologies will likely have a lot of overlap with similar classes in Wikidata like 'person' (Q215627), but they almost certainly won't be equivalent. The third-party class will almost certainly not have all the same properties as the Wikidata class (i.e. instantiable item), and so some instances that are members of one class in the third-party ontology wouldn't be instances of the "same" class in Wikidata. Thus, owl:sameAs, owl:equivalentClass and other equivalence relations don't seem like they could be properly applied.

That said, I agree it would smell bad to support multiple ontologies by having multiple ontology-specific 'type' properties on each item. To my knowledge the issue of how to map ontologies to each other (which is what this problem is about) is an open problem. In "Restricting the World", Denny seems to suggest that a strong "type" property is a bad idea. (FWIW, in that piece he also seems to "strongly disagree" with the current approach of restricting this property to six possible values.)

One option is to use the 'is a' property and the proposed 'generalization' property to fill the role of a 'type' property -- the former defining types for items that represent instances, the latter defining types for items that represent collections or classes. This would support the formation of an uncontrolled Wikidata ontology, and do so with built-in type-token distinction.

What are others' thoughts on how we could -- or whether we even should -- use third-party controlled ontologies, like perhaps the GND, upper ontologies like Cyc, UMBEL and SUMO, and domain-specific ontologies like FOAF, OBO, etc? Emw (talk) 02:42, 12 March 2013 (UTC)

"Classes like 'Person' in third-party ontologies will likely have a lot of overlap with similar classes in Wikidata like 'person' (Q215627), but they almost certainly won't be equivalent" — I'm not sure why that is the case. I'd be interested in knowing why you think that we can't say that Wikidata persons are the same as GND persons and FOAF persons and Schema persons.

If that is the case, then it would seem to me that the idea of using GND is fatally flawed. If the GND type for, say, person has semantics that differ so much from a Wikidata person property, then how can we trust Wikidata users to correctly categorise instances of things as persons without them being experts in the GND? Either the types will match, in which case all we need to do is say that the Wikidata type is "same as" the GND type, or it won't, in which case, a GND-specific type relation won't help solve the problem.

I'm beginning to think that if the only way to support controlled vocabularies is to have special magic type relations, then it would be a sensible idea to not support controlled vocabularies. —Tom Morris (talk) 07:08, 12 March 2013 (UTC)

Fictional character

Should the entity type of fictional character (like Homer Simpson or Gollum) be 'person' or 'creative work'? --Nightwish62 (talk) 19:32, 11 March 2013 (UTC)

I don't know, but it would be more descriptive to add property "is a" -> Character (arts). Regards, Espeso (talk) 19:49, 11 March 2013 (UTC)

It's easy to find out. Just talk a look at Wikidata:Infoboxes task force/persons: Persons (including pseudonyms), families, literary and mythical figures. --Kolja21 (talk) 01:00, 12 March 2013 (UTC)

Ok. However, I think this should stand more closer to the description of the "entity type". Noone should be compelled to search how something is handled. The rules/guidelines should be clearly and obviously. It's not about me or that I'm lazy. It's about there are thousands of others editors which perhaps didn't know this also and handles it wrong. --Nightwish62 (talk) 11:42, 12 March 2013 (UTC)

+1. Unfortunately the whole discussion (see above) is about how we can destruct this property and avoid controlled vocabulary. A clean solution would be to have separate items for the GND main types where we could put the explanation from Wikidata:Infoboxes task force directly into the description field. --Kolja21 (talk) 04:50, 13 March 2013 (UTC)

Yes, one shouldn't have to find a taskforce subpage to know how to apply this property (or any other). Unfortunately we can't display detailed usage notes on the property page. The top section on this talk page is a start, but fuller descriptions of the types are needed. --Avenue (talk) 00:45, 14 March 2013 (UTC)

This property overlaps with 'instance of' (P31)

Looking at the above figures, it strikes me that wherever this property occurs with a value of person, place, organization or event, it would also make sense to apply the instance of (P31) property with the same value. Doing so would allow 'instance of' to start off with a basic classification which could later be refined with more specific classes of person, place, organization or event. As has seemingly been established, this property has only one high level of specificity. Emw (talk) 01:12, 19 March 2013 (UTC)

• A simpler solution would be to deprecate P107 and just use P31. —Tom Morris (talk) 09:15, 19 March 2013 (UTC)

• "It strikes me": Wow, again? And again? You never give up! Let's delete P31, if this property only is meant to cannibalize and is not cooperating with the other properties. --Kolja21 (talk) 16:07, 19 March 2013 (UTC)

• If an item has a value of person, place, organization or event for P107, then would it not be valid to apply the same value on that item for P31? I see one possible use of P107 as giving many items an initial general classification for P31, after which the item's value for P31 could take on a more specific classification. Emw (talk) 03:20, 20 March 2013 (UTC)

• I don't think P31 (instance of) applies everywhere P107 does. For example, most items classified with a GND main type of 'work' are classes, not instances, and thus better suited for classification with subclass of. A discussion about the nature of those two properties is ongoing at is a -> instance of on the P31 talk page. Emw (talk) 03:29, 20 March 2013 (UTC)

• Another supporter of property 107 deprecation here. Espeso (talk) 19:54, 19 March 2013 (UTC)

There are hunderts! At least 160 users with the name "Emw": One new threat every day with the same topic "rename or delete P107", and twice the day the advice: don't use P107, "it would be good to classify them with 'instance of' (Property:P31) 'person' (Q215627)". 19 march, 00:13 h; 19 march, 2:53 h. Please use WD:RFD and stop this kind of endless discussion.--Kolja21 (talk) 20:08, 19 March 2013 (UTC)

@Emw You mix classification property and description property. A classification property implies that all items will have a value and only one value that is not the case with the original mean of the property "instance of". You can have several times the property "instance of" for the same item (for example for ethanol you can use that property with value "alcohol" and "chemical compound". Snipre (talk) 17:49, 22 March 2013 (UTC)

• The distinction you draw between a "classification property" and a "description property" is arbitrary. Saying that something has a cardinality restriction to one instance doesn't change something from being a "description" into being a "classification" in my view. What value is actually provided by such a restriction? Can't see it, personally. —Tom Morris (talk) 21:15, 22 March 2013 (UTC)
• With Tom having taken care of a meaningful reply, I'll ask this: why would one need to classify ethanol as both an instance of (more correctly, subclass of) alcohol and chemical compound? This sort of redundant use of transitive properties seems like it should be avoided. Ethanol is a subclass of alcohol, and alcohol is a subclass of chemical compound; thus ethanol is a subclass of chemical compound. Emw (talk) 03:48, 23 March 2013 (UTC)

A proposal/idea

Hello there,
I'm sorry, but I couldn't read the whole discussion above and so I don't know the actual state of the disc. But I've an idea: The GND doesn't (according to my opinion) cover enough with it's 7 types. I see a problem with "term", because it covers or should cover everything what's not covered by the other 6 types, that causes a problem. Two things which I mean:
"Term" itself means words, words like "table", "computer" (also netbook, laptop, ..), "car", "book" and similar. Those words don't mean an individualized object, they "describe" what something is. But "term" in GND usage also means nearly individualized object, for example the computer "Commodore 64" (C64) (or a book for example). The C64 itself is "nearly individualized", the lowest part of the describing hierarchy: It describes an object (group of exactly the same objects). So a type like "object (not individualized)" would maybe help there.
But also: it doesn't name a individualized object, like "C64 of person Xy", therefore the type "object (individualized)" could be created too.
Benefits: We could/would complete the GND list and describe - of course for data processing - if something is a term (in language usage) or an object (individualized, not individualized). That's not possible now and I think that would be a really good benefit to know what exactly is meant.
The other GND types already (nearly?) seperate between individualized and not individualized: Person (individualized), name (not individualized), organisation (individualized), event (ok.. depends on how it's meant, yearly music event "Xyz" or "Xyz 2012", hmm..), work (individualized? problem here), place (individualized) and term (both at moment).
Just my thoughts about that for now, if a separation would be possible, it would be a good thing. (Thanks for reading and sorry for my bad English).
Best regards, --#Reaper (talk) 15:10, 16 March 2013 (UTC)

Hi Reaper, wir haben ausgiebig (auf Englisch) diskutiert, ob man die GND-Typen ergänzen sollte, kamen aber auf keine Einigung, weil es am Ende auf ein eigenes Klassifizierungssystem hinauslaufen würde. (Abgesehen vielleicht von einem Typ x für alle wikiinternen items, die keinem anderen Typ zuzuordnen sind.) Der Typ s (Sachbegriff) ist natürlich im ersten Moment äußerst unbefriedend, aber wenn du einen Blick auf die Statistik wirfst (de:Vorlage:NORMDATENCOUNT), siehst du, dass er nur 2 Prozent der von Wikipedia verwendeten GNDs ausmacht. Der beiden großen Vorteile der GND-Typen sind: Einfache Anwendung und automatischer Abgleich mit bestehenden Datenbanken. Beides würde mit der Untergliederung verloren gehen. Fröhliches Schaffen --Kolja21 (talk) 02:58, 17 March 2013 (UTC)

Hi Kolja21, danke für deine Antwort. Meine Idee war, dass man schlicht lediglich (bei "Event" müsse man noch schauen) "Sachbegriff" in zwei Unterkategorien (Objekt un/individuell) aufzuteilen, ich denke das wäre noch möglich gewesen und es würde einen großen Mehrwert erzeugen. (Ich glaube bislang ging die Diskussion bzw. das Ziel der neuen Kategorien immer in eine andere Richtung?) Bislang habe ich das Property allerdings so verstanden, dass jedes Item ein GND zugeordnet werden soll. Verglichen mit den gerade einmal ~235.000 Einträgen auf (de)wiki sind die bald 7 Millionen Einträge hier in Wikidata schon was ganz anderes, und momentan dürfte vor allem unter Sachbegriff der allergrößte Teil fallen, da wären die Auswirkungen schon erheblich. (Und dann wird die Statistik ebenfalls ganz anders aussehen.) Anmerkung: eine ähnliche Diskussion hat sich gerade hier (P31) aufgetan. Ich weiß dass ich etwas spät mit der Idee gekommen bin (mir die Idee gekommen ist), hoffe dass sich aber trotzdem noch welche dafür interessieren. Beste Grüße, --#Reaper (talk) 13:10, 17 March 2013 (UTC)

Hier auf der Seite findet sich das Thema in dem Abschnitt "More types". Eventuell wäre das auch ein Job für die Qualifier, die als Ergänzung zu den Eigenschaften gesplant sind. --Kolja21 (talk) 15:35, 17 March 2013 (UTC)

de:Vorlage:NORMDATENCOUNT suggests that de.wikipedia uses real GND entries, while what is proposed here is to use it even when the item has no GND entry, and even for things like "Wikipedia template pages" that are really not what GND is about. That confirms my former point: if we consider GND type to be sufficiently interesting in itself to be imported here, it should be reserved to items with a GND link. If we want to have something more general for all items, we should do things differently, either with P31 or with a new property. --Zolo (talk) 16:04, 19 March 2013 (UTC)

Working with uncontrolled vocabularies like P31 might have some advantages (and might even be the next big thing), but unilaterally use only this way and destroy the traditional ways of working, can't be a good solution. The GND type is used in Wikipedia also for articles without GND, but since Wikidata is still pretty chaotic a lot of Wikipedia editors ignore or boycott it. --Kolja21 (talk) 16:21, 19 March 2013 (UTC)

• I agree that "object" is one of the keypoint additions to this property. If the community stays at present 6 values and will insist on using no other, I prefer also boycott this property and use something more convenient. Infovarius (talk) 12:56, 20 March 2013 (UTC)

Geography of other planets

Shall, for example, locations on Mars, like Cydonia Mensae, be considered a geographical feature? Can I classified it with this property or not? Thanks! - Sarilho1 (talk) 22:56, 19 March 2013 (UTC)

Same kind of question here. --Gloumouth1 (talk) 15:38, 21 March 2013 (UTC)

Thanks! But it is a bit different. - Sarilho1 (talk) 15:43, 21 March 2013 (UTC)

Templates and categories

Since we have a "disambiguation page" type, surely templates and categories deserve their own non-standard type? Marking them as "term" seems wrong to me. --Magnus Manske (talk) 14:37, 20 March 2013 (UTC)

I think the Property "instance of" would be better for this. We should limit P107 only for GND typs as they are defined by the german national library (http://www.dnb.de/DE/Standardisierung/GND/gnd_node.html). If we allow other uses what is the differences to Property:P31? --Sk!d (talk) 14:46, 20 March 2013 (UTC)

I am looking for a way to mark the linked pages, rather than the subject of the linked pages. "Category:Stuff" is not an instance of Stuff, and neither is it an instance of a category; the linked page itself is an instance of the category, though. Similar to "List of...", which I should have included with templates and categories. --Magnus Manske (talk) 14:59, 20 March 2013 (UTC)

No I mean it should look like Q1410641 so the Property:P31 has the value Q224414 (Category) --Sk!d (talk) 15:16, 20 March 2013 (UTC)

This isn't the right place for the question. "disambiguation" only exists as a type here because there's a GND type in similarity to it (which, its use here is questioned above). People using non-GND values for this parameter need to be trouted, as there isn't consensus for expansion of its use in that way. :) --Izno (talk) 15:38, 20 March 2013 (UTC)

I know what you mean. I say this feels wrong. The page is not about an instance of a category, it is a category. The P31 example says "<Fido (a specific dog)> instance of <dog>", because the Fido page is about a dog; it is not a dog itself. This is why I don't think P31 is appropriate here. P107 has the precedence of "disambiguation page", which we could expand without spoiling "instance of". --Magnus Manske (talk) 15:40, 20 March 2013 (UTC)

(sorry, edit conflict) Maybe the answer is to create a new property "page type"? --Magnus Manske (talk) 15:44, 20 March 2013 (UTC)

I see your point. But we should not use GND i think the use for disambiguation page is wrong too. We should develop an own Unique Categorization Index which has all wikidata items in it which fulfil wd:N and has (should have) exactly one Value e.g. Category, Template, Source, Person, Astronomical Object, Animal, State, Disambuigation Page ... . We should then have discussions about which other possible values should be enabled like on this page. GND and this other Property could overlap but the Wikidat own index should only be extended. We should only use GND where it is intend to do so (no on every item). And we should use the own index for every item. --Sk!d (talk) 15:57, 20 March 2013 (UTC)

I come to the same opinion at the end of the talkpage! I want to create a classification (or at least intuitive separation into types) for every item and initially I thought that P107 is about it. But now I see that this is particular German-library index which is of no general use. Let's rename it into "GND", make it not general and leave Kolya21 with it. And the dreamers about global classification for Wikidata let's choose some property "page type" and make our efforts there! --Infovarius (talk) 20:55, 21 March 2013 (UTC)

Proposal regarding P107 and P31

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

Individual animal - term or person

What kind of property should articles about an specific animal, an individual, like Dolly or Dürer's Rhinoceros use? I don't think that we can use term, being person the best. However, saying that the type of item of Dolly is person is also a bit strange, so I don't know what should I use and if person should be rename to individual or something like that. - Sarilho1 (talk) 14:45, 26 March 2013 (UTC)

It would be best to simply not apply this property to named non-human animals. Sheep are not persons, even if they're notable. To the best of my knowledge the GND doesn't even use the "person" main type this way. The idea that notable sheep, dogs and gorillas should be classified as persons is a peculiar adaptation unique to this one property on Wikidata. Consider using more reasonable statements like 'instance of sheep' and 'instance of clone'. Emw (talk) 00:03, 27 March 2013 (UTC)

I normally don't use property "instance of" because it is in discussing and I don't agree with the property, but I will see what I can do. - Sarilho1 (talk) 12:24, 27 March 2013 (UTC)

New proposal: Make it a string type and extend it to non-primary types

Yet another proposal, I would love it if we could reach consensus and move on.

Given that:

• GND type do not always correspond to intuitive classification, and for that reason is more useful for machines than for direct human reading, where P31 is much more suitable.
• The current property would logically requires special tailor-made items. That is an unwieldy ad hoc adjustment to notability guidelines.
• For a machine, it is much easier to play with a 3-char string than with a Wikidata item.
• Primary GND type can very easily be inferred from secondary types, and secondary types from tertiary types.

I propose to

• replace this property with a string property
• allow any GND type in the new property (most precise recommended).

I do not see any downside to it. Even documentation woud be easier as we could use MediaWiki:Gadget-AuthorityControl.js to link the string to a good documentation page.--Zolo (talk) 06:35, 28 March 2013 (UTC)

I restated that on Wikidata:RFD, so that is clearer and more visible. --Zolo (talk) 16:41, 28 March 2013 (UTC)

Botcontrolling

I just wanted to inform everybody that my bot is currently scanning all Items which have a P107. It will fix some common false values like linking to Q690940 instead of Q215627. If my bot spot any conflict which is not fixed automatically it reports the conflict to User:Sk!dbot/conflict so that the item can be fixed manually. --Sk!d (talk) 17:29, 31 March 2013 (UTC)

Thanx. Great job! --Kolja21 (talk) 04:25, 1 April 2013 (UTC)

The list also helps to prevent vandalism. --Kolja21 (talk) 13:01, 1 April 2013 (UTC)

Bad job (the data is being erased). Better stop doing that until you manage to copy information into other properties (simply P31, e.g.). Infovarius (talk) 19:17, 1 April 2013 (UTC)

Editors taking time correcting your errors and you are telling them "bad job"? --Kolja21 (talk) 01:28, 2 April 2013 (UTC)

You suppose that this property is useful. I suppose that my values was useful. Infovarius (talk) 12:03, 9 April 2013 (UTC)

Well of course a value like "10" is usefull. But if the question was: What is 30-21? The answer "10" is wrong. BTW: You have a button "view history". So next time you make errors, please correct them by yourself and don't bug people who clean up your mess. --Kolja21 (talk) 20:56, 9 April 2013 (UTC)

unknown value and no value

Should Items have this Property with no value or unknown value? E.g. Q329540 (a ship) should this item have the GND Property with no value (afaik there is no correct value for this item) or shoud I just nut use this property for this item? I would prefer not to use this property for this item what do you think? --Sk!d (talk) 23:53, 31 March 2013 (UTC)

I don't see any advantage of a property without value as well. BTW: Q329540 is like the SMS Emden (Q659864) type s ("transport with individual names"). --Kolja21 (talk) 04:33, 1 April 2013 (UTC)

"no values" tells us that a property does not apply to an item, while no property can mean that nobody bothered to check. The ability to make this difference was made a software core feature. As explained elsewhere, I do not think that the current P107 makes tremendous sense, but I think this kind of property can only be justified if it can be used in all items. If there are items where it cannot be applied, I would say we should use "novalue", but that it reveals some flaw in the property's design. --Zolo (talk) 06:54, 1 April 2013 (UTC)

I've set GND type sometimes to "unknown value" because I think there has to be this value, but I haven't know which one. For example the forename "My" Q956487 (GND has been removed). If it's set to "unknown" we could generate a list via query, which e.g. could be checked by a task force who knows good to handle with GND.

(Btw @Zolo: GND type has it's permission to be used, it's part of the GND norm data and is needed for it. The conflict about this property was only a misunderstanding because of the former wide-range name "type of object" (or so).) Greets, --#Reaper (talk) 12:53, 1 April 2013 (UTC)

Sorry, I deleted it, because I thought it was an error. Imho the job you describe (and the proposal of Zolo) could be better done by adding a "tpye x" (all non-articles), then we know what is left. (BTW: I like the side effect to produce statistics like de:Vorlage:NORMDATENCOUNT.) --Kolja21 (talk) 13:15, 1 April 2013 (UTC)

Hm ok on my next gnd bot check i will accept the value "no value" but list all "unknown values" so other can help to fix it. If we use "type x" in exactly the same way as "no value" why should we create it? Its not needed and "typ x" is not a correct GND value. Btw I thinkt the correct value for Q956487 should be name (disambiguation) (Q4167410), becaus it is name which is not individualized. I am very unhappy to use Q4167410 for this value as it does not have to be a real "wikipedia disambiguation" as the correct translation of "individualisiert" is individualized. This just means there could be severel "things" called like this. --Sk!d (talk) 23:39, 1 April 2013 (UTC)

1. (type x): If you look at the list of main tpyes there are only one kind of items (all non-articles) that have no type. If we would use tpye x for Wikipedia categories etc. all items without P107 would be "unknown value". (Imho this would be a better solution than using "unknown value" itself because it's irritating for other readers.) 2. The article about the female name "My" is not a disambiguation page, it's about the etymology of the name. (It's an article about language and social history.) Of course these kind of articles are in a lot of cases used for disambiguation lists, but if the description says "female name" it's type s (term). We can leave the type in these cases away, but if we use it, it should match with the description. --Kolja21 (talk) 01:53, 2 April 2013 (UTC)

If there is no type it should not be "unknown value", it should be "no value". That may be irritating, because special values are not (yet?) displayed in a really nice way, but that is really not the same thing as leaving the property blank. I do not think it makes sense to create new types and keep calling it "GND main type", nor create property-specific items when they are equivalent to something that already exists. --Zolo (talk) 15:40, 2 April 2013 (UTC)

Indeed "unknown value" (Who is not knowing the value: the editor, the DNB database, Wikipedia?) and "no value" (What kind of items should that be?) are irritating and we shouldn't start with this kind of mess. --Kolja21 (talk) 19:20, 2 April 2013 (UTC)

"Unknown value" means "unknown according to the source" (I dont think it makes sense to use it when we do not provide a source). "No value" means that the property does not apply for the item. They sound really useful to me, and I believe that development team had good reasons for developing them, though they should probably have been more careful about the layout --Zolo (talk) 19:42, 2 April 2013 (UTC)

We maybe should rename Q4167410. "Wikipedia:Disambiguation" sounds really strange, and a name (forename, familyname) page would always be a disambiguation page, but.. not necessarily the other way around. Question: Would for example a company name also be a "name" within the meaning of GND, or not? --#Reaper (talk) 19:23, 2 April 2013 (UTC)

"Name" in GND stands for disambiguation, but a Wikipedia article about a name doesn't have to be ambiguous. 1.) "Miller": list of persons with that name (disambiguation). 2.) "Miller": the etymology of that name, social, language etc. history (article). BTW: I'm still convinced that separate items would be the best solution. --Kolja21 (talk) 19:37, 2 April 2013 (UTC)

I agree that special items would be the best solution (well, the second best behind getting rid of this property;). --Zolo (talk) 19:42, 2 April 2013 (UTC)

I think special items, like for Property:P21 would be great. My bot could change all existing values. --Sk!d (talk) 14:15, 4 April 2013 (UTC)

As long as there are no special items what would be the correct value for Q1769191? --Sk!d (talk) 21:39, 10 April 2013 (UTC)

If there is no objection I will create extra items for all "name (disambiguation)" GND types. As the current Item has a false name and interwikilinks not all Items marked with this values have to be wikipedia-disambiguations. --Sk!d (talk) 10:58, 14 April 2013 (UTC)

+1, but we have to change first WD:N, please see Wikidata talk:Notability#Main types (GND). --Kolja21 (talk) 14:23, 14 April 2013 (UTC)

I dont think we have to change it. I would say the sentence: "It fulfils some structural need, i.e. it is needed to make statements made in other items more useful." allows this extra item. --Sk!d (talk) 18:10, 15 April 2013 (UTC)

Examples

A number of bots are mistagging items because there's still quite of ambiguity and confusion about what each type is supposed to contain. Currently it's almost impossible to clear that confusion because there's no convenient list of examples available. So here are a few common questions. Let's answer them once and for all and place that list somewhere that's easy to find. I've left some questions marks which I hope we can resolve. Feel free to add more entries (that's the whole point).

item	GND main type	example	example-link
single person	type p (person)	Emil Ermatinger	http://d-nb.info/gnd/118682334
(collective) pseudonym	type p (person)	Nicci French	http://d-nb.info/gnd/124352634
fictional character	type p (person)	Sherlock Holmes	http://d-nb.info/gnd/118816322
family	type p (person)	Medici	http://d-nb.info/gnd/118732455
siblings (as part of family)	type p (person)	Brothers Grimm	GND Jacob Grimm = person GND Wilhelm Grimm = person GND "Grimm, Brüder" = disambiguation (don't use) GND "Gebrüder Grimm" = disambiguation (don't use)
exception: siblings (music, entertainment)	type k ("organisation")	Kessler Twins	http://d-nb.info/gnd/10276965-5
exception: individual animal	type s ("term")	Dolly	http://d-nb.info/gnd/7576882-3
university	type k (organisation)	University of Tübingen	http://d-nb.info/gnd/36187-2
music group	type k (organisation)	The Beatles	http://d-nb.info/gnd/4005093-2
sport event	type v (event)	Olympic Games	http://d-nb.info/gnd/2021059-0
novel	type w (work)	El Señor Presidente	http://d-nb.info/gnd/4336802-5
TV series	type w (work)	Sherlock Holmes	http://d-nb.info/gnd/4719693-2
newspaper	type w (work)	Frankfurter Allgemeine Zeitung	http://d-nb.info/gnd/4155156-4
magazine	type w (work)	The Economist	http://d-nb.info/gnd/4184996-6/
electronic publication	type w (work)	Wikipedia	http://d-nb.info/gnd/7545251-0
exception: video games and other software	type s ("term", type siw)	Half-Life	http://d-nb.info/gnd/4580384-5
term	type s (term)	University	http://d-nb.info/gnd/4061778-6
groups of people that are not literally organized	type s (term)	Russians	http://d-nb.info/gnd/4051034-7
natural event (earthquake, eclipse and so on)	type s (term)	Hurricane Katrina	http://d-nb.info/gnd/7515869-3
historic event (war)	type s (term)	World War II	http://d-nb.info/gnd/4079167-1
biology, chemistry	type s ("term", type snz)	Arsenic	http://d-nb.info/gnd/4003041-6
constellation	type s (term)	Aquarius	http://d-nb.info/gnd/4131727-0
city, town	type g (geographical feature)	Tübingen	http://d-nb.info/gnd/4061147-4
planet	type g (geographical feature)	Jupiter	http://d-nb.info/gnd/4162926-7
building or monument	type g (geographical feature)	Eiffel Tower	http://d-nb.info/gnd/4102872-7
name	name (disambiguation)	Robert Newton	--
all non-articles	novalue	Category:Jupiter	--

I should note that the script "wikidata useful" considers fictional characters as "works" (which I find more intuitive) but earlier discussion above seemed to recommend "person" (although the justification seemed rather dubious). At least one bot has massively categorized music bands as "persons". Pichpich (talk) 16:48, 16 April 2013 (UTC)

• I changed the example and linked to to gnd for proof. --Sk!d (talk) 17:09, 16 April 2013 (UTC)

Excellent, thanks. Pichpich (talk) 17:29, 16 April 2013 (UTC)

• The problems with GND main type 'person' and animal='term' have been known (and unresolved) for a while, but I wasn't aware of those other basic classification problems with GND main types, e.g. calling the event 'Hurricane Katrina' a term even though 'event' is a GND main type. These problems do not exist with the more generic membership properties instance of (P31) and subclass of (P279). Emw (talk) 02:49, 17 April 2013 (UTC)

The problem with "event" is well known and due, at least for English users, to an imprecise translation from German. (And I'd like to take the opportunity to once more lament the choice of a one-word imprecise translation over a four-word precise translation) Pichpich (talk) 03:59, 17 April 2013 (UTC)

On a different note: as long as P107 is called "main type", people will feel the need to add it to every item. Adverts for P31 and P279 will not resolve that problem. Pichpich (talk) 04:01, 17 April 2013 (UTC)

I suppose that P107 descriptions should clarify that very sound. By the way, support the real main type property. Infovarius (talk) 16:51, 17 April 2013 (UTC)

• Pichpich, the precise nature (and name) of P107 have been debated for over two months. If you want to change the nature (i.e. definition) of this property, please vote at Property_talk:P107#Vote_for_the_nature_of_this_property. As it stands, the nature of this property is that it's based on the "main types" (also known as the "high level entities") of the GND ontology.

The problem with P107 is not in its name or usage, it's in that definition. Attempts to fix that definition and thus the major flaws it entails (like the misclassification issues above) have not gained consensus. Given that, since P31 and P279 solve those problems, I don't see what's wrong with suggesting those properties as alternatives to this property. Emw (talk) 00:50, 18 April 2013 (UTC)

The discussion you refer to has been stale for a month. I didn't write the table above to support or dispute the current nature of this property. I'm just being pragmatic: as long as this property is called "main type (GND)", it makes no sense to use values that don't match GND. Pichpich (talk) 12:24, 18 April 2013 (UTC)

I agree! Emw (talk) 21:56, 20 April 2013 (UTC)

• Just curious (I won't use this property any more): what the difference between "pair of famous siblings" and "siblings"? :) --Infovarius (talk) 16:51, 17 April 2013 (UTC)

  The problem is that while "normal" siblings are clearly "organisation". I am not sure with the "Brothers Grimm" I dont think the dnb link is the correct one. There are values for each person. I would delete this from example. I think we should use "organisation" too as this is the most plausible value. --Sk!d (talk) 18:10, 17 April 2013 (UTC)

The Kessler Twins are not "normal" siblings, they are part of "Systematik: Musik" and are treated like the Jackson 5. That's why they are type k (Körperschaft, Organisation, incl. music groups). I'll check the other examples. --Kolja21 (talk) 15:10, 25 May 2013 (UTC)

 Done The list is now complete. --Kolja21 (talk) 21:53, 25 May 2013 (UTC)

I changed all nonarticles to "no value" there is GND type for these Items. So "no value" is correct. --Sk!d (talk) 23:17, 25 May 2013 (UTC)

Please wait for RFD. Imho "no value" is more difficult to handle and to explain. --Kolja21 (talk) 00:52, 26 May 2013 (UTC)

Q11651459

I have created the new item Q11651459. It should be used for GND-Type n. This should solve all problems with the disambiguation dilemma. I will wait a few days until my bot will change all old values to this new value. --Sk!d (talk) 21:48, 20 April 2013 (UTC)

Comment: I think you should simply rename the old item and move the wikilinks to the new item, that would be easier / wouldn't be made it necessary to change hundred thousand items. (I know that this wouldn't be the correct way, but it also wouldn't stress users watchlists. ;) ) --#Reaper (talk) 22:09, 20 April 2013 (UTC)

Hm in this case this could be better. I only see a problem in other Properties linking to the old page. We would have to find them and fix them. --Sk!d (talk) 01:04, 21 April 2013 (UTC)

This page http://54.214.12.43:8085/api?q=claim[107:4167410] says there are bout 360k gnd links to the old property I think we can change all links. Maybe I bevor doing it I will count all links to the page Q4167410. --Sk!d (talk) 07:30, 23 April 2013 (UTC)

Because of your first response: Wouldn't be this the same problem the other way around? (Sry, but I'm not aware about the problem why there has to be a new item.) --#Reaper (talk) 17:42, 23 April 2013 (UTC)

As the new Page isn't that old and the use is clear there shouldn't be that many false entries. The reasons why we should use a extra page got discussed at #unknown_value_and_no_value. --Sk!d (talk) 00:04, 24 April 2013 (UTC)

Isn't there an easier way to solve this than to edit 360,000 items? --  Docu  at 07:58, 25 April 2013 (UTC)

The only alternate solution would probably be to change the descriptions for Q4167410 and move the existing ones to a new item. While I generally oppose this solution, given the 360k links the unlikely case that there are actual links to Q4167410 that relate to its description, I'd do this here. --  Docu  at 10:38, 27 April 2013 (UTC)

We should not only change the descriptions but also change the Labels. This has to be done for every language. I would prefer to change the items to be sure that there are no other conflicts. --Sk!d (talk) 11:02, 27 April 2013 (UTC)

Titles can be imported with the gadgets. Descriptions are somewhat limited anyways.

Odd, it seems that it's easier to do the 360k of edits .. seems that Wikidata lacks the "edit" button. --  Docu  at 11:20, 27 April 2013 (UTC)

Should we ask some other peoples on the Project Chat or should we just change the item? --Sk!d (talk) 20:56, 29 April 2013 (UTC)

Please go ahead with the solution that you prefer. Either would eventually lead to the same result. The current situation isn't satisfactory though. --  Docu  at 07:51, 4 May 2013 (UTC)

My bot will change the items to Q11651459 on the next run. --Sk!d (talk) 14:12, 9 May 2013 (UTC)

It's all done. Thanks. Three can remain. --  Docu  at 17:28, 14 May 2013 (UTC)

My bot runs this task every night so false entries should be corrected then.--Sk!d (talk) 22:25, 14 May 2013 (UTC)

Would you change the occurrences in wikidata_useful.js? Auto-edits by users with that tool keep re-adding it. --  Docu  at 05:04, 15 May 2013 (UTC)

I think changing "'p107:q4167410'" in the first part of the code would fix it. But you have to be sysop or "Magnus Manske" to do it. -- Lavallen (block) 05:53, 15 May 2013 (UTC)

Sk!d should be able to do it. --  Docu  at 05:59, 15 May 2013 (UTC)

 Done [5] --#Reaper (talk) 19:27, 15 May 2013 (UTC)

Good job. I've updated Help:Statements (and some minor pages that were left). On the long-run we should create separate items for the other entities as well. (Especially type s, called "term" is confusing.) --Kolja21 (talk) 12:34, 18 May 2013 (UTC)

If this is consent, we should start as soon as possible. There will be only more items to change. --Sk!d (talk) 14:06, 18 May 2013 (UTC)

Can we start with type p "person"? It would help if the order type p, k, v, w, s, and g is kept, even if it's not mandatory. --Kolja21 (talk) 02:41, 19 May 2013 (UTC)

PS: No objections since March 2013 (talk page WD:N). It's the same case as Q11651459 (GND, type n). --Kolja21 (talk) 23:01, 20 May 2013 (UTC)

If someone creates new Item which should be used. Please contact me on my talk page to make sure I change my bot. --Sk!d (talk) 21:42, 24 May 2013 (UTC)

Multiple main types?

Is it possible for an item to have multiple main types? I'm thinking of churches which are usually conceived of as buildings (places) and organizations, often by the same people at the same time. The same can be said for some other organizations. Also, I suppose an event can also be a creative work? --Jfhutson (talk) 15:14, 4 May 2013 (UTC)

One church can be place, another can be organization, the third will be a term. This depends on german librarians. Look for specific item in GND and be happy (or use another property). --Infovarius (talk) 19:07, 6 May 2013 (UTC)

OK, so this is only supposed to be applied to items found in the GND? It looks like it's being used for everything. --Jfhutson (talk) 19:37, 6 May 2013 (UTC)

No, not really. The item should be used if possible. Your problem is a really good question, the problem is, that GND is (afaik) only for one special "thing". But an article about a church would (nearly always) about the building itself and the organization of the church at the same time. But.. I think you should choose "place" if that is the main aspect/part of the article, or the other way around "organization". --#Reaper (talk) 21:14, 6 May 2013 (UTC)

Pardon, there is no reason to use the property wherever possible. This is not "main type", this is "main type of GND classification". One shouldn't imagine the value if it is not in GND. Infovarius (talk) 20:08, 7 May 2013 (UTC)

Until we have no main type property we should use GND instead. That would be better than nothing and would help later (it would fit for many items). (If there would ever be a "wikidata main type", but that wouldn't be easy, sadly.) Btw: If a item is in GND would be checked using the GND-ID. --#Reaper (talk) 21:16, 7 May 2013 (UTC)

There's a proposal to add a generic Wikidata 'main type' property that's independent of the GND: see the main type proposal. Emw (talk) 02:17, 8 May 2013 (UTC)

OK, thanks. I suppose the ideal would be to have two items for things like this, and to be able to link both to the WP article, but I will take your advice for now. --Jfhutson (talk) 21:31, 6 May 2013 (UTC)

In Q10498786 I have by now added both place and organisation. The problem is that this item is related to an article who is about a specific organisation in Swedish Lutheran Church. And since it is that church who has historically taken care of the Censuses in Sweden, these organisations are at the same time the smallest part in the Swedish Census-division. This will change in the future, but we are not there yet. -- Lavallen (block) 08:28, 9 May 2013 (UTC)

P:P107=Q215627 (person) based on categories in be/ja/ru/zh Wikipedia

Are there categories at these Wikipedias we could use with "array properties gadget" to add P:P107=Q215627 to items? Sometimes items with articles only in these languages don't have this property. I found ru:Category:Персоналии по алфавиту be:Category:Асобы.

See also: Property talk:P21#Gender data from be/ja/ru/zh Wikipedia. --  Docu  at 20:24, 19 May 2013 (UTC)

The Japanese Wikipedia has a ja:Category:人物 (people), but we need to exclude subcats like "templates of ...". A good start would be ja:Category:存命人物 (people alive). --Kolja21 (talk) 03:12, 20 May 2013 (UTC)

Thanks! I added ja:Category:存命人物 to User_talk:Legobot/properties.js/requests

The bot skips anything that is not in article namespace. So we are safe from templates.

Recursion through subcategories is a tricky thing. Personally, I avoid doing it more than 1 or 2 levels down as eventually every Wikipedia category tree ends at Q1.

Another way it can be done would be to add all articles that use a given template (e.g. for people stubs or infoboxes). --  Docu  at 16:36, 20 May 2013 (UTC)

new value

I made Q13411539 for "wikipedia"namespace. Before using made disscussion for using this value. How you guys think?--DangSunM (talk) 20:06, 1 June 2013 (UTC)

Please see Wikidata:RFD#Q13384863. --Izno (talk) 20:32, 1 June 2013 (UTC)

GND type of stars

"Sun (Q525) <P107 (P107)> geographical feature (Q618123)" is very strange statement because geographical feature (Q618123) and linked wiki-pages are about geographical features. Where is mistake? — Ivan A. Krestinin (talk) 16:17, 3 June 2013 (UTC)

That is not a mistake, and it is only one of the reasons GND main type should be deleted. --Izno (talk) 17:08, 3 June 2013 (UTC)

Radical way :-). Maybe "place, geographical feature" in terms of GND is not equals to geographical feature (Q618123)? Maybe we need to use some another item as value of GND-type property. Something like "place, geographical feature in terms of GND". — Ivan A. Krestinin (talk) 17:24, 3 June 2013 (UTC)

It seems to me that in that case you have defeated the entire purpose of using the type within our schema.... :) --Izno (talk) 19:18, 3 June 2013 (UTC)

GND-type is not usual type. GND classes are very synthetic as I see. instance of (P31) is more similar to "type". — Ivan A. Krestinin (talk) 19:38, 3 June 2013 (UTC)

Please see #Examples. Of cause it would be better to have separate items for the Wikidata main types. The one we use right now are a compromise. (BTW: The GND type for "sun" is gix = Extraterrestrika.) --Kolja21 (talk) 21:13, 3 June 2013 (UTC)

That it fails to be able to classify astronomical objects sanely seems to be yet another compelling reason to completely ignore this property as an extravagant waste of time and intellect. It's one thing to not be able to classify obscure types of beetle. It's another to not be able to denote the difference between a planet and a star. Fail. Delete and do something sane instead. —Tom Morris (talk) 17:37, 1 July 2013 (UTC)

I see this discussion for case. My two cents:

1. astronomical object and GND was already discussed here;
2. the right place to discuss of astronomical objects is the Wikidata:WikiProject Astronomy, please ;-) ;
3. also for me GND is a strange property, but I prefer to discuss about it in only one place. I would like to read your ideas concerning P107 there ;-) .

--Paperoastro (talk) 20:44, 3 July 2013 (UTC)

These objects are "geographical" because they can have poles, meridians, aequators, mountains, valleys, craters, coordinates, revolutions, orbits and so on like geographical objects on earth. In addition for astronomical objects the Property:P60 is needed, which can link to other items and mark it as "planet" "galaxy" "asteroid" or whatever you need.--Giftzwerg 88 (talk) 15:14, 18 August 2013 (UTC)

Are accidents events (type v)?

Events are more or less planned. Type v does not apply to natural desasters as earthquakes, storms, ther type s applies. But does it apply to man made desasters as shipwrecks, car accidents, plane crushes, atomic explosion? I found wars like WWII to be classified as events. --Giftzwerg 88 (talk) 15:03, 18 August 2013 (UTC)

Event is an incomplete translation of Veranstaltung. It should be Organized event, in my humble opinion. Bever (talk) 21:04, 21 September 2013 (UTC)

Leave us Normdaten (authority control) editors alone, please

If you all want to create some sort of main type, please go forward, but do it in another, new property, and please don't delete this property (which we will need in the long term for integration of Wikidata in de.wikipedia), but find yourself another playground. It is impertinent to first capture this well-defined and useful property, and then wanting to delete it because, of course, after that it became more and more useless. That said, of course everything not within the boundaries of GND types (disambig pages, categories etc.) must be deleted from this poperty. --FA2010 (talk) 11:48, 20 August 2013 (UTC)

I think it would be beneficial for everybody if you explained exactly what is happening on dewiki and how Normdatei are beeing used. Speaking for myself the problem is not that dewiki uses GND normdatei, it's that it seemed to be a start base classification for the whole project, although it is ill suited, and that policies and guidelines included recommandations to put a GND main type on each items, which is very confusing for newbies. Can you guys start a RfC to clarify the relationships between project specific classification and Wikidata as a whole ? It would be beneficial for the whole project if we could work together and benefit from each other work without a feeling that some people are playing their own game. That's why I don't understand why GND main type is essential for long term integration for dewiki as it's as ill suited for the task than for any other Wikipedia. TomT0m (talk) 13:00, 20 August 2013 (UTC)

We want the GND type shown in our "Normdaten" template, along with each GND entry. If we want to have thata data from Wikidata one day far away from now (if not: what is the point of Wikidata anyway then?), we need the type stored there. It's as easy as that. --FA2010 (talk) 13:49, 20 August 2013 (UTC)

I have no real opposition about that at least as it really keeps exactly that and no more. I'm curious though, why ? There must be something I ignore because I really do not understand : It's incomplete information, why just the main type and not the full type, and why not just the GND identifier which should be enough to find easily the type by checking the database, I really don't understand why this information is important to you guys by itself. TomT0m (talk) 14:07, 20 August 2013 (UTC)

Full-protected

The revert warring going on here is getting very disruptive. The consensus at the RfC was to delete the property, and since people don't seem to understand that, I have full-protected the property. TCN7JM 15:58, 20 August 2013 (UTC)

Description text has been changed in English and German but there are lots of other languages where it has not been changed yet and full protection makes it dificult to do those changes.

I checked the history. There was one revert from "***Do not use***" which was then reverted back. For me I don't think that rises to "disruptive". Can we take protection off? Filceolaire (talk) 00:23, 21 August 2013 (UTC)

The disruptive history of the property goes back to August 17th with the reverts. Anyway, I guess your first point is enough reason to undo full protection for now. Take note, though: Replacing the "***Do not use***" content with the property's original description claiming no consensus to delete is incorrect and will be considered disruptive from this point on. TCN7JM 00:29, 21 August 2013 (UTC)

@TCM - AFAIK the RfC you have referred to does not exsit. Can you provide a link? Allen4names (talk) 06:47, 22 August 2013 (UTC)

See Wikidata:Requests_for_comment/Primary_sorting_property and summary in Wikidata:Requests_for_comment (Outcome: The property is to be deleted) Michiel1972 (talk) 08:46, 22 August 2013 (UTC)

Replacements?

So if this is going to be deleted (why can't we just rename it "GND type" and leave it?), will the information be destroyed, or transferred to another property? I read something about "instance of" for people, but is there a proper mapping somewhere? Some of my tools are using this property, and one is actually generating it, so a mapping would be most helpful to have. --Magnus Manske (talk) 13:40, 22 August 2013 (UTC)

See Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type (and other RfCs are related to typing, see wd:rfc which is as far as I understand the place to be for those kind of discussions ;). TomT0m (talk) 13:47, 22 August 2013 (UTC)

Magnus: Your comments would be appreciated at the RFC, above. Maybe you have some suggestions related to the statements already made there.

To answer the actual question, yes, the information will (ideally) be preserved, and will in all cases be traceable via queries of the two subclass of (P279) and instance of (P31). In some cases, we're going to need to work on doing so; others will be plain switches of some sort based on categorization or otherwise. Creating the mapping is part of the RFC. --Izno (talk) 16:15, 22 August 2013 (UTC)

Half oc.Wikipedia is based on GND main type. It's easy to use and a basic property. I don't think deleting it will make P31 and P279 more popular. --Martssnail (talk) 19:47, 29 August 2013 (UTC)

If this is true maybe you should start another RFC as nobody brought up this point on the last RFC where the deletion was the result. --Sk!d (talk) 23:00, 29 August 2013 (UTC)

Aside from the vague and questionable claim that "Half (of) Wikipedia is based on GND main type", Martssnail's points are the default arguments for P107 and were robustly argued against at the Primary sorting property RFC. They have also been extensively rebutted on this page. I recommend reading through the arguments on the linked RFC and this talk page before starting yet another P107 RFC. Emw (talk) 14:20, 31 August 2013 (UTC)

Bot work

Bots have been busy deleting this property from a lot of items lately. As a side effect, other bots are now happily adding coordinate location (P625) to a lot of items that are not geographical features. Mostly organizations but also things like aircraft types. Before this property was removed en masse it was an important constraint for bots adding coordinates. This is a most unfortunate development. What can be done to prevent this? /Esquilo (talk) 17:03, 3 December 2013 (UTC)

You can add {{Constraint:Type|class=Q2221906|relation=instance}} that would be equivalent to the former p107 constraint, but actually this property seems to make sense for many items that are not places (for instance, battles, and, arguably, companies), so we seem to need something a bit more elaborate. --Zolo (talk)

For battles indeed, but for companies coordinates should rather be a qualifier for headquarters location (P159). It is edits like [6] and [7] that I want to prevent. How/Where do I add this Constraint:Type thing? /Esquilo (talk) 17:39, 3 December 2013 (UTC)

Constraints should be added to property talk:P625, but I do not know what it should be. I cannot think of anything that would accept battles, and individual aircrafts like those in en:Category:Individual aircraft, but not aircraft types like F-105. ‎Maybe you can ask user:Ivan A. Krestinin who do the reports. One thing that may work is "should not have subclass of (P279)", as is it seems that items that can be subclasses of something cannot have a location. --Zolo (talk) 17:55, 3 December 2013 (UTC)

"does not have subclass" claim and "does have instance" claim (our constraints can do booleans, right?) would probably work. --Izno (talk) 18:59, 3 December 2013 (UTC)

On an aside, the above F-105 item should be a subclass, not an instance of, attack aircraft. That is why you couldn't think of the correct way to fix the problem, Zolo. :) --Izno (talk) 19:03, 3 December 2013 (UTC)

1. If itemss are being identified as having a particular location, that seems to me a problem of the source data and not particularly the fact that the bots are adding those claims to those pages.
2. I cannot personally believe that bots ever obeyed the constraints as listed on talk pages. Those bot operators need to be communicated with regarding the fact that their code is no longer in keeping, either way. Attempting to solve the problem via constraint system doesn't actually solve the problem.
3. In accord with #2, those bot operators also need to be informed that when adding claims, they should also be adding a source (of some sort!). It is hard to track down the source of errors in data otherwise...

--Izno (talk) 18:59, 3 December 2013 (UTC)

Use in Wikipedia

Hello, Kolja21 said above that the Occitan Wikipedia is in trouble because of the removal of this property. He gave the Occitan article on the architect oc:Alvar_Aalto as an example. This stub (it consists completely of two templates) has almost no content any-more since the removal of P107. To investigate this, I reinstated this property for Alvar Aalto (Q82840). However, it seems to me that there is no difference.

The article says 'Alvar Aalto es un òme', so some way the server knows that he is a man (not a woman or a thing or term), but I think this text was already there before I reinstated the P107 property. And although country of citizenship (P27) is used in the Wikidata item, the nationality is not shown on the Occitan page. Neither are the place of birth and death, although the properties place of birth (P19) and place of death (P20) are also in use. The full text is 'Alvar Aalto es un òme,,, (n. a, m. a), país de nacionalitat:'. So it seems the template is broken.

By the way it is interesting that the Occitan people tried to make a great many stub articles by using Wikidata. A solution for languages with few editors... Bever (talk) 19:31, 6 January 2014 (UTC)

AFAIK oc:Utilizaire:Boulaur made most of this edits but stopped working (out of frustration?) for Wikipedia. Since the infobox was based on P107 it has been moved to oc:Modèl:Infoboxdecorregir. --Kolja21 (talk) 23:58, 6 January 2014 (UTC)

• The problems seen on Occitan Wikipedia caused by the P107 migration call for a better mechanism to announce a property's deprecation to clients. On August 17, the description of P107 was changed to announce the property would be deleted (diff), per the Primary sorting property RFC. On October 5, I posted on the Infobox talk page in oc-WP and announced that P107 would be deleted, and asked that the infobox be updated (see here). Large-scale migration of P107 claims began the same day (see here).

I did not intend for large-scale migration to begin with that post; I intended to enter bot requests at Wikidata:Bot_requests after checking in the public forum that the outcomes of the Migrating away from GND main type RFC sounded reasonable to general contributors. The questions and proposals I put there were misinterpreted as a request to actually begin large-scale migration. In hindsight, I should have asked that it be stopped until the notice at Discussion_Modèl:Infobox had been up for at least a week. Someone should have also found the oc-WP editor maintaining the Infobox code and posted on their talk page.

Large-scale migrations will happen in the future. It is responsibility of the Wikidata community to ensure that these things happen with minimal disruption. We need a protocol on how to properly notify Wikidata clients when we intend to making breaking changes to properties. This obviously includes large-scale claim deletions done as part of a remapping effort, but it could include other things.

Here is an idea of a checklist that should be completed in large-scale remapping efforts:

1. Change the label and description of the property to announce it is being deleted
2. Notify known Wikidata clients, e.g. on a talk page of a client wiki
3. Get in touch with someone maintaining Wikidata usage on a client wiki and explain that the property will be deleted
4. Ensure that the property is not being used by the Wikidata client before beginning large-scale migration

It would be nice if we could change the background color of data being used on client Wikipedias to a light red, and possibly add some text -- maybe an icon or red '!' -- beside the usage, as a way to indicate a property's impending deletion. Emw (talk) 13:59, 7 January 2014 (UTC)

Just to answer the original question: the oc.wikpedia template is supposed to make use of p107 for choosing the most appropriate info and to provide fallback solution when p107 is missing. However, there are major bugs in the template, so that it does not really work (nothing to do with p107 apparently). The template should be rewritten, but getting rid of p107 is only one of several things that would need to be done. --Zolo (talk) 20:04, 7 January 2014 (UTC)

Are you serious?

I was one of the guys pressing for Wikidata from the very beginning (see German Wikidata project discussion), indeed one of those triggering that project at WMDE. Later on I became desillusioned about how data mining was pushed in Wikidata with lots of, tons of unsourced data. At that point I ended actively working with wikidata, which in my opinion, never will become more than a better interwiki system. I vowed for myself never to get involved again with wikidata again, aside the occasional interwiki fix most Wikipedia users are doing. After a long time I came back to look what was about the bot modifications of P107. Are you serious? This project is getting nuts. You can't replace P107 with neither P279 nor P31. There are six valid values for GND. There are a zillion possible values for P279 or P31. The decision of deleting this property is just wrong, for not to say that is was really really senseless. Neither P279 nor P31 can be used for what P107 was created for, because they deliver invalid entries. This is so disappointing. --Matthiasb (talk) 04:19, 10 January 2014 (UTC)

• I'm about this far (|| <- that far) from locking this page from edits. Nothing constructive has been added here in months. Your (and other) arguments for the continued existence of this property have been refuted many times over. If you are unwilling to donate your time to the mission of Wikidata (and that is what it sounds like, for whatever reason), you should have nothing to say on the matter going forward. Please, exercise your right to vanish and go. --Izno (talk) 05:08, 10 January 2014 (UTC)

I would oppose locking this page from edits. (We should also not blow up at occasional editors like that.) Emw (talk) 13:59, 10 January 2014 (UTC)

• Matthiasb, if you haven't read it already, the discussion at Wikidata:Requests_for_comment/Primary_sorting_property might interest you. It provides background on why this community decision was made. The information captured by P107 was very useful as a first round of classification; it is currently being used to help build a larger, more robust classification system. P31 and P279 can certainly deliver valid entries on Wikidata, as they do in the rest of the Semantic Web -- including the GND ontology. Have you seen Wikidata Query, Wikidata Generic Tree? Emw (talk) 13:59, 10 January 2014 (UTC)
• Your vision is not so erroneous... Wikidata:Project chat#Question about classes, and 'instance of' vs 'subclass', Wikidata:Project chat/Archive/2013/12#Top of the subclass tree, language dependency problem (town/city), constraints problem (domain of P625), Wikidata:Database reports/Constraint violations/P279, Wikidata:Database reports/Constraint violations/P31, Property talk:P31#Inconsistency? and etc. So, looks like current status of P31/P279 is very far from complete.... And I am not sure that P31/P279 system will be completed anytime... But Wikidata can exists without type system too. For example see Module:Authority control (Q11640331). It is used in 19 wikies already. — Ivan A. Krestinin (talk) 20:30, 10 January 2014 (UTC)

User:Izno, I am very astonished about your arrogancy. First of all go reading Statement of principles, especially point 7 on which I was referring when I wrote my critique on how the decision was made concerning P107. Indeed you're disrespectful and seem not to carry on the way Wikimedia's projects are run; if any the user who should excercise his right to leave is not me but you. (In the German Wikipedia I would use some sharper words, but I see no reason to stress "no personal attacks" in this project further. Please refrain from dealing with me like with a troll. I never trolled in any of the WMF projects, with no single one of my about 150 thousand edits.) Just in case you still not got it: P107 is relevant for the German Wikipedias "Normdaten" template. There are exactly six valid values which can be used in that template. As a result neither P31 nor P279 can provide senseful data for that template "Normdaten", since both properties can assume many more values which would deliver illegal results. Wikidata is just attempting a wikispecies. I case you are not aware of: German WP does not link to Wikispecies beause of the project is not good enough. At the moment Wikidata is doing all possible, it seems, not to be used within German Wikipedia in the future. The reason? German Wikipedia has standards but parts of the Wikidata community are unwilling to respect those standards. It might come that the German community decides that Wikidata is not userful for the German Wikipedia and won't be used for anything besides interwikis. What a shame! --Matthiasb (talk) 21:39, 10 January 2014 (UTC)

User:Emw. In contrary to what User:Izno thinks I understand that there might be and probably should be a larger, more robust classification system, but this is Wikidata and Wikidata is meant to provide data which can be used. A larger, more robust classification system surely is useful for plenty of issues but not for the Normdatendatei. But P31 and P279 are not useful for w:de:Vorlage:Normdatendatei, they are trully useless. Perhaps some Wikidateans were in error when the deletion was discussed and thought, that the six GND values have been invented by the German Wikipedia. They're not. The classification was invented by the German National Library. Who the Wikidata community is to decide that "GND is harmful" for Wikidata? Would you ever contest a Library of Congress classification system as harmful for Wikidata? As I said something went really totally wrong. It's time to revert the mistake but I guess that some people here are not able to admit to the mistake they made. Reminds me on FIFA's Qatar decision. --Matthiasb (talk) 21:39, 10 January 2014 (UTC)

• While I haven't been following this discussion since the beginning, most of the arguments I've seen for deleting P107 say that we should manage our own sorting property. Why do we have to make that choice? If German editors find it useful to sort items in the same way as the GND, can't this property exist alongside P:instance and P:subclass? --Arctic.gnome (talk) 21:48, 10 January 2014 (UTC)

+1 --Kolja21 (talk) 23:41, 11 January 2014 (UTC)

Well I would go further: If German (Wikipedia) editors want this property, we'll have to keep it. Actually, in the sense of Wikidata as a WMF-project wide data repository deleting a property against the needs of a specific WMF project is again the basic idea which let us start with wikidata at all. --Matthiasb (talk) 21:35, 14 January 2014 (UTC)

• Matthiasb, TomT0m replied to points you make in Property_talk:P107#Leave_us_Normdaten_.28authority_control.29_editors_alone.2C_please. Emw (talk) 13:33, 11 January 2014 (UTC)
• @Matthiasb: I concur with @Izno:. This horse was dead long ago. The discussion I commented on above says a lot.--Jasper Deng (talk) 06:09, 12 January 2014 (UTC)

That's kind of polemic but not an argument. (It's easy to shoot the horse and later to claim it was dead long ago.) The decision to delete the property was wrong, is wrong and will be wrong, aside that the deciscion was a ridiculous prevarication of the consensus. Long before Wikidata started I discussed with Lydia Pintschner on that issue and we agreed that there must be place for different, concurrating sets of data. Having P107 aside of P31 and P279 is not a question of redudancy but those are different data sets. It's like having a set of inhabitant numbers for towns according to the 2010 census on one hand and the 2006 estimate on the other hand, for example. What has be done was to keep one hand and to chop off the other; deleting P31 (not only) for me was and is an act of vandalism. The basic idea of Wikidata is enabling WMF projects to use data kept on Wikidata. It is not to be decided in Wikidata if data used in a Wikipedia or Wikisource project has to be stored at Wikidata or not. Actually if comparing with Commons as a file repository we won't delete images because of commons:Commons:Scope of project which are used in any other WMF project. So why the Wikidata community chose (even was allowed to do so!) to delete datum used and/or useful for the German Wikipedia? Does Wikidata have a policy to determine which datum is useful to other projects and which are not and likely to be suppressed? --Matthiasb (talk) 21:35, 14 January 2014 (UTC)

The main issue with the GND main type was that it was creeping in as a sort of Wikidata primary sorting key. It is now clear that it is unfit for that purpose, does that mean we can safely reinstate it ? The maintenance burden is far from negligible: we have to add an essentially unsourceable property to all items. Users have to learn the quirks of the GND classification system or let other users correct their edits (there were many errors in p107 values). On the flip side, would it have any use ? de.wikipedia indeed transcludes it a GND main type in many articles, but no one has ever been able to tell me how that has any use except for tools, and tools can use other properties just as well. As said before, if we want to use the GND classification, I would rather use the 3-letter code that is more precise - when we do not have the full code, we can simply have the first letter, or the first two letters. --Zolo (talk) 05:52, 15 January 2014 (UTC)

That's not the point, Matthias appeals to. A few people in WD telling users in WP what is in their belief useful. Subsequently a large community of Wikipedians just ignore WD, what is sad and counterproductive. --Kolja21 (talk) 21:47, 15 January 2014 (UTC)

First may I say, the continued resistence against consensus is starting to get quite irritating for me here. If people have real arguments to provide for the keeping of this property besides 'dewiki uses it!! dewiki will not use Wikidata if this is deleted!!!!' then I would appreciate to hear them. At the moment, people are arguing that a small part of Wikidata is forcing something on dewiki, no. The Wikidata community had decided what it wants to manage on its project, the latter seems true in that dewiki is forcing Wikidata to do something which is has decided not to. So, if people have real arguments for the keeping of this property besides a 'if this happens, this will happen' when the latter is clearly true, please provide it. Otherwise, can be just get on with improving the knowledge instead of attempting to recall every single decision a single user disagrees with and attempts to use a community to back it up? For a first, only ocwiki and plwiki are actuallt registered as using this property therefore the dewiki argument is poor at best for now. John F. Lewis (talk) 21:53, 15 January 2014 (UTC)

Lets assume that dewiki community goes to WD:PP and says: We want create GND type property. It is needed for our project. I think you or another users says: We already created it and deleted it. So lets close the proposal speedily. So it does not matter was dewiki registered or was not registered. And it is not true that P107 was used only by ocwiki and plwiki. It was massively used for data verification inside Wikidata. It was used by my and possible another bots while data import to avoid creating invalid claims. These facts was known, but was ignored. Now we have no replacement for this mechanism (P31 does not work). Now we have conflict with dewiki community. What positive points we have from P107 deletion? I do not know any positive points. — Ivan A. Krestinin (talk) 08:44, 18 January 2014 (UTC)

Of course dear John F. Lewis, you has to justify your action. My proposal to retain P107 (P107) as qualifier for GND ID (P227) was completely ignored. --Succu (talk) 17:07, 18 January 2014 (UTC)

I have to justify why I act on consensus? Okay... John F. Lewis (talk) 17:59, 19 January 2014 (UTC)

This seems a good compromise, I'm not against putting the full GND type code as the GND identifier qualifier. That implies we don't have a GND on non GND classified things, and we got the information for those who want it. This is objective and non questionable, and sourcable. TomT0m (talk) 17:25, 18 January 2014 (UTC)

Seems pointless to be honest. It is like creating a 'Freebase title' property for use with the 'Freebase identified' the information is already there and there is a direct link. John F. Lewis (talk) 17:59, 19 January 2014 (UTC)

Okay, I'm with Izno and John here. These threads are starting to irritate me more and more as more bytes are added to them. Nothing is going to change with P107. We as a community have already decided that it's going to be deprecated and then deleted. I don't see why you guys think John needs to keep explaining himself. He's done it approximately a million times. Can't we all just do something more productive with our time? TCN7JM 18:53, 19 January 2014 (UTC)

I just don't understand why Izno and John demand a better explanation than "because dewiki wants it". I see why this property was problematic in the days before "instance of" and "subclass of", but now that we have our own categorization system, why not let dewiki have a property that they find useful? The argument that says "because dewiki wants it" seems sufficient to me. --Arctic.gnome (talk) 19:24, 19 January 2014 (UTC)

Because a 'because xxwiki wants it' is not a valid reason at all. Going by that, it is possible for me to request deletion of Main Page on all wikis going 'wikidatawiki wants it'. In fact my example applies here too. A wiki does not require a Main Page, having it is beneficial but is not required. Here, P107 is not required just beneficial but the community has decided its benefit has outlasted its stay and thus is no longer necessary. John F. Lewis (talk) 19:30, 19 January 2014 (UTC)

Fair enough. My next question is: when we got consensus to delete, how many people voted to delete solely because they were worried about P107 becoming our main categorization system? If we assumed that those people would abstain or vote to keep after the implementation of subclasses, would there still be consensus to delete? If one of the main reasons for the consensus is gone, are we sure that we still have consensus? --Arctic.gnome (talk) 19:51, 19 January 2014 (UTC)

What should we use instead in a template?

Hi all, I just discovered that part of the English Wikipedia Sister Projects links template that used P107 to identify geographical entities (and thus to deliver Wikivoyage links) is broken because of this change. Any ideas about what we should use to replace it? The idea is to deliver the wikivoyage parameter if an article is a place of any kind (i.e. geographic entity). It is far from obvious what to replace it with given the unstructured nature of P31.

p.s. Not that I'm looking for a fight... but as an information scientist & long-time editor I fail to see what it would have cost us to have both structure: a 6-point structured data class and an unstructured classification system. The former is good for unanticipated useful applications like this template, which depends on a restricted number of options; the latter is good for flexibility and detailed classification. The maintenance burden of keeping both, given a little regex driven botwork, seems negligible. Deleting P107 doesn't seem like it was helpful. -- Phoebe (talk) 06:29, 10 February 2014 (UTC)

The issue is how to tell if something is a geographical entity without this property? One could simply (or perhaps not so simply) travel up the subclass tree to check whether the entity is an instance of a geographic region (Q82794) (or territory (Q7703766) or geographic location (Q2221906) perhaps, depending on how specific is necessary). Would that work? --Yair rand (talk) 07:18, 10 February 2014 (UTC)

Not yet, since "travel up the subclasses" isn't possible until some bugs are solved. -- Lavallen (talk) 08:23, 10 February 2014 (UTC)

Many users have proposed that we develop our own high-level classification. Maybe it is time we try that ? --Zolo (talk) 08:26, 10 February 2014 (UTC)

By the way, is there a reason why en:Template:Sister project links doesn't retrieve sitelinks from Wikidata ? --Zolo (talk) 08:31, 10 February 2014 (UTC)

+1. Russian and Ukrainian WP did it already. You can use our code or create own without problem. --Voll (talk) 08:50, 10 February 2014 (UTC)

@voll: are all the sister projects supported now?? I didn't think they all were. Thanks, -- Phoebe (talk) 18:47, 10 February 2014 (UTC)

Sorry, I didn't get the question. If the question was: does the English WP support sitelinks to Wikivoyage, Commons and Wikisource - the answer is 'yes'. --Voll (talk) 20:44, 10 February 2014 (UTC)

@Voll: sorry, what I meant was it sounds like your sister projects template relies on a link to the right sitelink being present in Wikidata, but I didn't think Wikidata supported links to Wikisource, Wikiquote, etc yet. (Maybe I am wrong about that). Thanks -- Phoebe (talk) 19:44, 13 February 2014 (UTC)

@Phoebe: Commons, Wikisource and Wikivoyage are supported. The other projects are not yet. --Zolo (talk) 19:58, 13 February 2014 (UTC)

Actually, this is a really easy thing to solve and you don't even need to care about the subclass tree. As we support Wikivoyage links natively, you should just be able to query for the existence of a site link to Wikivoyage directly. I don't see an immediate issue with that approach... --Izno (talk) 12:48, 10 February 2014 (UTC)

When there is not real sitelink, en:Template:Sister project links links to the search page of the sister project. I suppose the above comment should be read "assuming this behavior makes sense" (though I am not sure it does).

Thinking about it, a "placeness" filter may actually not make much sense. Some topics are not places but may have related content on Wikivoyage. Museums are GND-organizations but a Wikivoyage link is certainly more useful for the British Museum than for many GND-places (say Saturn). --Zolo (talk) 13:53, 10 February 2014 (UTC)

Exactly, user:Zolo -- this is in the light of trying to replicate current behavior; I think enabling searching makes sense in an encouraging editing sense. I think the non-obvious topics tend to get added by hand... -- Phoebe (talk) 16:22, 10 February 2014 (UTC)

Yeah user:Izno to be fair I don't think wikivoyage links were supported when the template was coded -- this project moves fast :) But yes. What would you query? -- Phoebe (talk) 16:22, 10 February 2014 (UTC)

@Phoebe: Without getting into the complexities of it (which I can't assess), you'd use mw.wikibase.getEntity(), which returns information about the sitelinks (see the documentation on MediaWiki and in particular the bottom of the example on that page). --Izno (talk) 16:42, 10 February 2014 (UTC)

@Izno: ok thanks for the help! I didn't write the template myself but I will pass this along, and hope that we can implement it. That template's not converted to Lua yet so the whole thing needs to be rewritten. -- Phoebe (talk) 18:47, 10 February 2014 (UTC)

@Phoebe: I have create simple Module:Wikivoyage in English WP, you can use it there in such way: {{#invoke:Wikivoyage|link}} --Voll (talk) 21:02, 10 February 2014 (UTC)

That's probably functionality that should more generally be added to en:Module:Wikidata. Should probably drop a note there. --Izno (talk) 21:28, 10 February 2014 (UTC)

There is another solution which does not require either to use the subclass tree : class the geographical places classes using a class of class. e could regroups all the geographical place classes and tag them as instance of (P31) <Located object classes> for example. Then if we have an object of some type, like <Museum of History of Paris>, let's say it's an instance of <Museum>. We check if Museum is an instance of <Located object classes> , then we have a good hint to choose a corresponding infobox. TomT0m (talk) 15:57, 10 February 2014 (UTC) ┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Phoebe, Izno, TomT0m, Yair rand, Voll, Zolo: a discussion was begun here on Wikipedia, where it was suggested that I go to the chat page here on Wikidata and ask about this issue there. Nobody has answered, which is a good thing, because the question can hopefully be answered here. Specifically:

Was checking to see if a template documentation page on Wikipedia needed an update and came across one thing that may be of concern. In the w:Template:Sister project links/doc#Default display section resides:
However, voy (Wikivoyage) only displays by default if the entity type on Wikidata is "geographical feature".
That link, "entity type", is to Wikidata page Property:P107, which has been titled "(OBSOLETE) main type (GND) (P107)", and is further described:
** Do not use ** Due to be deleted. Please use instance of (P31)/subclass of (P279)
I'm not sure if we should stay with the P107 page (probably not) or if there is a better link, such as Property:P31, or Property:P279, or perhaps even Geographical object ("geographical feature" on Wikipedia). Also, P107 is used within the template itself as {{#property:P107}}, and we may need a replacement for that, as well. Can one or more of you provide guidance in regard to the best link and function that we can use for this purpose? – Paine Ellsworth ^CLIMAX! 22:06, 18 August 2014 (UTC)

@Paine Ellsworth: Actually this needs a feature soon to be deployed on Wikidata, the ability to access other items data on any page. We can already build trees on Wikidata, fo example {{Classification|Q5}} gives

Classification of the class human (Q5)   

For help about classification, see Wikidata:Classification.

Parent classes (classes of items which contain this one item)

• human (Q5)
  • mammal (Q110551885)
    • vertebrate (Q12898224)
      • animal (Q729) ^(@)→
  • omnivore (Q164509)
    • consumer (Q72638)
      • ^→(#) heterotroph (Q159344)
        • organism (Q7239) ^(%)→
    • animal (Q729) ^(@)→
  • individual animal (Q26401003)
    • individual organism (Q110224119)
      • individual (Q795052) ^(⁋)→
      • ^→(%) organism (Q7239)
        • physical anatomical entity (Q66394244)
          • anatomical entity (Q27043950)
            • independent continuant (Q53617489) ^(+)→
          • natural physical object (Q16686022)
            • physical object (Q223557)
              • material entity (Q53617407)
                • independent continuant (Q53617489) ^(+)→
              • concrete object (Q4406616) ^(¤)→
            • natural object (Q1970309)
              • object (Q488383) ^(§)→
          • ^→(¤) concrete object (Q4406616)
            • object (Q488383) ^(§)→
    • ^→(@) animal (Q729)
      • heterotroph (Q159344) ^(#)→
  • person (Q215627)
    • person or organization (Q106559804) ^(†)→
    • ^→(⁋) individual (Q795052)
      • agent (Q24229398) ^(¶)→
      • organism (Q7239) ^(%)→
    • legal person (Q3778211) ^(‡)→
  • natural person (Q154954)
    • ^→(‡) legal person (Q3778211)
      • person or organization (Q106559804) ^(†)→
    • ^→(†) person or organization (Q106559804)
      • ^→(¶) agent (Q24229398)
        • ^→(+) independent continuant (Q53617489)
          • continuant (Q103940464)
            • entity (Q35120) ^…
      • corporate body (Q106668099)
        • ^→(§) object (Q488383)
          • entity (Q35120) ^…

Subclasses (classes which contain special kinds of items of this class)

⟨human⟩ on wikidata tree visualisation (external tool)(depth=1)

Generic queries for classes

• Number of subclasses (query)
• List of subclasses
• List of direct subclasses
• Number of instances (query)
• Count of instances by class (query)
• List of instances (query)
• List of most frequent properties for items of this class (query)
• Properties suggested for this class (query)

Howether this is still hackish. In one of the next deployment we will be able to get rid of the hack, in Wikidata only. Doing this cleanly on Wikivoyage is not planned yet as far as I know, but a first deployment on Wikidata is a good omen imho.

Of course you may ask how it is related to your query. That's because if we can build the tree in lua, it's easy to check without displaying it if a class is in this tree, as a replacement of the P107 value check.

An alternative : build the trees using Wikidata query, and check if some instance of (P31) value has a value listed by Wikidat query, if the results are harcoded in a Lua module. This is less dynamic but could do the trick for now. TomT0m ^(talk) 11:06, 19 August 2014 (UTC)

Thank you, TomT0m, for your explanation! Still not certain of the impact on the Wikipedia template, Sister project links. Should we disable the Wikidata utility pending notice of deployment, or is the utility still functional? Also, the documentation link, which takes those who click it to this P107 page, does not seem helpful. Should it be temporarily disabled, also? – Paine Ellsworth ^CLIMAX! 13:35, 19 August 2014 (UTC)

Replacement for deciding if something is a person

P107=Q215627 offered an easy way to test whether an article is about a person (some templates need to be phrased differently in that case). How should that be done with P107 deprecated? Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type mentions P31=Q5 (is a human), but it is not clear whether that happened / will ever happen. Is there reliable documentation about this? --Tgr (talk) 00:17, 28 July 2014 (UTC)

It is happening. There are only 27,000 statements left with P107 (P107)=person (Q215627) compared with 1,200,000 statements last summer. In the same time, the number of statements instance of (P31)=human (Q5) increased to now 2,400,000. --Pasleim (talk) 03:30, 28 July 2014 (UTC)

Unfortunately bots seems to replace GND, typ p ("person") always with human (Q5) what of cause is nonsence.[8] --Kolja21 (talk) 03:23, 14 February 2015 (UTC)