Open main menu

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


PBuB Plattdüütsche Biblio- un Biografie/Plattdeutsche Biblio- und Biographie

DescriptionAn ID identifying Low German authors, works, organizations in the Low German Bibliography and Biography
Data typeString
DomainPersons, works, organizations etc
Allowed values\d+
Example<Gorch Fock> PBuB-ID <713>
Proposed bySlomox (talk)

This is an authority control identifier of the Institut für niederdeutsche Sprache (Institute for the Low German Language). This is in use at the nds.wp project in the template nds:Vörlaag:PBuB. To be fully functional this property will need a string qualifier stating the object class ('' for an author, 'T' for a work, 'K' for a corporation etc). Slomox (talk) 12:03, 11 April 2013 (UTC)

  Question, if there are several different sorts of ids for people / places / publishers, wouldn't it make more sense to use separate properties. It seems simpler both to encode and to decode. --Zolo (talk) 19:32, 6 May 2013 (UTC)
I don't know. One property with a qualifier seems easier to me, but I don't exactly know about the benefits or drawbacks of either solution. --Slomox (talk) 07:53, 14 May 2013 (UTC)
  Support published by an established authority Joshbaumgartner (talk) 07:42, 9 May 2013 (UTC)
  Support as single property; multiple properties should be avoided in these cases (as we use the same IMDb ID (P345) for character, movie, actor, etc.) --Ricordisamoa 08:04, 14 May 2013 (UTC)
Full IMDb IDs are unique so that qualifiers are not necessary. Things are different here: we have several databases with overlapping IDs (eg, author 403 and place 403) so that the value does not really have any meaning without specifying which database we are referring to. Having several properties would make statements more concise and external links easier. It would also simplify the work of bots that check for uniqueness of values. Beside, if at some point we can transform this kind of property into a sitelink, it will not be possible to use qualifiers.--Zolo (talk) 13:00, 20 May 2013 (UTC)
  Comment I tried to create this property, but the webpage seems to be broken. I can't even find Gorch Fock and the link form de-wiki doesn't work either. --Tobias1984 (talk) 08:34, 27 July 2013 (UTC)

  Done --Tobias1984 (talk) 06:28, 2 August 2013 (UTC)

date of disappearance (en) / verschollen seit (de)

Descriptiondate a missing person was seen or otherwise known to be alive for the last time
Data typePoint in time
ExampleAmelia Earhart (Q3355) => "July 2, 1937"; Roald Amundsen (Q926) => "June 18, 1928"; Vladimir Rusanov (Q1385267) => "August 18, 1912"
Proposed byKompakt (talk) 05:27, 14 June 2013 (UTC)
  •   Support--Micru (talk) 01:42, 8 July 2013 (UTC)

  Done --Nightwish62 (talk) 07:21, 2 August 2013 (UTC)

Burial place image

   Not done
DescriptionCommons file with photo or other image of grave/burial place/cenotaph
Data typeCommons media file
Allowed valuesCommons files
ExampleJohann Sebastian Bach (Q1339) => File:Grave of Johann Sebastian Bach Leipzig 01.JPG

First I thought we could add the qualifier "image" to the property Property:P119, but this seems to be the wrong way round. --  Docu  at 08:16, 25 April 2013 (UTC)

Yes, this would be wrong. But using property "image" with qualifier "place of burial" would be right in my opinion. --Nightwish62 (talk) 07:23, 28 April 2013 (UTC)
That would require to repeat "place of burial" there. --  Docu  at 05:06, 29 April 2013 (UTC)
  Comment How about this format of using the statement, I think that we can set the image in both statement and as qualifier. I dont think that it would be redundant because the image are also sometimes written in the Category page also.

Item: Person A

   Statement: Date of birth - pending
       Qualifier: Place of birth P19 
       Image: XXX.jpg P18
   Statement: Date of death - pending
       Qualifier: Place of death P20 
       Image: YYY.jpg P18
   Statement: Date of burial - pending
       Qualifier: Place of burial P119
       Image: ZZZ.jpg P18
   Statement: Image XXX.jpg
            : Image YYY.jpg
            : Image ZZZ.jpg
   Statement: Commons Category P373 

--Napoleon.tan (talk) 13:09, 30 April 2013 (UTC)

In every case ist must be some picture related to the person, the tombstone, mausolem, monument... something personal, not a picture of the graveyard as a whole.--Giftzwerg 88 (talk) 12:01, 11 May 2013 (UTC)
Thanks for your feedback. The various options seem tricky. Shall we go ahead with the initial proposal? --  Docu  at 07:47, 19 May 2013 (UTC)
  Strong support for the initial proposal. Although I see the benefit of nesting data into qualifiers, but currently, the broad consensus seems to be separate properties. This proposal will probably need a qualifiers itself that further describe the grave. Geocoordinates and maybe things like "artist that designed it" "style of grave", "erected", "moved", "restaurated". Somebody should also request birthhouse image. --Tobias1984 (talk) 07:35, 8 June 2013 (UTC)
  Oppose - there are simple to much objects in the world that everything which can be photographed has its own property. --Nightwish62 (talk) 21:06, 1 August 2013 (UTC)
I have removed my support. I think it would be better to find a new solution for image properties. Interest in this is anyway zero, so it can go into the archive. --Tobias1984 (talk) 21:08, 1 August 2013 (UTC)

  Not done --Nightwish62 (talk) 08:02, 2 August 2013 (UTC)

Unrecognized country of citizenship

   Not done
Descriptionstate or states that recognize or would recognize the subject as their citizen, but are not sovereign themselves (and were not at the time the person lived, either) [not things like Republic of Venice or Prussia]
Data typeItem
Template parameter#Italian Wikipedia person data
Example 1MISSING
Example 2MISSING
Example 3MISSING
  • Comments: We already have P27 "sovereign state or states that recognize the subject as their citizen", but not all (relevant) citizenships are sovereign states, the most notable example (in terms of wars happened) probably being Kurdish people. Some Wikipedias will use (some) of them for categorisation purposes (e.g. w:en:Category:Kurdish people, or w:en:Category:Chechen people used on but not etc., but it's not correct to mix them with P27. Creating this property is probably needed, unless some other simple way to make this distinction within P27 is found: it's not a way to encourage nationalist discussions but to confine them to a clearly labelled place; and existing policy-conforming usage on Wikipedia exists (see person data template). --Nemo 10:03, 1 March 2013 (UTC)
  1. "Country of citizenship" implies that the "country" recognizes some rights to the item based on the item, so it means that country of Citizenship: Kurdistan does not just mean that the person is of Kurdic ethincity (which could probably be a separate property). It means that there is a de facto or de jure Kurdistan entity that explicitly recognizes her as a citizen.
  2. I do not think it is very convenient to distinguish between recognized and unrecognized countries (is Palestine recognized?). Wikidata is about claim made in the outside World, not about the truth. It means that if an external source claims that someone is a citizen of Sealand, we can add that here without tricky internal debates. Of course, in some contexts, it can be useful to know whether this citizenship is recongized by the UN or by a particular country, but it sounds simpler and more flexible to do it client-side. --Zolo (talk) 10:23, 1 March 2013 (UTC)
  1. I don't understand how this relates to the proposal here. If you're speaking of P27, you're currently incorrect because the list of properties explicitly requires the country to be a sovereign state. Are you proposing to change this? Current status is that citizenships from unrecognized countries are forbidden/ignored by Wikidata, which brings us to point 2.
  2. This is not a problem of truth. There are two distinct problems and only one is being discussed here:
    1. whether the citizenship is relevant and verifiable for the person: this is decided by sources on the person and doesn't depend on the status of the country or our way to call the property;
    2. whether the citizenship comes from a sovereign state: if it doesn't, should it replace the official/other citizenship (e.g. Turk) of the person in P27, be added next to it in P27, be stored elsewhere?
Nemo 14:25, 1 March 2013 (UTC)
I am fine with the description of P27, but I do not think it can be more than a guideline ensuring that we do not add "California". Sovereignty is not the same thing as recognition. We could decide to restrict P27 to "recognized states", but I do not sure that would be feasible. There is no universally accepted list of "recognized states". Even "recognized by the United Nations may not be practical. Is Palestine recognized by the UN ? We could perhaps decide that it has been since November 2012. Would that mean that the value of a P27-claim can be set to P27 only with the qualifier "since November 2012" ? Few countries recognize Taiwan, does that mean we cannot use Taiwan (or Republic of China) in P27 ? I do not know much about Kurdish politics and I doubt there is such a thing as an organized Kurdistan political entity recognizing people as its citizens, but if there is, yes, I think it should go to P27. I do not see any problem with having several values in P27. --Zolo (talk) 15:47, 1 March 2013 (UTC)
I simply don't understand how it is supposed to work (yes I have clicked on the weblink and know that _some_ articles on :it contain an item Cittadinanza in their infobox). Can you give an example of an item where you would use this property, and the "source" you would call to assert it ? I don't really see how you know that if a state existed it "would recognize the subject as its citizen". If Austria existed, would it recognize Reinhold Messner as its citizen ? We know that the answer is "no" since it happens that Austria exists, but how can you know for non-existent countries ? If Kurdistan existed, would it be located on the territory of today's Iran, of today's Irak, of today's Turkey ? How can you know ? Touriste (talk) 12:05, 2 March 2013 (UTC)
I keep trying to understand and visited w:it:Template:Bio. On this page, there is a definition of Cittadinanza quite different from the tricky one given above which left me so perplexed. I quote the Italian template page : "Cittadinanza = da usare nei casi di nazionalità culturale differente dalla nazionalità anagrafica (es. Curdi di Turchia)". This is clearer but badly tricky. What kind of sources can be admitted ? Is it sufficient that any book (even with a strong nationalist bias) asserts that "X" is "Y" to admit the use of the property ? Let's take an example : after a few tries in Google I find a sentence in a book from Jon Krakauer that reads as follows : "the famed Tyrolean alpinist Reinhold Messner". Am I allowed to put "Tyrol" as the value of this property for Reinhold Messner ? If I find a second source that asserts that Tyrol is part of Austria, am I allowed to use "Austria" ? If I find a third source that asserts that Austria is an artificial creation and that Austrians are culturally south Germans, am I allowed to use "Germany" ? If I find a source asserting that nowadays a common culture is being born throughout the European Union, am I allowed to use "European Union" ? Am I allowed to use "Corsica" for a French citizen born and living in this island ? "Sardinia" for an Italian citizen born and living in this island ? "Piedmont" for an Italian citizen born and living in Turin ? This seems quite nightmarish. Touriste (talk) 12:25, 2 March 2013 (UTC)

Support expanding the scope of P27 and editing "sovereign state" to "country". The problem doesn't just apply to disputed territories like Kurdistan and Palestine, but also non-sovereign territories like Gibraltar, Falklands, Hong Kong, and American Samoa etc. whose citizens have an explicitly different citizenship classification than their parent nation. Putting "object is a sovereign state" in the description was a mistake in the first place. Deryck Chan (talk) 20:10, 5 March 2013 (UTC)

Isn't this also a problem for native north americans? -- Lavallen (block) 11:42, 13 March 2013 (UTC)
  •   Oppose Touriste already described how subjective and prone to nationalism this property would be. What makes a person a Kurdish citizen, or a Tyrolean? These countries don't exist let alone do they have citizens. It's pure speculation.--Kompakt (talk) 07:11, 14 June 2013 (UTC)

  Not done --Nightwish62 (talk) 08:18, 2 August 2013 (UTC)

Number of completed seasons (en)

   Not done
DescriptionThe last completed competitive league season. i.e Not the current season.
Data typeItem
Template parameteren:template:Infobox football club season
Domainorganization (football clubs)
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceExternal reference, Wikipedia list article
Robot and gadget jobsthey should be allowed
Proposed byXaris333 (talk) 15:54, 3 May 2013 (UTC)

"number of completed seasons" seems more natural. --Jfhutson (talk) 18:53, 5 May 2013 (UTC)

  • Done. Xaris333 (talk) 19:09, 5 May 2013 (UTC)
  •   Comment - Isn't this supposed to be a number or date for the datatype? An example would be helpful. --Tobias1984 (talk) 10:47, 18 May 2013 (UTC)

  Not done No response to the question of Tobias1984 since month. For me it's also not clear what exactly the property is meant to be for. However, labeled it "number of..." seems it can be queried if every season has it's own item. --Nightwish62 (talk) 09:13, 2 August 2013 (UTC)

running time / länge / durée / длительность

   Not done
Descriptionmovie duration in minutes
Data typeNumber (not available yet)
Template parameteren:Template:Infobox film runtime
Examplefor The Matrix it would be 136
Robot and gadget jobscollect data from movie templates
Proposed byEnzet (talk) 11:11, 28 March 2013 (UTC)
  Comment it should be QuantityValue instead (it is not dimensionless) --Ricordisamoa 12:39, 28 March 2013 (UTC)
  Comment Is it with QuantityValue possible to use more than one quantity, like minutes or metres for it? That would be useful for silent movies. The property should be named "length", so that you can give a length or a time.--CENNOXX (talk) 13:24, 28 March 2013 (UTC)
  Oppose The Property duration is pending. It was made for albums, but as there mentioned it also could be used for films.--CENNOXX (talk) 13:35, 28 March 2013 (UTC)
  Comment Yes, sure, I saw this property, so I want to discuss here whether it is possible to use it both for movies and albums. Enzet (talk) 14:26, 28 March 2013 (UTC)

  Not done Property 'duration' already has approved. This can surely also be used for movies. --Nightwish62 (talk) 09:27, 2 August 2013 (UTC)


   Done: has edition (P747) (Talk and documentation)
Descriptionthis item is used to link the main work item with its editions items.
Data typeItem
Domainmainly books, can be used for other domains
ExampleHamlet <edition> Edwards, Phillip, ed. 1985
Proposed by--Micru (talk) 01:02, 5 June 2013 (UTC)
  •   Tentative support Needed to complete the logical structure of book sources. See Wikidata:Books_task_force#Work_properties--Micru (talk) 01:02, 5 June 2013 (UTC)
  •   Support --Stevenliuyi (talk) 20:32, 5 June 2013 (UTC)
  •   OpposeAgainst the general consensus of a bottom-up structure for data, see Wikidata:Project_chat#Need of a general concept for properties. If you have the link edition item -> work item, you don't need the inverse link. Snipre (talk) 11:32, 10 June 2013 (UTC)
    I agree that a bottom-up structure would be better, if that is not possible, I support this property.--Micru (talk) 20:27, 10 June 2013 (UTC)
  •   Support In this particular case I think an inverse link will be useful. Filceolaire (talk) 18:00, 10 June 2013 (UTC)   Oppose Now I prefer edition (2) below. Filceolaire (talk) 20:40, 11 June 2013 (UTC). I have changed my mind again - see comment om edition (2) below.   Support In this particular case I think an inverse link will be useful. Filceolaire (talk) 08:07, 13 June 2013 (UTC)
  •   Oppose per Snipre. Could be transcluded or handled as a bi-directional property. --Tobias1984 (talk) 18:07, 10 June 2013 (UTC)
  •   Support until the software supports inverse properties. Would be very handy to link e.g. Old Testament (Q19786) to Catholic Old Testament (Q14405870). —Ruud 16:25, 1 August 2013 (UTC)

  Done Another reason is, that Property 'translated into' has been rejected and therefore this item is necessary to retrieve the languages. --Nightwish62 (talk) 09:30, 2 August 2013 (UTC)

Football player statistics

The image show a possible structure of what i suggest about players statistics (sorry about the quality :) ). For every team with can have the same data (team 2, team 3, ... by chronological order). The same for national teams. (Now we have the general item member of sports team). Xaris333 (talk) 00:51, 6 May 2013 (UTC)  

  Not done not a proper property proposal. This sites is designed for single properties, but this is a whole concept. Would be better to start a taskforce for it. Besides this: some of the values can be retrieved out of queries in my opinion. --Nightwish62 (talk) 11:55, 2 August 2013 (UTC)

appointed by (en)

   Done: appointed by (P748) (Talk and documentation)
DescriptionWho appointed the person to the office, can be used as a qualifier
Data typeItem
Template parameter"appointed" in en:template:Infobox officeholder
Domainpresident, judge, prime minister, etc.
Exampleen:Adly Mansour (appointed as president by en:Abdul Fatah Khalil Al-Sisi)
Sourceen:template:Infobox officeholder
Proposed byAude (talk) 20:31, 3 July 2013 (UTC)
  Support --Nightwish62 (talk) 17:04, 6 July 2013 (UTC)
  Support --Micru (talk) 01:43, 8 July 2013 (UTC)
I support as long as you are not limiting it to only persons. In Sweden governors are appointed by the goverment, not by the prime minister for example. -- Lavallen (block) 05:30, 1 August 2013 (UTC)

  Done --Nightwish62 (talk) 11:59, 2 August 2013 (UTC)

Chinese style name (zh:表字)

   Not done
Descriptionsee en:Chinese style name.
Data typeString
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byGZWDer (talk) 11:35, 28 May 2013 (UTC)
Needed, but I think that we should have a more general discussion about names (several properties vs qualifiers, and perhaps item vs string). --Zolo (talk) 07:07, 1 June 2013 (UTC)
  • I wonder if this should be a multilingual text to open up for transliteration. That said, the multilingual text needs a source language and I don't think thats in the model. Jeblad (talk) 11:51, 9 June 2013 (UTC)
  •   Oppose When we get monolingual-text we can input the first and last name for Chinese without the need for another property. --Tobias1984 (talk) 08:56, 30 July 2013 (UTC)

  Not done --Nightwish62 (talk) 12:09, 2 August 2013 (UTC)

Parent company / Dachgesellschaft / maison mère

Descriptiona parent company of an organisation
Data typeItem
Template parameterCan be mapped to en:template:infobox company, with its field called parent. Also en:template:infobox airline, again the field is called parent.
Allowed valueslinked objects
Examplesee en:British Airways and en:GE Capital. At the moment we can scrape divisions (such as en:GE Money), but not parent companies or subsidiaries. BA's parent company would be en:International Airlines Group, and GEC's en:General Electric. BA would then also be added as the parent company of en:BA CityFlyer, en:OpenSkies, en:British Airways Limited.
Sourceseveral infoboxes use this -- like the one given above
Robot and gadget jobsIdeally this should be reciprocal with subsidiary, I would imagine, but that doesn't exist at the moment either (though I'm about to propose it too).

Hope this is okay, my first shot at making a proposal... Buttons to Push Buttons (talk) 09:53, 10 March 2013 (UTC)

  •   Support "parent organisation" would be good too --Goldzahn (talk) 00:18, 12 March 2013 (UTC)
  • Is there any benefit over using P:P127 (owner) ? --Zolo (talk) 18:30, 12 March 2013 (UTC)
  • Let's use "owner" ("owned by"). Espeso (talk) 06:06, 15 March 2013 (UTC)
  •   Oppose per Zolo, it's the same concept. --NaBUru38 (talk) 20:13, 27 March 2013 (UTC)
  •   Move sorted in organizations from unsorted page. Joshbaumgartner (talk) 05:14, 17 May 2013 (UTC)
  •   Oppose handled fine by owner. Joshbaumgartner (talk) 05:14, 17 May 2013 (UTC)
  •   Support as parent organization which differs from owned by, can be used to indicate the parent agency or department of government organizations. They do not own their child agencies. See Met Office infobox. Danrok (talk) 13:38, 17 May 2013 (UTC)
  •   Support As Danrok, "owned by" and "parent" are not always the same thing. Because of "Competition-rules" some companies are not allowed to "parent" their children because they would dominate the market if they did. The relation between Sandvik (Q1753718) and Q10664977 where like that until recently. Today Sandvik both parent and own all of the other company. And the "parent" and "ownership" in organisations like IKEA (Q54078) is very difficult to understand since it has a offshore-foundation in the top. The parent/ownership-structure is designed to be difficult to understand, to minimize the amount of tax they have to pay. -- Lavallen (block) 06:49, 18 May 2013 (UTC)
  Comment Seems to be important, because this term is defined in law. See Parent company. But, I think it should be used for all organization parents, i.e. including government agencies. Danrok (talk) 21:15, 24 May 2013 (UTC)

  Done --Nightwish62 (talk) 13:10, 2 August 2013 (UTC)

original author / Originalautoren

   Not done
DescriptionName of the original author or publisher of the software product.
Data typeItem
Template parameteren:Template:Infobox software author
Domainsoftware products
Robot and gadget jobsCould be done using bots
Proposed by#Reaper (talk)

I'm not really sure how it's used in enwp. It seems to be for "former developers", so it is the same as the developer property and could be done using qualifiers. I only post it here to clarify this. --#Reaper (talk) 14:17, 14 April 2013 (UTC)

  Comment I think your interpretation is correct. We should do it rigorously with qualifiers (X Company developed it from May 1999-November 2003), rather than the author/developer distinction we use on English Wikipedia (which is less flexible). Superm401 - Talk 03:10, 27 May 2013 (UTC)

  Not done --Nightwish62 (talk) 14:27, 2 August 2013 (UTC)

film distributor

   Done: distributor (P750) (Talk and documentation)
Descriptioncompany name of the distributor
Data typeItem
Template parameterTemplate:Infobox film distributor
Allowed valuesIntended for values to be instances of film distributor
ExampleRush Hour => New Line Cinema
SourceTemplate:Infobox film
Robot and gadget jobsCould be imported from English Wikipedia, maybe others.

Template:Infobox film has both studio ("company that produced the film") and distributor ("the company name(s) of the distributor(s)). For studio, we have Property:P272, but I don't think there's a clear separate property for distributor yet. I'm leaning on this being specific to film, like screenwriter, but I'm open to other viewpoints. Superm401 - Talk 02:27, 4 April 2013 (UTC)

What about renaming it to simply "distributor"? So it could be used also for other things like video games. But btw one question at this point: I don't know (I've never really understood) the difference or why there is a difference between a publisher and a distributor..? Respectively who does what.
I think the publisher is more concerned with the promotional side of it, whereas a distributor organises the operational and logistical part. Danrok (talk) 14:58, 16 May 2013 (UTC)
Example item would be en:Counter-Strike: Source (see infobox). If there is no reasons against this property it would be good if it could be created in next time, it would be needed. Greets, --#Reaper (talk) 13:59, 21 April 2013 (UTC)
  Support just as distributor for use with other types of products/services. Danrok (talk) 14:59, 16 May 2013 (UTC)
I'm fine with using it for all mediums. Amended accordingly. Reaper35's Counter-Strike link provides a good illustration of the difference between publisher and distributor (there is often more than one distributor, as there is there) in a non-film area. Superm401 - Talk 03:16, 27 May 2013 (UTC)
  Support--Micru (talk) 02:00, 8 July 2013 (UTC)

  Done --Nightwish62 (talk) 14:32, 2 August 2013 (UTC)

Album type

   Not done
DescriptionAlbum type (studio album, EP, compilation, single)
Data typeItem
Template parameterUsed e.g. in w:Template:Infobox album type
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byStryn (talk) 09:37, 21 February 2013 (UTC)
  Oppose per Emw. Silver hr (talk) 03:55, 31 March 2013 (UTC)
  •   Not done This can be easily done using instance of (P31). No need to create a new property for this. — ΛΧΣ21 06:51, 7 April 2013 (UTC)
    • I don't agree with that. It's the same old discussion and as far as I know there is no conclusion. Therefore this still remain opened. --Nightwish62 (talk) 19:06, 8 April 2013 (UTC)
      • Why? I don't believe that we need a separate property for types of albums. — ΛΧΣ21 03:12, 9 April 2013 (UTC)
  • I would recommend that anyone interested in this topic read through a discussion Nightwish and I have been having here and here (the latter starts with "I hear this argument"). Emw (talk) 03:27, 10 April 2013 (UTC)
Nightwish, the way you can capture this information with instance of and subclass of is the following. "studio album" subclass of "album", "EP" subclass of "album", "compilation" subclass of "album", "single" subclass of "album", (particular album 1) instance of "studio album", (particular album 2) instance of "EP", etc. Silver hr (talk) 23:49, 12 April 2013 (UTC)
Yeah, we don't will find an agreement. But the point is, at moment there are more pro than cons and therefore definitely nothing to mark as 'not done'. --Nightwish62 (talk) 00:01, 20 April 2013 (UTC)
Would you care to explain what specifically in my argument you disagree with? Silver hr (talk) 13:32, 25 April 2013 (UTC)
  •   Support the instance of (P31) can have the value album while the subclass of (P279) is too generic to be used in query. --Napoleon.tan (talk) 12:32, 30 April 2013 (UTC)
  •   Oppose the template is missing examples. --Tobias1984 (talk) 10:38, 30 July 2013 (UTC)

  Not done --Nightwish62 (talk) 14:38, 2 August 2013 (UTC)

Wikipedia article importance & core topic lists (en)

  • Isn't this language-specific? --Yair rand (talk) 05:24, 27 June 2013 (UTC)

  Not done --Nightwish62 (talk) 14:45, 2 August 2013 (UTC)

Reuse for commercial purposes allowed / / / Consentito l'uso a fini commerciali

   Not done
Descriptionwhether a license allows redistribution of a work also for commercial purposes
Data typeboolean-invalid datatype (not in Module:i18n/datatype)
Template parameternot known
DomainTerm (perhaps also Creative work): licenses
Allowed valuestrue or false
Sourcenot known
Robot and gadget jobsnot supposed
Proposed byRicordisamoa 00:26, 13 March 2013 (UTC)
  Question Should this be used only so licenses or also for works licensed under one of these licenses? -- MichaelSchoenitzer (talk) 01:46, 20 March 2013 (UTC)
  Answer If the item has a standard license (from all licenses' items on Wikidata), then the property is not required, since it can be obtained easily; else, if the item has a custom license by its own, then it should have this property. --Ricordisamoa 10:30, 23 March 2013 (UTC)
  Question What would you like to tag with this property, whole items or properties themselves (in latter case, I think it would be more a qualifier, than a property)? --Faux (talk) 12:18, 24 March 2013 (UTC)
  Answer Only items, of course; see examples. --Ricordisamoa 12:30, 24 March 2013 (UTC)
For some reason there was an error in the proposal's template call, so the example was not shown. It's fixed now. Now I understand the idea. --Faux (talk) 13:28, 27 March 2013 (UTC)
  Comment Can this question always be answered with yes or no? Maybe there are situations where a more specific answer is required (e.g. yes, if the source code is published, no otherwise). --Faux (talk) 13:28, 27 March 2013 (UTC)
So, write those examples! --Ricordisamoa 14:27, 27 March 2013 (UTC)
Strongly Oppose This is a proposal that we provide Legal Advice based on Original Research. Not just that but the legal advice is a yes/no answer with no qualifiers! We should never give legal advice. We should list the licence which applies and if a reuser wants to know if reuse for commercial purposes is allowed then the reuser should employ his or her own lawyer to advise him or her. Filceolaire (talk) 14:05, 2 April 2013 (UTC)
If you still want to have this property then the allowed values should be limited to 'No' = Commercial redistribution not allowed. If we think commercial redistribution is allowed then we should say nothing. You should change the property name to match. That is still Legal Advice but its hard to see how we could get sued over it. Better not to have it at all though. Filceolaire (talk) 19:18, 3 April 2013 (UTC)
It could potentially work provided that it was required (and enforced) that a reliable source be cited. Then again, in corner cases, it could vary by jurisdiction, so maybe there would need to be a source and jurisdiction qualifier. Superm401 - Talk 22:12, 3 April 2013 (UTC)
Any reliable source will have their legal advice hedged around with qualifiers. if we leave any of that out then we are at risk. We should not give legal advice on Wikidata. Leave that to Wikipedia where they have room to expand and say "Creative Commons have advised that their CC-0, CC-BY and CC-BY-SA licenses are compatible with commercial redistribution provided the other conditions of those licenses are complied with." 26 words and not one that can be safely omitted in my opinion. Even if something similar could be cobbled together with a bunch of qualifiers it would be too easy to get wrong. We should just stick to the principal that Wikidata doesn't give legal advice. Filceolaire (talk) 08:33, 4 April 2013 (UTC)

  Not done --Nightwish62 (talk) 14:47, 2 August 2013 (UTC)

Disambiguation page target (en)

   Not done
Descriptionsee example. it can collect disambiguation page target and make disambiguation page more simple in the future
Data typeItem
DomainDisambiguation page
ExampleTest (Q224615) => test (Q27318), test (Q257491), test (Q3519023), ...
Proposed byGZWDer (talk) 06:28, 14 June 2013 (UTC)
  •   Oppose I assume this proposal is to add data to wikidata somehow so disambiguation pages can be created using some sort of query. This won't work because disambiguation pages are language specific. The disambiguation page targets in one language can be different from the targets of the same disambiguation page in other languages. Filceolaire (talk) 11:28, 14 June 2013 (UTC)
    • if the disambiguation page targets in one language is different from the targets of the same disambiguation page in other languages, It should split to 2 items. Or a qualifier can be used.--GZWDer (talk) 15:07, 14 June 2013 (UTC)
      • See how your example looks to me: Тест (Q224615) => Контрольная работа (Q27318), Test (Q257491), test (Q3519023). Infovarius (talk) 20:09, 16 June 2013 (UTC)
  • It's difficult. Most words have slightly different meanings in different languages even if they are closely related. I don't want to remove language links from pages like en:System (disambiguation) just because of one mismatch. —PοωερZtalk 00:54, 17 June 2013 (UTC)
    • I think a qualifier can be used.--GZWDer (talk) 02:43, 19 June 2013 (UTC)
      • Can you show how a qualifier could help achieve whatever it is you are trying to achieve with this property? Filceolaire (talk) 20:10, 19 June 2013 (UTC)
        • Probably wait for Phase 3.--GZWDer (talk) 05:06, 20 June 2013 (UTC)

  Not done --Nightwish62 (talk) 14:52, 2 August 2013 (UTC)

introduced feature / removed feature (en) / eingeführte Funktion / entfernte Funktion (de)

Status:    Done


Descriptionwhich feature was introduced/removed by this version of a product
Data typeItem
Domaincreative work
introduced: Android Jelly Bean (Q2846924) => Google Now (Q79564)
introduced: iOS 5 (Q3919641) => Siri (Q582159)
introduced: Windows Vista (Q11230) => Windows Desktop Gadgets (Q828312)
removed: Windows XP (Q11248) => AppleTalk (Q200606)
Proposed byNightwish62 (talk) 18:46, 30 June 2013 (UTC)
  •   Comment - This proposal is for two new properties ("introduced feature" and "removed feature"), not a single one ("introduced feature / removed feature") - --Nightwish62 (talk) 21:09, 30 June 2013 (UTC)

  Done, also with removed feature (P756) --Nightwish62 (talk) 15:05, 2 August 2013 (UTC)

UNESCO reference

Descriptionthe reference given to the place by UNESCO. Applies to World Heritage Sites only.
Data typeString
Template parameter"ID" in en:Template:Infobox World Heritage Site
ExampleDead Cities (Q393841) --> 1348
SourceUNESCO [1]
Proposed byDanrok (talk)
  •   Support: useful – see also the "link" parameter in it:Template:UNESCO. --Ricordisamoa 18:38, 11 June 2013 (UTC)
  •   Support --Fralambert (talk) 12:42, 26 June 2013 (UTC)
  •   Support --Benoit Rochon (talk) 03:05, 27 June 2013 (UTC)
  •   Comment not sure why this have to be 'string' and not numbers? Ok, I found one element which contains characters ([2]). Are there more than this one? If so, are those also '...rev' or are there other characters? --Nightwish62 (talk) 23:32, 24 July 2013 (UTC)
  •   Support we only use number-datatype for numbers that could be used for calculations. String datatype is appropriate here. --Tobias1984 (talk) 06:40, 31 July 2013 (UTC)

Kulturminne identifier / Riksantikvaren identifier

DescriptionUnique ID number used by Riksantikvaren (the Norwegian Directorate for Cultural Heritage) for their kulturminnesøk database. The ID number refers to a single cultural heritage site.
Data typeString
Template parameterN/A
ExampleQ755010 - Borgund Stavechurch which has Kulturminne ID 83933
Format and edit filter validation1321237
Robot and gadget jobsImporting IDs from municipality based lists of cultural heritage sites, for example: nb:Liste over kulturminner i Drangedal, as well as creating and syncing such list in multiple languages.
Proposed byProfoss (talk)

I'm currently engaged as a Wikipedian in Residence with Riksantikvaren. This property would make it a lot easier promote the use of wikipedia in collaboration with the Kulturminnesøk database and the two Norwegian language and one sami language wikipedia. Profoss (talk) 12:43, 24 June 2013 (UTC)

  •   Support Each of 125 000 cultural heritage sites within Norway have this unique ID. Adding the ID to Wikidata may enable syncing between wikiprojects and The Norwegian Directorate for Cultural Heritage H@r@ld (talk) 09:18, 28 June 2013 (UTC)
  •   Comment I think this at some point should be coordinated with Europeana (local version Norwegiana), they will probably need geographical object ids at some point. For now it is more important to get the present projects with Riksantikvaren going, so I say use the available ids and set up a property to handle this unless we should take the work to define generalized location ids. Problem is that some items will need several mutually exclusive locations. There is at least the position itself, then artefacts on that location (that would be Riksantikvarens ids), then also different names for that location in space-time (can have directionality and language constraints - two sides of a mountain with different names), and possibly different roles with separate names (island, city, municipality, etc). I'm tempted to say take the whole id discussion later and use a specialized id for now. Jeblad (talk) 04:36, 6 July 2013 (UTC)
  •   Support Even in the future these IDs will be valuable for historical reasons. And currently they can be of great practical value for maintaining lists of Norwegian cultural heritage sites etc. related to the cultural heritage wikiproject. Danmichaelo (talk) 19:28, 2 August 2013 (UTC)
  •   Support As a valuable cultural heritage Register. --Fralambert (talk) 01:01, 3 August 2013 (UTC)

Length (en) / Länge (de)/ Lunghezza (it)

   Not done
Descriptionlength as a measured dimension (m) of an object, that can also include: railways, metro lines, highways, trunk roads. SI base unit for length is metre (m), although "km" would be a recommended unit for roads, railways, etc.
Data typeNumber (not available yet)
Domainplace, term
ExampleFlorence-Rome railway, 314 km - Template:Q1158780
Robot and gadget jobsa great number of railways and important roads, in many Wikipedias, are provided with infoboxes, including "length" (in km). A bot should parse them without trouble. It is easier to find information of regional/less relevant lines in the relative national Wikipedias.
Proposed byLion-hearted85 (talk) 11:55, 20 July 2013 (UTC)
  Comment A "length" property would be very useful. A few suggestions:
  • List this as a property instead of a qualifier.
  • Leave the "domain" field empty. This property would be applicable well beyond places, and "term" is more or less meaningless. Other possible uses:
We should also try to formally define how "length" differs from the related idea of "height", which has a somewhat ambiguous meaning but would be another very useful property. Emw (talk) 14:50, 20 July 2013 (UTC)
Height can go with width in an (at least) two dimensional and depth (the third dimension, used in common language to denote how deep we are under water but do not seem relevant here), and is usually related to verticality. Lenght seems dimension independant, for example a distance in a 3D space is a length. TomT0m (talk) 14:59, 20 July 2013 (UTC)
Also in common language, size is similar and related. Anyway in french we got taille, longueur, largeur, profondeur, distance ... TomT0m (talk) 15:08, 20 July 2013 (UTC)
  Oppose/  duplicate - We already have a distance property pending (Wikidata:Property_proposal/Pending#Distance). In this generic sense the both terms are synonymous. I will archive this unless somebody can find a good reason not to. --Tobias1984 (talk) 15:11, 29 July 2013 (UTC)

  Not done --Tobias1984 (talk) 10:49, 3 August 2013 (UTC)

Politcal party leader

   Not done
DescriptionLeader of the party
Data typeItem
Template parameteren:template:infobox political party Leader
ExampleLabour Party (Q9630) => Ed Miliband (Q216594)
Proposed byDanrok (talk) 13:39, 14 May 2013 (UTC)
We have specific properties for many things, why would political parties be excluded? Why swap the word leader with headed, when leader is the word in common use? Danrok (talk) 22:41, 17 May 2013 (UTC)
I do not care very much about the "name" of any property, since the title of the "leader" depends on which parti. The leader of Green Party (Q213451) has the title "språkrör" in Swedish and they are two. Feminist Initiative (Q388981) has (today) three leaders with the title "talesperson". Other parties prefer the title "partiordförande" or "partiledare". -- Lavallen (block) 06:28, 18 May 2013 (UTC)
I think a specific property makes sense only if it makes the statement more precise. chief executive officer (P169) arguably does that (a CEO is not a chairman), but I do not see how "Conservative Party: party leader: David Cameron" is better than "conservative party: leader: David Cameron". That said there are some properties that I would definitely support deleting. --Zolo (talk) 06:58, 18 May 2013 (UTC)
Parties do have more than one type of leader, e.g. the elected political leader(s), a chief executive, chairpersons, as well as board members. See for example: [3]. But, I have no objection to a generic "leader" property provided we are able to qualify the persons with roles, CEO, party leader, etc. Danrok (talk) 01:25, 17 June 2013 (UTC)
  Oppose position held (P39) can be used as qualifier and 'Politcal party leader as value (item). Example: Labour Party (Q9630) <members> Ed Miliband (Q216594) <office held> party leader --Nightwish62 (talk) 22:26, 30 June 2013 (UTC)

  Not done can be done with existing properties and queries --Tobias1984 (talk) 10:51, 3 August 2013 (UTC)

Alberta Register of Historic Places identifier (en) / identifiant Registre des lieux historiques de l'Alberta (fr)

DescriptionThe (unique) identifier of the Alberta Register of Historic Places
Data typeString
Domaininstance of Provincial Historic Sites of Alberta (Q7252655)
Allowed valuesnumbers only
ExampleHead-Smashed-In Buffalo Jump (Q683110) ==> 4665-0139
Proposed byBenoit Rochon (talk) 02:50, 27 June 2013 (UTC)

Useful as not all the properties inscribed in the Provincial Historic Sites of Alberta (Q7252655) are present in Canadian Register of Historic Places ID (P477). Benoit Rochon (talk) 02:50, 27 June 2013 (UTC)

  •   Support Danrok (talk) 17:27, 29 June 2013 (UTC)

DPLA identifier

   Done: DPLA ID (P760) (Talk and documentation)
DescriptionDPLA (Digital Public Library of America) is an internet portal that acts as an interface to millions of books, paintings, films, museum objects and archival records that have been digitised throughout United States. This id will be used to link with online resource available through that site.
Data typeString
Domainpublished works
ExampleA book of birds (1908 edition) <DPLA identifier > b25fa28c7e8d01f0fedfd7f8fafc208c
Proposed by--Micru (talk) 00:47, 25 June 2013 (UTC)
  •   Support It might be relevant for digital objects created in US.--Micru (talk) 00:46, 25 June 2013 (UTC)
  •   Support Aubrey (talk) 09:08, 29 June 2013 (UTC)

  Done --Tobias1984 (talk) 13:11, 4 August 2013 (UTC)

Proper motion (Dec.) (en)

   Not done
Descriptionen:Proper motion
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
ExampleAlgol (Q13080)=>−1.44 mas/yr
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)
  •   duplicate a property proper motion was already approved

  Not done --Tobias1984 (talk) 13:16, 4 August 2013 (UTC)

Parallax (en)

   Not done
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
ExampleAlgol (Q13080)=>35.14 ± 0.90 mas
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)

  Not done --Tobias1984 (talk) 13:16, 4 August 2013 (UTC)

Distance (en)

   Not done
Descriptionen:Distance (astrometry)
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
ExampleAlgol (Q13080)=>93 ± 2 ly(= 28.5 ± 0.7 pc)
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)

  Not done --Tobias1984 (talk) 13:16, 4 August 2013 (UTC)

Absolute magnitude (en)

   Not done
Descriptionen:Absolute magnitude
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
ExampleAlgol (Q13080)=>−0.15
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)

  Not done --Tobias1984 (talk) 13:16, 4 August 2013 (UTC)

Absolute bolometric magnitude (en)

   Not done
Descriptionen:Absolute magnitude
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)
  Oppose I prefer to use the property absolute magnitude with a qualifier --Paperoastro (talk) 18:26, 20 July 2013 (UTC)

  Not done --Tobias1984 (talk) 13:16, 4 August 2013 (UTC)

Proper motion (RA) (en)

   Not done
Descriptionen:Proper motion
Data typeNumber (not available yet)
Template parameteren:Template:Starbox astrometry
ExampleAlgol (Q13080)=>2.39 mas/yr
Proposed byGZWDer (talk) 11:04, 8 July 2013 (UTC)

  Not done --Tobias1984 (talk) 13:17, 4 August 2013 (UTC)

Database of cultural heritage ID (en) / číslo restříku ústředního seznamu kulturních památek (cs)

DescriptionID of sinle cultural property
Data typeString
Template parameterID_objektu in WLM lists cs:Šablona:Památky v Česku
Domaingeographic feature, cultural heritage in Czech republic
Format and edit filter validationnumber with hyphens
Robot and gadget jobsShould be added by bots when items are created for single objects.
Proposed byJAn Dudík (talk) 21:29, 28 June 2013 (UTC)
  Support I agree with the property, I'm just not sure about the filter definition. Most of the examples on the linked page content also slash signs, while others are just 6-digit numbers. Looks more like [0-9/\-]{1-12}, but it's worth a second look from someone more familiar with the system.--Shlomo (talk) 16:56, 30 June 2013 (UTC)
  Support But th only problem is that I don't see any exemple for making the property and I don't read Czech.--Fralambert (talk) 14:10, 4 August 2013 (UTC)

PEI Register of Historic Places identifier (en) / identifiant Répertoire des lieux patrimoniaux de l'Île-du-Prince-Édouard (fr)

DescriptionThe (unique) identifier of a property protected under the Heritage Places Protection Act (Q13559774)
Data typeNumber (not available yet)
Allowed valuesnumber only
ExampleProvince House (Q2113954) ==> 3241
Proposed byFralambert (talk) 03:29, 27 June 2013 (UTC)

A another heritage register in Canada. --Fralambert (talk) 03:29, 27 June 2013 (UTC)

  •   Support, just like other provinces who have an Historic places Website. Benoit Rochon (talk) 16:20, 2 July 2013 (UTC)

  Done as string, as all other such identifiers. --  Docu  at 15:15, 4 August 2013 (UTC)

OKTMO (en) / OKTMO (de)/ ОКТМО (ru)

   Done: OKTMO ID (P764) (Talk and documentation)
Descriptionlink to Classification on Objects territory of municipal formations (Russia)
Data typeString
Template parameter"ОКТМО" in ru:template:Сельское поселение, ru:template:Городское поселение etc.
DomainObjects of municipal formations in Russia (main type - place)
Allowed valuesa set of numbers
ExampleBol'shekolpanskoe rural settlement (Q50699) => OKТМО 41618408
Source[4], [5]
Proposed byArt-top (talk) 21:26, 19 July 2013 (UTC)
  Support--Kompakt (talk)
  SupportIvan A. Krestinin (talk) 10:34, 26 July 2013 (UTC)
  Comment the link from the example seems to not work. --Tobias1984 (talk) 09:47, 28 July 2013 (UTC)
Fixed. — Ivan A. Krestinin (talk) 10:35, 28 July 2013 (UTC)
Can you still explain what the difference between this proposal and OKATO ID (P721) is? --Tobias1984 (talk) 13:36, 30 July 2013 (UTC)
There are multiple official classifiers in Russia. It is possible that ОКТМО will replace ОКАТО in the future ([6]). But currently they are exists in parallel. There was no ОКТМО codes for populated places in the past. — Ivan A. Krestinin (talk) 18:08, 30 July 2013 (UTC)
On 1 January 2014 there OKTMO codes for populated places. Temirov1960 (talk) 04:39, 26 March 2014 (UTC)

surface / Belag / surface

Descriptionthe surface on which the tournament is played
Data typeItem
Template parameter"surface" in en:template:Infobox GrandSlamTournaments
Domainsporting events
Allowed valuesall types of surfaces
ExampleWimbledon Championships => lawn
Proposed byKompakt (talk)

I'm thinking of tennis tournaments at the moment, but it certainly has use beyond that. Basically for all types of sports that are played on different surfaces.--Kompakt (talk) 06:16, 27 May 2013 (UTC)

We need a more general property to define in which matter the istem is made not only for sport surface. Snipre (talk) 19:05, 10 June 2013 (UTC)
How about using existing properties like this: material used (P186) = lawn (Q207766) with qualifier applies to part (P518) = tennis court (Q741118). Danrok (talk) 22:35, 25 June 2013 (UTC)
  Support - label should be "surface played on". Solutions with existing properties don't really capture what needs to be said. Simple queries about materials will otherwise result in things like "Wimbledon" being returned. --Tobias1984 (talk) 11:41, 3 August 2013 (UTC)
  Support if the label is changed to 'surface played on'. This property should probably be used to describe the venue rather than the event but either way the property is needed. Filceolaire (talk) 13:44, 3 August 2013 (UTC)

  Done --Nightwish62 (talk) 10:14, 5 August 2013 (UTC)

place (location?) (en) / Ort (de)

   Done: no label (P766) (Talk and documentation)
Descriptionplace where a specific event took (or will take) place
Data typeItem
Template parametere.g. "place" in "en:template:news event" / "location" in "en:template:Infobox rail accident" / "location" in "en:template:music festival"
ExampleGreat Smog (Q913640) => London (Q84) / Battle of the Hornburg (Q1764229) => Helm's Deep (Q1641279)
Proposed byNightwish62 (talk) 09:27, 28 July 2013 (UTC)
If you're supporting this property, please also comment which name (location/place) you're preferring. --Nightwish62 (talk) 09:27, 28 July 2013 (UTC)

  Done --Nightwish62 (talk) 10:16, 5 August 2013 (UTC)


DescriptionA person or organization that contributed in the creation of a creative work.
Data typeItem
Domainpublished works
ExampleDiscworld Noir (Q914128) <collaborator> Terry Pratchett (Q46248)
Proposed by--Micru (talk) 00:47, 25 June 2013 (UTC)
  •   Support The involvement is less than an author (P50), but sometimes the person collaborating is relevant enough to be mentioned.--Micru (talk) 00:46, 25 June 2013 (UTC)
  •   Support LaddΩ chat ;) 21:28, 29 June 2013 (UTC)
  •   Done --Fralambert (talk) 12:56, 5 August 2013 (UTC)

Electoral district

DescriptionFor members of parlaments (local or national), the electoral district the person is representing.
Data typeItem
Template parameterfor example krets in sv:Mall:Riksdagsledamot
ExampleJönköpings (Q10542122) -> Jimmie Åkesson (Q518776) as the sandbox-property is used in this example
Sourceexternal references or Wikipedia list article
Robot and gadget jobspossible
Proposed byLavallen (block)
Nominated as a qualifier property.

This is maybe best applied to Contries who does not have one person per electoral district in the parlament. The Swedish Riksdag for example has 349 seats, but only 29 electoral districts, and svwp has articles for every electoral district, also historical. Lavallen (block) 12:25, 28 July 2013 (UTC)

  Support Even in one member constituencies the electoral district boundaries are usually different from Administrative divisions and need their own property. Filceolaire (talk) 12:28, 5 August 2013 (UTC)
Correct, it's true even in Sweden. The Electoral districts in Sweden are not corresponding to the administrative division, even if it is true in some cases. We have articles about all the Swedish districts on svwp, they are mainly used as lists of MP's. -- Lavallen (block) 12:53, 5 August 2013 (UTC)

  Done --Nightwish62 (talk) 17:06, 5 August 2013 (UTC)


DescriptionIndex in Swedish National Water Information Database (VISS)
Data typeString
Template parameter"sjöid" in sv:Mall:Insjöfakta
ExampleOrlången (Q3424558) => 656833-162888
Format and edit filter validation\d\d\d\d\d\d-\d\d\d\d\d\d
Robot and gadget jobsMost properties mentioned bellow (average_depth, maximum_depth, volume, etc) can be fetched and added automatically from VISS webserver-interface using this property as a key.
Proposed byEsquilo (talk)

Swedish National Water Administration is an important source for information for most lakes, watercourses and fjards in Sweden. Esquilo (talk) 11:10, 23 May 2013 (UTC)

Full   Support! -- Lavallen (block) 11:53, 23 May 2013 (UTC)
  Wait Can we create an unique property for the different national classifications instead of different properties for each natioanl code ? See above for Russia Snipre (talk) 12:50, 29 July 2013 (UTC)
If it is feasable, but the discussion above indicate such solution to be very complicated and awkvard to use. /Esquilo (talk) 14:09, 30 July 2013 (UTC)
If your code can handle different properties in the same code, it can handle different qualifiers too. Snipre (talk) 15:47, 30 July 2013 (UTC)
We need a system here on Wikidata that is easy to use both for ordinary users and for the code in our templates on Wikipedia. Otherwise will this place only be a place for your own entertainment. It's also hard to explain for external data-users why they have to scan through all of Russia, when they are searching for a lake in Sweden. -- Lavallen (block) 13:35, 1 August 2013 (UTC)
  Support, good property. — Ivan A. Krestinin (talk) 14:58, 29 July 2013 (UTC)
  Support good to keep identifiers separate for constraint violations. --Tobias1984 (talk) 13:41, 1 August 2013 (UTC)

drug action altered by (en) / Arzneiwirkung beeinflusst durch (de)

Descriptiona clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (so-called 'precipitant') alters the pharmacokinetics or pharmacodynamics of another substance (so-called, 'object'). The property should be used in this direction: <object> <drug action altered by> <precipitant>
Data typeItem
Examplewarfarin (Q407431) => Lovastatin (Q417740)
Robot and gadget jobsThere should be bots automatically updating drug interaction information from public datasets (depending on what we want to include, there can be hundreds or even thousands of such interactions)
Proposed byMatthiassamwald (talk) 16:36, 31 July 2013 (UTC)
  •   Comment I support the addition of a data element like this but wonder if it should be more specifically called "drug-drug interaction" to distinguish it from drug-food, drug-allergy, and drug-condition interactions. Does the direction of the arrow specify the precipitant and object drugs involved in the interaction? User:Boycer
  • My intention was to make this property useful for both drug-drug and drug-food interactions (see description). I see no need to create distinct properties at this stage. --Matthiassamwald (talk) 20:15, 31 July 2013 (UTC)
  • One of the of the goals of introducing this term is to integrate drug-drug interaction data into wikipedia. My opinion is that it will be better to keep the term very specific because the mechanisms, epistimology, and approach to managing the various kinds interactions in clinical settings patients vary significantly. Also, I see that there might already be a term Drug Interaction User:Boycer
  • I am not sure about the 'directedness' of the interaction. Originally I thought I would simply introduce this as a symmetric property. On the other hand, sources like make a clear distinction between object and precipitant... Do you suggest to make this distinction clear in the property definition? If so, could you suggest an improved (yet still somewhat short) description? --Matthiassamwald (talk) 20:16, 31 July 2013 (UTC)
  • I think that clarifying the direction of the interaction is important. Here is a suggested description based on work forthcoming from the 2013 AHRQ DDI Conference: "a clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (i.e., precipitant) alters the pharmacokinetics or pharmacodynamics of another substance (i.e., object)."
  • If the description I offer in the previous line is acceptable, I think we should also clarify somewhere that a clinically relevant interaction is defined as an interaction that is associated with a clinical outcome serious enough to warrant the attention of clinicians and/or systems involved in the medication therapy process. Depending on the context, the “attention” that a clinically significant potential DDI warrants might include a change in therapy, monitoring, and/or patient education. This will help avoid publishing large lists of DDIs of questionable or unknown clinical relevance under the suggested term. Boycer
  • To incorporate these suggestions, I changed the label from "drug interaction / Arzneimittelwechselwirkung" to "drug action altered by (en) / Wirkung beeinflusst durch (de)". I changed the description from "interaction of a drug with a substance (usually another drug) that affects drug activity when both are administered together" to "a clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (so-called 'precipitant') alters the pharmacokinetics or pharmacodynamics of another substance (so-called, 'object'). The property should be used in this direction: <object> <drug action altered by> <precipitant>"..... The label and description should certainly not become any longer than that! --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
  •   Support I think this approach will be quite satisfactory. Boycer
  • Ideally, we could use this property to represent interactions of different severity and clinical significance, and differentiate between different severity/significance levels using Wikidata qualifiers (we are not limited to simple triples in Wikidata). Tobias1984 -- Do you have suggestions for this? In Wikipedia, will we be able to create queries to only list interactions with a specific significance level and exclude others? This would help to not clutter the UI with interactions that are only mildly relevant to most users. --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
  •   Support - And a qualifier could say something like "interaction = strong" or "interaction = reduces effectiveness". If we keep the number of items we link to low then we can make some really intelligent queries. --Tobias1984 (talk) 23:19, 4 August 2013 (UTC)
  • Sounds good! I guess we have to start another property proposal for this qualifier property after this property is approved... --Matthiassamwald (talk) 08:50, 5 August 2013 (UTC)
  •   Comment How do you plan to add information about what the interaction is? Also the molecular biology people are using physically interacts with (P129). Could you use that property instead? --Tobias1984 (talk) 18:19, 31 July 2013 (UTC)
  • One could use qualifiers to add further information about the nature of the interaction. physically interacts with (P129) is a wholly different kind of property. In a drug interaction, the drugs are not interacting directly/physically. So I think the property I proposed is entirely novel. --Matthiassamwald (talk) 20:15, 31 July 2013 (UTC)
  • I agree that the proposed term represents a distinct concept from physically interacts with (P129) but disagree with the comment that drugs do not interact directly. While most interactions involve some indirect mechanism, adsorption and chelation drug-drug interactions are in fact physical interactions. So, I would distinguish the proposed term from physically interacts with (P129) by stating that its both broader and of a different focus. Its broader in the since that some drug-drug interactions be of type physically interacts with (P129), and broader in the since that we are about the clinical implication of the interaction. User:Boycer
  • I know that there are few cases where drug interactions also can be caused by direct interactions. Usually, this is not the case. Still, they are clearly distinct properties, and one cannot substituted for the other. Any other, more subtle relationships are completely out of scope for Wikidata purposes. --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
  •   Support I think the proposal is mature and ready for inclusion into Wikidata now, thanks to the feedback from Boycer and Tobias1984. --Matthiassamwald (talk) 08:50, 5 August 2013 (UTC)
  •   Support I agree and look forward to the discussion of the qualifier(s) Boycer

  Done --Tobias1984 (talk) 08:33, 6 August 2013 (UTC)

cause of destruction (en) / Grund der Zerstörung --> (de)

Descriptionincident which destroyed the item
Data typeItem
Domainplace, creative work, (term?)
ExampleColossus of Rhodes => earthquake
Proposed byNightwish62 (talk) 10:28, 17 June 2013 (UTC)
  • Your example uses "earthquake" as the value. Shouldn't it be 292 BC Rhodes earthquake (Q2060017)? Or is the property intended to only give general causes? --Yair rand (talk) 16:38, 17 June 2013 (UTC)
  • There are many cases where I wished we could express cause, and I would suggest a generic property to be used as a qualifier. In this case, I guess it could qualify "key event: destruction" (or "destruction date: 226 BC" depending on the format we choose). --Zolo (talk) 16:55, 17 June 2013 (UTC)
Sounds like destructive force would be more appropriate, things like flood, fire, earthquake and explosion would fit. Cause of destruction is quite ambiguous. Danrok (talk) 19:34, 23 June 2013 (UTC)
Change to "Cause" and use as a qualifier to "Key Event" above. Filceolaire (talk) 21:25, 24 July 2013 (UTC)
  Support this is currently the best solution to store this information. It can be used both on its own e.g. the Hindenburg or as a qualifier or for cities that were destructed multiple times in their history. We should link to the specific natural disaster if it has an own item 1906 San Francisco earthquake (Q211386) --Tobias1984 (talk) 11:32, 2 August 2013 (UTC)
Right. Beside this: The problem how to link exist in most other properties to. Should we list all mayors or a city individual or create a item 'mayors of city xyz' and put this into city xyz? Same for sport contest (link individual players or the 'English football team of WM 2006'), movies (individual cast members or outsource the cast members to it's own item and linking this), and so on and so forth. So this is a big question which concern many properties, therefore we should discuss this outside this proposal.
However: The key-event-modeling has been rejected and the RfC has closed meanwhile. --Nightwish62 (talk) 11:46, 2 August 2013 (UTC)

  Done --Tobias1984 (talk) 09:25, 6 August 2013 (UTC)

Municipality code (CH)

Descriptionid for municipalities in Switzerland
Data typeString
Template parameter"Codice statistico" in it:Template:Divisione amministrativa (Swiss places), "municipality_code" in en:Template:Infobox Swiss town
Domainmunicipalities in Switzerland
ExampleVacallo (Q67470) = 5268
Proposed by- Vacallo (talk) 05:20, 3 June 2013 (UTC)
  •   Support Also good for Danish municipalities. --Laketown (talk) 13:02, 6 June 2013 (UTC)
  •   Support Danrok (talk) 02:08, 9 June 2013 (UTC)
  •   Support Note that this code must be interpreted in the context of a specific country. Jeblad (talk) 04:39, 6 July 2013 (UTC)

  Done --Tobias1984 (talk) 07:51, 7 August 2013 (UTC)

BFS-Number (en) / BFS-Nummer --> (de)

   Not done
DescriptionNumber assigned by the federal authority of the Swiss Confederation (FSO)
Data typeNumber (not available yet)
Template parameter"BFS" in de:template:Infobox Ort in der Schweiz
ExampleZürich (Q72) => 0261
Format and edit filter validation4 digit number
Proposed byNightwish62 (talk) 23:36, 22 June 2013 (UTC)

  duplicate --Tobias1984 (talk) 07:55, 7 August 2013 (UTC)

INE municipality code (en)

Descriptionmunicipality identifier by the National Institute of Statistics (INE) in Spain
Data typeString
Template parameter"codi" in ca:Plantilla:Infotaula del municipi espanyol
ExampleChiclana de la Frontera (Q277302) = 11015
Sourcemunicipality codes
Proposed byAlbertvillanovadelmoral (talk) 08:35, 26 July 2013 (UTC)
  Support--Kompakt (talk)
  SupportIvan A. Krestinin (talk) 10:33, 26 July 2013 (UTC)

  Done --Tobias1984 (talk) 08:02, 7 August 2013 (UTC)


   Done: LAU (P782) (Talk and documentation)
DescriptionLAU 1 and LAU 2 - local administrative unit, renamed from NUTS 4 and NUTS 5
Data typeString
Template parametercs:Šablona:Infobox české obce a města (par. NUTS5), cs:Šablona okres (par. NUTS)
ExampleBlansko District (Q804356) = CZ0641, Blansko (Q850676) = CZ0641 581283
Proposed byShlomo (talk)

I asked at Property talk:P605 if the NUTS code (P605) could be used for LAU codes as well, since they are an extension of NUTS 1-3 and a direct continuation of NUTS 4-5. I was asked to move the discussion here in order to attract more contributors. Please make your opinion whether we should rename/redefine NUTS code (P605) to NUTS/LAU or we should create a new LAU property. I personally prefer the first variant, but both of them are acceptable for me. Shlomo (talk) 10:17, 12 June 2013 (UTC)

  •   Support I have also proposed to create a LAU2 code for municipalities (see link here Wikidata_talk:Country_subdivision_task_force#Municipality_codes_in_the_European_Union). --Albertvillanovadelmoral (talk) 14:16, 26 July 2013 (UTC)
    I don't think we need special properties for LAU1 and LAU2. Particular levels and versions of LAU can be described by qualifiers. (Actually, I don't think we need special properties for LAU and NUTS either, but I can live with this).--Shlomo (talk) 06:59, 30 July 2013 (UTC)
    Yes, I agree. My link was to point out that this new property would indeed be very useful, among other things, to substitute many other current properties used to identify municipalities by a code number. --Albertvillanovadelmoral (talk) 09:20, 30 July 2013 (UTC)
  •   Support. [[#ref_{{{1}}}|^]]  cz.nuts5 for Blansko (Q850676) should be 581283 only, because this part of code is often used as stand-alone (in many databases). JAn Dudík (talk) 20:15, 29 July 2013 (UTC)
    I changed the proposal appropriately. Please remember this if you plan to program a robot to extract the NUTS5 parameter from cs:Šablona:Infobox české obce a města - it usually has the long version as a value.--Shlomo (talk) 07:18, 30 July 2013 (UTC)
    Better used directly the offical document of Eurostat here and put Eurostat as source. It's time to use offical document instead of infobox data. Snipre (talk) 09:11, 30 July 2013 (UTC)

ISO 3166-3

   Done: ISO 3166-3 (P773) (Talk and documentation)
DescriptionThis is part of the ISO 3166 standard published by the International Organization for Standardization (ISO). It defines codes for country names which have been deleted from ISO 3166-1 since its first publication in 1974. The official name of the standard is Codes for the representation of names of countries and their subdivisions – Part 3: Code for formerly used names of countries. It was first published in 1999. Each former country name in ISO 3166-3 is assigned a four-letter alphabetic code.
Data typeString
Template parametershould be added into en:Template:Infobox former country
Domainformer countries which ceased to exist after 1974, the list: en:ISO 3166-3#Current codes
Allowed valuesfour uppercase ASCII letters
ExampleQ33946 => "CSHH"
Format and edit filter validationPCRE: [A-Z]{4}
Source[7], [8], en:ISO 3166-3
Robot and gadget jobs

1. Any subject must not have both ISO 3166-3 and ISO 3166-1 codes.
2. There must not be two subjects with the same ISO 3166-3 code. (The code is unique.)
3. After releasing an update of ISO 3166‑3 [9] the new values could be imported.
4. More complex rules for value checking of a code abcd (could change in the future):
a) cd value: "HH" or "XX", ab value any
b) cd value: "AA", ab value is one of ISO 3166-1 Alpha-2 codes

c) cd value: one of ISO 3166-1 Alpha-2 codes, ab value any
Proposed byPabouk (talk)

We already have ISO 3166-1 codes for existing countries we should have ISO 3166-3 codes for countries which used to have an ISO 3166-1 code. --Pabouk (talk) 11:02, 21 May 2013 (UTC)

  Done --Tobias1984 (talk) 10:39, 7 August 2013 (UTC)


DescriptionOfficial identification Code for geographic objects in the US, see: Federal Information Processing Standard
Data typeString
Template parameteren:template:geobox/type/settlement: blank_info.
Domainall kinds of geographic objects in the US

  Comment - does concern only administrative geographic objects, does not exist for rivers or mountaines. Possible to fetch also from w:de:Vorlage:Infobox Ort in den Vereinigten Staaten, parameter name: Fips --Matthiasb (talk) 13:06, 7 March 2013 (UTC)

It also concern CDP's. -- Lavallen (block) 20:56, 21 March 2013 (UTC)
  •   Comment Datatype should be String. The future of this property is seemingly limited as the US gov't is phasing out FIPS codes in favor of GNIS IDs. Mrwojo (talk) 16:50, 26 March 2013 (UTC)
  • Having the data around might still be useful. There may be applications of FIPS codes beyond that of the government, that may continue using those codes after the government stops, or someone may need the codes for some historical reason, etc. —Scott5114 [EXACT CHANGE ONLY] 18:53, 15 April 2013 (UTC)
  •   Support Regardless of whether it will be phased out, it is already used in most infoboxes of cities in the US. The Anonymouse (talk) 17:59, 4 June 2013 (UTC)

  Done --Tobias1984 (talk) 10:44, 7 August 2013 (UTC)

Urban area code in Sweden

DescriptionCity Code (Q10708035)
Data typeString
ExampleT7524 or 7524 for Kramfors (Q645351) or TX006 or X006 for Alby (Q934689)
Robot and gadget jobsGather data from this list: the use of parameter tätortskod sv:Mall:Ortsfakta Sverige.
Proposed byLavallen (block) 11:24, 1 August 2013 (UTC)
  •   Comment In this list sv:Lista_över_Sveriges_tätorter Tätortskod column gives "7400" for Alby. Is that a different Tätortskod? --Tobias1984 (talk) 13:07, 1 August 2013 (UTC)
    • That is "Alby, Ånge kommun". "Alby, Botkyrka kommun" is missing in that list, since it ended to exist as an independent urban area in the 1970's. But there is an object for it. --- Lavallen (block) 14:49, 1 August 2013 (UTC)
  •   Comment Which list and infobox field exactly? —Ruud 13:59, 1 August 2013 (UTC)
    • tätortskod in sv:Mall:Ortsfakta Sverige. Observe that this code sometimes is written with an "T" in the beginning, and sometimes not. Today I and Statistics Sweden prefer a "T" in the beginning, but it is not mandatory. -- Lavallen (block) 14:49, 1 August 2013 (UTC)

  Done --Tobias1984 (talk) 10:49, 7 August 2013 (UTC)

Minor urban area code in Sweden

DescriptionSmåortskod (Q10672543)
Data typeString
ExampleS9729 for Herrskog (Q2417483)
Robot and gadget jobsGather data from Template "Ortsfakta Sverige", for each entitiy that has "småortskod = S9729" filled in.
Proposed byLavallen (block) 11:24, 1 August 2013 (UTC)
  •   Strong support - Identifier used in Infobox. --Tobias1984 (talk) 13:15, 1 August 2013 (UTC)
  •   Support Looks okay too me. —Ruud 13:43, 1 August 2013 (UTC)
  • But be carefull with botimport to Wikidata. Many articles are about 2 or 3 three urban areas. Many articles have no code in the infobox yet, and many articles on NLWP and SVWP are not identified yet. We will do an inventory of this set of articles very soon. -- Lavallen (block) 15:28, 1 August 2013 (UTC)

  Done --Tobias1984 (talk) 10:52, 7 August 2013 (UTC)

Civil parish code/ATA-code in Sweden

Descriptioncivil parish-code for Sweden (Q14175801)
Data typeString
Example2482 for Nora socken (Q10601915)
Robot and gadget jobsGather data from Template "Infobox socken Sverige" from each entity that has "sockenkod" entered.
Proposed byLavallen (block) 11:24, 1 August 2013 (UTC)
  Support - Used in infobox. --Tobias1984 (talk) 13:18, 1 August 2013 (UTC)
  •   Support Looks okay too me. —Ruud 13:44, 1 August 2013 (UTC)

  Done --Tobias1984 (talk) 10:56, 7 August 2013 (UTC)

Code for parishes in the Church of Sweden

DescriptionChurch of Sweden parish code (Församlingskod) (Q10501451)
Data typeString
Example228202 for Nora-Skogs församling (Q10601889)
Robot and gadget jobsGather data from template "församlingsfakta" from field "församlingskod"
Proposed byLavallen (block) 11:24, 1 August 2013 (UTC)
  •   Support - used in infobox --Tobias1984 (talk) 13:22, 1 August 2013 (UTC)
  •   Support Looks okay too me. —Ruud 13:46, 1 August 2013 (UTC)

  Done --Tobias1984 (talk) 10:58, 7 August 2013 (UTC)


DescriptionPastoratkod" (not been able to translate it, it's an administrative level between Parish and Diocese for the Church of Sweden, the Church of Sweden is still not completly separated from the administrative division of the nation, but it will shortly in the future)
Data typeString
Example100109 for Nora-Skogs församling (Q10601889)
Robot and gadget jobsGather data from template "församlingsfakta" from field "pastoratskod"
Proposed byTobias1984 (talk)
  •   Support --Tobias1984 (talk) 13:24, 1 August 2013 (UTC)
  •   Support Looks okay too me. I think both Pastoratkod and Församlingskod translate to "parish code" in English. —Ruud 13:55, 1 August 2013 (UTC)
    • Most likely, but they are two different kinds of Parishes on two levels. Every församling is inside a pastorat, and sometimes, like in the example, there is only one församling in one pastorat. -- Lavallen (block) 15:31, 1 August 2013 (UTC)

  Done --Tobias1984 (talk) 11:01, 7 August 2013 (UTC)


(fr) signes cliniques

   Done: symptoms (P780) (Talk and documentation)
Descriptionsymptoms a disease has
Data typeItem
Template parameter?
Allowed valuesall types of symptoms
Examplemeningitis (Q48143) = headache (Q86), meningism (Q32069), photophobia (Q281289), phonophobia (Q2434711)
Format and edit filter validationtarget item has to be a subclass of symptom
Sourcemedical literature
Robot and gadget jobs?
Proposed byTobias1984 (talk)
  Support Note that the annotations between diseases and phenotypes can be drawn from (and phenotypes can be linked to HPO terms). --Andrew Su (talk) 21:10, 11 July 2013 (UTC)
I also plan to create a bot for automatically porting data from ontologies/linked data sources into Wikidata (in this case, from drug interaction data from NDF-RT and DrugBank). Maybe there could be some synergies with this suggested import from HPO? --Matthiassamwald (talk) 18:56, 5 August 2013 (UTC)
  Support Makes sense. --Matthiassamwald (talk) 18:56, 5 August 2013 (UTC)

  Done --Tobias1984 (talk) 16:11, 7 August 2013 (UTC)


   Done: SIKART ID (P781) (Talk and documentation)
Descriptionidentifier in SIKART (Q683543), a biographical dictionary and a database on visual art in Switzerland and Liechtenstein
Data typeString
Template parameterfr:Modèle:SIKART, en:Template:SIKART
ExampleLe Corbusier (Q4724) = 4000293, Friedrich Traffelet (Q1462543) = 4026315
Proposed by- Vacallo (talk) 05:06, 10 June 2013 (UTC)
  •   Support Seems useful.--Kompakt (talk) 06:24, 13 June 2013 (UTC)
  •   Support--Micru (talk) 01:34, 8 July 2013 (UTC)

  Done --Tobias1984 (talk) 19:18, 7 August 2013 (UTC)

Mushroom Infobox

Hymenium type

DescriptionType of spore-bearing surface: gills, pores, et cetera.
Data typeItem
Template parameter"hymeniumType" in en:template:Mycomorphbox
Allowed valuesgills, pores, smooth, ridges, teeth, gleba
ExampleQ320999 => "gills", Q271098 => "pores"
Robot and gadget jobsRobot could scrape wikipedia articles to collect this information.
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   oppose datatype - items can be created for those limited number of types, plus the term need to be translatable. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Mushroom cap shape

DescriptionDescriptor of the general shape of the cap.
Data typeItem
Template parameter"capShape" in en:template:Mycomorphbox
Allowed valuescampanulate, conical, convex, depressed, flat, infundibuliform, offset, ovate, umbilicate, umbonate, no, NA
ExampleQ320999 => "convex", Q271098 => "offset"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   oppose datatype - items can be created for those limited number of shapes, plus the term need to be translatable. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Hymenium attachment

DescriptionDescriptor of how the hymenium attaches to the stem. Applies even to ridged, toothed and pored species, despite parameter name.
Data typeItem
Template parameter"whichGills" in en:template:Mycomorphbox
Allowed valuesadnate, adnexed, decurrent, emarginate, free, seceding, sinuate, subdecurrent, no, NA
ExampleQ320999 => "free", Q271098 => "NA"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   oppose datatype - items can be created for those limited number of types, plus the term need to be translatable. NA could probably be NoValue? --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Stipe character

DescriptionIndicates if a universal or partial veil is present.
Data typeItem
Template parameter"stipeCharacter" in en:template:Mycomorphbox
Allowed valuesbare, ring, volva, ring and volva, cortina, NA
ExampleQ320999 => "bare", Q271098 => "NA"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   oppose datatype - items can be created for those limited number of types, plus the term need to be translatable. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Spore print color

DescriptionColor of the spore print.
Data typeItem
Template parameter"sporePrintColor" in en:template:Mycomorphbox
Allowed valuesblack, blackish-brown, brown, buff, cream, green, ochre, olive, olive-brown, pink, pinkish-brown, purple, purple-black, purple-brown, reddish-brown, salmon, tan, white, yellow, yellow-orange
ExampleQ320999 => "white", "buff", Q271098 => "brown"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   oppose datatype - We already have items for different colors. So this should be item-datatype. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Mushroom ecological type

DescriptionIndicates how the mushroom obtains nutrients.
Data typeItem
Template parameter"ecologicalType" in en:template:Mycomorphbox
Allowed valuesmycorrhizal, parasitic, saprotrophic
ExampleQ320999 => "saprotrophic", Q271098 => "parasitic", "saprotrophic"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

Mushroom edibility

   Done: edibility (P789) (Talk and documentation)
DescriptionIndicates whether the mushroom is edible or poisonous.
Data typeItem
Template parameter"howEdible" in en:template:Mycomorphbox
Domainmushrooms. (Could be made into a generic Edibility or Toxicity Property??)
Allowed valueschoice, edible, inedible, unpalatable, caution, psychoactive, poisonous, allergenic, deadly, unknown
ExampleQ320999 => "choice", Q271098 => "edible"
Proposed byEmok (talk) 21:19, 31 July 2013 (UTC)
  •   Support All the mushroom infobox additions seem to make sense to me. --Matthiassamwald (talk) 10:06, 1 August 2013 (UTC)
  •   Comment I think this should be generalized to all foods, substances,... and should get the species qualifier to distinguish humans from other animal. Example:
  • chocolate
  • edibility = palatable / edible
  • species = human
  • edibility = may be poisoneous
  • species = dog
In the case of poisenous foods we should try to add another qualifier that links to the item about the poison and the concentration that would be lethal. --Tobias1984 (talk) 11:03, 2 August 2013 (UTC)
  •   oppose datatype - Limited amount of items can be created and string is not translatable. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
  •   Support - changed datatype after consulting Emok. Concept of edibility should go further than just mushrooms. --Tobias1984 (talk) 16:01, 7 August 2013 (UTC)

  Done --Tobias1984 (talk) 22:34, 9 August 2013 (UTC)

approved by (en)

   Done: approved by (P790) (Talk and documentation)
Descriptionitems that are approved by other items
Data typeItem
ExampleGNU General Public License (Q7603) = Open Source Initiative (Q845918), Boost Software License (Q2353141) = Free Software Foundation (Q48413)
Proposed byGZWDer (talk) 10:34, 21 June 2013 (UTC)
  Move --Tobias1984 (talk) 13:29, 4 August 2013 (UTC)
  Support --Tobias1984 (talk) 13:34, 4 August 2013 (UTC)
  Comment Just note it can be in conflict with Wikidata:Property proposal/Generic#executing authority / power of decision (en). We have also to make sure it is not a another version of maintained by (P126) and owned by (P127). --Fralambert (talk)
In my opinion we need a certain amount of basic language properties in order to make semantic relations between items. Owning, maintaining and approving something would never get mixed up in a day-to-day conversation. So I don't see a point in combining them on Wikidata. This proposal will also get rid of two boolean-datatype proposals (See approved by OSI). I also don't see the connection with "executing authority/power of decision". Having something and doing something are just too far apart to be combined in one property. --Tobias1984 (talk) 18:08, 7 August 2013 (UTC)
  Support Ok, I think I undertand the difference between «approved by» and «executing authority». --Fralambert (talk) 22:02, 10 August 2013 (UTC)

former / ehemalige / ancien(ne) / voormalige

   Not done
Descriptionindication that the value of the property has been valid in the past, but is not valid anymore.
Data typeboolean-invalid datatype (not in Module:i18n/datatype)
Allowed valuesNot applicable
RAF Abbots Bromley would get property Royal Air Force station with qualifier "former"
Aalst would get property Dutch municipality with qualifier "former"
Lake Agassiz would get property lake with qualifier "former"
SourceLists of former items (e.g. Category:Former lakes, List of former Royal Air Force stations)
Proposed byNormanB (talk) 22:37, 13 May 2013 (UTC)

The need for this qualifier has already been discussed several times, for example here. NormanB (talk) 22:37, 13 May 2013 (UTC)

  •   Oppose – We already have proposals for qualifiers until and as of which are waiting for the time datatype. If any of these two is used, it automatically implies "former", so a more unprecise former qualifier is not needed. Byrial (talk) 23:36, 13 May 2013 (UTC)
  •   Oppose, per Byrial. --Yair rand (talk) 23:41, 13 May 2013 (UTC)
    • Dear Byrial and Yair rand, for historical items the as of and/or the until dates are often unknown. How would you then be able to record that the property is not currently valid anymore? How could you tell for example that a lake is a former lake and not a current lake?, that a building was an Royal Airforce station, but not anymore? The until qualifier will only allow dates, so it doesn't allow "unknown, but definitely before today", which is what former would mean. --NormanB (talk) 10:08, 14 May 2013 (UTC)
      • Yes, it allows unknown. For unknown dates, you can always use "until somevalue". "somevalue" is a special value indicating that a value do exist but it is unknown. Alternatively, I think you will also be able to use a time value with a very little precision, like for instance a 1000 year range. Byrial (talk) 13:42, 14 May 2013 (UTC)
  •   Oppose, the "from", "until" and "as of" are better ways to describe the time of a statement. --NaBUru38 (talk) 13:10, 14 May 2013 (UTC)
  •   Support, because this qualifier will let us handle situations that "until" and "as of" won't handle well. I disagree with one of Byrial's points in particular. To say something is true "as of" a certain date does not necessarily mean that it is no longer true. If I have a source saying that the Mayor of London on 30 July 2012 was Boris Johnson, that doesn't mean he is no longer the Mayor.
I also think "until" "somevalue" doesn't clearly imply former status. Why can't "somevalue" refer to an unknown date in the future? And using a very imprecise time value is an ugly kludge. How would people know what value to search for, for example? It's much better to add a clear "former" qualifier.
My one concern about the proposed "former" qualifier is that it is possible for "former" statuses to become true again (e.g. if a former Mayor is elected Mayor again later), so I think the qualifier should take an (optional) time value to specify when the statement was made. --Avenue (talk) 00:43, 16 May 2013 (UTC)
1) I think that it would be abuse of "as of" to mark a point somewhere in a time range, but even if that is deemed acceptable you can still also use "until somevalue" in addition to that. 2) How could "somevalue" be a future date? That would mean that you would be able to predict the future. Well no immortal person can be Mayor of London forever, but there would be no point in stating that with a "until somevalue" qualifier. 3) If a former mayor (statement using "until" or "former" qualifier) becomes mayor again, then you create another statement for this fact with a new "from" qualifier" Byrial (talk) 06:28, 16 May 2013 (UTC)
1) The natural English meaning for "as of" doesn't seem so restrictive to me. For example, see the asof template on enwiki. If the qualifier was called "as at", I would be more likely to agree with you.
2) I see this as mainly being a matter of good style. Even if "until somevalue" was equivalent to "former", it's much less intuitive, and I think the readability of data is especially important on an open wiki like this. I'm also still unconvinced that future dates make no sense, even for "until", although a good example escapes me at present.
3) My point was that an undated "former" qualifier runs the risk of later becoming incorrect, and that adding the date the statement was made would avoid this risk. I don't see any way of avoiding this problem with the "until somevalue" approach. Yes, adding a new statement with a new "from" qualifier could fix the problem (once someone gets around to doing that), but I think we should try to avoid making statements that may become inaccurate until someone gets around to fixing them. --Avenue (talk) 08:45, 16 May 2013 (UTC)
"Nobody is Mayor of London forever?" Well, tell that to Kim Il-sung (Q41117)! -- Lavallen (block) 14:59, 16 May 2013 (UTC)
Ad 2) When Boris Johnson would announce his resignation per 2014-01-01, the until date would lie in the future.
Ad 3) Avenue, I agree with you that there is a chance that an undated 'former' qualifier later becomes incorrect. But this is basically true for all information on Wikidata. Do you really feel we should record a 'per'-date on every 'former'-qualifier to prevent this in this case? --NormanB (talk) 23:03, 16 May 2013 (UTC)
2) I was looking for an example where the date was in the future, but still unknown. Maybe something like deprecated software features, or a situation like the cheating husbands puzzle.
3) No, I think most "former" qualifiers wouldn't need a date, because that status is unlikely to change. I do think it could be useful in some situations though. I did propose the date should be optional. --Avenue (talk) 23:39, 16 May 2013 (UTC)
  •   Comment @Byrial: "Former" means "until some date, which for sure lies in the past". So, even if the until date is unknown, it is still certain that it lies in the past. This is clearly not the same as "until somevalue", which means that the until date is not known at all. When we stick with the example of Boris Johnson, the following statement is currenly valid, while he is still mayor, which shows that "until somevalue" is not the same as 'former': <since>='2008-05-04' and <until> = 'somevalue'. --NormanB (talk) 23:03, 16 May 2013 (UTC)
    • NormanB and Avenue: Please give a concrete example of a still valid statement where it would make sense to use "until somevalue". If "somevalue" is the future, how can you know that it will happen: 1) if it because everyone eventually dies, and thus cannot hold an office forever, it makes no sense to state that for every use of position held (P39) and other properties. 2) if it is because there is a planned or announced date for something to end, you can enter that date as value instead of somevalue. Byrial (talk) 08:13, 17 May 2013 (UTC)
      • Dear Byrial, I already gave the example of Boris Johnson with <since>='2008-05-04' and <until> = 'somevalue'. It may be wrong or useless in your opinion to use 'until somevalue' this way, but that doesn't make the statement invalid. So people could use 'until' like this, without the intention of implying 'former'. 'Until somevalue' simply means something else then 'former', so I don't think we should try to see if we can use it as an equivalent when it is not. This can only cause trouble. 'Former' is equal to 'until somedate in the past', but such value for 'until' will not be possible, or will it? --NormanB (talk) 11:55, 17 May 2013 (UTC)
        • Yes, it is not technically false to say that Boris Johnson will stop being Mayor of London some unknown date, and I admit that it may be a source of errors to demand that "somevalue" must be in the past, so I regret that I proposed that. However I still feel that it is unnecessary to have both "until" and "former" qualifiers, as you will always be able to use "until" with some given past date to indicate "fomer". For the examples in the proposal, it could be: RAF Abbots Bromley (Q7275121) instance of Royal Air Force station (Q7373622) until 31 March 1949, Aalst (Q2661558) instance of municipality of the Netherlands (Q2039348) until 1923, Lake Agassiz (Q390804) instance of lake (Q23397) until 6200 BC precision 250 years (or whatever precision the sources for the claim say). You will even be able to specify different precisions backwards and forwards in time according to meta:Wikidata/Data_model#Dates and times. Byrial (talk) 13:09, 17 May 2013 (UTC)
          • I am glad that you agree that 'until somevalue' is not equal to 'former'. But I have to disagree when you say that "you will always be able to use "until" with some given past date to indicate "fomer"". Cleopatra IV of Egypt is the former wife of Antiochus IX Cyzicenus. The from and until dates of their marriage however are unknown. I don't see which 'until' date could validly be used here. --NormanB (talk) 15:30, 17 May 2013 (UTC)
          • And even if such a date could be conceived, please consider practical use. A list like this could be automatically generated from Wikidata data. This would be easy if all relevant former Royal Air Force stations can be recognised by a 'former' qualifier. If such qualifier does not exists and the 'until'-date would have to be used, the query will become much more complex, since Royal Air Force stations can then only be included in the list when 1. an until-date qualifier is available, 2. the value of that is not empty or equal to 'somevalue', 3. the value is a date in the past. And getting a Royal Air Force stations on the list would be difficult as well. In stead of just adding a 'former'-qualifier, one would have to come up with some "until-date". If the until-date is not clearly known, this can be a lot of work or lead to the use of made-up dates. --NormanB (talk) 15:46, 17 May 2013 (UTC)
            • I don't know how difficult it will be to make the query as the query entity does not yet exist, but it is something you only have to do once to make the list. And yes, it may be more work to enter an until qualifier with a date value, than just a former qualifier without a date, but you should enter the until date anyway, and then nothing is saved on that account. And if somebody deliberately enter made-up dates not supported by a source, they should be kicked out of Wikidata. Byrial (talk) 17:54, 17 May 2013 (UTC)
              • Why should you enter an until date anyway? When someone can't find the until date, they could add the 'former' qualifier, and that would be correct in itself. --NormanB (talk) 01:01, 18 May 2013 (UTC)
  •   Support, if you have several sources writing about a person being a former mayor who is now retired, but it is unclear in what year/date he stepped down, the until-property cannot be used. If you have sources that confirm an old airfield is closed, but you cannot find a source for the year it was closed, the until-property cannot be used. In those kind of situations 'former' can be useful I think. - Robotje (talk) 05:19, 18 May 2013 (UTC)
The point is that you don't have to state an exact date/year. You will be able to add a "precision"-parameter to a time-value that allows you to specify a range of time. As to your example of airfields, this would probably be the 20th century (if you have no idea when the airfield was established), or "from 1900 to 2013" or something similar. The same is true with the mayor whose retirement date is unknown - still you'll be able to specify this date with a precision of years, decades or at least centuries. A "former"-qualifier doesn't have this more precise information, for it can't tell whether something ended yesterday or 5 million years ago.--Kompakt (talk) 09:07, 18 May 2013 (UTC)
  •   Support, specification of a start/end date is not sufficient. For many object (buildings, castles) the exact dates of a change of function maybe unknown so the qualifier 'former' will help. Michiel1972 (talk) 22:28, 5 June 2013 (UTC)
  •   Support I'm not sure we can have a property with no object like this. Maybe it has to be "former"->true.
I had thought a from date range and an until date range would do this but we have to follow what sources say so I've come around to this property. Filceolaire (talk) 20:40, 6 June 2013 (UTC)
  •   Support Yes, I think former can be boolean-invalid datatype (not in Module:i18n/datatype) data type (not available yet), and it can be optional (ie ignored) when there is a statement of end time (P582) or point in time (P585).--GZWDer (talk) 12:16, 28 June 2013 (UTC)
  •   Oppose If each statement has to be sourced then you will get a date for the end of a characteristic or at least an interval. This qualifier is dangerous because it will be mainly used by people knowing that something is not more valid but without knowing exactly when this applies. Wikidata need sources and even if the sources are not providing an accurate date, with a source you can define the "until date" from the publication date of the source. Snipre (talk) 13:29, 28 June 2013 (UTC)
    • Dear Snipre, specifiying an until date from the publication date of the souce would be really wrong. Take for example an article dated march 2nd 2013 about a former army base. If it is unknown until when the base was in use, using march 2nd 2013 would be nonsense. That would be entering wrong info into Wikidata. --NormanB (talk) 00:46, 4 August 2013 (UTC)
  •   Oppose – if I understand well, until:somevalue will do exactly this. Littledogboy (talk) 22:06, 2 August 2013 (UTC)
    • Dear Littledogboy, I sorry to say that 'until:somevalue' does NOT do exactly this, since 'somevalue' could be any date and former implies a date in the past. Former means the same as 'until:someday in the past'. If you prefer creating a value 'somedate in the past' for 'until' I could live with that, but I still feel it is much more usefull to use the term 'former' in stead. --NormanB (talk) 00:46, 4 August 2013 (UTC)
  Oppose - boolean datatype is not on the roadmap and contrary to the semantic framework of Wikidata. Either this has to be changed to "former instance of", "former subclass of" (both item datatype) or handled with qualifiers. Example:
  • instance of (P31) = Abandoned site (or "abandoned air force base" if it needs to be more specific)
I chose "abnonded site" because there are still some buildings left that can be identified as airforce infrastructure. After that would be eroded or demolished I would add:
  • instance of (P31) = Abandoned site (or "abandoned air force base" if it needs to be more specific)
I think that this will be a consistent and semantic approach for all historic information. --Tobias1984 (talk) 08:32, 4 August 2013 (UTC)
  Oppose. Tobias1984's example above looks fine to me, we don't need another property to complicate things. For most things, start and end dates are known. Even if they are not known precisely, the time datatype allows things like "in the 1940s" or "in the 20th century". Mushroom (talk) 16:36, 7 August 2013 (UTC)

  Comment 7 votes against and 5 in favor. I will archive this unless somebody has anything to add. --Tobias1984 (talk) 18:18, 7 August 2013 (UTC)

  Oppose - it's adding something that's, in essence, the same as some other properties. Dusti*poke* 03:35, 12 August 2013 (UTC)

  Not done --Tobias1984 (talk) 06:14, 12 August 2013 (UTC)

height (en) / Höhe/Größe (de)

   Not done
Descriptionheight of an object or person, optionally qualified to indicate the specific reference point used
Data typeString
Domainperson, object
Allowed valuesstrings representing positive numbers (possibly fractional), followed by a unit
  1. Eiffel Tower (Q243) => ["324.00 m" ("reference point" => "antenna spire"), "300.65 m" ("reference point" => "roof"), "273.00 m" ("reference point" => "top floor")]
  2. Robert Wadlow (Q192789) => "2.72 m" ("point in time" => "27 Jun 1940")
Proposed bySchneelocke (talk) 18:25, 10 August 2013 (UTC)
Yeah, we will have to see how the different height measurements of buildings can be handled, but until then we are not going to run out of work that could be done :) --Tobias1984 (talk) 14:07, 11 August 2013 (UTC)

  Not done --Tobias1984 (talk) 06:16, 12 August 2013 (UTC)


DescriptionInternational Standard Identifier for Libraries and Related Organizations / Internationales Bibliothekssigel / Identificateur international normalisé pour les bibliothèques et organisations liées / ISO 15511, International Standard Identifier for Libraries and Related Organizations (Q470458)
Data typeString
Template parameter
DomainOrganisations: libraries, places: libraries
Allowed values[A-Z]{1,3}-[A-Z0-9:/]{8,10}
ExampleLibrary of Congress (Q131454) => "US-DLC"
Proposed byReclus (talk) 13:10, 18 March 2013 (UTC)
  •   Move --Tobias1984 (talk) 09:01, 29 July 2013 (UTC)
  •   Support --Kolja21 (talk) 18:52, 7 August 2013 (UTC)
  •   Support --Tobias1984 (talk) 19:15, 7 August 2013 (UTC)
  • completed description above. --  Docu  at 19:14, 8 August 2013 (UTC)
  •   Done --Tobias1984 (talk) 10:29, 12 August 2013 (UTC)


    Status:    Done


    • Description: chapter in which the claim is made
    • Datatype: string (a chapter can have a number, a letter, a title...)
    • Links:
    • Infobox parameter example: en:Template:Cite book
    • Comments: Zolo (talk) 16:03, 26 March 2013 (UTC)
    Not really necessary if you have the page of the publication from where the reference is coming from. Snipre (talk) 17:45, 26 March 2013 (UTC)
      Support Redundancy is underrated. It's useful for checking for errors, among other things. And sometimes you might not even know the page number. Anyway, when citing something in a compilation of chapters by different authors, chapter titles (while perhaps technically redundant) are often seen as a necessary part of a complete citation. --Avenue (talk) 09:11, 27 March 2013 (UTC)
      Support - I support chapter name, but chapter number should be a value/number and not a string. I would go for "chapter name" and "section number". "section number" would be also useful for law-related items that could link to the paragraph in which the law is stated. --Tobias1984 (talk) 11:36, 8 May 2013 (UTC)
      Support Might help to keep already existing information. --Micru (talk) 03:22, 3 June 2013 (UTC)
      Comment - We need to clearly distinguish a cited reference work from the citation of that work. Page numbers etc belong in the citation of the work, they reflect the way the work is used by the citing editor. One work may be cited many times in many places and for many purposes. LeadSongDog (talk) 21:02, 5 June 2013 (UTC)
      Support as proposal, for use in source info citations. Filceolaire (talk) 08:30, 13 June 2013 (UTC)

    Emigrated on date (en) / Emigrato in data (it) / emigrierte nach Datum (de)

       Not done
    DescriptionDate when a Person is emigrated / Data in cui la persona è emigrata
    Data typePoint in time
    Allowed valuestype of linked items,allowed values (if limited)
    ExampleRudolph Valentino (Q188692) emigrated 23 december 1913 / Rudolph Valentino (Q188692) è emigrato il 23 dicembre 1913
    SourceCould be sourced from Category:Emigrants by nationality and its subcategories
    Proposed byLucaBiondi (talk) 16:38, 25 July 2013 (UTC)
    •   Support-- 17:24, 27 July 2013 (UTC)
    •   Weak oppose in favor of a more general "related date" property used as qualifier for "emigrated to". --Ricordisamoa 23:29, 2 August 2013 (UTC)
      •   Support I Agree, i proposed these 2 properties but i prefer your idea: "#Emigrated on date" must be a qualifiers for "emigrated to"! ...Should i change the property proposal? Thanks LucaBiondi (talk) 14:33, 3 August 2013 (UTC)
    •   Oppose use as suggested a more general qualifier named 'related date' --Nightwish62 (talk) 17:32, 5 August 2013 (UTC)
      •   Support Hi Nightwish62, i proposed these 2 properties but i Agree with you! "#Emigrated on date" will be a qualifiers named 'related date' for "emigrated to"! I just wanted to ask if it was necessary to modify and unify the two property proposal?

    p.s. you support the property "emigrated in"? Thanks LucaBiondi (talk) 19:54, 5 August 2013 (UTC)

    •   Oppose Use point in time (P585) as qualifier to 'Emigrated to'. Some people might emigrate twice over the course of their life and it needs to be clear which data parameter applies to which migration. Filceolaire (talk) 20:13, 5 August 2013 (UTC)
      •   Support Hi Filceolaire, I proposed these 2 properties and i agree with you: "emigrated to" will use point in time (P585) as qualifier for the related date'.

    p.s. may i ask if you support the property "emigrated in"? Thanks LucaBiondi (talk) 21:11, 5 August 2013 (UTC)

    •   Comment Consensus seems to be to use existing time-properties. I'm going to archive this unless somebody would like to add something. --Tobias1984 (talk) 18:22, 7 August 2013 (UTC)

      Not done --Tobias1984 (talk) 10:37, 12 August 2013 (UTC)

    OSI approved / / / approvata dalla OSI

       Not done
    Descriptionwhether a software license is approved by the Open Source Initiative
    Data typeboolean-invalid datatype (not in Module:i18n/datatype)
    Template parameterthe OSI approved parameter in en:Template:Infobox software license
    Domainsoftware licenses
    Allowed valuestrue or false
    ExampleGNU GPLtrue
    SourceWikipedia and the OSI website
    Robot and gadget jobsSamoaBot could import it from en.wp, once the boolean datatype is supported
    Proposed byRicordisamoa 14:44, 2 April 2013 (UTC)
    •   Support However, it should be used for particular versions of a license, such as GNU GPLv3 (not all versions of the license are necessarily approved). These version entities may need to be created. Superm401 - Talk 21:09, 2 April 2013 (UTC)
      Yes, we should act so. --Ricordisamoa 21:19, 2 April 2013 (UTC)
      Support --★ → Airon 90 21:57, 8 April 2013 (UTC)
      Comment I think 'approved by' would be a better more generic solution. --FischX (talk) 16:34, 9 April 2013 (UTC)
      Comment What about a qualifier for "instance of: open source license"? Something general like "according to". --AVRS (talk) 10:39, 25 April 2013 (UTC)
      Oppose - booelan datatype not on the roadmap. use "approved by" = "OSI" instead. --Tobias1984 (talk) 13:24, 4 August 2013 (UTC)
    Approved by is now used in GNU General Public License (Q7603). --Tobias1984 (talk) 08:53, 13 August 2013 (UTC)

      Not done - although this property had initial support, a better solution was found to store this kind of relation. --Tobias1984 (talk) 08:57, 13 August 2013 (UTC)

    FSF approved

       Not done
    DescriptionWhether the license has been approved the Free Software Foundation as a free license. Not to be confused with whether they consider it copyleft, or whether it is compatible with the GPL.
    Data typeboolean-invalid datatype (not in Module:i18n/datatype)
    Template parameterthe FSF approved parameter in en:Template:Infobox software license
    Domainversion of a license (GPLv3), or a license if there is only one version (e.g. Clarified Artistic License).
    Allowed valuestrue or false.
    ExampleBoost Software Licensetrue
    Robot and gadget jobsPer above, could be imported, possibly by SamoaBot
    Proposed bySuperm401 - Talk 21:22, 2 April 2013 (UTC)

    Similar to above, except FSF instead of OSI. Superm401 - Talk 21:22, 2 April 2013 (UTC)

      Support Waiting only for boolean datatype... --Ricordisamoa 21:37, 2 April 2013 (UTC)
      Support --★ → Airon 90 21:57, 8 April 2013 (UTC)
      Comment I think 'approved by' would be a better more generic solution. --FischX (talk) 16:34, 9 April 2013 (UTC)
      Comment FSF doesn't require freedom for opinion and non-utility artistic works. It uses CC BY-ND for articles at its sites, but doesn't consider it free. So the description probably needs to be very clear on that; maybe make the main label more detailed. --AVRS (talk) 10:34, 25 April 2013 (UTC)
      Comment What about a qualifier for "instance of: free software license"? Something general like "according to". --AVRS (talk) 10:39, 25 April 2013 (UTC)
    But GNU FDL is accepted (though not endorsed) by Debian only when used without invariant sections. --AVRS (talk) 11:43, 25 April 2013 (UTC)
      Oppose boolean datatype not on the roadmap. use "approved by" = "FSF" instead. --Tobias1984 (talk) 13:25, 4 August 2013 (UTC)
    Approved by is now used in Boost Software License (Q2353141). --Tobias1984 (talk) 08:54, 13 August 2013 (UTC)

      Not done - although this property had initial support, a better solution was found to store this kind of relation. --Tobias1984 (talk) 08:57, 13 August 2013 (UTC)

    Key event

    (hoisted from archives, as I find the reasons given for its non-creation puzzling)

    Descriptionsignificant events associated with the subject, opening date, premiere date for a movie, in service (aircraft), production started (manufacturing), ship naming and launching, etc.
    Data typeItem
    Template parametermany infoboxes have this type of information
    Domainall domains
    Allowed valuesitem which describes the type of event, e.g. première (Q204854). We can just create suitable items if none exist.
    ExampleFriedland (Q4492725) key event ceremonial ship launching (Q596643) date 4 March 1840 (note: we'd need a generic date property which could be used as a qualifier).
    Proposed byDanrok (talk) 15:57, 23 May 2013 (UTC)

    For previous discussion see: Wikidata:Property_proposal/Archive/11#Key_event

    •   Strong support. To respond to the comments from JFLewis above:
      • The only Oppose above is from Nightwish who follows it up with "you're right" which sounds like he is withdrawing the Oppose. How does no Oppose votes turn into 50% Oppose?
      • 'More direct' time (and location) properties means a special time (and location) property for every type of event. Hundreds of them. With users having to try and find the right one. This is not better.
      • There is a time property. It is point in time (P585).
      • No one else is finding this ambiguous.
    Please create this property now. Filceolaire (talk) 20:32, 5 August 2013 (UTC)
    I think I will create this property. I am afraid I do not understand the reasons given by John F Lewis. What does "redundant to itself" mean, and why is it ambiguous ? --Zolo (talk) 16:48, 12 August 2013 (UTC)

      Done with two more supporting votes the property has majority support. Further discussion should give the property some development time and then take the route of an RfC if needed. --Tobias1984 (talk) 16:59, 13 August 2013 (UTC)

    generic qualifier "AS" (en) / Generika Sichter "AS" (de)/ classificatore generico "come" (it)

       Done: no label (P794) (Talk and documentation)
    Descriptiongeneric qualifier "AS"
    Data typeItem
    Examplesee below
    Proposed byLucaBiondi (talk) 11:25, 7 August 2013 (UTC)


    Item: Person XYZ

     Property: residence
      Value: country A (say, this is the place the person was born and lived for the first years)
       qualifier: start date
        Value: XX.YY.ZZZZ
       qualifier: end date
        Value: XX.YY.ZZZZ
     Property: residence
      Value: country B (say, he makes here a longer stay for several years, e.g. for education)
       qualifier: start date
        Value: XX.YY.ZZZZ
       qualifier: end date
        Value: XX.YY.ZZZZ
     Property: residence
      Value: country A (say, he came back to the country he has born)
       qualifier: start date
        Value: XX.YY.ZZZZ
       qualifier: end date
        Value: XX.YY.ZZZZ
     Property: residence
      Value: country B (say, this is the country he has emigrated to)
       qualifier: start date
        Value: XX.YY.ZZZZ
       qualifier: end date
        Value: XX.YY.ZZZZ
       qualifier: as
           value: emigrant

    I think "AS" generic qualifiers is needed, also for other statements. It is a very generic qualifier which can be used for many claims. We could make the example above why such a qualifier is needed. LucaBiondi (talk) 11:25, 7 August 2013 (UTC)

      Support, can be used for the "as" parameter in Wikipedia succession boxes (see here) and many other things. Maybe it could also replace character role (P453). Mushroom (talk) 16:03, 7 August 2013 (UTC)
      Support for the proposal, but against use it instead of character role (P453). Let me explain why: Three month ago we had two properties: one 'starring' and one 'support actor/actress'. It was me how made a request to one property 'cast member' (Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P482), which was agreed. Since then, we didn't have any information anymore to distinguish between starring and support roles. As also told in the deletion request, the idea was to make this distinction by a 'as' qualifier. Now let's show what's happen when we merge 'role' and 'as':
    Item: The Lord of the Rings: The Fellowship of the Ring
     Property: cast members
      Value: Elijah Wood
       qualifier: as (formally 'role')
        Value: Frodo Baggins
       qualifier: as
        Value: starring role

    So the as would be used for the role as well as to describe the role type. I think this isn't good, therefore I suggest we remain the 'role' property. --Nightwish62 (talk) 22:43, 7 August 2013 (UTC)

    Oh I see. That information is important to have, so I withdraw the proposal. Mushroom (talk) 10:31, 8 August 2013 (UTC)

      Done --Nightwish62 (talk) 22:38, 13 August 2013 (UTC)

    Comment (string) /

       Not done
    Data typeString
    Template parameterAdditional information
    DomainAny item
    Allowed valuesAny useful information which cannot be described semantically. Will be replaced by a "Comment" Property with multilingual text datatype once this datatype is available.
    Example 1MISSING
    Example 2MISSING
    Example 3MISSING
    Proposed byFilceolaire (talk)
    •   Support as nom. There are many cases where there is additional information which cannot be described using the properties and datatypes available at the moment or which won't ever be described semantically. This property can be used to store that information as free text.
    Ideally this property should have the multilingual text datatype but that doesn't exist yet so the property name is "Comment (string)" leaving the name "Comment" available for use when that datatype is ready. Filceolaire (talk) 18:53, 11 July 2013 (UTC)
    •   Comment This is really very unspecific and I can't see a use for this property (beside being a temporary workaround in order to save urls, which I wouldn't support). Could you name an example (item + value) to explain where you would use this property, and why it wouldn't be possible or a good idea to have a new, own property for this specific type of data in your example.--Kompakt (talk) 09:36, 16 July 2013 (UTC)
    •   Oppose If there is no way to classifiy some informations this is not the goal of wikidata to store it for 2 reasons: 1) wikidata is a structured database 2) data are imported in the client meaning that the client has to know the content of the data in order to call it. If you have data which can't be described nobody will call it because nobody knows its existence and nobody will call the data just to see what kind of data we have in that property. This is not the goal to have everything even the small details in wikidata. Snipre (talk) 11:16, 16 July 2013 (UTC)
    •   Support I think that this is a very useful addition -- not necessarily for term properties, but for adding comments in qualifiers of statements!! A usecase I currently have are pharmaceutical drug-drug interactions. We recently got the property "drug action altered by" approved. If we have a relationship of <Drug A> <drug action altered by> <Drug B>, we would like to add as a a qualifier a short description about the exact nature of how they interact. I think that this need will arise for several other properties as well, and having a generic property to add short comments seems like the ideal solution.--Matthiassamwald (talk) 10:14, 6 August 2013 (UTC)
    •   Comment There probably could be a way to describe that interaction using an item that corresponds to the nature of the interaction. Do you have an example ? TomT0m (talk) 15:21, 6 August 2013 (UTC)
    •   oppose datatype - This is something that needs to be translatable. If the datatype is changed one can merge it with the proposal below. --Tobias1984 (talk) 15:14, 6 August 2013 (UTC)
    •   Oppose too unspecific. in most case as good description on the Talk page is sufficient.  — Felix Reimann (talk) 18:26, 6 August 2013 (UTC)
    •   Not done No consensus to create. Regards, — Moe Epsilon 23:57, 13 August 2013 (UTC)

    subject of

    Descriptionitem about the subject of the statement
    Data typeItem
    ExampleBarack Obama <office held> President of the United States qualifier subject of Presidency of Barack Obama, Osama bin Laden <died> May 2, 2011, qualifier subject of Death of Osama bin Laden, United States <shares border with> Canada qualifier subject of Canada–United States border
    Proposed byYair rand (talk)

    "Related item" might not be the best name for this property, though... Yair rand (talk) 21:35, 5 May 2013 (UTC)

    •   Support The examples are really all items about the various claims. How about calling the qualifier "item about"? Emw (talk) 21:41, 5 May 2013 (UTC)
      That seems more like it's saying the claim is an item about the item, instead of the other way around (the item is an item about the claim), no? --Yair rand (talk) 21:58, 5 May 2013 (UTC)
    Good point. My concern is that "related" is very broad: the article "presidency" and "election" are related to "Presidency of Barack Obama", but they aren't directly about it. Perhaps "subject of" would be better? The claim is the subject of the item, i.e. the value of the qualifier. Emw (talk) 22:39, 5 May 2013 (UTC)
    Hm, I'm not sure. I think both options could probably be vague/confusing. --Yair rand (talk) 00:00, 8 May 2013 (UTC)
    •   Support – Nice qualifier which can used by the Wikipedias to provide links to related articles. Byrial (talk) 22:19, 5 May 2013 (UTC)
    •   Support --Viscontino (talk) 20:53, 7 May 2013 (UTC)
    •   SupportPοωερZtalk 21:17, 7 May 2013 (UTC)
    •   Oppose Subjective relation: without a clear relationship everybody can add this property and link to topic he wants. Property have to characterize item, relation between topics will be performed by search algorithms not by data management. Snipre (talk) 23:09, 8 May 2013 (UTC)
      How could this be "subjective"? It seems pretty objective to me. Could you give an example of where it could be ambiguous whether this qualifier should be used or not? --Yair rand (talk) 23:27, 8 May 2013 (UTC)
      If I take the example I can link Death of Osama bin Laden with Barack Obama or with Navy Seal: this is a relation between these different items but how can we fix a limit ? Snipre (talk) 23:55, 8 May 2013 (UTC)*:: If I take the example I can link Death of Osama bin Laden with Barack Obama or with Navy Seal: this is a relation between these different items but how can we fix a limit ? I can even provide sources for that. the problem is to distinguish between item characterization with properties and connection between items. The first is data management and the second is data use. What you are proposing is categorization with the help of property. Don't do in wikidata what wikipedia is doing connection based on text or links. Snipre (talk) 23:55, 8 May 2013 (UTC)
      This proposal is in the "Qualifiers" section. The proposed property would not be used directly on items at all. Please see the examples given in the box above. --Yair rand (talk) 00:00, 9 May 2013 (UTC)
      If you ensure that this property will be used only as qualifier we can discuss but you can't. I can already bet that in 3 months this property will be used in a different manner and nobody will be able to check its correct use. Again what you are doing is connection between wikipedia articles in wikidata. Snipre (talk) 00:13, 9 May 2013 (UTC)
      First of all, I really disagree with the idea that properties shouldn't be created when some editors might use it incorrectly. Second, I've implemented Emw's proposal above to change the name to "subject of". Does that remedy your concerns? --Yair rand (talk) 00:23, 9 May 2013 (UTC)
    •   Oppose I also think that the use of this property will be too subjective and adds very little content. Barack Obama, President of the United States and Presidency of Barack Obama would already be connected through other properties anyways (maybe you have to jump over one node in the graph, so what?). I think that because of the subjectiveness and the redundancy with existing information, this property would add confusion and would not be put to good use. --Matthiassamwald (talk) 10:23, 6 August 2013 (UTC)
      I don't think you understand what the proposal is. The property would be used exclusively as a qualifier, to link to an item completely dedicated to the subject of the statement. I don't see how that could be subjective at all. --Yair rand (talk) 18:29, 6 August 2013 (UTC)
    •   Support. Very useful. What about a really clumsy but unambiguous name like "topic of the following item". We dont want it to be used for "James Cameron is a subject of her Majesty the Queen", and can use aliases as shortcuts. --Zolo (talk) 06:31, 9 May 2013 (UTC). Or "dedicated item" ? --Zolo (talk) 10:32, 9 May 2013 (UTC)
    •   Oppose are you suggest that Obama is the subject of the Death of bin Laden, or that bin Laden is the subject of Obama? Neither are correct. They are topics related in a large number of different ways, of which being the subject of is not one. Nor does it match Zolo's suggestion of topic of the following item. bin Laden or the death of bib Laden is not the topic of Obama, or vice-versa. If you want some sort of relator here, you need to think of all the actually appropriate relators. This is being used in the meaning of "might have an appropriate wikilink to" , which is a very broad concept indeed. Possibly the relationship you are thinking of is "sub-topic of" in the sense that Death of bin Laden is a subtopic of Bin Laden. that might be useful, because articles in WP are in fact organized in this fashion. DGG (talk) 23:13, 17 May 2013 (UTC)
      •   Comment – There is no suggestion in this proposal about a connection between Obama and bin Laden. Example 1 in the proposal is about Obama's Presidency, example 2 is about bin Laden's death, and example 3 is about the US-Canada border. These examples are independent of each other. Byrial (talk) 00:19, 18 May 2013 (UTC)
    I think death of Osama bin Laden (Q19085) should be claimed as part of (P361) Operation Neptune Spear which is part of (P361) War on Terror (Q185729). Note that Operation Neptune Spear does not have it's own item at this time, but could be created. Danrok (talk) 00:09, 24 May 2013 (UTC)
    •   Comment Surely most subject relationships can be found by following the connections of existing properties? Danrok (talk) 00:00, 24 May 2013 (UTC)
    •   Comment It seems there is much confusion about what this property is all about. I'll try to explain it in detail. There is a major problem this property is able to solve: Statements themselves can be items. To use one of the examples above: death of Osama bin Laden (Q19085) is an item describing an event that is also described by the statement | Osama bin Laden (Q1317) died: May 2, 2011 |. The proposed property shows this relation by adding the describing item as a qualifier to the statement it describes. —PοωερZtalk 11:39, 24 May 2013 (UTC)
    •   Comment Unless there are new objections, I'll create this one as "dedicated item", as I think it is the clearest label. --Zolo (talk) 13:12, 24 May 2013 (UTC)
    •   Comment, an annoying point is that the property does not apply to an "item - property - value" but just to an "item - property". For instance "death of Osama bin Laden: dedicated Death of Osama bin Laden" applies to Osama bin Laden (Q1317) - cause of death (P509) but to no particular value of P509. So where should we put it when the property has several values ? --Zolo (talk) 13:25, 24 May 2013 (UTC)
    To make death claims, you can just add cause with two qualifiers, time and place. Danrok (talk) 21:08, 24 May 2013 (UTC)
    Sure, better to have one statement for one event. I'd say time of death should be the basic property, but this is not the place to discuss that in detail. —PοωερZtalk 02:40, 25 May 2013 (UTC)
    What I meant is: what do we do when the same property should have several values ? For instance: Henry VIII - spouse (P26) - Catherine of Aragon (Q162819), Anne Boleyn (Q80823). Dedicated item: list of wives of King Henry VIII (Q3408870). --Zolo (talk) 06:03, 25 May 2013 (UTC)
    I would prefer 'Dedicated article' instead of 'Dedicated item'. in most cases a sub-page is about the same item as the main page but it is a separate article. Filceolaire (talk) 21:02, 6 June 2013 (UTC)
    It means a page in Wikidata main namespace, I think "article" is slightly ambiguous as it can often refer to Wikipedia articles. --Zolo (talk) 07:00, 7 June 2013 (UTC)

      Not done No real consensus for creation plus the above seems to discuss flaws with the proposal. John F. Lewis (talk) 00:01, 14 August 2013 (UTC)

      Done After being asked to review this decision and looking in the opposes more, while they do exist they are purely misunderstanding of the proposal therefore carry little or no weight. John F. Lewis (talk) 11:03, 14 August 2013 (UTC)

    subsequence of (en) / série incluse dans (fr)

       Not done
    DescriptionThe sequence is a subsequence of a larger sequence represented by the item object
    Data typeItem
    Template parameterput Wikipedia infobox parameters here. If existing, sample: "population" in en:template:infobox settlement
    Domaininstances of sequences of items of the same type than the object sequence type
    Allowed valuessequences of items of the same type than the subject sequence type
    Examplea TV series season is a subsequence of the whole TV series. Suggested qualifiers : preceeded by and followed by to qualify which subsequence follows in the sequence)
    Format and edit filter validation(sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17)
    SourceExternal reference, Wikipedia list article (either infobox or source)
    Robot and gadget jobsCheck other properties for consistency (same sequence type, collect data)
    Proposed byTomT0m (talk) 17:14, 21 July 2013 (UTC)

      Comment (from proposer) Maybe the part-of could do the job but I think it is more a kind of unordered composition, whether sequences ordering is important. TomT0m (talk) 17:14, 21 July 2013 (UTC)

      Support. TomT0m (talk)
      Oppose we have already "part of". Snipre (talk) 18:33, 29 July 2013 (UTC)
    Like I said, composition, which part of seems supposed to represent, is related to unordered stuff, whereas in a sequence the ordering of subsequence is important. This justifies another property imho, or we would have to infer that from other properties. For example maybe a compilation from the best episode from a TV serial is possible. It is a part of the whole also, but it might not respect the ordering. TomT0m (talk) 11:59, 5 August 2013 (UTC)
      Oppose We have part of (P361). We can use follows (P155) and followed by (P156) as qualifiers to show the ordering. Filceolaire (talk) 12:53, 5 August 2013 (UTC)
    As a matter of fact I used follows (P155) and followed by (P156) of course, but directly on the item, not in the part-of qualifier (it seems natural to say that a TV series season is preceded by the previous directly). But the qualifier solution allows to be subsequence of several series ... I don't know what is best. If a serie is a sequence of episodes, It seems that a part of a serie is an episode, not a season which is a subsequence. On the other hand an episode is also followed by and preceded by another, and part of the serie, so using part of for both leaves an ambiguity which can be resolved by checking the types of the items, but it's not a generic solution. I still think it's better to have a subsequence property then, to distinguish between atomic elements (episodes) and other subsequences (seasons, which are themselves sequences of episodes).TomT0m (talk) 13:21, 5 August 2013 (UTC)
    I would say an episode is part of a season and a season is part of a series. Dr Who used to have some stories in a season which were told over multiple episodes. In that case an episode would be part of a story which is part of a season which is part of a series for a particular regeneration of the Doctor which is part of the entire series. Even when we have sequences nested five deep, as this case, I think we can manage it with part of and qualifiers.
    We can use 'preceded by' and succeeded by' directly on items for each episode, story, season and regeneration to link items in each sequence to adjacent items in that sequence, for the benefit of querybots which don't understand qualifiers, and we can use 'part of' to link to the item for the sequence of which the current item is part. We can even use 'consists of' to list all the elements in the current sequence/item. Filceolaire (talk) 15:13, 5 August 2013 (UTC)
    It does not meet the definitions, see the articles on en: as an example. A serie is a sequence of episode. A season is a sequence of episode. An episode is not a sequence of episode. A story might be told in several episode, but it's not the story which is a sequence of episode itself. The problem with tour solution is the lack of regularity, for example some series does not have several seasons, it's still a sequence of episode : a bot would still find the same properties and would not have to treat it as a corner case. I think episode is a fundamental unit in this model (as well as the elements of a sequences are from different kind than the sequences themselves). The subsequence property solution has the advantage to make explicit this separation between the kind of the elements of the lists and the kind of subsequences. Of course this is the basic model, we also can add other facts to separate narrative units, but it's important to keep this regularity if we want the datas to be easily processable for a bot.[serie 1][serie 2]TomT0m (talk) 15:28, 5 August 2013 (UTC)


    1. Serials are series of television programs and radio programs that rely on a continuing plot that unfolds in a sequential episode-by-episode fashion. Serials typically follow main story arcs that span entire television seasons or even the full run of the series, which distinguishes them from traditional episodic television that relies on more stand-alone episodes. Worldwide, the soap opera is the most prominent form of serial dramatic programming.
    2. a series is a connected set of television program episodes that run under the same title, possibly spanning many seasons (north american definition)

      Not done There is no consensus for the creation of the property. John F. Lewis (talk) 00:01, 14 August 2013 (UTC)

    Distance along (en)

    DescriptionThe distance of an object from a defined datum point.
    Data typeItem
    DomainLinear features
    Allowed valuesRailway lines, roads
    Exampleexample item and/or example value. Please add one or several sample uses of the property. Sample: Universe (Q1) => Earth (Q2)
    Proposed bySfan00 IMG (talk) 14:13, 2 August 2013 (UTC)

    My proposal is for a property that allows objects which can be spatially located to have distances from other spatially locatable objects added to them.

    My inital thought with this was railroad mileages which are typically defined as being that X is so many miles from a defined Zero mileage at Y.

    This property would need a qualifer - measurement datum.

    Sfan00 IMG (talk) 14:13, 2 August 2013 (UTC)

      Oppose - property is already pending Wikidata:Property_proposal/Pending#Distance. --Tobias1984 (talk) 20:53, 2 August 2013 (UTC)
    That deals with astronomical objects, not earth based ones :) Sfan00 IMG (talk) 11:37, 3 August 2013 (UTC)
    Some proposals were not really well discussed in the early days of Wikidata :). But maybe you could change the datatype to "item" and change the title to "distance along". Example: We have the Arlberg railway (Q620564) which will get a length/distance property to say 136 km. A town along the railway is a certain distance from the railway measurement datum (see: de:Kilometrierung). So the statement could say for the town Sankt Anton am Arlberg (Q659996):
    • distance/length = 99 km
    The measurement datum could be defined in the item of the track: Arlberg railway (Q620564): "measurement datum" = "Innsbruck train station" --Tobias1984 (talk) 12:05, 3 August 2013 (UTC)
    That sounds good, see below Sfan00 IMG (talk) 18:07, 3 August 2013 (UTC)
      Support --Tobias1984 (talk) 18:41, 3 August 2013 (UTC)
      Support --Paperoastro (talk) 20:16, 3 August 2013 (UTC) P.S.:I gave support to the distance proposal. Is it possible, for clarity, modify it for a generalization?
      Support, good idea. Mushroom (talk) 16:11, 7 August 2013 (UTC)

      Done John F. Lewis (talk) 00:06, 14 August 2013 (UTC)

    Geo datum (en)

       Done: no label (P796) (Talk and documentation)
    Description'Zero' point for measurement.
    Data typeItem
    DomainGeographical feature.
    Allowed valuesNode based geographical features.
    Robot and gadget jobsRouting engine and mileage calculations.
    Proposed bySfan00 IMG (talk) 14:13, 2 August 2013 (UTC)

    I've called this Geo_Datum, rather than measurement datum, because there may be other specifc "measurement datums' in other fields. Sfan00 IMG (talk) 18:07, 3 August 2013 (UTC)

    •   Support - I think this would also be useful for altitude measurements, where almost every country has their own datum. Example from the list de:Höhe_über_dem_Meeresspiegel:
    • Amsterdam
    • altidude = 2 m
    • geo datum = Amsterdam datum --Tobias1984 (talk) 19:16, 3 August 2013 (UTC)

      Done John F. Lewis (talk) 00:10, 14 August 2013 (UTC)

    executing authority / power of decision (en)

       Done: authority (P797) (Talk and documentation)
    DescriptionWhat office (or similar) executes the power of decision in matters relating to the entity.
    Data typeItem
    DomainSeveral domains.
    Allowed valuesValid items
    ExampleThe executing authority when choosing names for geographic objects. Mapping service, postal service, munincipality, etc.
    SourceFor the example Sentralt stadnamnregister (SSR) (Norwegian)
    Robot and gadget jobsWill be used during import of data from the Norwegian Sentralt Stedsnavnregister.
    Proposed byJeblad (talk) 14:36, 6 July 2013 (UTC)

    This property will be part of an on-going work to import parts of SSR into Wikidata. The property seems to be of general value and is because of this not prefixed with any project specific letters. Similar properties are maintained by (P126). Jeblad (talk) 14:36, 6 July 2013 (UTC)

      Support I think it would be usefull as a qualifier for the canadian heritage properties, since they have many autorities who can protect with different statuses. I actually use owned by (P127), but a new property will be better, since they are not really maintained or owned by the governement in question. (ex: Charlotte County Court House (Q5085897)) --Fralambert (talk) 14:00, 5 August 2013 (UTC)
      Support useful qualifier and semantically distinct from existing properties. --Tobias1984 (talk) 15:45, 11 August 2013 (UTC)

      Done John F. Lewis (talk) 00:13, 14 August 2013 (UTC)

    category (en)

       Not done
    Descriptioncategory for this item
    Data typeItem
    Template parameteriverse property to "main article" templates and to Property:P301, maybe "main category" parameter exists in some infoboxes or templates also.
    Domainall domains (main type=category)
    Allowed valuesthe linked item need to be "Category:"
    Format and edit filter validationshould link only from non-category item to category-item
    Sourceiverse property to "main article" templates and to Property:P301
    Robot and gadget jobsgenerate as complementary inverse property to Property:P301 which can be generated from "main article" template in Wikipedias and Commons categories. Items which are connected by Property:P360 should link to identic category.
    Proposed byŠJů (talk) 15:49, 6 August 2013 (UTC)

    Generally, Q subjects should represent items, not articles. Thus, article links belong to the item equally inehrently as category links. However, Wikidata structure was wrongly based and therefore we have mostly two Q subject for identic item, one for articles and second one for categories. This fault complicates integration of Wikimedia Commons because Commons categories are related not specifically to Wikipedia articles nor specifically to Wikipedia categories but to items, which are represented by both, articles and categories.

    Most of properties are inherently complementary: some of them are inverse, some of them are symmetric. However, the Wikidata logic was is hardly deficiently thought out and thats why complementary properties doesn't works automatically as complementary yet but need to be rendered from ones to the complementary properties. It this case, link from the item itself to the additional category "item" should be primary toward the existing opposite property Property:P301.

    This proposed property is also analogic to Property:P373. The "items" connected by this proposed property (really two Q subjects related to identic item) should have identic Property:P373. --ŠJů (talk) 15:49, 6 August 2013 (UTC)

      Comment If this is organizing the structure of Wikipedia shouldn't the property be called "Wikipedia Category". It is not Prague that has a category, but Wikipedia has a category for Prague. --Tobias1984 (talk) 18:40, 6 August 2013 (UTC)
    You can say also similarly: "It is not Prague that has an article, but Wikipedia has article for Prague". However, the decision that Wikidata "items" should be a tool to organizing the structure of other Wikimedia project (Wikipedias first of all) is not something now. Wikipedia articles appertain to their items just so as Wikipedia categories do. Wikidata are ill-based in this point as far as they don't allow to treat category-links equally as article links in relation to their common items. However, if the Wikidata Team ousted category links to such subsidiary or parallel duplicate "items", there is no reason to limit them to Wikipedia projects. Also some other Wikimedia projects have item categories. --ŠJů (talk) 21:32, 8 August 2013 (UTC)

      Oppose This seems to be the inverse of category's main topic (P301). I don't think we need both. Filceolaire (talk) 22:41, 6 August 2013 (UTC)

    You repeat my arguments but do not answer them. Yes, most of properties are inherently complempentary and it is a fatal defect of Wikidata that they don't really work as complementary. That's why we need to have inverse properties for most of properties and to render their data mutualy for now. However, if we should have only one property instead both complementary properties, we should prefer to link from the primary item to the secondary one, i. e. from the main item to the quasi-item in this case. --ŠJů (talk) 21:32, 8 August 2013 (UTC)

      Oppose Categories are essentially queries on a set of pre-defined properties, and so should be obsolesced by Wikidata. The archived discussion Proposal for phase 4: unify and centralize categories contains detailed comments from several other contributors on this, but the gist is "get rid of categories". We should not be building infrastructure like specific 'category' properties to support a redundant, legacy categorization system on Wikidata. Emw (talk) 01:35, 7 August 2013 (UTC)

    You are right, categories are esentially queries on a set of some elements and if Wikidata Team will comprehend all aspects and functions of wiki categorization, it would be very welcomed and interesting to try to transform them into WikiData. Unfortunately, Wikidata didn't implemented nor even modularity principle yet and drowns in countless useless duplicities when attributing. I'm afraid that such trials will bring more harm than benefits if they will be so rash and ill-planned as the first phases of WD.
    However, simple (non-compound) item categories have a direct relation to their items, just as articles have. Relation between categories is esentially a relation between their items. If Wikidata usurped the organization of article interwikis, it should adopt responsibility for all interwikis and also for the relation between items, articles (or gallery pages) and categories, and rather improve and integrate than to peck out, sunder, smash and shatter the previous system. --ŠJů (talk) 21:32, 8 August 2013 (UTC)

      Oppose per Emw. Mushroom (talk) 16:05, 7 August 2013 (UTC)   Not done No consensus. John F. Lewis (talk) 00:14, 14 August 2013 (UTC)

    Mission Design Series designation

    Descriptionaerospace vehicle identifier as per United States Department of Defense
    Data typeString
    Domainaircraft, missiles, and other vehicles assigned DoD designations
    Allowed valuesalpha-numeric string
    ExampleAero Commander 500 => U-9
    SourceDoD 4120.15-L Model Designation of Military Aerospace Vehicles, May 12, 2004
    Proposed byJoshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
      Info This is a distinct designation issued publicly by the US Dept. of Defense. These designations are widely used and are the official designation/name for any aircraft in service with the US Armed Forces since 1962. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
      Support Dusti*poke* 18:29, 12 August 2013 (UTC)

      Done John F. Lewis (talk) 00:29, 14 August 2013 (UTC)

    Air Ministry specification

    Descriptionaircraft specification issued by the United Kingdom Air Ministry
    Data typeString
    ExampleAvro Shackleton => R.5/46
    Sourcew:en:List of Air Ministry specifications
    Robot and gadget jobsimport from w:en:List of Air Ministry specifications
    Proposed byJoshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
      Info Specifications issued by the UK Air Ministry (Air Board before 1918, RAF 1918 to 1920). These exist for most all aircraft operated by the UK military up to the 1970s. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
    Seems a rather misleading name, as if the UK was the only place that could have such a ministry LeadSongDog (talk) 17:51, 28 June 2013 (UTC)
    •   Support Danrok (talk) 01:33, 3 July 2013 (UTC)

      Done John F. Lewis (talk) 00:37, 14 August 2013 (UTC)

    GNIS Antarctica ID (en)

    DescriptionIdentification code for geographic objects in Antarctica, used in the US Geological Survey's Geographic Names Information System
    Data typeString
    Template parameterUsed in en:Template:GNIS with the "type=antarid" parameter
    Domaingeographic features in the antarctic region
    ExampleEllsworth Mountains (Q1139110) = "4460"
    Source[10] (use dropdown menu under "Topical Gazetteers -- File Format")
    Proposed byKam Solusar (talk) 16:13, 4 August 2013 (UTC)
    • We already have GNIS ID (P590) for geographic features in the US, but the USGS uses separate IDs for antarctic features. --Kam Solusar (talk) 16:13, 4 August 2013 (UTC)
    •   Support I was wondering how long it would take for this one to be requested after GNIS was created. --  Docu  at 17:14, 4 August 2013 (UTC)
    •   Strong support Since it's the best database for validate the existance of a toponyme. --Fralambert (talk) 17:19, 4 August 2013 (UTC)

    Establishment year /‌ سال شهر شدن

       Not done
    DescriptionIf the place or venue has an "established", "founded", "opened" or similar date
    Data typePoint in time
    Template parameterput infobox parameter here if existing, e.g. en:template: Start_date or fa:الگو:جعبه شهر ایران سال شهر شدن
    Example 1MISSING
    Example 2MISSING
    Example 3MISSING
    Proposed byدوستدار ایران بزرگ (talk) 12:02, 31 March 2013 (UTC)
      Support but propose name change to 'established': Datatype should be 'date', which should allow more detail than year alone. This property would apply widely to buildings, organizations, etc. A related 'disestablished' property is equally valid. Joshbaumgartner (talk)
      Support --Rschen7754 05:19, 30 May 2013 (UTC)
    There is no difference between time and date data types. They are the same and now you can use it. For buildings, organizations, etc the property is already created دوستدار ایران بزرگ (talk) 16:13, 30 May 2013 (UTC)
    This proposition will be deleted because it is redundant with an existing property inception (P571) Snipre (talk) 16:17, 30 May 2013 (UTC)
    As TCN7JM(wikidata sysop) says here "inception (P571) is usable for items about cities, but I feel like "date established" would be better wording, but I suppose if this property works, the later would become an alias for inception (P571)." Maybe its's better to rewrite inception (P571) as foundation/establishment date. By the way don't forget that many Wikipedia categories are set by year not a more precise date --دوستدار ایران بزرگ (talk) 18:39, 30 May 2013 (UTC)
    Time datatype accepts year as well as full date. For the renaming of the inception (P571) I let you start the discussion on the talk page of that property. If you have no other comment I will delete your proposal. Snipre (talk) 19:27, 10 June 2013 (UTC)
    OK, you can remove it–دوستدار ایران بزرگ (talk) 06:19, 12 June 2013 (UTC)

    Key dates for buildings:start date

    • Description: start date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      Support Danrok (talk) 15:26, 4 March 2013 (UTC)
      Support --Jcornelius (talk) 03:09, 22 March 2013 (UTC)
    I could see this being relevant to other things too, not just buildings. --Rschen7754 03:44, 30 May 2013 (UTC)
      Comment Presumably this is construction start date? Danrok (talk) 00:20, 11 June 2013 (UTC)
    •   Oppose Change to 'key date for building' and link to the 'construction' item with start date and end date qualifiers. See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:groundbreaking

    • Description: groundbreaking date
    • Datatype: year
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
    •   Oppose unless all the properties in this section are combined into one property 'key date for building" with datatype 'item' and qualifier 'date' or 'start date' and 'end date'.
    This property would link to items 'groundbreaking, construction, inauguration etc. as listed here. Filceolaire (talk) 21:13, 11 June 2013 (UTC)
    It's seem a little complicated to manage those dates the way you are proposing it. I think that having properties seems more intuitive. Greenski (talk) 16:39, 19 June 2013 (UTC)
    After thinking, I think I understand, but then it can't apply to opening and closing date, as it can't be an interval. Greenski (talk) 16:42, 19 June 2013 (UTC)
    Events that have duration rather than a date would have qualifiers for both 'start time (P580)' and 'end time (P582)'. --Filceolaire (talk) 19:44, 19 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)
    Now that significant event (P793) has been created these should be archived. Filceolaire (talk) 02:07, 15 August 2013 (UTC)

    Key dates for buildings:completion date

    • Description: completion date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      Support Danrok (talk) 15:26, 4 March 2013 (UTC)
      Support --Jcornelius (talk) 03:09, 22 March 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:opened date

    • Description: opening date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      Support --ThorstenX1 (talk) 16:26, 3 March 2013 (UTC)
      Support --Jcornelius (talk) 03:09, 22 March 2013 (UTC)
      Support Danrok (talk) 13:36, 9 June 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
      Support this would be useful, such as opening of a subway station, building or whatever. Aude (talk) 21:51, 1 August 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:inauguration date

    • Description: inauguration date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      Oppose --ThorstenX1 (talk) 16:27, 3 March 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:renovation date

    • Description: renovation date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:

      Support --Jcornelius (talk) 03:09, 22 March 2013 (UTC)

    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    • This would need the option of having a start and end date. Aude (talk) 21:54, 1 August 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:closing date

    • Description: closing date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links:
    • Infobox parameter example:
    • Comments: date for the closing of the structure to the public. ex. w:en:Saint-Martin (Paris Métro), closing date September 2, 1939.

      Support If we have opening date, we do need a closing date. It may for example be used for old railway stations, closed, but not demolished. Greenski (talk) 16:36, 19 June 2013 (UTC)

      Support Aude (talk) 21:58, 1 August 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 02:09, 15 August 2013 (UTC)

    Key dates for buildings:demolition date

    • Description: demolished date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      Comment I think we would need a start and end date. It can take a long time. Danrok (talk) 00:21, 11 June 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Key dates for buildings:destruction date

    • Description: destroyed on this date
    • Datatype: date, as precisely as possible, possibly down to the day and month
    • Links: w:en:Template:Infobox building
    • Infobox parameter example:
    • Comments:
      • What's the difference between destruction and demolition? --NaBUru38 (talk) 20:43, 1 March 2013 (UTC)
        • As explained at demolition is the planned destruction (i.e. knocking down) of a building, as opposed to destruction by natural or man-made disaster... Shawn in Montreal (talk) 20:48, 1 March 2013 (UTC)
          • Ok, then I   Support destruction date and   Oppose demolition date. Just one is better. --NaBUru38 (talk) 18:44, 8 March 2013 (UTC)
            • Question: since en:Template:Infobox building does have both the demolished and destroyed fields, will there be some way later to qualify how a building has been lost? I don't see users at the English Wikipedia opting to use a Wikidata generated table in phase two if it means a loss of information from what they currently have, and I thought this was the point. Shawn in Montreal (talk) 22:50, 10 March 2013 (UTC)
              • How about a property "destructed by"? --NaBUru38 (talk) 18:55, 20 March 2013 (UTC)
                • Sorry, I just saw this comment: well, aside from the minor grammar point (it's "destroyed by") I'd have no objection if you Wikidata whizzes think such a property is possible. So you'd have a property for when it was destroyed (a date) and how it happened (an item)? If so, okay. Shawn in Montreal (talk) 20:07, 29 March 2013 (UTC)
                  • Exactly: "destroyed by" would described how it happened. --NaBUru38 (talk) 18:55, 18 April 2013 (UTC)
    •   Oppose See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
    •   Oppose we should try to find a better way of handling key events. --Tobias1984 (talk) 17:41, 12 August 2013 (UTC)

    Opening date

       Not done
    DescriptionDate when the station commenced operation.
    Data typePoint in time
    Example 1MISSING
    Example 2MISSING
    Example 3MISSING
    Proposed byWylve (talk)
      Support-- DangSunM (T · C) 21:16, 7 February 2013 (UTC)
      Support--Incola (talk) 19:58, 10 February 2013 (UTC)
    To be clear, if this property is approved, this would not apply only to stations, but to all things that have opening dates. This is a good thing though. Sven Manguard Wha? 05:40, 18 February 2013 (UTC)
      Support. There should also be "Closing date", and each of them could be multiple, with qualifiers for different purposes. I'm thinking in particular of stations that closed to passenger traffic before they closed completely (eg en:Idle (GNR) railway station) but I'm sure there are other cases. --ColinFine (talk) 09:46, 22 February 2013 (UTC)
      Support Missing at the moment.   Support too for Closing date. Greenski (talk) 17:17, 22 April 2013 (UTC)
      Support this should be a generic property as it can be applied to a great many items. Joshbaumgartner (talk) 04:35, 9 May 2013 (UTC)
    Why not a date property with a qualifier to say what the date refers to? Danrok (talk) 17:59, 22 May 2013 (UTC)
    That would be waaay too general. Using "date" as the property name would be like using "family members" as properties and using "father", "mother", "brother", etc, as qualifiers. --Wylve (talk) 15:46, 26 May 2013 (UTC)
    It's not generalized when a qualifier is used. Yes, it would be like having a "relatives" property with a relationship qualifier, which works just fine in practice. How many date properties will there be if we create a specific one for every event? 10, or 1000 or 10,000? Danrok (talk) 15:56, 26 May 2013 (UTC)
    Merge this proposal with Wikidata:Property_proposal/Place#Key_dates_for_buildings:opened_date Snipre (talk) 17:30, 26 May 2013 (UTC)
    •   Oppose use 'key date for building'. See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:28, 11 June 2013 (UTC)
    •   Support--Ahonc (talk) 13:23, 16 July 2013 (UTC)
    • Comment I support having an "opening date" property but think a generic "opening date" property would be better. (see key dates for building) Aude (talk) 22:18, 1 August 2013 (UTC)

    Start of operation / Inbetriebnahme / mise en service

       Not done
    Descriptionthe date when the facility / railway line / machine was put into operation
    Data typePoint in time
    Template parametermany
    Domainindustrial facilities, railway lines, machines
    Allowed valuespoint in time
    Exampleen:Farallon Island Light: "Year first lit"; de:Pustertalbahn: "Inbetriebnahme"
    SourceExternal reference, Wikipedia list article (either infobox or source)
    Proposed byFrank Schulenburg (talk)

    A general property that will be useful to describe the date of first operation for all kinds of facilities and machines. --Frank Schulenburg (talk) 02:01, 29 April 2013 (UTC)

      Comment I'd suggest generic start and end date properties which could be used as qualifiers. Danrok (talk) 13:17, 24 May 2013 (UTC)
      Comment That would be another property called "end of operation". However, either way is fine for me. I'm just wondering how long it will take to create this property. I asked for it end of April. Now it's mid July… --Frank Schulenburg (talk) 17:11, 14 July 2013 (UTC)
      Oppose. Not needed now we have significant event (P793). Filceolaire (talk) 19:43, 15 August 2013 (UTC)
    Use significant event (P793) instead Snipre (talk) 09:39, 18 August 2013 (UTC)

    Event location

       Not done
    Descriptionthe location(s) where this event took place
    Data typeItem
    Template parameter"place" in en:template:military conflict
    Allowed valuesplaces
    ExampleNorwegian Campaign (Q5084679) = Norway (Q20)
    Sourceinfoboxes and others
    Proposed byDanrok (talk) 13:13, 24 May 2013 (UTC)
    Because we need to be able to specify locations which are not administrative units. Danrok (talk) 17:54, 4 June 2013 (UTC)
    Alright. In the meantime, a more general property for locations, not being limited to administrative units, has been proposed on Wikidata:Property proposal/Place#located on terrain feature (en). I think this could be used here as well.--Kompakt (talk) 09:55, 16 July 2013 (UTC)

      Oppose as Kompakt. Filceolaire (talk) 12:08, 16 July 2013 (UTC)