Wikidata:Property proposal/Archive/10

From Wikidata
Revision as of 15:59, 24 September 2024 by ZioNicco (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Street

Descriptionstreet of the address of a building
Data typeItem
Proposed byZolo (talk) 19:55, 17 June 2013 (UTC)
   Done: house number (P670) (Talk and documentation)
Descriptionstreet number
Data typeString
Proposed byZolo (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)


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

Mouse Genome Informatics ID

Descriptionprovides integrated access to data on the genetics, genomics and biology of the laboratory mouse
Data typeString
Template parameteren:Template:GNF_Protein_box = MGI-ID
Domainterm
Examplemyoglobin = "96922", FOXP2 = "2148705", glucagon = "95674"
Format and edit filter validationnumber of digits can be constrained, only numbers
Sourcehttp://www.informatics.jax.org/
Robot and gadget jobsCollect 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
DescriptionFor 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 typeItem
Template parameterEnglish Wikipedia template Infobox VG, field released =
Domaincreative work
Allowed valueslinked 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 validationNope
SourceN/A, reference would be for P577
Robot and gadget jobsPossibly, as it uses the vgrelease template
Proposed bySven Manguard Wha? 03:36, 19 June 2013 (UTC)
Discussion


CAS number (en)

Descriptionunique numerical identifier assigned by Chemical Abstract Society for every chemical and drugs
Data typeString
Template parameter"CAS number" in en:template:drugbox see
Domainterm
ExampleDiclofenac - CAS number 15307-83-5
Format and edit filter validationsee for detail mathod of numbering
Sourcearticle infobox suggested above
Proposed by117.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) --Ricordisamoa 10:31, 5 July 2013 (UTC)

marriage date (civil)/ Heiratsdatum (Zivil)

   Not done
DescriptionDatum, an dem eine Person geheiratet hat
Data typePoint in time
DomainPerson
ExampleBeispiel: Q73111 => Q304857
SourceQuelle
Proposed byRaywood (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)
Descriptionlist of characters
Data typeItem
Domainplays, operas, operettas, may be books
ExampleSee w:en:Hamlet#Characters
Proposed byEugeneZelenko (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)


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

Google Books identifier

DescriptionThis identifier gives access to the books that Google has scanned.
Data typeString
Domainpublished works
ExampleTirant lo Blanch (1409 edition) <Internet Archive identifier> 7r14FzJdSuAC
Proposed by--Micru (talk) 00:47, 25 June 2013 (UTC)
Discussion


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

lyrics by

   Done: lyricist (P676) (Talk and documentation)
Descriptionauthor of song lyrics
Data typeItem
Domainsongs
ExampleLet It Be lyrics by Paul McCartney
Proposed byEugeneZelenko (talk)
Discussion

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


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

Encoded by

   Done: encoded by (P702) (Talk and documentation)
Descriptionthe gene that encodes some gene product (usually a protein or RNA). Inverse of "encodes".
Data typeItem
Domainprotein, RNA
Allowed valuesgene
Examplereelin (Q13569356) --> RELN (Q414043)
Proposed bySee 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
Descriptionsee example. This property is proposed so that items can be read and edited by machines easily.
Data typePoint in time
Domainterm
Example2010 (Q1995)->2010, 2010s (Q19022)->2010s, February 2010 (Q236283)->February 2010, 21st century (Q6939)->21st century...
Proposed byGZWDer (talk) 11:30, 6 June 2013 (UTC)
Discussion


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

Ensembl Transcript ID

Descriptiontranscript ID issued by Ensembl database
Data typeString
Domaingene/RNA
ExampleRELN (Q414043) -> "ENST00000428762", "ENST00000343529"
Proposed byAndrew 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

Descriptionprotein ID issued by Ensembl database
Data typeString
Domainprotein
ExampleRELN (Q414043) -> "ENSP00000392423", "ENSP00000345694"
Proposed byAndrew 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)

Descriptionlocated 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 typeItem
Domainstructures (e.g. buildings), places (towns), landforms, and bodies of water
Allowed valueslandforms or bodies of water
ExampleOahu (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)
SourceExternal references. There may be data on Wikipedia, not sure how feasible it is to extract automatically.
Robot and gadget jobsShould or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.)
Proposed bySuperm401 - 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)


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

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

Descriptionплатформа
Data typeItem
Template parameterru:Шаблон:Космический аппарат Платформа
DomainКосмические аппараты
Allowed valuesимя платформыКРАУ-1
ExampleКазсат построен на базе платформы Яхта Eutelsat 3D uses the <Spacebus 4000> bus from Thales Alenia Space.
SourceКарточки в статьях и т. д.
Proposed byIvan 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)
DescriptionThe diocese to which the monastery belongs or belonged (also true for persons or organizations)
Data typeItem
Template parameter"diocese" in en:Template:Infobox monastery
Domainperson, place, organization
ExampleRoman Catholic Diocese of Hong Kong (Q869506)
Proposed byAyack (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)

DescriptionHB Number in Historic Scotland database
Data typeString
Template parameteren:Template:Hbnumber
Domainplace
ExampleTantallon Castle (Q57803) => 14722
Sourcehttp://hsewsf.sedsh.gov.uk/hslive/hbsearch.show
Robot and gadget jobshttp://hsewsf.sedsh.gov.uk/hslive/hsstart?P_HBNUM=$1
Proposed byAyack (talk) 14:18, 19 July 2013 (UTC)
Discussion


✓ 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
DescriptionThe 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 typeItem
Domainterm (basically names of specialized fields)
Examplethe 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)
Sourceshouldn'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 jobsgadgets, 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 byPichpich (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
DescriptionCalibre of a firearm
Data typeNumber (not available yet)
Template parameterInfobox Firearm Cartridge --> Specifications --> Bullet diameter
Domainterm
ExampleFN MAG (Q842066) => 7.62
Proposed byEsquilo (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οωερZtalk 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
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

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:

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

 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
DescriptionPopilation density of the subject city or town
Data typeNumber (not available yet)
Template parameteren:template:infobox settlement population density
Domaintype of items that may have this property
Allowed valuesper km2
Exampleen: São Paulo
SourceGeographical 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)


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

Souvenir / ره آورد

   Not done
DescriptionSouvenirs associated with a city which are usually bought by tourists as valuable materials of the subject city
Data typeItem
Template parameterfa:الگو: جعبه شهر ایران ره آورد
Domaincountries, cities, towns and villages
Examplefa: یزد
Sourcefa:الگو: جعبه شهر ایران
Proposed byدوستدار ایران بزرگ (talk) 16:51, 31 March 2013 (UTC)


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

participant / Teilnehmer / participant

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)

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

Descriptiona string that is assigned to minerals and mineral groups
Data typeString
Template parameterde:Vorlage:Infobox Mineral, Kurzform_Strunz_8
Domainmineral items, mineral group items
Examplealbite = "VIII/J.07", magnesite = "V/B.02"
Sourcemindat.org: Strunz 8 ed (1982), de:Systematik_der_Minerale_nach_Strunz_(8._Auflage)
Robot and gadget jobsBot can collect data from German infobox or from mindat.
Proposed byTobias1984 (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(UO2)4(AsO4)4·40H2O. The chemical formula was revised (Al(UO2)2(AsO4)2F·20H2O) 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:

  • 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

Descriptiona string that is assigned to minerals and mineral groups
Data typeString
Template parameterde:Vorlage:Infobox Mineral, Kurzform_Strunz_9, en:strunz=, fr:strunz=
Domainmineral items, mineral group items
Examplealbite = "9.FA.35", magnesite = "5.AB.05"
SourceCNMNC Master list 2009, Nickel–Strunz 9 ed (2001), de:Systematik_der_Minerale_nach_Strunz_(9._Auflage)
Robot and gadget jobsBot can collect data from different language infoboxes and from online sources.
Proposed byTobias1984 (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

Descriptiona string that is assigned to minerals and mineral groups
Data typeString
Template parameternot part of any infobox at the moment
Domainmineral items, mineral group items
Sourcemindat.org ("10 ed, pending publication")
Robot and gadget jobsBot can collect and update data from online sources.
Proposed byTobias1984 (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

Descriptiona string that is assigned to minerals and mineral groups
Data typeString
Domainmineral items, mineral group items
SourceDana 8th edition
Robot and gadget jobsBot can collect and update data from online sources.
Proposed byTobias1984 (talk)

lower boundary definition / Liegendgrenze Definition

   Not done
DescriptionDescribes the lower boundary of a stratigraphic package
Data typeItem
Template parameternot included in any infobox yet, usually in the text of all articles
Domainitems about geologic ages and stratigraphic units
Allowed valuesfossils, magnetic stages, angular-, erosional unconformity, special beds (e.g. volcanic ashes)
ExampleFortunian = 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.
SourceStratigraphic databases See: Wikidata:Stratigraphy task force
Robot and gadget jobsProbably has to be done by hand. Depends on the database (every geologic service has its own).
Proposed byTobias1984 (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

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)

Descriptionlink to JPL Small-Body Database (Q4026990) for use in source section
Data typeString
Template parameterlink to JPL Small-Body Database (Q4026990) use in the vast majority of articles about asteroids as external/source link
Domainasteroid items (place)
Allowed valuesdescribed in detail here (some variants), but main value type - JPL SPK-ID consisting of 7 digits
Example7777 Consadole (Q1134434)
SourceJPL Small-Body Database Browser
Robot and gadget jobsbot Ra-bot-nik
Proposed byArt-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)

DescriptionObservatory code assigned by the Minor Planet Center (Q522039)
Data typeString
Template parameter"code" in en:template:Infobox observatory
DomainObservatory items
Allowed valuesnumeric or alphanumeric code
ExampleSimeiz Observatory (Q944482) => 094
Sourcelist of observatory codes (Q953917)
Proposed byArt-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)
 SupportIvan 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)
DescriptionID 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 typeString
Template parameter"2" in fr:template:RCAHMS
Domainplace
ExampleTantallon Castle (Q57803) => 56630
Sourcehttp://canmore.rcahms.gov.uk/
Robot and gadget jobshttp://canmore.rcahms.gov.uk/en/site/$1/details/
Proposed byAyack (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
DescriptionMISSING
Data typeMultilingual text (not available yet)
Template parameterHeavy Rail, Light Rail
Domainrailway
Exampleexamples
SourceSource
 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). --Ricordisamoa 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
DescriptionType 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 typeItem
Domainnatural terrain features, landforms, and bodies of water
Allowed valueslandforms or bodies of water
ExampleOahu (Q131347) => 'island', Manitoulin Island (Q654405) => 'island', Nettilling Lake (Q1132211) => 'lake', Mount Blue Sky (Q1950460) 'mountain'
SourceExternal references. There may be data on Wikipedia, not sure how feasible it is to extract automatically.
Robot and gadget jobsShould or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.)
Proposed byFilceolaire (talk)
Discussion

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


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

Chairperson (en)

   Not done
DescriptionThe name of the club's chairman
Data typeItem
Template parameteren:template:Infobox football club chairman
Domainorganization (football clubs)
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (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)
Descriptiona 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 typeItem
Domainevents
ExampleFukushima Daiichi Nuclear Power Plant > Fukushima Daiichi nuclear disaster
Proposed byMacadamia1472 (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 typeItem
    Template parameterPart 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
    DomainOther taxons (i.e. family and possibly below)
    Allowed valuesSuperfamilies, but presumably not enforced, so item
    Examplehttps://en.wikipedia.org/wiki/Template:Taxonomy/Coelophysoidea
    Sourcehttps://en.wikipedia.org/wiki/Template:Taxonomy/Coelophysoidea
    Robot and gadget jobsCould probably be migrated from English Wikipedia
    Proposed bySuperm401 (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
    Descriptionen:color index, included U−B, B−V, V−R, R−I, J−H, J−K
    Data typeNumber (not available yet)
    Template parameteren:Template:Starbox observe
    Domainterm
    ExampleAlgol (Q13080)=>−0.37 (U−B), −0.05(B−V)
    Proposed byGZWDer (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)

    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)

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

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

       Not done
    Descriptionthe diagonal screen size
    Data typeNumber (not available yet)
    Domaindevices with a screen (for example computers or smartphones)
    Example
    Nexus 4 => 4.7 ''
    Nexus 4 => 11,938 cm
    Robot and gadget jobsA bot can search in the wikis for the screen size value in tables.
    Proposed by88.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
    Descriptionen:Apparent magnitude
    Data typeNumber (not available yet)
    Template parameteren:Template:Starbox observe
    Domainterm
    ExampleAlgol (Q13080)=>2.12
    Proposed byGZWDer (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)
    DescriptionID for searching for publications from/about
    Data typeString
    Template parametercs:template:NK ČR
    Domainmainly person, other too
    ExampleQ9065647 => [1]
    Q57434 -> [2]
    Sourcehttp://aleph.nkp.cz/F/
    Robot and gadget jobsShould be added by bots.
    Proposed byJAn Dudík (talk) 09:49, 3 July 2013 (UTC)
    Discussion

    Origin

       Not done
    DescriptionThe city from which the singer or group originated
    Data typeItem
    Template parameterOrigin parameter in Template:Infobox musical artist
    DomainMusical artists or groups
    Allowed valuesCity, but if not known, country
    ExampleThe BeatlesLiverpool, England
    SourceTemplate:Infobox musical artist
    Proposed byFrigidNinja

    Surprised this isn't already used. FrigidNinja 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)
    DescriptionOKATO (Q856636)
    Data typeString
    Template parameterru:Шаблон:НП-Россия ОКАТО/Цифровой идентификатор
    Domainнаселённые пункты России / Russian populated places
    ExampleKuznetsovka (Iglinsky District) (Q1063777) <ОКАТО> 80228825007
    Format and edit filter validation11 цифр
    Sourceкарточки, сама база
    Robot and gadget jobsWikidata:Database reports/Constraint violations
    Proposed byIvan A. Krestinin (talk)
    Discussion
       Done: OKATO ID (P721) (Talk and documentation)
    Descriptionlink to OKATO (Q856636) (Russia)
    Data typeString
    Template parameter"цифровой идентификатор" in ru:template:НП-Россия
    DomainObjects of administrative division in Russia (main type - place)
    Allowed valuesa set of numbers separated by spaces
    ExampleGatchina (Q7436) => OKATO 41 420
    Source[3], [4]
    Proposed byArt-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

    DescriptionUIC ids are used by railway operators to refer to railway stations in Europe.
    Data typeString
    Domaintrain stations
    ExampleGare de Nantes has UIC code 8721351
    Format and edit filter validationUIC station reference always consists of 7 digits, beginning with a 2-digit UIC country code
    Proposed bySke (talk) 21:35, 25 April 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.
    • 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
    • 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)


    • 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 watercourseP403Itemriver 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
    DescriptionHeight of the mountain
    Data typeString
    Template parameter(as in section name)
    Domainplace (?)
    Allowed valuesnumbers – we should choose one unit (meters) and if an infobox uses another unit it should convert it by itself
    Example 1MISSING
    Example 2MISSING
    Example 3MISSING
    Robot and gadget jobsCollect data from wikipdia articles and paste to wikidata; report cases of conflict somewhere.
    Proposed byKaligula (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)

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

    minister of

       Not done
    Descriptionsubject holds/held ministry office at object (minister, pastor, imam, etc.)
    Data typeItem
    Template parameter"churches" in en:template:infobox minister of religion
    Domainperson
    Allowed valuesreligious organizations (churches, mosques, etc.)
    ExampleHuldrych Zwingli => Grossmünster
    Proposed byJfhutson (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

    Descriptionreference to the DBNL-website http://www.dbnl.org/ for Dutch language authors.
    Data typeString
    Template parameterput Wikipedia infobox parameters here. If existing, sample: "dbnl" in nl:sjabloon:infobox auteur
    Domainperson, authors (writers, poets, etc)
    ExampleQ2359791 -> star003
    Proposed byEdoderoo (talk)
    Discussion

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

    Dodis

       Done: Dodis ID (P701) (Talk and documentation)
    DescriptionIdentifier in the dodis database (Diplomatic Documents of Switzerland 1945-1969), see Diplomatic Documents of Switzerland (Q661051)
    Data typeString
    Template parameterTemplate:Dodis (Q12064410)
    Domainall: persons, organisations, terms, ..
    ExampleHenri Guisan (Q123497) = P495
    Proposed by- Vacallo (talk) 05:15, 10 June 2013 (UTC)

    Airbase

       Not done
    DescriptionAirbase used by a military or other organization
    Data typeItem
    Domainorganization
    ExampleUnited States Air Force -> airbase -> Andrews Air Force Base
    Proposed byJoshbaumgartner (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
    Descriptionmain topic of portal
    Data typeItem
    Domainportals
    ExamplePortal:Oceania => Oceania
    Proposed byYpnypn (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
    DescriptionMemorial Hall / Memorial_Building etc.
    Data typeItem
    Domainperson
    ExampleQ8573 => Q1051254
    Proposed byGZWDer (talk) 13:15, 29 May 2013 (UTC)
    Discussion

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

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

       Not done
    Descriptionblood type of the person
    Data typeItem
    Domainperson
    Allowed valuesA,B,AB,O
    ExampleQ249719 => No wikidata entry for each blood type must be created
    Format and edit filter validationnone
    SourceThis is usually used for east asian wikipedia, I guess it is important for them to know the blood type
    Robot and gadget jobsI guess this could be done and retrieved from wikipedia entry, usually from japanese, korean, chinese entry
    Proposed byNapoleon.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

    GenPept

       Not done
    DescriptionGenPept (full) sequence from NCBI, EBI, GenomeNet etc.
    Data typeI 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)
    DomainProteins
    Allowed valuesBegins with "LOCUS", ends with "//"
    ExampleFrom [5] - Passed as parameter 1 inen:Template:ImportProtein/Src (gene)
    SourceSee [6] for a bit of the definition, or help for the example from NCBI below.
    Robot and gadget jobsen:Module:ImportProtein
    Proposed byWnt (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

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


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

    type of settlement

       Not done
    DescriptionA complement to P132 (type of administrative division), for non-administrativ settlements like urban areas/CDP/hamlets/villages etc who has no administrative function.
    Data typeItem
    Template parametersv:template:Geobox category
    Domainp107:place
    Exampleurban areas/cdp's in Swedish/US-settlement and others who are not a city/municipality with a local administration.
    Proposed byLavallen (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)


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


    Code / (generic) /

    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)