Wikidata:Property proposal/Archive/10

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Street

Done: located on street (P669) (Talk and documentation)

Description	street of the address of a building
Data type	Item
Proposed by	Zolo (talk) 19:55, 17 June 2013 (UTC)

Done: house number (P670) (Talk and documentation)

Description	street number
Data type	String
Proposed by	Zolo (talk) 19:55, 17 June 2013 (UTC)

An address string-type property does not allow to link to the item about the street, so we need it to do it another way. One possibility would be to use located in the administrative territorial entity (P131) but we need a street number qualifier, and that would be a bit stretched to do that with P131. The street number needs to be a string, it cannot be a number because of things like 2bis or 21-23, but it can probably be a more general "number" property. Note that it may be tricky, and perhaps not always possible, to create a standardly formed address using this property, so we may still need a string-type property for the address in addition to it. --Zolo (talk) 19:55, 17 June 2013 (UTC)

Support For the street I beleive we should have a multilingual property and a item property. I don't think non-important street need to be a item. --Fralambert (talk)

I am a bit wary that using two properties for the same relation will make things harder to manage with uncertain benefits. Also, the cutoff between an important an an unimportant street is rather subjective, note that most streets in Paris have an article in fr.wikipedia though many are tiny and unremarkable. --Zolo (talk) 21:45, 1 July 2013 (UTC)

Comment How it will be possible to write a adress with a street with a cardinal point, like «51, Sherbrooke Street (Q3450058) Ouest» for Notman House (Q11845348)? --Fralambert (talk) 03:58, 27 June 2013 (UTC)
Oppose per Fralambert. --Rs chen 7754 04:27, 27 June 2013 (UTC)

Comment - where is the problem?--Nightwish62 (talk) 20:43, 28 June 2013 (UTC)
Comment Good question Nightwish62! I can't see a problem either. Notman House (Q11845348) can be found on the street named Sherbrooke Street (Q3450058). Danrok (talk) 21:26, 28 June 2013 (UTC)
I think the problem is that the address is usually written "51, rue Sherbrooke ouest" but "ouest" is not really part of the street name, so we cannot really guess the usual way of writing the address with just the street name (item) + street number (string). I doubt we can really overcome this issue any other way than by complementing the whole thing with an "address" property with string datatype. --Zolo (talk) 21:45, 1 July 2013 (UTC)

Support See also the discussion right above this one here --Nightwish62 (talk) 20:43, 28 June 2013 (UTC)
Support Danrok (talk) 21:20, 28 June 2013 (UTC)

Done - both created by User:Zolo on 3. July 2013. --Nightwish62 (talk) 22:06, 1 August 2013 (UTC)

Mouse Genome Informatics ID

Done: Mouse Genome Informatics ID (P671) (Talk and documentation)

Description	provides integrated access to data on the genetics, genomics and biology of the laboratory mouse
Data type	String
Template parameter	en:Template:GNF_Protein_box = MGI-ID
Domain	term
Example	myoglobin = "96922", FOXP2 = "2148705", glucagon = "95674"
Format and edit filter validation	number of digits can be constrained, only numbers
Source	http://www.informatics.jax.org/
Robot and gadget jobs	Collect data from infoboxes and the online database.
Proposed by	--Tobias1984 (talk) 08:26, 27 May 2013 (UTC)

Discussion

The property sounds sensible, but it should be decided whether mouse genes should have separate items before using it (see Wikidata talk:Molecular biology task force ‎). --Zolo (talk) 12:22, 31 May 2013 (UTC)

Agreed that this needs some further thought on how to handle various species. Andrew Su (talk) 21:47, 10 June 2013 (UTC)

Isn't this just the same case as the Ensembl ID (e.g. Q192642) Just that the species qualifier is always set to Mouse? --Tobias1984 (talk) 10:13, 11 June 2013 (UTC)

Support Since I think we're converging on consensus on how to handle orthologs, I think this property is good to go for use on mouse genes... Cheers, Andrew Su (talk) 17:52, 29 June 2013 (UTC)

release region (en)

Not done

Description	For use as a qualifier for Property:P577 (date of publication) in video games, where it is not uncommon for a game to have different release dates for Japan, North America, Europe, and Australia.
Data type	Item
Template parameter	English Wikipedia template Infobox VG, field released =
Domain	creative work
Allowed values	linked items
Example	(mock-up) For Lost Odyssey: date of publication => December 6, 2007 --> Qualifier: release region => Japan & date of publication => February 8, 2008 --> Qualifier: release region => Australia (and two more)
Format and edit filter validation	Nope
Source	N/A, reference would be for P577
Robot and gadget jobs	Possibly, as it uses the vgrelease template
Proposed by	Sven Manguard Wha? 03:36, 19 June 2013 (UTC)

Discussion

Support - Definitely is needed. T C N7JM 03:43, 19 June 2013 (UTC)
Comment Cannot place of publication (P291) be used instead? It can be used more than once in the same item, like <place of publication> UK, <place of publication> PAL region (Q2729044), etc.--Micru (talk) 23:08, 24 June 2013 (UTC)
- It can. I had not seen that. This is now withdrawn. Sven Manguard Wha? 22:27, 29 June 2013 (UTC)

CAS number (en)

Done: CAS Registry Number (P231) (Talk and documentation)

Description	unique numerical identifier assigned by Chemical Abstract Society for every chemical and drugs
Data type	String
Template parameter	"CAS number" in en:template:drugbox see
Domain	term
Example	Diclofenac - CAS number 15307-83-5
Format and edit filter validation	see for detail mathod of numbering
Source	article infobox suggested above
Proposed by	117.227.159.223 10:25, 5 July 2013 (UTC)

Discussion

--117.227.159.223 10:25, 5 July 2013 (UTC)

Already here: CAS Registry Number (P231) --Ricordi samoa 10:31, 5 July 2013 (UTC)

marriage date (civil)/ Heiratsdatum (Zivil)

Not done

Description	Datum, an dem eine Person geheiratet hat
Data type	Point in time
Domain	Person
Example	Beispiel: Q73111 => Q304857
Source	Quelle
Proposed by	Raywood (talk)

Discussion

Es fehlen dann noch: Heiratsdatum (Religiös); Heiratsort (Zivil); Heiratsort (Religiös); Scheidungsdatum; Scheidungsort. Beispiel: Q828108.

Raywood (talk) 23:08, 22 June 2013 (UTC)

Oppose. Redundant to adding start time (P580) as a qualifier to spouse (P26). --Yair rand (talk) 21:46, 23 June 2013 (UTC)

Oppose as Yair rand --Nightwish62 (talk) 21:19, 30 June 2013 (UTC)

Oppose as Yair rand Snipre (talk) 11:56, 2 July 2013 (UTC)

Not done - archived by --Nightwish62 (talk) 16:56, 6 July 2013 (UTC)

characters / действующие лица

Done: characters (P674) (Talk and documentation)

Description	list of characters
Data type	Item
Domain	plays, operas, operettas, may be books
Example	See w:en:Hamlet#Characters
Proposed by	EugeneZelenko (talk)

Discussion

It may be useful to generate list of characters automatically as well as link relevant items together. EugeneZelenko (talk) 02:32, 19 May 2013 (UTC)

Comment How about using character role (P453) and use that to make a list of character roles in the book? Just a matter of changing the description of character role (P453). Danrok (talk) 15:37, 23 May 2013 (UTC)

I think better to keep qualifiers and regular properties separate to simplify constrains violation checking. character role (P453) is already used for aviation related topics what is contradictory with its purpose. --EugeneZelenko (talk) 02:57, 24 May 2013 (UTC)

Support This property is different than character role (P453). "Role" describes the relationship actor->character, while "character" represents the relationship between work->character. Better to make the distinction instead of mixing concepts and overstretching properties.--Micru (talk) 18:21, 12 June 2013 (UTC)
Support per Micru. Filceolaire (talk) 08:16, 13 June 2013 (UTC)
Support —Ruud 23:14, 24 June 2013 (UTC)

Done and archived by --Nightwish62 (talk) 18:06, 6 July 2013 (UTC)

Google Books identifier

Done: Google Books ID (P675) (Talk and documentation)

Description	This identifier gives access to the books that Google has scanned.
Data type	String
Domain	published works
Example	Tirant lo Blanch (1409 edition) <Internet Archive identifier> 7r14FzJdSuAC
Proposed by	--Micru (talk) 00:47, 25 June 2013 (UTC)

Discussion

Support There are many sources in Commons that come from this site, it is also used in Wikipedia.--Micru (talk) 00:46, 25 June 2013 (UTC)
Support ·addshore· ^{talk to me!} 10:34, 27 June 2013 (UTC)
Support Aubrey (talk) 09:08, 29 June 2013 (UTC)

Done and archived by --Nightwish62 (talk) 18:13, 6 July 2013 (UTC)

lyrics by

Done: lyrics by (P676) (Talk and documentation)

Description	author of song lyrics
Data type	Item
Domain	songs
Example	Let It Be lyrics by Paul McCartney
Proposed by	EugeneZelenko (talk)

Discussion

We have Property:P87, but it has other domain. --EugeneZelenko (talk) 13:33, 23 May 2013 (UTC)

Support Needed
- Comment The domain should cover musicals (i.e. musical theatre) as well. In this field, it is common for the lyrics of the musical numbers to be written by somebody different from the spoken text (the 'book'): the latter should be a different property. --ColinFine (talk) 23:08, 6 June 2013 (UTC)
Support --Nightwish62 (talk) 18:55, 30 June 2013 (UTC)

Done - created and archived by --Nightwish62 (talk) 18:21, 6 July 2013 (UTC)

Encoded by

Done: encoded by (P702) (Talk and documentation)

Description	the gene that encodes some gene product (usually a protein or RNA). Inverse of "encodes".
Data type	Item
Domain	protein, RNA
Allowed values	gene
Example	reelin (Q13569356) --> RELN (Q414043)
Proposed by	See wikidata talk:Molecular biology task force

Comment reciprocal property of "encodes"

Support --Andrew Su (talk) 01:12, 9 July 2013 (UTC)

Support Chinmay26 (talk) 18:13, 9 July 2013 (UTC)

Support ~~Wait~~ See comment for "encodes" proposal above. Emw (talk) 05:17, 10 July 2013 (UTC)

Agreed, and changed! Cheers, Andrew Su (talk) 17:11, 11 July 2013 (UTC)

Thanks, this looks good to go from my perspective. Emw (talk) 22:54, 11 July 2013 (UTC)

Comment This property's inverse -- encodes (P688) -- was created several days ago. This property has unanimous support. Is there anything specific holding back the creation of this property? Emw (talk) 02:47, 17 July 2013 (UTC)

Done - created and archived by Paperoastro (talk) 12:32, 21 July 2013 (UTC)

time (en)

Not done

Description	see example. This property is proposed so that items can be read and edited by machines easily.
Data type	Point in time
Domain	term
Example	2010 (Q1995)->2010, 2010s (Q19022)->2010s, February 2010 (Q236283)->February 2010, 21st century (Q6939)->21st century...
Proposed by	GZWDer (talk) 11:30, 6 June 2013 (UTC)

Discussion

The name seems kind of ambiguous. I suspect that the property might be misused. Perhaps "is time" would be better? --Yair rand (talk) 11:42, 6 June 2013 (UTC)
Not sure how this is used but I think it should be added to the discussion at Wikidata:Requests for comment/Time DataType Properties. Filceolaire (talk) 21:15, 6 June 2013 (UTC)
Oppose This property just create a string from the label: a program can easily retrieve the string from the label. No added information. Snipre (talk) 15:31, 8 June 2013 (UTC)
Oppose, I dont see any use for this property --Nightwish62 (talk) 16:38, 6 July 2013 (UTC)

Not done --Nightwish62 (talk) 19:31, 21 July 2013 (UTC)

Ensembl Transcript ID

Done: Ensembl transcript ID (P704) (Talk and documentation)

Description	transcript ID issued by Ensembl database
Data type	String
Domain	gene/RNA
Example	RELN (Q414043) -> "ENST00000428762", "ENST00000343529"
Proposed by	Andrew Su (talk)

Support --Andrew Su (talk) 16:42, 11 July 2013 (UTC)

Support Emw (talk) 01:11, 17 July 2013 (UTC)

Comment not sure about this one. Why not rename Ensembl gene ID (P594) to Ensembl ID? It is after all the same authority? --Tobias1984 (talk) 16:38, 17 July 2013 (UTC)

Hmm, good suggestion I hadn't thought of. The only two downsides of having one generic Ensembl ID property are 1) limits possibilities for constraint violations (a point that I recently learned ;) ), and 2) it means we would definitely have to separate genes from the RNAs that they encode. (Recall that our tentative plan was to just combine those items except for the rare cases where the distinction matters. I know, not a perfect situation, so I'm not married to this choice...) Cheers, Andrew Su (talk) 22:09, 17 July 2013 (UTC)

Done --Tobias1984 (talk) 19:26, 23 July 2013 (UTC)

Ensembl Protein ID

Done: Ensembl protein ID (P705) (Talk and documentation)

Description	protein ID issued by Ensembl database
Data type	String
Domain	protein
Example	RELN (Q414043) -> "ENSP00000392423", "ENSP00000345694"
Proposed by	Andrew Su (talk)

Support --Andrew Su (talk) 16:42, 11 July 2013 (UTC)

Support Emw (talk) 01:12, 17 July 2013 (UTC)

Comment not sure about this one. Why not rename Ensembl gene ID (P594) to Ensembl ID? It is after all the same authority? --Tobias1984 (talk) 16:48, 17 July 2013 (UTC)

Done --Tobias1984 (talk) 19:29, 23 July 2013 (UTC)

located on terrain feature (en)

Done: located in/on physical feature (P706) (Talk and documentation)

Description	located on the specified landform or body of water. Should not be used when the value is only political/administrative (towns, cities, provinces, states, countries, etc.).
Data type	Item
Domain	structures (e.g. buildings), places (towns), landforms, and bodies of water
Allowed values	landforms or bodies of water
Example	Oahu (Q131347) => Pacific Ocean (Q98) (island in ocean), Manitoulin Island (Q654405) => Lake Huron (Q1383) (island in lake), Nettilling Lake (Q1132211) => Baffin Island (Q81178) (lake on island), Meyer–Womble Observatory (Q6826502) => Mount Blue Sky (Q1950460) (building on mountain)
Source	External references. There may be data on Wikipedia, not sure how feasible it is to extract automatically.
Robot and gadget jobs	Should or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.)
Proposed by	Superm401 - Talk 17:44, 14 June 2013 (UTC)

Discussion

This is a follow-up to discussion at the deletion discussion for P526 (located on island). Many people there agreed there should be a general property for this, distinct from located in the administrative territorial entity (P131) (only for political/administrative concepts). Superm401 - Talk 17:44, 14 June 2013 (UTC)

Support Filceolaire (talk) 21:27, 14 June 2013 (UTC)
Support Danrok (talk) 14:49, 14 July 2013 (UTC)
Support --Kompakt (talk) 09:48, 16 July 2013 (UTC)
Oppose weak: how do you define the limits of a geographical entity in order to define if an element is located on it or not ? I don't like properties which dependent on the judgement of contributors and in that case external sources can be very partial. The best solution woulb be an automatic definition based on the geo data of the geographical entity and the geo data of the element. Better work on an automatic tool which gives that informations instead of doing that manually. Snipre (talk) 11:25, 16 July 2013 (UTC)
Support Yes, I have been looking for this one! This allows me to state that a city is on an island (which is not an adm. unit) and that the island is in that sea. --Denny (talk) 22:50, 22 July 2013 (UTC)
Support Yes, we need this for non-administrative localisation Michiel1972 14:43, 23 July 2013 (UTC)

Done 6 pro, 1 cons --Nightwish62 (talk) 19:53, 23 July 2013 (UTC)

Satellite bus/ Платформа

Done: spacecraft bus (P707) (Talk and documentation)

Description	платформа
Data type	Item
Template parameter	ru:Шаблон:Космический аппарат Платформа en:Template:Infobox spacecraft bus
Domain	Космические аппараты
Allowed values	имя платформыКРАУ-1
Example	Казсат построен на базе платформы Яхта Eutelsat 3D uses the <Spacebus 4000> bus from Thales Alenia Space.
Source	Карточки в статьях и т. д.
Proposed by	— Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC)

Comment I think this is bus, rather than platform. Secretlondon (talk) 14:03, 27 April 2013 (UTC)

Comment If this has to link to an article we don't have that many articles on buses (on en:). Secretlondon (talk) 15:54, 28 April 2013 (UTC)

Support Secretlondon (talk) 10:12, 6 May 2013 (UTC)

Comment Can somebody add another example for this. Even with the translation program I don't understand what this is about. --Tobias1984 (talk) 21:27, 20 May 2013 (UTC)

Support - Probably a good piece of info. --Tobias1984 (talk) 13:31, 21 May 2013 (UTC)

Support - Seems useful. But we might want to think through how we ought to handle, in a standardized way, satellites for which their is no satellite bus, and the satellite is merely a one-off, a unique design being built and flown only once. Cheers. N2e (talk) 02:41, 10 June 2013 (UTC)

Oppose - too qualitative, should be handled locally. --WDGraham (talk) 02:54, 10 June 2013 (UTC)

Could you explain in details your comment? — Ivan A. Krestinin (talk) 07:53, 10 June 2013 (UTC)

Comment en: doesn't have to use it and I see this as making a link between items, not as free text. Secretlondon (talk) 19:30, 10 June 2013 (UTC)

Done --Tobias1984 (talk) 09:18, 24 July 2013 (UTC)

diocese / / diocèse

Done: diocese (P708) (Talk and documentation)

Description	The diocese to which the monastery belongs or belonged (also true for persons or organizations)
Data type	Item
Template parameter	"diocese" in en:Template:Infobox monastery
Domain	person, place, organization
Example	Roman Catholic Diocese of Hong Kong (Q869506)
Proposed by	Ayack (talk)

Discussion: Support --Чаховіч Уладзіслаў (talk) 06:44, 17 June 2013 (UTC)

Done : diocese (P708) Ayack (talk) 12:46, 24 July 2013 (UTC)

Historic Scotland ID (en) / identifiant Historic Scotland (fr)

Done: Historic Environment Scotland ID (P709) (Talk and documentation)

Description	HB Number in Historic Scotland database
Data type	String
Template parameter	en:Template:Hbnumber
Domain	place
Example	Tantallon Castle (Q57803) => 14722
Source	http://hsewsf.sedsh.gov.uk/hslive/hbsearch.show
Robot and gadget jobs	http://hsewsf.sedsh.gov.uk/hslive/hsstart?P_HBNUM=$1
Proposed by	Ayack (talk) 14:18, 19 July 2013 (UTC)

Discussion

Support As other heritage register. --Fralambert (talk) 20:54, 19 July 2013 (UTC)

Done: Historic Environment Scotland ID (P709) Ayack (talk) 13:04, 24 July 2013 (UTC)

field in which the term is used (en) / champ d'utilisation du terme (fr)

Not done

Description	The subject is a technical term in the field of the object. (the idea is to have a property that groups technical terms that are used in a given field)
Data type	Item
Domain	term (basically names of specialized fields)
Example	the term "cut" means different things in civil engineering, archaeology, jewellery and clothing. So we'd have cut is a term used in civil engineering. Similarly, Cut is a term used in archaeology and so on.
Format and edit filter validation	(sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17)
Source	shouldn't be needed as the item is usually its own source for the statement and the statement is common knowledge in any case
Robot and gadget jobs	gadgets, why not. It's not so clear how bots can help although perhaps they could extract that information starting with glossary articles such as en:Glossary of tennis terms
Proposed by	Pichpich (talk) 21:29, 17 June 2013 (UTC)

Discussion

Oppose Goal of Wiktionary and this can be a problem for translation reasons. Snipre (talk) 12:01, 19 June 2013 (UTC)

Point taken about Wiktionary. But I don't see why translation would be a problem: surely the translation of a technical term in, say, cricket is still a technical term in cricket. Pichpich (talk) 15:32, 19 June 2013 (UTC)

After mulling it over, I'll make a couple of extra comments. First, why should Wikidata absolutely avoid doing something that Wiktionary does? After all, Wikipedia keeps a record of people's occupation and that's not stopping us from recording it in Wikidata. Second, my motivation for this is that there are items for which no statements seem to be available. For instance, take Q814254. Once we've added the statement that its GND type is "term", I can't see what other statements would make sense. If there existed an item for "Glossary of archaeology" (there is one for Glossary of architecture) it would make perfect sense to add the statement "is part of the glossary of archaeology". The property I'm proposing would allow an equivalent to that. Pichpich (talk) 17:47, 19 June 2013 (UTC)

The create the item is also a general solution which do not require a property. Then <Glossary of X> would be instances of <Glossaries> or <Domain specific Glossary>, and we could have something like a domain relation which states that the domain of this glossary is X. Why should we be so shy about creating an item ? Plus there already exists items of this kind, so we multiply the ways of expressing and modeling the same things. (see my proposition to centralize and document that to check easily if somebody already thought on something for this). TomT0m (talk) 18:16, 19 June 2013 (UTC)

OpposeThe problem is that each wikidata page groups together pages on the same concept in various wikipedias. Even though all the pages are about the same concept that does not guarantee that all of them are named after the technical term for that concept. The wikipedia or wikidata page name in some languages may be a simplified description instead (Simple English Wikipedia is specifically dedicated to avoiding technical terms). Maybe if this property was renamed 'field of which this concept (or 'item') is part or something like that. Filceolaire (talk) 19:34, 19 June 2013 (UTC)

Not done More cons than pros --Nightwish62 (talk) 23:13, 24 July 2013 (UTC)

Calibre

Not done

Description	Calibre of a firearm
Data type	Number (not available yet)
Template parameter	Infobox Firearm Cartridge --> Specifications --> Bullet diameter
Domain	term
Example	FN MAG (Q842066) => 7.62
Proposed by	Esquilo (talk)

Discussion

Oppose - Isn't caliber just a fancy word for diameter? --Tobias1984 (talk) 12:55, 22 May 2013 (UTC)

A very specific diameter. Just specifying "diameter" for M61 Vulcan (Q725972) is awfully ambiguous. /Esquilo (talk) 09:53, 23 May 2013 (UTC)

Also, for an item like .308 Winchester (Q2005795), "diameter" (at the base) is 12 mm while "calibre" is 7.62 mm. /Esquilo (talk) 14:36, 24 May 2013 (UTC)

It's defined as the diameter of the ammunition the firearm is constructed for. —★PοωερZ_{_talk} 15:05, 24 May 2013 (UTC)

I think this could work: (data taken from: en:FN_5.7×28mm --Tobias1984 (talk) 15:12, 24 May 2013 (UTC)

Property	Qualifier	Statement
amunition dimensions		5.7 mm
	measurement	Calibre/bullet diameter
		6.35 mm
	measurement	Neck diameter
		7.9 mm
	measurement	Shoulder diameter
		7.9 mm
	measurement	Base diameter
		7.80 mm
	measurement	Rim diameter
		1.14 mm
	measurement	Rim thickness
		28.83 mm
	measurement	Case length
		40.50 mm
	measurement	Overall length

Oppose in preference to cartridge (item) for a firearm. Danrok (talk) 15:15, 24 May 2013 (UTC)

Not all firearms are loaded with cartridges. M1 (Q2297239) for example. /Esquilo (talk) 08:50, 28 May 2013 (UTC)

Maybe we should name the property ammunition instead. I can see now that cartridge might imply that it is the casing of many bullets (I changed the proposal below). --Tobias1984 (talk) 09:20, 28 May 2013 (UTC)

I get your point, but I am a bit worried about the ambiguousnes of a property called "ammunition". In infoboxes that label usually refers to things like high-explosive anti-tank warhead (Q60124), high-explosive squash head (Q1034063), kinetic energy penetrator (Q858329) or full metal jacket bullet (Q1429535) instead. /Esquilo (talk) 12:30, 28 May 2013 (UTC)

This is more complicated than I thought :). Have you looked at en:Cartridge_(firearms)? The article also uses shell and round as synonyms of something you fire with a weapon. If you have time could you make some sort of weapons classification tree going from gun to projectile? I would like to see what you have in mind ;) --Tobias1984 (talk) 12:44, 28 May 2013 (UTC)

Comment some guns can be configured to take different calibres, see AR-15 .223 and 5.56. Danrok (talk) 15:27, 24 May 2013 (UTC)

Not done More cons than pros --Nightwish62 (talk) 23:13, 24 July 2013 (UTC)

Escutcheon / Wappenschild / Écu

Description: Image of the escutcheon of the coat of arms
Datatype: MediaValue
Links: en:List of cities in Germany by population, en:Europe#Political_geography, en:Battle of Landriano, en:Template:Coat of arms, Escutheon
Infobox parameter example:
Comments:

It is a good thing that "Coat of arms image" has been added, but many countries' heraldic emblems have several variants, any one of which could be defined as "the coat of arms image". Belgium, for example:

greater version

greater version
lesser version

lesser version
crowned version
escutcheon

The escutcheon is generally the only one that allows for an orderly illustration of entities – e.g. in lists of countries, regions, cities or persons – by means of coats of arms, due to its uniformity with other coats of arms. This is explained in the description of en:Template:Coat of arms: "The omission of all elements of achievement save the quintessential escutcheon is a conventional heraldic practice that ensures the distinctiveness of the motifs even at low resolutions (20px is default). This also provides a meaningful degree of uniformity." (I've added links to examples above.)

I propose a new mediavalue named "Escutheon image". The use of heraldry as a means to identify geographical entities is a centuries-old tradition, preceding flags. So especially for historical articles (historical countries that had no flag), and in lists of cities/states, an escutheon database on Wikidata would be extremely valuable. Some coats of arms do of course not have variants, save the escutcheon. It would however be perfectly correct to have for instance File:Coat of Arms of Germany.svg written into both "coat of arms image" and "escutcheon image" on Germany's page.

(A more extensive proposal could be to introduce media values for "escutcheon", "lesser", "middle" and "greater" etc. coats of arms. It would also be possible to introduce for the en:blazons of each of these. But since the division into "lesser", "middle" and "greater" isn't universally applicable, I'm currently only proposing a media value for escutcheons, with the aforementioned reasons, and also because this variant exists for all the world's coats of arms.)

~~PS: Coats of arms, and escutcheons, should of course also be an option in the organisation and person categories. - Ssolbergj (talk) 01:07, 26 February 2013 (UTC)~~

All types of symbols (logos, seals, flags, coats of arms, etc.) can apply to entity types person, organization, geographical feature, and some terms such as products and services. Danrok (talk) 17:31, 26 February 2013 (UTC)

Nice! Thanks. - Ssolbergj (talk) 17:33, 26 February 2013 (UTC)

~~Support~~ No, I like the qualifier ideas better. Espeso (talk) 20:16, 26 February 2013 (UTC)
Support Danrok (talk) 01:36, 28 February 2013 (UTC)
Oppose As escutcheon is just coat of arms with a qualifier. /Ch1902 (talk) 11:02, 28 February 2013 (UTC)

Comment Such a solution could be ideal, but considering that this option isn't currently available, and we don't know when it will be introduced, I'm not sure if we should impede this (escutcheon image) property. I would presume that it would be possible to turn the values of this property into an additional value of the "coat of arms image" property, with an "escutcheon" qualifier. - Ssolbergj (talk) 15:05, 28 February 2013 (UTC)

Oppose if escutcheon is considered a variant of the coat of arms, then I would oppose the 'escutcheon' property and instead propose a 'variant' property to be used as a qualifier with values such as 'escutcheon', 'lesser version', etc. This also applies to flags and other insignia: either we can create properties for every different defined type of coat-of-arms, flag, logo, etc., or we can have a qualifier 'variant' to allow this to be defined on an as-needed basis. I would propose the later. Joshbaumgartner (talk)

Not done --Nightwish62 (talk) 23:26, 24 July 2013 (UTC)

Borders ocean

Description: The ocean(s) with which this country, county, state, city, place, etc. borders with
Datatype: Item
Links: Links to ocean articles.
Infobox parameter example:
Comments: Danrok (talk) 16:30, 26 February 2013 (UTC)
Comment: Generalize to "borders body of water"? Espeso (talk) 20:22, 26 February 2013 (UTC)

Comment yes it could include landlocked "seas", lakes which serve as borders in other words. Danrok (talk) 04:08, 27 February 2013 (UTC)

Comment perhaps this could be opened up further to all natural borders? Danrok (talk) 23:40, 28 February 2013 (UTC)

Support --NaBUru38 (talk) 20:02, 27 March 2013 (UTC)

Oppose. There is a property 'shares borders with'. What we need is an general property we can use as qualifier to state how two places are separated. Something like 'separated/divided by' or 'border type'. Example <New York> <shares border with> <New Jersey> -> (qualifier) <separated by> <river (or water)>. Sorry I didn't have an example for ocean, but I hope you know what I mean. Otherwise we would have several properties like "Borders ocean", "Borders river", "Borders land". I will make the proposal later for this. --Nightwish62 (talk) 15:38, 31 March 2013 (UTC)

Oppose in the present concept. A proposal specifing all type of border (river, ocean, mountain rang,...) is necessary. Snipre (talk) 19:13, 10 June 2013 (UTC)

Not done --Nightwish62 (talk) 23:26, 24 July 2013 (UTC)

Population density / تراکم جمعیت

Not done

Description	Popilation density of the subject city or town
Data type	Number (not available yet)
Template parameter	en:template:infobox settlement population density
Domain	type of items that may have this property
Allowed values	per km2
Example	en: São Paulo
Source	Geographical references
Proposed by	دوستدار ایران بزرگ (talk) 16:35, 31 March 2013 (UTC)

Oppose derivable properties like this (the value for the 'population' property divided by the value for the 'area' property) seem like a plausible use case for Wikidata queries. In that case, I think properties like this one would be unnecessary. Emw (talk) 17:47, 31 March 2013 (UTC)
Comment or the infobox can calculate this when it imports the area and population into wikipedia (making sure we get a up to date value). Filceolaire (talk) 20:32, 6 April 2013 (UTC)

Oppose per the 2 above comments ·addshore· ^{talk to me!} 14:32, 22 June 2013 (UTC)

Not done --Nightwish62 (talk) 23:35, 24 July 2013 (UTC)

Souvenir / ره آورد

Not done

Description	Souvenirs associated with a city which are usually bought by tourists as valuable materials of the subject city
Data type	Item
Template parameter	fa:الگو: جعبه شهر ایران ره آورد
Domain	countries, cities, towns and villages
Example	fa: یزد
Source	fa:الگو: جعبه شهر ایران
Proposed by	دوستدار ایران بزرگ (talk) 16:51, 31 March 2013 (UTC)

Oppose - I don't think that something like this can be sourced. --Tobias1984 (talk) 14:07, 8 May 2013 (UTC)
Comment not specific enough. There may be a better way to handle this kind of thing. Danrok (talk) 14:10, 9 June 2013 (UTC)

Not done --Nightwish62 (talk) 23:35, 24 July 2013 (UTC)

participant / Teilnehmer / participant

Done: participant (P710) (Talk and documentation)

Description	person, group of people or organization that actively takes/took part in the event
Data type	Item
Domain	all kinds of events
Example	2010 FIFA World Cup (Q176883) => Denmark national association football team (Q131785); 2010 Wimbledon Championships (Q476638) => Roger Federer (Q1426); First Continental Congress (Q252612) => George Washington (Q23); Hambach Festival (Q551416) => Ludwig Börne (Q213595)
Proposed by	Kompakt (talk)

Discussion

Regarding sporting events, the property can also be equipped with a qualifier to express the round or place that the participant reached. Properties like "champion", "runner-up", etc are used in many infoboxes for sporting events. For the Olympics, there are group items like Canada at the 2012 Summer Olympics (Q140982), so you don't have to list all 11,000+ athletes under one item; in order to be fully accurate, you would arguably need to introduce similar items for events like 2010 FIFA World Cup (Q176883), to list the actual squad members that participated.--Kompakt (talk) 08:15, 30 May 2013 (UTC)

Support I think this is definitely needed. Danrok (talk) 23:13, 8 June 2013 (UTC)
Comment Maybe it would be better to have only the reverse property, "participated in", because otherwise there will be too many properties (imagine how many athletes participate in the Olympic games).--Micru (talk) 01:50, 8 July 2013 (UTC)

I proposed above to have group items for events with a lot of participants, like the Olympics. As a matter of fact, we do have such items already, e.g. Canada at the 2008 Summer Olympics (Q140854). So 2008 Summer Olympics (Q8567) would have "participants": Canada at the 2008 Summer Olympics (Q140854)", and within Canada at the 2008 Summer Olympics (Q140854), all members of that team would be listed using has part(s) (P527). Still you're right, this property could have a hundred values in some occasions, so another grouping level could be necessary (e.g. "Canadian archers at the 2008 Olympics"). But on a closer look, your proposal of creating such a property on the participants' side actually bears the just same problem: professional sportspeople usually take part in hundreds of events within their career.

But that's not my main point. What is the mains idea behind this property? Using a qualifier like "ranking", it will make it possible to describe the result of a sports event; we are then able to tell who won the event, who was second, etc. Taking the example above, we could use this for archery at the 2008 Summer Olympics (Q223519) to tell who got the gold medal, who was second, etc. As mentioned above, this is an infobox property for sport events in wikipedia, but could also be used to create result lists or even complete draws at some later point. All of this would hardly be possible when we have this information distributed at the participants - although you could arguably create queries to fetch such information, I don't think that's the best way to do it. The winner, the runner-up as well as other participants should be stored along with the event itself.

A final remark: Note that the Olympics are the most complicated case by far. Take an ordinary single-sport event like the Soccer World Cup instead: for 2022 FIFA World Cup (Q284163) you'd use "participant" to list all teams with single items like "Icelandic team at the 2022 FIFA World Cup", and then list all team members within these team items using has part(s) (P527). Then none of these properties would have more than (roughly) 30 values.--Kompakt (talk) 08:49, 16 July 2013 (UTC)

Support --Nightwish62 (talk) 19:20, 21 July 2013 (UTC)

Done --Nightwish62 (talk) 23:41, 24 July 2013 (UTC)

Mineral identifiers

Strunz 8 classification/ Strunz 8 Klassifikation / Strunz classification 8 / RUSSIAN / OTHERS

Done: Strunz 8th edition (series ID, updated) (P711) (Talk and documentation)

Description	a string that is assigned to minerals and mineral groups
Data type	String
Template parameter	de:Vorlage:Infobox Mineral, Kurzform_Strunz_8
Domain	mineral items, mineral group items
Example	albite = "VIII/J.07", magnesite = "V/B.02"
Source	mindat.org: Strunz 8 ed (1982), de:Systematik_der_Minerale_nach_Strunz_(8._Auflage)
Robot and gadget jobs	Bot can collect data from German infobox or from mindat.
Proposed by	Tobias1984 (talk)

Query classifications of minerals, update infoboxes. Tobias1984 (talk) 08:19, 20 April 2013 (UTC)

I will delete this proposition because it is a redundant one: don't mix source and property. A property is valid for different sources. Snipre (talk) 08:57, 20 April 2013 (UTC)

I'm not sure I fully understand what you mean. There is only one main source for this kind of classification. Not sure that that is mixing source and statement. Isn't this just the same case as ICD10 that is published by the WHO. There is no second organization that came to the same conclusion and the same ICD-10 codes. --Tobias1984 (talk) 09:55, 20 April 2013 (UTC)

Why not an unique property Strunz ? What is not good is the creation of property dependent on the edition number of the source. Here you mix data of source level at the level of the property. For each property use there will be a source defined in the source claim of the data structure. So put the information of the edition number in the source section not in the property. Snipre (talk) 10:02, 20 April 2013 (UTC)

Ok I think I understand the problem: it is the edition number of method not of the source. But even in that case qualifier can be a better solution and you can already use the property edition in the qualifier section. Snipre (talk) 10:11, 20 April 2013 (UTC)

That sounds reasonable. Would you group all mineral classifications together into one property and then make qualifiers for Strunz 8, 9, 10, Dana and some others? Or would you divide for example Strunz and Dana into separate properties? We (mineralogy task force) are also discussing another classification that divides silicates into different structural groups. --Tobias1984 (talk) 10:20, 20 April 2013 (UTC)

No, Dana and Strunz are different and as Strunz will be subdivided better into 3 distinctions better to avoid to mix different things. Just to explain my position: I assume that the different edition of Strunz are quite similar or if not the more recent will be used. That means that most of the time you will have only one data for that property. Snipre (talk) 11:20, 20 April 2013 (UTC)

Well Strunz 8 ed had less than 3,000 valid minerals, Strunz 9 ed had more than 4,000 minerals, the grandfathered minerals are even older. The newer minerals are less important, on average. This is a publication, it gets cited, so this data is a search tool. Strunz and Dana are like the IMA mineral list, it is the reference "telefone book" of their time. --Chris.urs-o (talk) 11:35, 20 April 2013 (UTC)

@Snipre: different Strunz editions are quite different: for example actinolite Strunz 8th edition ID is: 8/F.10-20, Strunz 9th edition ID is: 9.DE.10. From 8th to 9th edition there are many changes, from 9th to 10th there are only minor changes (10th edition, that is still a work in progress, reports also new approved minerals). --Sbisolo (talk) 08:22, 22 April 2013 (UTC)

These are telefone books. The important minerals are old, so they are already listed on Strunz 8 ed (nice for sorting). Nickel–Strunz 9 ed is used by de.wikipedia because it is the last published edition. 'Nickel–Strunz 10 ed' is kept updated by mindat.org. We need Nickel–Strunz 9 ed first. Strunz 8 ed classification used roman numerals too. --Chris.urs-o (talk) 06:06, 24 May 2013 (UTC)

E.g.: arsenuranospathite had Strunz 8 ed ID 7/E.04-20 or VII/E.04-20 and chemical formula HAl(UO₂)₄(AsO₄)₄·40H₂O. The chemical formula was revised (Al(UO₂)₂(AsO₄)₂F·20H₂O) and 'Nickel–Strunz 10 ed' ID is 8.EB.25 now. --Chris.urs-o (talk) 06:22, 24 May 2013 (UTC)

How about this:

Scheme	Property	Qualifier
All qualifier	mineral classification	Strunz 8 Strunz 9 Strunz 10 Dana
All property	Strunz 8 Strunz 9 Strunz 10 Dana	-
Group similar schemes	Strunz 8	-
	Strunz	Sturnz 9/Strunz 10
	Dana	-

Please support one of the schemes or your favored scheme below: --Tobias1984 (talk) 11:32, 23 April 2013 (UTC)

New Strunz Dana votes:

All qualifier --Sbisolo (talk) 14:23, 30 April 2013 (UTC)
All property --Chris.urs-o (talk) 15:41, 12 May 2013 (UTC)
All qualifier Snipre (talk) 12:30, 18 May 2013 (UTC)

I was observing recent property creations, and it looks like most people think it is better to create more string properties that can be edit filtered than introduce qualifiers for different classifications. If nobody objects I will just create 3 string properties for strunz 8, 9 and dana. --Tobias1984 (talk) 16:19, 1 June 2013 (UTC)

Done --Tobias1984 (talk) 20:08, 25 July 2013 (UTC)

Strunz 9 classification/ Strunz 9 Klassifikation / Strunz classification 9 / RUSSIAN / OTHERS

Done: Nickel-Strunz 9th edition (updated 2009) (P712) (Talk and documentation)

Description	a string that is assigned to minerals and mineral groups
Data type	String
Template parameter	de:Vorlage:Infobox Mineral, Kurzform_Strunz_9, en:strunz=, fr:strunz=
Domain	mineral items, mineral group items
Example	albite = "9.FA.35", magnesite = "5.AB.05"
Source	CNMNC Master list 2009, Nickel–Strunz 9 ed (2001), de:Systematik_der_Minerale_nach_Strunz_(9._Auflage)
Robot and gadget jobs	Bot can collect data from different language infoboxes and from online sources.
Proposed by	Tobias1984 (talk)

Query classifications of minerals, update infoboxes. --Tobias1984 (talk) 08:25, 20 April 2013 (UTC)

I will delete this proposition because it is a redundant one: don't mix source and property. A property is valid for different sources. Snipre (talk) 08:57, 20 April 2013 (UTC)

Wrong, this doesn't change anymore. Like ICD-9 and ICD-11 --Chris.urs-o (talk) 15:46, 12 May 2013 (UTC)

Strunz 10 classification/ Strunz 10 Klassifikation / Strunz classification 10 / RUSSIAN / OTHERS

Done: Nickel-Strunz '10th ed', review of (9th ed/ 2009 update) (P713) (Talk and documentation)

Description	a string that is assigned to minerals and mineral groups
Data type	String
Template parameter	not part of any infobox at the moment
Domain	mineral items, mineral group items
Source	mindat.org ("10 ed, pending publication")
Robot and gadget jobs	Bot can collect and update data from online sources.
Proposed by	Tobias1984 (talk)

Query classifications of minerals, update infoboxes. --Tobias1984 (talk) 08:30, 20 April 2013 (UTC)

This proposal has to be rework in order to give a general property independent on the source. Snipre (talk) 08:57, 20 April 2013 (UTC)

Wrong, it's similar to ICD-9 and ICD-11 --Chris.urs-o (talk) 15:50, 12 May 2013 (UTC)

Dana 8

Done: Dana 8th edition (P714) (Talk and documentation)

Description	a string that is assigned to minerals and mineral groups
Data type	String
Domain	mineral items, mineral group items
Source	Dana 8th edition
Robot and gadget jobs	Bot can collect and update data from online sources.
Proposed by	Tobias1984 (talk)

lower boundary definition / Liegendgrenze Definition

Not done

Description	Describes the lower boundary of a stratigraphic package
Data type	Item
Template parameter	not included in any infobox yet, usually in the text of all articles
Domain	items about geologic ages and stratigraphic units
Allowed values	fossils, magnetic stages, angular-, erosional unconformity, special beds (e.g. volcanic ashes)
Example	Fortunian = Treptichnus pedum (qualifier = first appearance of the species) Ionian = Brunhes-Matuyama magnetic reversal Tapeats Sandstone = Erosional unconformity & angular unconformity (see picture on the right) Muav limestone = conformable.
Source	Stratigraphic databases See: Wikidata:Stratigraphy task force
Robot and gadget jobs	Probably has to be done by hand. Depends on the database (every geologic service has its own).
Proposed by	Tobias1984 (talk)

Lower boundaries play an important role for the geologic time scale and stratigraphic units.

Tobias1984 (talk) 21:18, 22 April 2013 (UTC)

Support - it might be possible to reduce the number of options to make them machine sortable. Mikenorton (talk) 14:00, 28 April 2013 (UTC)

I think I know what your hinting at. We could say for example that the lower boundary can be either: a fossil, magnetic or lithologic. The qualifiers could then have the species name, the magnetic anomaly name or the name of the special lithology. For formations the character of unconformity might be better suited as a qualifier for underlies/overlies. --Tobias1984 (talk) 14:26, 28 April 2013 (UTC)

Wait I am voting wait on my own proposal because I still have to think about this property for a while. Might be better to handle this with qualifiers ;) --Tobias1984 (talk) 10:26, 2 May 2013 (UTC)

Not done --Tobias1984 (talk) 20:20, 25 July 2013 (UTC)

Drugbank ID

Done: DrugBank ID (P715) (Talk and documentation)

Data type	String
Template parameter	Template:Infobox drug (Q6033882): en:Template:Drugbox: DrugBank
Domain	term
Example	vitamin C (Q199678) = http://www.drugbank.ca/drugs/DB00126 = 00126
Source	http://www.drugbank.ca/
Proposed by	--Tobias1984 (talk) 08:37, 19 July 2013 (UTC)

Discussion: Support --WS (talk) 16:49, 19 July 2013 (UTC); Support -- Andrew Su (talk) 23:09, 19 July 2013 (UTC)

Done --Tobias1984 (talk) 08:54, 26 July 2013 (UTC)

JPL Small-Body Database identifier (en) / идентификатор JPL Small-Body Database (ru)

Done: JPL Small-Body Database SPK-ID (P716) (Talk and documentation)

Description	link to JPL Small-Body Database (Q4026990) for use in source section
Data type	String
Template parameter	link to JPL Small-Body Database (Q4026990) use in the vast majority of articles about asteroids as external/source link
Domain	asteroid items (place)
Allowed values	described in detail here (some variants), but main value type - JPL SPK-ID consisting of 7 digits
Example	7777 Consadole (Q1134434) provisional designation (P490) => 1993 CO1 stated in (P248) => JPL Small-Body Database (Q4026990) JPL Small-Body Database identifier 2007777 point in time (P585) => 2013.06.20
Source	JPL Small-Body Database Browser
Robot and gadget jobs	bot Ra-bot-nik
Proposed by	Art-top (talk) 20:39, 19 July 2013 (UTC)

Discussion: Support --Tobias1984 (talk) 20:52, 19 July 2013 (UTC); Support --Paperoastro (talk) 20:58, 20 July 2013 (UTC); Support, will be useful as separate property too. — Ivan A. Krestinin (talk) 19:47, 21 July 2013 (UTC)

Done --Tobias1984 (talk) 09:04, 26 July 2013 (UTC)

Observatory code (en) / Код обсерватории (ru)

Done: Minor Planet Center observatory code (P717) (Talk and documentation)

Description	Observatory code assigned by the Minor Planet Center (Q522039)
Data type	String
Template parameter	"code" in en:template:Infobox observatory
Domain	Observatory items
Allowed values	numeric or alphanumeric code
Example	Simeiz Observatory (Q944482) => 094
Source	list of observatory codes (Q953917)
Proposed by	Art-top (talk) 21:41, 19 July 2013 (UTC)

Discussion: Support --Tobias1984 (talk) 08:06, 20 July 2013 (UTC); Support --Paperoastro (talk) 21:00, 20 July 2013 (UTC); Support — Ivan A. Krestinin (talk) 19:48, 21 July 2013 (UTC)

Done --Tobias1984 (talk) 09:12, 26 July 2013 (UTC)

Canmore ID (en) / identifiant Canmore (fr)=

Done: Canmore ID (P718) (Talk and documentation)

Description	ID in the Royal Commission on the Ancient and Historical Monuments of Scotland's Canmore database (buildings, sites, and ancient monuments of archaeological, architectural and historical interest in Scotland)
Data type	String
Template parameter	"2" in fr:template:RCAHMS
Domain	place
Example	Tantallon Castle (Q57803) => 56630
Source	http://canmore.rcahms.gov.uk/
Robot and gadget jobs	http://canmore.rcahms.gov.uk/en/site/$1/details/
Proposed by	Ayack (talk) 14:11, 19 July 2013 (UTC)

Discussion: Support--Kompakt (talk)

Done Ayack (talk) 14:31, 26 July 2013 (UTC)

type of railway / /

Not done

Data type	Multilingual text (not available yet)
Template parameter	Heavy Rail, Light Rail
Domain	railway
Example	examples
Source	Source

Support Danrok (talk) 23:54, 4 March 2013 (UTC)

Support --Hoff1980 (talk) 09:26, 10 March 2013 (UTC)

Question Why very different definition than the one given in , according to which datatype item seems to be possible? – The preceding unsigned comment was added by ? (talk • contribs).

Comment "item" seems the better choice as datatype. -- Docu at 12:07, 14 April 2013 (UTC)

Oppose This is already covered with instance of and subclass of. Joshbaumgartner (talk) 04:29, 9 May 2013 (UTC)

Comment This is an old proposal. I no longer support it. Danrok (talk) 00:06, 25 May 2013 (UTC)

Oppose: should be Item IMHO, and maybe it's already covered by instance of (P31)/subclass of (P279). --Ricordi samoa 22:33, 26 May 2013 (UTC)

Not done more cons than pros (as Danrok withdrawn his support for it). --Nightwish62 (talk) 19:26, 26 July 2013 (UTC)

type of terrain feature (en)

Not done

Description	Type of terrain feature - mountain, island, body of water etc.. Should not be used when the value is only political/administrative (towns, cities, provinces, states, countries, etc.).
Data type	Item
Domain	natural terrain features, landforms, and bodies of water
Allowed values	landforms or bodies of water
Example	Oahu (Q131347) => 'island', Manitoulin Island (Q654405) => 'island', Nettilling Lake (Q1132211) => 'lake', Mount Blue Sky (Q1950460) 'mountain'
Source	External references. There may be data on Wikipedia, not sure how feasible it is to extract automatically.
Robot and gadget jobs	Should or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.)
Proposed by	Filceolaire (talk)

Discussion

This property works with the 'located on terrain feature' property above.

Support as nominator. Filceolaire (talk) 07:41, 15 June 2013 (UTC)
Oppose for now. It seems to me this can be done with instance of (P31). Superm401 - Talk 17:33, 16 June 2013 (UTC)
Oppose per Superm401. —★PοωερZ_{_talk} 00:38, 17 June 2013 (UTC)
Oppose, redundant with instance of (P31) Emw (talk) 02:08, 17 June 2013 (UTC)

Not done --Nightwish62 (talk) 19:35, 26 July 2013 (UTC)

Chairperson (en)

Not done

Description	The name of the club's chairman
Data type	Item
Template parameter	en:template:Infobox football club chairman
Domain	organization (football clubs)
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Source	External reference, Wikipedia list article
Robot and gadget jobs	they should be allowed
Proposed by	Xaris333 (talk) 17:27, 5 May 2013 (UTC)

No reason to restrict this to football clubs. I don't believe we have a chairman property. --Jfhutson (talk) 18:41, 5 May 2013 (UTC)

I agree. Thats why i named it Organization chairman. Xaris333 (talk) 19:09, 5 May 2013 (UTC)

Comment Simply 'chairperson' is sufficient. Joshbaumgartner (talk) 03:40, 10 May 2013 (UTC)

Comment - Property:P488 was created on 4. May 2013. It was just not added to the list of properties. --Tobias1984 (talk) 10:42, 18 May 2013 (UTC)

Oppose We already have the chairperson (P488) property. Danrok (talk) 00:27, 28 June 2013 (UTC)

Not done a general property "chairman" was created right before this proposal --Nightwish62 (talk) 19:49, 26 July 2013 (UTC)

Notable Incident

Done: no label (P719) (Talk and documentation)

Description	a link to a notable incident involving that item. Intended for use with Airlines and also buildings such as the Chernobyl Nuclear Power plant. Note that it should be used on the power plant in this example, not on the town of Chernobyl. Criteria to determine its notability would include, naturally, that it has a Wikdata item and one or more of the following: Resulted in loss of life Resulted in significant injury to multiple persons Resulted in an excess of a certain amount of financial damages Causes significant environmental, economic, cultural and/or political damage (i.e Deepwater Horizon)
Data type	Item
Domain	events
Example	Fukushima Daiichi Nuclear Power Plant > Fukushima Daiichi nuclear disaster
Proposed by	Macadamia1472 (talk) 09:32, 23 March 2013 (UTC)

Support --Nightwish62 (talk) 09:47, 19 April 2013 (UTC)

Comment This property seems useful. However, the criteria outlined in the proposal really describes a disaster, not merely an incident. The word "incident" often has a neutral connotation or implies a minor negative event. (In "diplomatic" terms, however, "incident" often implies something serious, but not of the nature described in the proposal.) Given that, I would suggest changing the label to 'disaster affecting'. Emw (talk) 14:32, 20 April 2013 (UTC)

Support Seems useful.--Micru (talk) 04:50, 25 June 2013 (UTC)

Done --Nightwish62 (talk) 21:45, 26 July 2013 (UTC)

superfamily

Not done

Description	'Superfamily' in biological taxonomy. Family and others exist as a property.
Data type	Item
Template parameter	Part of the template system on English Wikipedia. More complicated than just a single parameter. See https://en.wikipedia.org/wiki/Template:Automatic_taxobox and e.g. https://en.wikipedia.org/wiki/Template:Taxonomy/Coelophysoidea
Domain	Other taxons (i.e. family and possibly below)
Allowed values	Superfamilies, but presumably not enforced, so item
Example	https://en.wikipedia.org/wiki/Template:Taxonomy/Coelophysoidea
Source	https://en.wikipedia.org/wiki/Template:Taxonomy/Coelophysoidea
Robot and gadget jobs	Could probably be migrated from English Wikipedia
Proposed by	Superm401 (talk) 23:01, 31 March 2013 (UTC)

Weak oppose Each node in a taxon's classification is deducible through the parent taxon (P171) property, or, as I argue at that property's RFD, the preferable subclass of (P279) property. In my opinion the current listing of all taxonomic ranks on many taxon items is redundant and sets a bad precedent. It seems like Lua or Wikidata queries would be a much better approach to get that chain of values, rather than listing them all out explicitly in hundreds of thousands of taxon items. Emw (talk) 23:33, 31 March 2013 (UTC)
Fair enough. It should be consistent though, so if we're not going to have superfamily, we should remove family, etc. My only concern with parent taxon is that it can be unclear until you actually go to the parent. Is it a superfamily or an order (it depends)? I realize this can be inferred (and maybe eventually displayed) automatically if the parent is properly marked, so this isn't a major obstacle. There is a case to be made that the indeterminate number of ranks makes your proposal better. Superm401 (talk) 05:28, 1 April 2013 (UTC)
Not sure if this is what you meant, but I believe the taxon rank property solves that problem. Emw (talk) 11:58, 1 April 2013 (UTC)
Oppose, also per the discussion at Wikidata:Requests for comment/Inheritance of taxon ranks. --Izno (talk) 22:37, 26 July 2013 (UTC)

Not done --Tobias1984 (talk) 08:10, 27 July 2013 (UTC)

color index (en)

Not done

Description	en:color index, included U−B, B−V, V−R, R−I, J−H, J−K
Data type	Number (not available yet)
Template parameter	en:Template:Starbox observe
Domain	term
Example	Algol (Q13080)=>−0.37 (U−B), −0.05(B−V)
Proposed by	GZWDer (talk) 11:04, 8 July 2013 (UTC)

Discussion: duplicate - Pretty sure this is a duplicate of Wikidata:Property_proposal/Pending#Color_index. Not sure if the color-index-filter property has been proposed yet. --Tobias1984 (talk) 11:17, 8 July 2013 (UTC); duplicate, as Tobias1984: a color index property was already approved. Here there is my proposal to a color-index-filter property --Paperoastro (talk) 18:43, 20 July 2013 (UTC)

Not done --Tobias1984 (talk) 08:12, 27 July 2013 (UTC)

Asteroid spectral types (en) / Classification spectrale des astéroïdes (fr)/ Classificazione spettrale degli asteroidi (it)/ Tipo espectral des asteroides (es)

Done: asteroid spectral type (P720) (Talk and documentation)

Description	spectral classifications of asteroids based on spectral shape, color, and albedo
Data type	Item
Template parameter	en:template:Infobox planet spectral_type
Domain	astronomical object (Q6999): asteroid (Q3863)
Allowed values	A type (Q2038808), B type (Q2085153), C-type asteroid (Q729623), D-type asteroid (Q1814074), E type (Q987331), F type (Q1095693), G-type asteroid (Q2009707), J-type asteroid (Q2316414), K-type asteroid (Q2583913), L-type asteroid (Q2583904), M-type asteroid (Q847310), O-type asteroid (Q392659), P-type asteroid (Q2373252), Q-type asteroid (Q2449449), R-type asteroid (Q2449442), S-type asteroid (Q543157), T-type asteroid (Q2583884), V-type asteroid (Q1400344), X-type asteroid (Q2314759)
Example	4 Vesta (Q3030) => V-type asteroid (Q1400344)
Source	Small-Body Database of the Jet Propulsion Laboratory (e.g. 4 Vesta)
Robot and gadget jobs	constraint of allowed values
Proposed by	Paperoastro (talk) 20:50, 14 July 2013 (UTC)

Discussion

But where can we find asteroid type? What source?--Ahonc (talk) 13:26, 16 July 2013 (UTC)

You are right! I added a source. --Paperoastro (talk) 07:39, 17 July 2013 (UTC)

Support --Art-top (talk) 21:12, 20 July 2013 (UTC)
Support --Tobias1984 (talk) 09:28, 24 July 2013 (UTC)

Done --Tobias1984 (talk) 08:14, 27 July 2013 (UTC)

Screen size (en) / Bildschirmgröße (de)

Not done

Description	the diagonal screen size
Data type	Number (not available yet)
Domain	devices with a screen (for example computers or smartphones)
Example	Nexus 4 => 4.7 '' Nexus 4 => 11,938 cm
Robot and gadget jobs	A bot can search in the wikis for the screen size value in tables.
Proposed by	88.65.195.123 11:14, 30 June 2013 (UTC)

Discussion: Support --Nightwish62 (talk) 22:39, 30 June 2013 (UTC); Oppose Oppose without a general concept of size definition of object. Because there are plenty of other length parameters which can be used to describe an object and only a general concept can avoid the creation of specialized properties. Why not a property "Dimension" and a qualifier "element" which can be used for screen but other characteristics too ? Snipre (talk) 11:35, 1 July 2013 (UTC); Oppose --Tobias1984 (talk) 20:22, 25 July 2013 (UTC)

Not done --Tobias1984 (talk) 08:19, 27 July 2013 (UTC)

Apparent magnitude (en)

Not done

Description	en:Apparent magnitude
Data type	Number (not available yet)
Template parameter	en:Template:Starbox observe
Domain	term
Example	Algol (Q13080)=>2.12
Proposed by	GZWDer (talk) 11:04, 8 July 2013 (UTC)

Discussion

duplicate a property apparent magnitude was already approved --Paperoastro (talk) 18:37, 20 July 2013 (UTC) Not done --Tobias1984 (talk) 08:21, 27 July 2013 (UTC)

National_Library_of_the_Czech_Republic ID (en) / záznam v Národní knihovně ČR (cs)

Done: NL CR AUT ID (P691) (Talk and documentation)

Description	ID for searching for publications from/about
Data type	String
Template parameter	cs:template:NK ČR
Domain	mainly person, other too
Example	Q9065647 => [1] Q57434 -> [2]
Source	http://aleph.nkp.cz/F/
Robot and gadget jobs	Should be added by bots.
Proposed by	JAn Dudík (talk) 09:49, 3 July 2013 (UTC)

Discussion

Support --Tobias1984 (talk) 12:41, 3 July 2013 (UTC)
Support. Very useful indeed. -- Blackcat (talk) 14:27, 7 July 2013 (UTC)
Support + Comment: Not sure if I understand the “example” value correctly, but the property on Wikidata should definitely not contain URLs. It should contain just the authority file identifier, e.g. “jk01011783”, or “jn19990218045”, and it should be rendered as a link leading to http://aut.nkp.cz/$1, e.g. http://aut.nkp.cz/jk01011783 or http://aut.nkp.cz/jn19990218045. --Mormegil (talk) 20:54, 15 July 2013 (UTC)
- Support for Mormegil's version.--Shlomo (talk) 22:29, 16 July 2013 (UTC)
Done Property:P691 JAn Dudík (talk) 07:38, 17 July 2013 (UTC)

Origin

Not done

Description	The city from which the singer or group originated
Data type	Item
Template parameter	Origin parameter in Template:Infobox musical artist
Domain	Musical artists or groups
Allowed values	City, but if not known, country
Example	The Beatles → Liverpool, England
Source	Template:Infobox musical artist
Proposed by	Frigid Ninja

Surprised this isn't already used. Frigid Ninja 23:58, 7 April 2013 (UTC)

Oppose. For an individual, I think it's too subjective (birthplace, location of first gig, location of first recording studio?, etc.). For an organization (including but not limited to a band), it should be more definite (where did the group form), but I think we can do a more general property. See below. Superm401 - Talk 17:29, 8 April 2013 (UTC)

Support for artist groups,

Oppose for individuals. People usually start a group by meeting somewhere (Internet being an exception). --NaBUru38 (talk) 19:10, 18 April 2013 (UTC)

Oppose per Superm401 that it can be better accomplished with more clearly defined properties. Joshbaumgartner (talk) 10:50, 9 May 2013 (UTC)

Oppose Danrok (talk) 01:08, 17 June 2013 (UTC)

Not done --Tobias1984 (talk) 08:42, 27 July 2013 (UTC)

OKATO / ОКАТО

Done: OKATO ID (P721) (Talk and documentation)

Description	OKATO (Q856636)
Data type	String
Template parameter	ru:Шаблон:НП-Россия ОКАТО/Цифровой идентификатор
Domain	населённые пункты России / Russian populated places
Example	Kuznetsovka (Q1063777) <ОКАТО> 80228825007
Format and edit filter validation	11 цифр
Source	карточки, сама база
Robot and gadget jobs	Wikidata:Database reports/Constraint violations
Proposed by	— Ivan A. Krestinin (talk)

Discussion

Support. It is an important geographical code that identifies every populated place in Russia. But it also can be used for an administrative divisions too, so I propose to include them to the domain of this property. --Emaus (talk) 21:41, 13 July 2013 (UTC)
Oppose Do you want to create codes for each country? Many countries have codes of administrative divisions and/or places. For example for Russian it is ОКАТО, for Ukraine it is КОАТУУ, for Kazakhstan — КАТО, for PRC — 中华人民共和国行政区划代码, for Kyrgyzstan — СОАТЕ, for Uzbekistan — СОАТО, for USA — FIPS codes etc. So I suggest that we should create general element for all countries, for example: Code of place or administrative division.--Ahonc (talk) 22:05, 13 July 2013 (UTC)
In Russia we have some different geographical codes: OKATO, OKTMO, KLADR. Are you sure that chinese 中华人民共和国行政区划代码 is the same thing as russian OKATO? --Emaus (talk) 22:30, 13 July 2013 (UTC)
I do not know exactly, but English Wikipedia says that they are similar, see en:OKATO#See_also.--Ahonc (talk) 23:05, 13 July 2013 (UTC)
The codes have different format (it is critical for {{Constraint:Format}}), different holder organization (for MediaWiki:Gadget-AuthorityControl.js), they are unique for every code, but not unique for all codes ({{Constraint:Unique value}}), it is hard to manage one common property because you must not forget specify qualifier of code type. And we already have properties for other countries: INSEE municipality code (P374), CBS municipality code (P382), dantai code (P429), dantai code (P429), German municipality key (P439), China administrative division code (P442) and other. — Ivan A. Krestinin (talk) 06:01, 14 July 2013 (UTC)

Done: OKATO ID (P721) (Talk and documentation)

Description	link to OKATO (Q856636) (Russia)
Data type	String
Template parameter	"цифровой идентификатор" in ru:template:НП-Россия
Domain	Objects of administrative division in Russia (main type - place)
Allowed values	a set of numbers separated by spaces
Example	Gatchina (Q7436) => OKATO 41 420
Source	[3], [4]
Proposed by	Art-top (talk) 21:26, 19 July 2013 (UTC)

Discussion: Support--Kompakt (talk); Comment See Wikidata:Property proposal/Place#OKATO / ОКАТО — Ivan A. Krestinin (talk) 10:37, 26 July 2013 (UTC)

Done --Tobias1984 (talk) 15:35, 28 July 2013 (UTC)

UIC station code

Done: UIC station code (P722) (Talk and documentation)

Description	UIC ids are used by railway operators to refer to railway stations in Europe.
Data type	String
Domain	train stations
Example	Gare de Nantes has UIC code 8721351
Format and edit filter validation	UIC station reference always consists of 7 digits, beginning with a 2-digit UIC country code
Proposed by	Ske (talk) 21:35, 25 April 2013 (UTC)

Support See also discussion below.--Ahonc (talk) 13:23, 22 May 2013 (UTC)
Support looks good to me. Danrok (talk) 15:35, 22 May 2013 (UTC)
Support. For every country where it is used, not only Europe. --Emaus (talk) 22:02, 13 July 2013 (UTC)

Done --Tobias1984 (talk) 15:35, 28 July 2013 (UTC)

Historic name

Description: Historic name(s) of the location (possibly tagged by language)
Datatype: Text
Links:
Infobox parameter example:
Comments: I am not sure if this is covered by "Also known as" or not; Q914 has "also known as: Stalingrad", but if we had a property for the name we could say Tsaritsyn 1589-1925, Stalingrad 1925-1961. Andrew Gray (talk) 18:37, 26 February 2013 (UTC)
Support the idea. I tend to think aliases can't replace a property like this. They are not "structured", and moreover their contents serve numerous purposes (abbreviations, variations, ease of lookup within the Wikidata UI); and they can't be qualified for a time period, for example; so yes, support. Espeso (talk) 20:21, 26 February 2013 (UTC)

Weak oppose Wouldn't people without a doubt add the relevant years behind the historic name? That could get messy. In that case, it would perhaps be a better idea to wait until a datatype enabling the combination of time values and text is introduced. Does anyone know if such a feature is being planned? - Ssolbergj (talk) 03:53, 27 February 2013 (UTC)

Support I don't really understand the objection -- there's lots of stuff on the list and proposed that could and probably should be modified by "relevant years." Coaches? Yes. Stadiums of teams? Yup. Headquarters (which I had suggested). Ditto. Mayors. Heads of national governments. And on and on and on. There's a vast past to everything, and a single name change is small potatoes. Shawn in Montreal (talk) 04:00, 27 February 2013 (UTC)
Support Agree it does need qualifiers, i.e. Stalingrad; from 1925 to 1961. But so do many existing properties, so that should not impede this property. Danrok (talk) 04:03, 27 February 2013 (UTC)
Oppose per Ssolbergj. Better do it right from the start that proliferate a bunch of half-cooked values which will all need to be verified/expanded later.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:18 (UTC)
Support Maybe it would have been better not to start with a half-baked system, but that's what we have. The lack of much support for recording sources is a much bigger problem than missing dates would be here. There's still some value to a collection of historic names, even without their associated dates. --Avenue (talk) 08:24, 13 March 2013 (UTC)
Support per usual "there will be qualifiers" argument. However, you could also argue that a historic place is "different from" the current place (e.g. city) and deserves its own item, so that if a person was born in Stalingrad, then it reads that they were born in... Stalingrad. Frankly, that would be a more robust solution, since you could record the history of that entity in other ways as well. Espeso (talk) 18:51, 13 March 2013 (UTC)
Oppose as String; weak Support as multilingual text. -- MichaelSchoenitzer (talk) 22:07, 13 March 2013 (UTC)
Oppose This should be done via the "Official Name" (or maybe "Local Name") properties (See Generic proposals) with date qualifiers. Filceolaire (talk) 20:01, 6 April 2013 (UTC)
Support --Чаховіч Уладзіслаў (talk) 12:52, 19 May 2013 (UTC)
Oppose -- as told Filceolaire: this should be done using "Official Name" property, approved with multilingual text datatype, with date qualifiers. --Paperoastro (talk) 11:07, 5 June 2013 (UTC)
Comment I think place names need form a timeline, have explicit language versions and relate to geographic areas the named entities cover in given times. Maybe changes should be explicitly stated: merge, split. etc. with dates. I cannot say if Historic name is the right way. --Susannaanas (talk) 13:53, 7 June 2013 (UTC)
Oppose -- as told Filceolaire. Snipre (talk) 19:14, 10 June 2013 (UTC)
Oppose. --Yair rand (talk) 19:15, 10 June 2013 (UTC)

Not done --Tobias1984 (talk) 16:11, 28 July 2013 (UTC)

Geography / Géographie / Geographie / Geografia (pt)

Description: geography of the place (country, state, town, ...)
Datatype: Item
Links:
Infobox parameter example:
Comments:It can link to the geography article about the place. Like Portugal --» Geography of Portugal. It can also be created to other topics. I don't think that this could be used in a Infobox. It can be useful because it links the topic to the subtopic. - Sarilho1 (talk) 15:43, 24 March 2013 (UTC)
- Comment: Do you think we have to do this for every subject? Will we add properties for each subarticle of Wikipedia articles? We have P:P358 for discography of music artists or groups already. I supported it, but now I think this will grow exponentially, and I'm worried. --NaBUru38 (talk) 20:07, 27 March 2013 (UTC)

If you prefer we can rename to Subtopics. I don't know! I was just trying to create a property that seams useful to me. - Sarilho1 (talk) 12:19, 28 March 2013 (UTC)

I understand your view, it does help to list subarticles. But we must find a reasonable way to do it, and I'm not sure which is. --NaBUru38 (talk) 18:53, 18 April 2013 (UTC)

Not done --Tobias1984 (talk) 16:13, 28 July 2013 (UTC)

Rivers / Flüsse / rivières

Status: Done

→ Property:P469

(Sorry for putting in this in German at the moment, will translate later. I've taken this from the German Infobox which appearantly is the most developped river infobox I am aware of.)

GKZ Zahl Gewässerkennzahlen des Flusses in der Form ISO-3166-1-Code/ID1[/ISO-3166-1-Code/ID1...] (Beispiel: DE/2/CH/5 ergibt DE: 2, CH: 5). Implementiert sind derzeit die ISO-Kodes AT, BE, CH, CZ, DE, FI, FR, LU, RU, US.
- Comment each identifier on de:Gewässerkennzahl should probably be a separate property with datatype "string". -- Docu at 19:18, 9 June 2013 (UTC)

FLUSSSYSTEM Text Es wird nur der Fluss angegeben, der für das Gesamtflusssystem namensgebend ist. Die Eingabe erfolgt nach EBNF-Syntax:
ABFLUSSWEG Text Mit diesem Parameter wird der Abflussweg bis zum Flussende (in der Regel das aufnehmende Meer) spezifiziert, d.h. es werden alle Flüsse angegeben, die den Abflussweg bilden. Wenn der Fluss in ein Meer mündet, dann wird dieses auch angegeben werden. Es werden maximal 10 Angaben in der Infobox dargestellt.
ABFLUSSWEG = { Lemma "/" [ Darstellung ] "/" } ("/" am Ende können entfallen)
FLUSSGEBIETSEINHEIT Text Flussgebietseinheit der europäischen Wasserwirtschaftrichtlinie, falls abweichend vom Flusssystem.
BEZEICHNUNG-QUELLE Text Anders lautende Bezeichnung für Quelle (z.B. Ursprung) (optional)
QUELLE Text Quelle des Flusses, auch für die Quellflüsse (siehe dazu Beispiel unten) und Ausfluss aus Seen (Wartungsseite). Fehlt diese Angabe, dann werden keine Quellkoordinaten angezeigt.
QUELLE_LAT_GRAD Text Angabe der Geographischen Breite (Gradangabe). Eine Angabe gemäß Vorlage:Coordinate, also etwa 45/10/10/N, ist möglich. Die anderen Angaben zum Breitengrad müssen dann entfallen.
QUELLE_LONG_GRAD Text Angabe der Geographischen Länge (Gradangabe). Eine Angabe gemäß Vorlage:Coordinate, also etwa 10/10/10/E, ist möglich. Die anderen Angaben zum Längengrad müssen dann entfallen.
QUELLE_REGION Text Angabe von Land und Region nach ISO-3166-1 und ISO 3166-2.
QUELLE_AUFLÖSUNG Zahl Angabe der Größe in Meter
QUELLHÖHE-PREFIX Text Prefix zur Quellhöhe (optional)
QUELLHÖHE Zahl Höhenlage des Quellortes in Metern ohne Einheit
HÖHENBEZUG-QUELLE Text Höhenbezug der Quelle (gemäß Vorlage:Höhe)
QUELLHÖHE-SUFFIX Text Suffix zur Quellhöhe. (optional)
NACHWEIS-QUELLHÖHE Text Einzelnachweis für die Quellhöhe.
QUELLSCHÜTTUNG Text Angabe der Messwerte. Die Eingabe erfolgt nach EBNF-Syntax:

QUELLSCHÜTTUNG = [NNQ] "/" [NNQ-DATUM] "/" [MNQ] "/" [MQ] "/" [MHQ] "/" [HHQ] "/" [HHQ-DATUM] "/"

Die Bedeutung der einzelnen Angaben:

    NNQ - niedrigste, gemessene Abflussmenge (in m³/s)
    NNQ-Datum - Datum des NNQ
    MNQ - Mittlerer Abfluss bei Nierigwasser (in m³/s)
    MQ - Mittlerer Abfluss (in m³/s)
    MHQ - Mittlerer Abfluss bei Hochwasser (in m³/s)
    HHQ - höchste, gemessene Abflussmenge (in m³/s)
    HHQ-Datum - Datum des HHQ

QUELLSCHÜTTUNG-REIHE Text Messreihe für die Quellschüttung (Beispiel: "1960/2005").
NACHWEIS-QUELLSCHÜTTUNG Text Einzelnachweis für die Quellschüttung.
BEZEICHNUNG-MÜNDUNG Text Anders lautende Bezeichnung für Mündung (z.B. Zusammenfluss) (optional)
MÜNDUNG Text Mündung des Flusses. Fehlt diese Angabe, dann werden keine Mündungskoordinaten angezeigt. (Wartungsseite)
MÜNDUNG_LAT_GRAD Text Angabe der Geographischen Breite (Gradangabe)
MÜNDUNG_LONG_GRAD Text Angabe der Geographischen Länge (Gradangabe) (Wartungsseite)
MÜNDUNG_REGION Text Angabe von Land und Region nach ISO-3166-1 und ISO 3166-2.
MÜNDUNG_AUFLÖSUNG Zahl Angabe der Größe in Meter. Dieser Parameter beeinflusst den Anfangsmaßstab einer externen Kartenansicht (Siehe Parameter dim in der Vorlage:Coordinate)
MÜNDUNGSHÖHE-PREFIX Text Prefix zur Mündungshöhe (optional)
MÜNDUNGSHÖHE Zahl Höhenlage der Flussmündung in Metern ohne Einheit (Wartungsseite)
HÖHENBEZUG-MÜNDUNG Text Höhenbezug der Mündung (gemäß Vorlage:Höhe) (Wartungsseite)
MÜNDUNGSHÖHE-SUFFIX Text Suffix zur Mündungshöhe. (optional)
NACHWEIS-MÜNDUNGSHÖHE Text Einzelnachweis für die Mündungshöhe.
HÖHENUNTERSCHIED Zahl Höhenunterschied zwischen Quellhöhe und Mündungshöhe (Wartungsseite)
LÄNGE Zahl Die Länge des Flusses (Wartungsseite)
NACHWEIS-LÄNGE Text Einzelnachweis der Länge als Referenzangabe (Wartungsseite)
LÄNGE-PREFIX Text Präfix für die Längenangabe. (optional)
LÄNGE-SUFFIX Text Suffix für die Längenangabe (optional). Die Angabe wird nach dem Nachweis dargestellt. Für die Darstellung weiterer Längenangaben kann hier die Vorlage:Infobox Fluss/LÄNGE eingesetzt werden (Beschreibung siehe Vorlage).
EINZUGSGEBIET Zahl Größe des Einzugsgebiets des Flusses im km² (Wartungsseite)
EINZUGSGEBIET-PREFIX Zahl Präfix für die Angabe des Einzugsgebietes. (optional)
NACHWEIS-EINZUGSGEBIET Text Einzelnachweis für das Einzugsgebiet als Referenzangabe (Wartungsseite)
EINZUGSGEBIET-SUFFIX Text Suffix für die Angabe des Einzugsgebietes (optional). Die Angabe wird nach dem Nachweis dargestellt.
PEGEL1 Text Angabe der Pegelhauptwerte. Die Eingabe erfolgt nach EBNF-Syntax:

PEGEL1 = [<NAME>] "/" [<LoM>] "/" [<EZG>] "/" [NNQ] "/" [NNQ-DATUM] "/" [MNQ] "/" [MQ] "/" [MHQ] "/" [HHQ] "/" [HHQ-DATUM] "/"

Die Bedeutung der einzelnen Angaben:

    NAME - Name des Pegels
    LoM - Lage oberhalb der Mündung (in km)
    EZG - Größe des Einzugsgebietes (in km²)
    NNQ - niedrigste, gemessene Abflussmenge (in m³/s)
    NNQ-Datum - Datum des NNQ
    MNQ - Mittlerer Abfluss bei Nierigwasser (in m³/s)
    MQ - Mittlerer Abfluss (in m³/s)
    MHQ - Mittlerer Abfluss bei Hochwasser (in m³/s)
    HHQ - höchste, gemessene Abflussmenge (in m³/s)
    HHQ-Datum - Datum des HHQ

PEGEL1-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL1 Text Einzelnachweis für die Pegelwerte.
PEGEL2 Text Angabe der Pegelhauptwerte. Siehe PEGEL1
PEGEL2-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL2 Text Einzelnachweis für die Pegelwerte.
PEGEL3 Text Angabe der Pegelhauptwerte. Siehe PEGEL1
PEGEL3-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL3 Text Einzelnachweis für die Pegelwerte.
ABFLUSS-NNQ Niedrigster je gemessener Abfluss in m³/s (Wartungsseite)
ABFLUSS-NNQ-JAHR Jahr des niedrigsten Abflusses
ABFLUSS-MNQ Mittlerer Abfluss bei Niedrigwasser in m³/s (Wartungsseite)
ABFLUSS-MQ Mittlerer Abfluss in m³/s (Wartungsseite)
ABFLUSS-MHQ Mittlerer Abfluss bei Hochwasser in m³/s (Wartungsseite)
ABFLUSS-HHQ Höchster je gemessener Abfluss in m³/s (Wartungsseite)
ABFLUSS-HHQ-JAHR Jahr des höchsten Abflusses

ABFLUSS-PEGEL Messstelle des Abflusses

NACHWEIS-ABFLUSS Nachweis für die Abflusswerte
LINKE NEBENFLÜSSE Linke Nebenflüsse
RECHTE NEBENFLÜSSE Rechte Nebenflüsse
SEEN Text Durchflossene natürliche Seen
STAUSEEN Text Durchflossene Stauseen
- These two should probably be grouped into one and whether a lake is natural or artificial could be derived from the lake item. Nikola (talk) 04:42, 8 March 2013 (UTC)
  - Done as Property:P469. -- Docu at 09:03, 27 April 2013 (UTC)
GROSSSTÄDTE Städte über 100.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
MITTELSTÄDTE Städte zwischen 20.000 und 100.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
KLEINSTÄDTE Wichtige Städte unter 20.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
- These three should probably be grouped in on property, "cities", "flows through", "passes through" and cities' sizes could be derived from the city item.
  But the cities should probably be ordered in the order the river flows, and I don't see any reasonable way of including this information. Nikola (talk) 04:42, 8 March 2013 (UTC)
GEMEINDEN Gemeinden entlang des Flusses (bei kleineren Flüssen). Gemeint ist die Ortschaft, nicht die Gemarkung.
EINWOHNER IM EINZUGSGEBIET Einwohnerzahl des Einzugsgebiets des Flusses
HÄFEN Binnenhäfen am Fluss

Comments
Comment I suggest you put the full list of parameters on the Wikidata:Infoboxes task force/places instead, and do the mapping to any current properties there. (Would it be possible to map these parameters to the corresponding English template parameter names?) At this page, please state the datatype of each parameter, and only include parameters that use the three currently defined parameters (monolingual text, item, media). Mange01 (talk) 19:38, 11 March 2013 (UTC)

Basin country - can use Property:P205--Ymblanter (talk) 15:36, 7 March 2013 (UTC)
A general question: do we want to have more general properties or less general properties? For example, for rivers, should we use "is in" to denote the watershed? Another example, should we have "passes through" (cities) that could be applied to roads and rivers? Nikola (talk) 16:46, 7 March 2013 (UTC)

Actually at least DE:WP is treating rivers and catchment areas differently; the Donau is not a river in Italy but its catchment area comprises parts of upper Italy. --Matthiasb (talk) 10:58, 8 March 2013 (UTC)

Status: Done

→ Property:P403

Comment I just created a section River in the list of properties, as there had been added already some properties without discussion or proposal:

property does not exist. Use "id=new" if it's to be created. property does not exist. Use "id=new" if it's to be created.

Title	ID	Data type	Description	Examples	Inverse
mouth of the watercourse	P403	Item	river mouth: none	[[d:Volga\|Volga]] <mouth of the watercourse> [[d:Caspian Sea\|Caspian Sea]]	-

Apart from these, perhaps there are some more? --Brühl (talk) 14:46, 8 April 2013 (UTC)

There are three more below. Your properties have a problem that the altitude can be measured in meters, and can be measured in feet, and we do not yet have a property which switches between the two.--Ymblanter (talk) 15:31, 8 April 2013 (UTC)

Note: The German Infobox expects numeric values for parameter QUELLHÖHE and MÜNDUNGSHÖHE (altitude) and a defined string for the height reference system (parameter HÖHENBEZUG-QUELLE and HÖHENBEZUG-MÜNDUNG). The altitude difference is calculate by the IB.--SteveK (talk) 18:03, 8 April 2013 (UTC)

Elevation / Höhe / Altitude

Not done

Description	Height of the mountain
Data type	String
Template parameter	(as in section name)
Domain	place (?)
Allowed values	numbers – we should choose one unit (meters) and if an infobox uses another unit it should convert it by itself
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Robot and gadget jobs	Collect data from wikipdia articles and paste to wikidata; report cases of conflict somewhere.
Proposed by	Kaligula (talk)

Discussion

This should be useful (as well as e.g. depth of a lake od sea). Kaligula (talk) 19:28, 27 April 2013 (UTC)

Support Would be useful, is one of the main properties of a mountain. (Augapfel (talk) 08:41, 17 May 2013 (UTC))
Oppose Idea is good, but not with string datatype. We have to wait until numbers with units are available. --Pasleim (talk) 21:53, 24 May 2013 (UTC)

Not done --Tobias1984 (talk) 16:27, 28 July 2013 (UTC)

minister of

Not done

Description	subject holds/held ministry office at object (minister, pastor, imam, etc.)
Data type	Item
Template parameter	"churches" in en:template:infobox minister of religion
Domain	person
Allowed values	religious organizations (churches, mosques, etc.)
Example	Huldrych Zwingli => Grossmünster
Proposed by	Jfhutson (talk)

Discussion

Information regarding the churches and other religious organizations where the person was designated the minister or other religious ministerial office. Often there is no named office for which you could use Property:P39. Jfhutson (talk) 02:07, 9 May 2013 (UTC)

Oppose member of with qualifiers office held, occupation, or role can fulfill this task, e.g. Gordon B. Hickley member of The Church of Jesus Christ of Latter-day Saints office held President of the Church. Joshbaumgartner (talk) 10:21, 9 May 2013 (UTC)

Comment if there is no item for the office, you can just create the item. Here's one I made earlier: Q13360127. Danrok (talk) 21:06, 21 May 2013 (UTC)

Oppose per Joshbaumgartner Snipre (talk) 18:51, 10 June 2013 (UTC)

Not done --Tobias1984 (talk) 16:53, 28 July 2013 (UTC)

DBNL-id

Done: Digitale Bibliotheek voor de Nederlandse Letteren author ID (P723) (Talk and documentation)

Description	reference to the DBNL-website http://www.dbnl.org/ for Dutch language authors.
Data type	String
Template parameter	put Wikipedia infobox parameters here. If existing, sample: "dbnl" in nl:sjabloon:infobox auteur
Domain	person, authors (writers, poets, etc)
Example	Q2359791 -> star003
Proposed by	Edoderoo (talk)

Discussion

This field links to an official external website with more information about Dutch language authors, and is currently used on many writers on the Dutch Wikipedia. Edoderoo (talk) 13:34, 30 June 2013 (UTC)
Support--Micru (talk) 01:42, 8 July 2013 (UTC)
Support —Ruud 08:23, 17 July 2013 (UTC)
Support--Kompakt (talk) 08:52, 26 July 2013 (UTC)
Support -- 93.232.235.92 10:28, 28 July 2013 (UTC)

Done --Tobias1984 (talk) 18:16, 28 July 2013 (UTC)

Dodis

Done: Dodis ID (P701) (Talk and documentation)

Description	Identifier in the dodis database (Diplomatic Documents of Switzerland 1945-1969), see Diplomatic Documents of Switzerland (Q661051)
Data type	String
Template parameter	Template:Dodis (Q12064410)
Domain	all: persons, organisations, terms, ..
Example	Henri Guisan (Q123497) = P495
Proposed by	- Vacallo (talk) 05:15, 10 June 2013 (UTC)

Done--GZWDer (talk) 15:30, 19 July 2013 (UTC)
archived --Tobias1984 (talk) 09:15, 29 July 2013 (UTC)

Airbase

Not done

Description	Airbase used by a military or other organization
Data type	Item
Domain	organization
Example	United States Air Force -> airbase -> Andrews Air Force Base
Proposed by	Joshbaumgartner (talk)

Oppose Better do the inverse: add in each airbase item the name of the army using the base. Think of property like a characterization of the item: the US Air Force is not defined by its airbases. So the use of property "part of" for all airbases will be enough. Snipre (talk) 09:24, 12 May 2013 (UTC)

For the air base item, I think operator (P137) is best. Danrok (talk) 00:19, 28 June 2013 (UTC)

Not done --Tobias1984 (talk) 09:17, 29 July 2013 (UTC)

Portal topic (en)

Not done

Description	main topic of portal
Data type	Item
Domain	portals
Example	Portal:Oceania => Oceania
Proposed by	Ypnypn (talk) 15:29, 3 June 2013 (UTC)

Discussion

I don't see how such a property will be useful. What is the reason for this proprosal? Byrial (talk) 22:06, 10 June 2013 (UTC)
Oppose I don't like the idea of using property to do the categorization work of wikipedias: this assumes an uniform categorization among the wikipedias and as we can see it for the articles there is not an unique way to divide and categorize the topics. Snipre (talk) 23:02, 10 June 2013 (UTC)
Comment Before we can create something like this we should decide whether the Portal namespace should be even linked to the content namespace. Or in general which namespaces to consider. I think User was already declined. But in general I think that centralizing categories would be a good idea. --Tobias1984 (talk) 09:51, 11 June 2013 (UTC)

Not done --Tobias1984 (talk) 09:18, 29 July 2013 (UTC)

Minister/ Kirchliches Amt/Ministère Q1423891

As Property:P39 but describing the position held in a church hierarchy. For example _Walter Kasper Q44100 is classified "office held: cardinal of the Roman Curia" but in German it is "Politisches Amt:Kurienkardinal" or just a bad translation?--Giftzwerg 88 (talk) 14:20, 21 March 2013 (UTC)

P39 is in discussion to widen up the use of this property to non political offices, so there is no need für an extra property. Please contribute to Property_talk:P39. --Giftzwerg 88 (talk) 11:28, 4 May 2013 (UTC)

Not done --Tobias1984 (talk) 09:22, 29 July 2013 (UTC)

monuments / Memorial Hall / Memorial_Building (en) / 纪念碑/纪念馆/纪念建筑 (zh)

Not done

Description	Memorial Hall / Memorial_Building etc.
Data type	Item
Domain	person
Example	Q8573 => Q1051254
Proposed by	GZWDer (talk) 13:15, 29 May 2013 (UTC)

Discussion

Oppose We have commemorates (P547) and named after (P138) on the objects' side.--Kompakt (talk) 05:55, 30 May 2013 (UTC)

Not done --Tobias1984 (talk) 09:23, 29 July 2013 (UTC)

Blood Type (en) / 血液型 (ja)

Not done

Description	blood type of the person
Data type	Item
Domain	person
Allowed values	A,B,AB,O
Example	Q249719 => No wikidata entry for each blood type must be created
Format and edit filter validation	none
Source	This is usually used for east asian wikipedia, I guess it is important for them to know the blood type
Robot and gadget jobs	I guess this could be done and retrieved from wikipedia entry, usually from japanese, korean, chinese entry
Proposed by	Napoleon.tan (talk) 01:32, 19 June 2013 (UTC)

Discussion

--Napoleon.tan (talk) 01:32, 19 June 2013 (UTC)

Oppose This is against the private data policy of a lot of countries about medical data. Snipre (talk) 11:55, 2 July 2013 (UTC)

Not done --Tobias1984 (talk) 09:24, 29 July 2013 (UTC)

album cover

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus, not done. Sven Manguard Wha? 04:35, 19 June 2013 (UTC)

Not done

Description	An image that represents the cover image of an album.
Data type	Item
Template parameter	Used in w:Template:Infobox album. cover
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Source	Album infoboxes, Musicbrainz

Discussion

Support Danrok (talk) 03:49, 27 February 2013 (UTC)
Weak oppose unless I'm overlooking a lot of "free" album covers. Fair use images won't be available for linking, since they're not on Commons... Espeso (talk) 15:53, 27 February 2013 (UTC)

Good point. I think many will eventually lose copyright status. But we're a bit premature for that. Danrok (talk) 17:20, 28 February 2013 (UTC)

Support Even if there are not many album covers, this doesn't mean that we cannot have such property. --Viscontino ^talk 10:23, 26 March 2013 (UTC)
Oppose I don't know any album articles, where the cover is from Commons... there is not many, so I think that this is not so useful. --Stryn (talk) 17:18, 26 March 2013 (UTC)
Support there are 300+ images in commons:Category:Album covers, not many, but I think this property is still needed --Stevenliuyi (talk) 17:38, 26 March 2013 (UTC)
Support, but you will need a lot of luck to get covers! --NaBUru38 (talk) 19:44, 27 March 2013 (UTC)
Support, no reason why it shouldn't exist, even if there are 'only' 300+ images. --Nightwish62 (talk) 13:06, 29 March ~2013 (UTC)
Oppose Use the generic property Property:P18: for an album this are not several associated images. Snipre (talk) 09:57, 2 April 2013 (UTC)

What's in situation when P18 is used more than once for an album, not all showing the album cover? E.g. one showing a picture while the record session or the building of the record studio, or a picture from the release event, notes from a song, sales charts, etc.? --Nightwish62 (talk) 09:44, 6 April 2013 (UTC)

A property like that should only be used if its really and directly related to the article. A photo like you described has "nothing" to do with the album itself and should generally not be linked here on Wikidata, thats would be the job of Commons and its categories. --#Reaper (talk) 21:33, 30 April 2013 (UTC)

Support but we should keep an eye out, to help Commons (so people don't upload non-free covers and use this). Superm401 - Talk 21:49, 6 April 2013 (UTC)

Oppose I quote Snipre --★ → A ir on 90 10:57, 7 April 2013 (UTC)
I agree with Nightwish62. It's good to be specific that we mean the album cover. Other images can apply, particularly photos of them while recording. Superm401 - Talk 19:35, 7 April 2013 (UTC)
Support Non-free images are available for linking, and we'd need this to associate them with their respective albums (or singles, etc). This is an example of an item of an album cover: Q10772612. We need this and another property to make the link back. — ΛΧΣ²¹ 07:22, 9 April 2013 (UTC)
Oppose I think too, Property:P18 is good for that. Picture of an album is pretty clear. Never saw a picture of recordiung an album or something like that on Commons.--CENNOXX (talk) 18:49, 9 April 2013 (UTC)
- Comment It took me 5 seconds to find an example here (box set). There are many more like this. --Nightwish62 (talk) 10:36, 19 April 2013 (UTC)
- Comment Here an example with record studio and here one showing the original subject the cover is illustrating. --Nightwish62 (talk) 16:14, 19 April 2013 (UTC)
Oppose. Conny (talk) 14:30, 28 April 2013 (UTC).
Support I think that the album cover can be used later when they go out of copyright. --Napoleon.tan (talk) 12:24, 30 April 2013 (UTC)
Oppose redundant with P:P18 --#Reaper (talk) 21:33, 30 April 2013 (UTC)
Oppose - as per Reaper35. --Tobias1984 (talk) 12:40, 24 May 2013 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

GenPept

Not done

Description	GenPept (full) sequence from NCBI, EBI, GenomeNet etc.
Data type	I have no idea. Annotations on these files are in English, but it's not a "phrase" to be "pronounced".-invalid datatype (not in Module:i18n/datatype)
Domain	Proteins
Allowed values	Begins with "LOCUS", ends with "//"
Example	From [5] - Passed as parameter 1 inen:Template:ImportProtein/Src (gene)
Source	See [6] for a bit of the definition, or help for the example from NCBI below.
Robot and gadget jobs	en:Module:ImportProtein
Proposed by	Wnt (talk)

I've developed en:Module:ImportProtein that can create graphics from these text files. An example is presented inen:Src (gene). Wikipedia won't process these directly from NCBI, so if they are ever to be used, these lengthy files should be copied in full to Wikimedia somewhere. Logically Wikidata should handle this centrally, and they can then be transcluded into the #invoke from here. (I know little of Wikidata, so feel free to point out if I've missed something obvious!) Wnt (talk) 16:48, 16 April 2013 (UTC)

Data and references are mixed together: you have to separate them. Snipre (talk) 16:56, 18 April 2013 (UTC)

I was thinking of the whole file as the data, and the references mentioned in that file are part of it. You could subparse it into a hundred different features, but I don't even know how you edit a whole Wikidata entry at one time, so dealing with that kind of input as a hundred different properties/tags would be a nightmare. Wikidata already seems too organized to be useful when I can't just dump this data in without proposing one property for discussion. Wnt (talk) 01:30, 22 April 2013 (UTC)

Comment Which fields from the file do you actually need to create the graphics? Dumping entire structured files into simple strings is pretty much the antithesis of Wikidata which is about structured, linked data. Plus, there could be the issue of licensing depending on how much is copied and where from. Silver hr (talk) 19:08, 26 April 2013 (UTC)

I'm not happy with this response - to me, these files (which are US government works and PD) should best be used as intact properties. You'd have to break them up into all the individual fields otherwise, as many different properties - anything less than a full dissociation into all components would be an imperfect copy, and also more trouble to make. I guess I was under the wrong impression that Wikidata was a common repository of data to use, but from this, it seems to be a collaborative enterprise in creating some kind of limited association database I don't really understand, don't see how to practically edit, and don't know what to do with. Though there is one application I know of (the interlanguage links) it is clear that any idea how to use Wikidata needs to start here - I'm going to abandon any attempt to make use of it in writing modules. Wnt(talk) 01:07, 10 May 2013 (UTC)

The problem of your proposition is its dependency on the source format: if another source is providing data in another format (like in different files or using different annotations for identifying data parts) your proposition won't be able to manage the data. The correct procedure is to list all properties which can be found in your raw data file then find the appropriate properties in wikidata anf if you can't find one, you propose a new property, then parse the raw data in order to extract values for the properties and then fill item with the strutured data. Wikidata is not a simple data storage but wants to propose a data structure which avoid the need of data parsing each each time you do a query: with a structured data format you can directly match the data with your query. Snipre (talk) 08:26, 11 May 2013 (UTC)

@Wnt: If I understand this problem correctly you just have to split your program into two pieces. Right now your taking data and a program structures it and outputs a picture. The part of the program that structures the information would have to be the part that imports the data into Wikidata in a structured form. Your output function would then take the already structured data and only generate a picture from it. I hope you don't give up your problem, and I would suggest you talk to some of the people at Wikidata:Molecular_biology_task_force who are working (I think) on similar problems. --Tobias1984(talk) 13:01, 4 June 2013 (UTC)

This proposal will be deleted: This proposal will be deleted without modification in order to fit the wikidata structure (property.value instead of raw data, separation of data and sources,...) Snipre (talk) 11:47, 2 July 2013 (UTC)

I veto the deletion of this proposal. We can move it to "property proposal/term". The proposal is just a little ahead of its time. We need to work out a couple of other things until something like this can be handled properly. --Tobias1984 (talk) 12:01, 2 July 2013 (UTC)

It seems that some reformulation is needed: better delete the proposal until a better formulation is done. This will clear this page. Snipre (talk) 09:43, 29 July 2013 (UTC)

Not done --Tobias1984 (talk) 10:06, 29 July 2013 (UTC)

Internet Archive identifier

Done: Internet Archive ID (P724) (Talk and documentation)

Description	The Internet Archive is a non-profit digital library that provides permanent storage of and free public access to collections of digitized materials.
Data type	String
Domain	published works
Example	Frankenstein, or, The modern Prometheus (1831) <Internet Archive identifier> ghostseer01schiuoft
Proposed by	--Micru (talk) 00:47, 25 June 2013 (UTC)

Discussion

Support There are many sources in Commons that come from this site, it is also used in Wikipedia.--Micru (talk) 00:46, 25 June 2013 (UTC)
Support Aubrey (talk) 09:08, 29 June 2013 (UTC)

Done Ayack (talk) 10:38, 29 July 2013 (UTC)

type of settlement

Not done

Description	A complement to P132 (type of administrative division), for non-administrativ settlements like urban areas/CDP/hamlets/villages etc who has no administrative function.
Data type	Item
Template parameter	sv:template:Geobox category
Domain	p107:place
Example	urban areas/cdp's in Swedish/US-settlement and others who are not a city/municipality with a local administration.
Proposed by	Lavallen (block) 12:55, 6 April 2013 (UTC)

I will not forbid the use of P132 and this in the same item, they should complement each other, not exclude. -- Lavallen (block) 12:55, 6 April 2013 (UTC)

Comment. If we do it this way, we may also need properties for electoral circonsriptions, military divisions and various other things. I think it would be very relevant to merge them all in instance of. Instance of is supposed to tell what precisely the item is. In the case of an administrative division, its value should be equal to that of P132 anyway, so that no information will be lost. That will avoid questions like "is X and administrative division or not ?", and that would make the overall structure simpler, more scalable, and more flexible. --Zolo (talk) 13:21, 6 April 2013 (UTC)

I do not like the nature of "instance of", it's used for everything. If we can define a better usefull property for frequent cases, I think we should. I cannot even find a well-defined translation for "instance of" that makes sense for all the things it is used for. I do not propose "instance of" to be deleted, but that we should use it only when there is nothing better. -- Lavallen (block) 17:34, 6 April 2013 (UTC)

I was first skeptical of "instance of" too. That is a technical words, which means it is rather obscure, but also technically correct. The point of "instance of" is precisely that it can be used for everything. What harm is there in that ? We cannot have "type of" for everything, and maintaining a mix of two systems does not seem very clear nor convenient. For Wikipedias infoboxes, there would be no real benefit over querying instance of. For Wikidatians, it would still be easier to learn how to use a few "membership properties" than having to cope with dozens of potentially overlapping "instance of" properties (type of administrative division, type electoral circonscription, type of zone defined for statistical purpose, type of place with no administrative status, type of special economic zone, type of protected natural area, type of school district, etc, etc.) --Zolo (talk) 18:25, 6 April 2013 (UTC)

How do you use "instance of" in an infobox? Under which label? You will have a mixture of not-well-defined and well-defined properties, which will be hard to use in many cases. -- Lavallen (block) 19:19, 6 April 2013 (UTC)

I do not understand what you mean. If you want a general term, I suppose you can use "type" or "nature", but what would you use that for ? Labels are defined in infobox templates. What difference does it make whether the data you use come from P31 or from P132 ? --Zolo (talk) 19:53, 6 April 2013 (UTC)

When you make templates, it is easier to use properties with a wel-defined purpose, than inside P31 who today contain almost anything. And an urban area is not administrative (P132), it is a wel-defined type of settlement, defined by the Nordic statistical organisations. -- Lavallen (block) 08:33, 15 April 2013 (UTC)

The problem could be if there are several values for "instance of" and we wouldn't know which value to show as a type of settlement. --DixonD (talk) 09:26, 15 April 2013 (UTC)

Yes, use in templates is something we have to think about, but I do not think that multiplying subproperties is the best solution for that. We should rather have better guidelines for P31. At some point, we are supposed to be able to mark some statements as preferred, and I think it would help solve the problem. The preferred P31 for London should be "city" or whatever its administrative status. "City with more than 1 million people", "Host of the Summer Olympics", or even "capital" do not seem very relevant in P31. --Zolo (talk) 09:43, 15 April 2013 (UTC)

One part of the Swedish settlement-template has no label, and that is "category" in sv:Mall:Geobox, it defines the whole infobox. It can have multipurpose, like "city" and "urban area" and others, but as long as "instance of" is used for everything its more or less useless. I would not be suprised to find "a place where the sun don't shine" in P31 today. "Instance of Capital" would be better to replace with a binary version of P36. Stockholm is capital of at least Sweden, one County and two Municipalities (Landsting and Kommun). "Instance of Capital" with several qualifiers is another solution. -- Lavallen (block) 10:37, 15 April 2013 (UTC)

Then just a "status" property that that would not accept values like "a place where the sun don't shine", but would not impose the needless topical constraint of "admninistrative-divisionness" either ? That would be useful for other cases as well. For instance, the Musée d'Orsay is an instance of museum, but from a legal point of view, it is an instance of "établissement public à caractère administratif". A "status" property may solve that as well. --Zolo (talk) 07:38, 19 April 2013 (UTC)

An individual does not have to belong to only one class, so I don't see why the Musée d'Orsay can't be an instance of museum as well as an instance of "établissement public à caractère administratif". The problem is when an individual is described as an instance of a class and its sub/superclass, which is redundant. Silver hr (talk) 22:26, 26 April 2013 (UTC)

If I understand you correctly, you want this property to have a list of allowed values, and you don't want to use "instance of" because it couldn't have such a list? If so, where would these values come from? Nordic statistical offices in the case of Nordic countries? You could still use "instance of" and get the official settlement type to display in the infobox. Let me give an example. Suppose Swedishtown is a settlement in Sweden, and its type as defined by the Swedish statistical office is "cool town". You want Template:Geobox to display "cool town" as the value for the category field. First, you create the item "cool town", and you add to it the statement "instance of: type of settlement". Then you add the statement "instance of: cool town" to Swedishtown. Now, because Swedishtown can have other "instance of" statements, the Geobox template needs to look at all of Swedishtown's "instance of" statements and their values. Suppose those values are the items I1 and I2. Which of them is "cool town"? The template needs to query I1 and I2 and get their "instance of" statements. Then, whichever of I1 and I2 has "instance of: type of settlement" is the "cool town" item, and is the one to display. Would this solve your problem? Silver hr (talk) 22:26, 26 April 2013 (UTC)

I guess it would. A possiblility would also be to allow a limited number of values in the categories, and not everything that can be put into "instance of". -- Lavallen (block) 06:12, 27 April 2013 (UTC)

I haven't seen it mentioned here, but Help:Basic membership properties is worthwhile background reading for discussions about P31. Emw (talk) 20:19, 20 April 2013 (UTC)

Oppose: We should be very careful about using '... of xyz' as part of a property name. By naming it 'type of settlement', we are presuming that it will only be used for settlements, for it would be rather illogical to have an item that is not a settlement of some type be a 'type of settlement'. But if the property 'type of settlement' is only used for items that are a settlements, then the '...of settlement' portion seems a bit superfluous. Wouldn't 'type' suffice? If the concern is to account for an official standardized type classification, then that should have its own property ('Nordic settlement classification' or whatever it is that makes it exclusive to an official designation). Joshbaumgartner (talk)

Oppose redundant with instance of and subclass of. Emw (talk) 19:12, 5 May 2013 (UTC)

You can look at Q934689 to see an experiment with the use of "instance of" in an item. It would have been easier to use a "type of settlement"-property like the way "type of administrative division" is used. -- Lavallen (block) 19:17, 5 May 2013 (UTC)

Why would it have been easier? Having a proliferation of "type of" properties is unsustainable. It implies that we'll need new properties whenever we want to apply 'instance of' or 'subclass of' to a specific domain (set of valid subjects). There are thousands and thousands of different types on Wikidata. Instead of creating new "type of foo" properties for each of those many, many types and requiring people and automated reasoners to handle each of them, I think it would be far easier to use two generic properties based on W3C standards (rdf:type with 'instance of' and rdfs:subClassOf with 'subclass of') to capture that kind of information. Emw (talk) 20:17, 5 May 2013 (UTC)

Comment I can't see what this would provide beyond instance of (P31). It would be possible to work out what each item listed is, by examining the subclass of (P279) in the listed item. Danrok (talk) 00:17, 25 May 2013 (UTC)

Not done --Nightwish62 (talk) 16:32, 29 July 2013 (UTC)

Code / (generic) /

Not done
Description: NUTS/LAU/ other statistical code
Datatype:
Links:
Infobox parameter example:
Comments: maybe useful for different items than places too.
Exists in all EU countries for any administrative level, but should rather obtained by original sources (EU Statistical Office) than by fetching it from Wikipedia. --Matthiasb (talk) 13:34, 7 March 2013 (UTC)
Question. The description says it can be a NUTS/LAU/any other code. If supplied, how are we to know exactly which type of code was used?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:35 (UTC)
Oppose I can only second Ëzhiki, that means we should have different properties for each type of code: ISO 3166-1, ISO 3166-2, NUTS, LAU, IOC country code, Community Identification Number (perhaps also different codes for Austria, France, Germany, Switzerland, ...) ... --Monsieurbecker (talk) 14:59, 12 March 2013 (UTC)
Not necessarily. We can still have one code field with a qualifier (whenever those are implemented). However, it's unclear whether such solution is the intent of the proposal (and whether having just one code would be enough) or something else was meant.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 12, 2013; 20:11 (UTC)

I think we need to have one entry for each level, because some countries don't have all the levels and the ISO matching is not the same, so you can't derive everything from a single entry. For instance, Romania has:

LAU-2: SIRUTA code
LAU-1: does not exist
NUTS-3: județ, which is the same level as ISO 3166-2, but has different codes:
- Eurostat: ROxxx
- ISO 3166-2: RO-yy
- Romanian Statistics Administration: SIRUTA, but also another code (the latter can be skipped/inferred from SIRUTA, but would be necessary in order to have a complete database)
- Car registration: yy (this is the same as the yy from ISO)
NUTS-2/NUTS-1: Development regions and Macroregions - don't have a code in Romania, only NUTS code.

AFAIK, Germany or France have a totally different system, so we do need a code for each level.

That being said, I thing we shouldn't oppose the proposal for that technicality, but rather change and implement it :)--Strainu (talk) 07:55, 17 April 2013 (UTC)