Wikidata:Property proposal/Archive/12

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)

Discussion

•   Support--Micru (talk) 01:42, 8 July 2013 (UTC)

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

 

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)

• 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 en.wiki but not it.wiki) 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 it.wiki 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" 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)

  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)

Discussion

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

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)

Discussion

  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)

Discussion

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)

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 Seco Tools (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)

•   Support --Tobias1984 (talk) 06:41, 2 August 2013 (UTC)

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

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)

Discussion

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)

Discussion

•   Support Danrok (talk) 20:13, 21 February 2013 (UTC)
•   Support --Viscontino ^talk 10:03, 2 March 2013 (UTC)
•   Support Also suitable for mark an album as 'Bootleg' --Nightwish62 (talk) 20:48, 23 March 2013 (UTC)
•   Oppose: redundant with instance of (P31) and subclass of (P279). Emw (talk) 02:14, 27 March 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. — ΛΧΣ²¹ 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. — ΛΧΣ²¹ 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)

Discussion

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

  Not done --Nightwish62 (talk) 14:45, 2 August 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)

Discussion

•   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οωερZ_talk 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)

→ Property:P756

Discussion

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

Discussion

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

•   Support Danmichaelo (talk) 19:31, 2 August 2013 (UTC)

Discussion

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)

Discussion

  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:

• Boeing 747SP (Q2421517) length 56.31 m, per Boeing 747SP#Specifications
• HTC Dream (Q727665) length 117.7 mm, per "Dimensions" field in HTC Dream.
• Appalachian Trail (Q620648) length 3,500 km, per "Length" field in Appalachian Trail
• Many others

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)

Discussion

•   Support if restricted to official leader defined according to the legal status of the parti. Snipre (talk) 14:17, 15 May 2013 (UTC)
• Is there any point in having a specific property for political parties ? I would prefer a more general "headed by" property. Beside, I think the value for this kind of property should be Leader of the Conservative Party (Q3303456), and that the name of current leader should be retrieved in some other way (probably a query), see Wikidata:Project_chat/Archive/2013/05#Political offices. --Zolo (talk) 20:29, 17 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)

Discussion

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)

Discussion

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

Discussion

•   duplicate a property proper motion was already approved

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

Discussion

•   duplicate a property parallax was already approved --Paperoastro (talk) 18:16, 20 July 2013 (UTC)

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

Discussion

•   duplicate a property distance was already approved --Paperoastro (talk) 18:18, 20 July 2013 (UTC)

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

Discussion

•   duplicate a property absolute magnitude was already approved --Paperoastro (talk) 18:23, 20 July 2013 (UTC)

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

Discussion

  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)

Discussion

•   duplicate a property proper motion was already approved --Paperoastro (talk) 18:12, 20 July 2013 (UTC)

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

Discussion

  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)

Discussion

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)

Discussion

  Support--Kompakt (talk)

  Support — Ivan 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)

Discussion

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: made from material (P186) = lawn (Q207766) with qualifier applies to part, aspect, or form (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)

Discussion

•   Comment There is already a pending proposal for "location" which can be found here. However, the other one is just for rivers. This one is designed to make statements where a event took place. Example: I checked up some data objects of and notice there is no statement where the disaster occurred, e.g. 2013 Savar building collapse (Q11838739), 2011 Reno Air Races crash (Q153570) or Nyamiha disaster (Q2634583). Some (like Chernobyl disaster (Q486)) use the property "coordinate location", but:
  • It would take a long time still we can clearly assign every coordinate to the corresponding administrative unit (like city), so we can't make queries like 'get all disasters which occurred in Italy'.
  • for most fictional events we just have the name of the place, which can't assign to a coordinate. E.g. the Battle of the Hornburg (Q1764229) took place at Helm's Deep (Q1641279).

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)

Discussion

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

Discussion

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)

Discussion

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)

Discussion

•   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 http://www.crediblemeds.org/healthcare-providers/drug-drug-interaction 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)

Discussion

• Your example uses "earthquake" as the value. Shouldn't it be 226 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)
  • Yes, better as a general qualifier. —★PοωερZ_talk 19:05, 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)

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

Discussion

•   Comment - Although the string is only composed of numbers we are not going to do any calculations with it. Plus we don't want it to convert into other number formats. I think datatype string would be more appropriate. --Tobias1984 (talk) 15:14, 29 July 2013 (UTC)
• Seems to be the same as Wikidata:Property_proposal/Place#Municipality_code_.28CH.29. --  Docu  at 18:23, 5 August 2013 (UTC)

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

Discussion

  Support--Kompakt (talk)

  Support — Ivan A. Krestinin (talk) 10:33, 26 July 2013 (UTC)

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

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)

Discussion

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)

•   Support Danrok (talk) 23:56, 25 May 2013 (UTC)
•   Support. --Yair rand (talk) 10:33, 6 June 2013 (UTC)

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

  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)

Discussion

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

Discussion

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

Discussion

  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)

Discussion

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

Discussion

•   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

Discussion

  Support Note that the annotations between diseases and phenotypes can be drawn from http://www.human-phenotype-ontology.org/ (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)

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

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

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

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

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

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

•   oppose datatype - Items can be created or already exist. See: parasitism (Q186517) --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)

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

Discussion

• see here.

  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)

Discussion

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)
          • I fail to see why you say that "until" cannot be used here: Antiochus IX Cyzicenus (Q296446) spouse (P26) Cleopatra IV of Egypt (Q40023) from around 115 BC until around 112 BC, my source no:Antiokos IX Kyzikenos Byrial (talk) 17:54, 17 May 2013 (UTC)
            • For someone who is not able to speak Norwegian or who simply isn't aware of the impact when the "until date" is filled with "unknown" and therefor doesn't search the entire internet for it, so in most practical situations, the "until date" in this example is unknown. Can we agree on that? --NormanB (talk) 00:50, 18 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:

• RAF Abbots Bromley (Q7275121)

• instance of (P31) = Unoccupied site

• end time (P582) = 1940

• instance of (P31) = Royal Air Force station (Q7373622)

• start time (P580) = 1940
• end time (P582) = 31 March 1949

• instance of (P31) = Abandoned site (or "abandoned air force base" if it needs to be more specific)

• start time (P580) = 31 March 1949

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)

• start time (P580) = 31 March 1949
• end time (P582) = 2012

• instance of (P31) = Unoccupied site

• start time (P580) = 2012

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)

Discussion

•   Oppose wrong datatype and duplicate of Wikidata:Property_proposal/Pending#Height_of_person --Tobias1984 (talk) 21:00, 10 August 2013 (UTC)
  • Ah, didn't see that, thanks for the pointer. Would still be nice to have something for buildings and other objects. And if a number datatype's going to be available in the future, all the better! Schneelocke (talk) 21:04, 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)

  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)

  Done --Tobias1984 (talk) 10:29, 12 August 2013 (UTC)

→ Property:P792

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