Testwiki:Property proposal/Archive/9

coordinate location / Standort / Position

Template:Status → Property:P625

• Description: Coordinates of the place
• Datatype: GeoCoordinateValue
• Links:
• Infobox parameter example:
• Comments:

Template:Support must needed property. --Nizil Shah (talk) 20:39, 8 February 2013 (UTC)

Template:Support. --NaBUru38 (talk) 21:39, 8 February 2013 (UTC)

Proposal to change the label from "Location" to "location coordinate" to be more explicit and to avoid conflict with the other proposed property. (see: http://www.wikidata.org/wiki/Wikidata:Property_proposal#Is_in_.2F_Ist_in_.2F_Est_a) --Napoleon.tan (talk) 02:50 February 16, 2013 (UTC)

Template:Support: location coordinate --ThorstenX1 (talk) 19:47, 16 February 2013 (UTC)

Template:Support Important, but should be renamed as proposed above. -- Faux (talk) 21:52, 17 February 2013 (UTC)

Changed. Sven Manguard Wha? 05:37, 18 February 2013 (UTC)

Sandbox-GeoCoordinateValue / Spielwiese-GeoCoordinateValue / Bac à sable-GeoCoordinateValue / Pagina delle prove-GeoCoordinateValue

Template:Status Template:Comment → Property:P626 created now that coordinates datatype is available. — PinkAmpers&^{(Je vous invite à me parler)} 18:47, 10 June 2013 (UTC)

---

• Description: any kind of values
• Datatype: GeoCoordinateValue (1 Sandbox type per available data type)
• Domain: any kind of values
• Infobox parameter: any/generic (but more for testing than productive)
• Comments:

---

Original discussion below copied from Wikidata:Property proposal/Archive/4#P370.

To be honest I am badly informed about wikidata, just to make that clear. I do think that I need a property to be created in order to store values, please confer Wikidata:Requests for permissions/Bot/DrTrigonBot and Wikidata talk:Infoboxes task force#Feasibility of DrTrigonBot/Subster to update Wikidata. Thanks for all your help and patience. Greetings --DrTrigon (talk) 20:54, 22 March 2013 (UTC)

Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)

In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)

Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)

Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)

I think testing bots should not be done on the productive Wikidata, except in the sandbox.--Faux (talk) 17:04, 23 March 2013 (UTC)

It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)

I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)

Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)

Sounds good! (+1) Thanks for the idea! Greetings --DrTrigon (talk) 22:41, 23 March 2013 (UTC)

Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)

I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)

So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:

1. Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
2. Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
3. Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String

any comments or thoughts on this? Thanks and Greetings --DrTrigon (talk) 10:52, 29 March 2013 (UTC)

Ok here we go:

1. Sandbox-CommonsMediaFile (P368)
2. Sandbox-Item (P369)
3. Sandbox-String (P370)

so these can be considered done but I think it makes sence to propose the future ones too and set them to the pending page:

• Label: Sandbox-Quantity / Description: Sandbox property for value of type "Quantity" / Data type: Quantity
• (and all other data types to be introduced in future...)

Thanks for all your help! Greetings --DrTrigon (talk) 01:09, 30 March 2013 (UTC)

Reference property: Minor planet circular

Discussion

Today I see q328 used as "source" everywhere and my insticts tells me it's wrong, but I understand why it's necessary. This gives us a better alternative. Lavallen (block) 18:24, 10 May 2013 (UTC)

• Template:Support This is a good idea! A script could automatically show the link to the web page, as for GND or VIAF properties. --Paperoastro (talk) 11:25, 12 May 2013 (UTC)

A good idea, if it's possible. I have tried to copy those uri, but there is something strange with them. Does it demand a POST? -- Lavallen (block) 13:37, 12 May 2013 (UTC)

This is one of the last MPC. The link is made with the date of publication. Perhaps my idea is not so simple! --Paperoastro (talk) 18:59, 12 May 2013 (UTC)

Please do not create a particular reference system. For website we have a set of "mandatory" parameters see in order to have a general concept as explained in Help:Sources. And if you want to use URL data please wait on the appropriate datatype because it would be a mess later. Snipre (talk) 17:22, 18 May 2013 (UTC)

@Paperoastro Your proposition (pdf) can be defined as a report in the Help:Sources page. Snipre (talk) 17:26, 18 May 2013 (UTC)

I did not proposed it as a webb-property. I do not simply find a way to create a url based on this "number". I rather propose this as a "serial number" for this publication. The matrix in the webb-page above simply connects each "serial number" with some claim in some items. I know there is a RFC about references in progress, and this proposal should not be closed as succesfull until we know the result of that RFC.

Regarding the RFC: I find it very difficult to understand what they talk about there. But I often fail to understand the technical parts of references even when they are discussed on Wikipedia. To often are Wikipedians speaking about references as if they are going to publish a hand-written dissertation. My teacher told me to not bother about such things, as long as I use the same system in all of the paper. LaTeX simply solved that for me. -- Lavallen (block) 17:52, 18 May 2013 (UTC)

RFC concerns mainling books and the problem of different editions of the same but having different bibliographic data. Do not focus on that if you are not using books for referencing. Snipre (talk) 04:24, 19 May 2013 (UTC)

I'm sorry to generate confusion with my idea of automatic link! MPC circulars are identified only by a progressive number (and, optional, by the date of pubblication), as specified by Lavallen in this proposal. My idea of creating automatically a link to the web page (as for GND or VIAF) is not feasible because the circulars are grouped by the day of pubblication.

@Snipre thank you very much for the link, I read it very carefully. Imho the idea to have few properties to manage sources is intriguing and "MPC circulars" could be identified in the group of report.

@Lavallen your professor (and you) has right: is importat to use the same system, and in Help:Sources people try to do this for Wikidata ;-) Do not be discouraged! If I understand correctly, MPC circulars can be identified as "Report" in this manner:

• Title: MPC circulars number;
• Author: the list of authors;
• Publisher: Minor Planet Center;

and, if we want, we can use also the Date of publication and the language. Do you agree?

If all of you are agree, we can change this proposal to create the missing property title for Reports. --Paperoastro (talk) 00:31, 19 May 2013 (UTC) P.S.: I hope not to be too bold!

That's it. This property is already proposed in Wikidata:Property_proposal/References#Article title. We can extend the application field to report and media without any problem. Snipre (talk) 04:24, 19 May 2013 (UTC)

Please support the Article title proposal with your comment for extension to report in order to show the consensus for the property creation. Snipre (talk) 17:53, 26 May 2013 (UTC)

I support such property, but it should have also link to circular.--Ahonc (talk) 20:45, 26 May 2013 (UTC)

@Lavallen: they actually use some sort of silly referer check, the message is "This script can only be called by the MPES or from the list of discovery circumstances of numbered minor planets." --Ricordisamoa 22:44, 26 May 2013 (UTC)

Template:Done, http://scully.cfa.harvard.edu/cgi-bin/showcitation.cgi?num=005002 can now be shortened and hotlinked with http://ricordisamoa.tk/mpc/005002! --Ricordisamoa 23:25, 26 May 2013 (UTC)

Very interesting! Thanks! :) Can be used automatically without URL datatype? --Paperoastro (talk) 10:45, 8 June 2013 (UTC)

Can we close the proposal ? Snipre (talk) 13:31, 10 June 2013 (UTC)

I think yes. --Paperoastro (talk) 14:05, 10 June 2013 (UTC)

edition of

Discussion

• Template:Support Needed to complete the logical structure of book sources. See Wikidata:Books_task_force#Edition_properties--Micru (talk) 01:02, 5 June 2013 (UTC)
• Template:Support --Stevenliuyi (talk) 20:32, 5 June 2013 (UTC)
• Template:Oppose We can use instance of or subclass of. Snipre (talk) 18:14, 8 June 2013 (UTC) I am not convinced by this proposal but I prefer to have this property and a solution for sourcing statement than spending still weeks in discussion. We can always change the property later. Snipre (talk) 19:26, 14 June 2013 (UTC)
  • Probably "subclass of" would confuse users. "Edition of" is more clear in that regard.--Micru (talk) 20:07, 12 June 2013 (UTC)
• Template:S Filceolaire (talk) 18:00, 10 June 2013 (UTC)

==> continued in #edition (2), below.

Paris electronic code / code information de la ville de Paris

• Template:Support - We need this. --Tobias1984 (talk) 19:36, 1 June 2013 (UTC)

Structural engineer

Discussion

Template:Support --Чаховіч Уладзіслаў (talk) 08:56, 3 June 2013 (UTC)

Cultural properties of Belarus reference number / Шыфр гісторыка-культурнай каштоўнасці Рэспублікі Беларусь

Discussion

Template:Support--Хомелка (talk) 05:30, 3 June 2013 (UTC)

Répertoire du patrimoine culturel du Québec identifier / identifiant Répertoire du patrimoine culturel du Québec

Discussion

Useful as not all the properties inscribed in the Template:Q are present in Template:P. --Fralambert (talk) 03:19, 26 May 2013 (UTC)

Template:Support. This should probably be at Wikidata:Property proposal/Authority control, though. Superm401 - Talk 03:03, 27 May 2013 (UTC)

Should I move the proposal? I put this here because Template:P and Template:P was in creative work. --Fralambert (talk) 13:08, 28 May 2013 (UTC)

• Template:Support Danrok (talk) 13:57, 9 June 2013 (UTC)

Captain / Kapitän / Capitaine

Template:Status → Property:P634

• Description: Captain of a sports team
• Datatype: Item
• Links:
• Domain: sports teams
• Infobox parameter example: hockey club: en:Template:Infobox hockey team (captain parameter)
• Comments: --Carport (talk) 17:36, 8 March 2013 (UTC)

Template:Support Shawn in Montreal (talk) 17:45, 8 March 2013 (UTC)

Template:Comment only current captain or every captains in the team history? --Stryn (talk) 09:04, 16 March 2013 (UTC)

All. Qualifiers will tell when each player was captain. --NaBUru38 (talk) 19:39, 27 March 2013 (UTC)

Template:Support --Stryn (talk) 12:08, 28 May 2013 (UTC)

Template:Done - Created at Template:P. Superm401 - Talk 19:10, 16 June 2013 (UTC)

Station Class / 车站等级

Template:Property proposal Template:Support, but I think it would be better if the property is named "station classification". --Wylve (talk) 15:50, 26 May 2013 (UTC)

I don't know if there is an official translation or not. "station class" can only be found on English Wikipedia. --凡其_Fanchy 19:57, 1 June 2013 (UTC)

On second thought, This can be done with Template:P.--凡其_Fanchy 19:17, 2 June 2013 (UTC)

This proposal will be deleted: proposal withdrawn Snipre (talk) 08:27, 15 June 2013 (UTC)

Article title

Template:Property proposal It is not possible to have an item for every article so for reference purpose so we need an additional property allowing to enter this information in reference data. A constraint to use this propery will be to use it in parallel of the property "stated in": the "Article title" property concern only subpart of another work (a journal for example) and the whole work in which the article is published has to be cited too. Snipre (talk) 09:31, 13 April 2013 (UTC)

I think we need a "title" property for all sorts of works. It should be a monolingual string, a be the full title, by contrast to the label that is multilingual, will often be missing in many languages, and can clip the real title for convenience).

I would support simply renaming P:P357 to title. Having two properties is confusing, as we do not know which one to choose when the work does not have any translation. Major libraries simply use "title" for the original title, and that makes even more sense in a multilingual database. Note that I had initially created P:P357 under the name title and documented it with Q12418, where "original title" does not make any sense. --Zolo (talk) 07:29, 25 April 2013 (UTC)

"monolingual string", what is the difference between "monolingual string" and "string"? -- Lavallen (block) 16:13, 26 May 2013 (UTC)

A general title property for articles, report, books and so on will be very useful. Initially I was agree with Zolo to use P:P357, but I prefer as datatype monolingual string instead of string, so I Template:Support the creation of this property with monolingual string datatype. To avoid confusion, P357 should be deleted. @Lavallen: monolingual string is a string with in addition the specification of the language of the text. --Paperoastro (talk) 18:36, 26 May 2013 (UTC)

We have a property to specify the language of the work see Property:P407, so we don't need to wait on a monolingual datatype. Using a property to screen language of sources is more simpler than using a subinformation of a datatype. And if you assume that you will have item as sources like for books, the language property will be the best solution to screen and compare languages of all sources and in a independent way from the datatype. Snipre (talk) 07:38, 27 May 2013 (UTC)

Your idea sounds good, and surely it could avoid confusion. (I "delete" my comment above, after your explanation) ;) Before to support this proposal, I have a question: what is the difference between this new property and P:P357? There are any reasons to have a different property? --Paperoastro (talk) 11:47, 27 May 2013 (UTC)

I did a proposition to extend the application field of the original title property there. Snipre (talk) 18:57, 27 May 2013 (UTC)

This proposal will be deleted: an existing properties is used in an extending concept. Snipre (talk) 13:49, 13 June 2013 (UTC)

Original name /// Название на языке страны

Discussion

This proposal will be deleted: it is redundant with Wikidata:Property_proposal/Pending#Official_name_.2F_Name_.2F_Nom_.2F. Snipre (talk) 19:18, 10 June 2013 (UTC)

Critical pressure (en)

Discussion

Template:Support Snipre (talk) 12:09, 7 June 2013 (UTC)

This proposal will be deleted: this proposal is merged. Snipre (talk) 19:27, 12 June 2013 (UTC)

Critical temperature (en)

Discussion

Template:Support Snipre (talk) 12:09, 7 June 2013 (UTC)

This proposal will be deleted: this proposal is merged. Snipre (talk) 19:29, 12 June 2013 (UTC)

Triple point pressure (en)

Discussion

Template:Support Snipre (talk) 12:09, 7 June 2013 (UTC)

Template:Comment Isn't it enough to create the property "triple point temperature" and use a qualifier for the pressure? As an alternative we could also make a property called "triple point" that links to an item which describes which triple point were talking about. Both temperature and pressure would be existing qualifiers for that property and we would be able to create items for all the phase changes not only the triple point for solid-liquid-gas. --Tobias1984 (talk) 15:25, 10 June 2013 (UTC)

This proposal will be deleted: this proposal is merged. Snipre (talk) 19:29, 12 June 2013 (UTC)

Triple point temperature (en)

Discussion

Template:Support Snipre (talk) 12:09, 7 June 2013 (UTC)

Template:Comment I think key point (item) with qualifiers temperature (number) and pressure (number) would be a better solution than having these 4 properties. This way all the information belonging together would be in the same claim. —★PοωερZ_talk 14:56, 8 June 2013 (UTC)

• I can't really be done like that, because all of those measurements need qualifiers themselves if they weren't carried out by STP-conditions. I think we would need a new multi-dimensional data type to fully describe a chemical system with all its physical characteristics. --Tobias1984 (talk) 16:03, 8 June 2013 (UTC)

STP is only temperature and pressure, the things being measured here. —★PοωερZ_talk 16:47, 8 June 2013 (UTC)

• Template:Support - As all of thermodynamics everything should be strictly in Kelvin and Pascal. No Bars, Fahrenheit, mmHG, etc. --Tobias1984 (talk) 16:03, 8 June 2013 (UTC)

  No, unit as to be put in the original ãnd unit will be converted in the template in the client. the reason for that is to ensure a correct conversion of the unit. Snipre (talk) 17:53, 8 June 2013 (UTC)

• To my knowledge all thermodynamic literature is metric so if somebody enters a non-metric number, that number has already been converted. So there is no way to tell if it has been converted correctly the first time around. --Tobias1984 (talk) 20:35, 8 June 2013 (UTC)

• In organic chemistry they used a lot the calorie unit and depending the publication especially the old ones you can find formation enthalpy in kcal. Snipre (talk) 21:53, 10 June 2013 (UTC)

Units are a core problem of number datatype. We should wait for the devs to create the datatype before discussing possible problems with it. —★PοωερZ_talk 22:01, 10 June 2013 (UTC)

phase diagram of water for different ice phases (German)

• Template:Comment Water has eleven known triple points, so you have to group them together in one way or another (and also two critical points). —★PοωερZ_talk 04:20, 10 June 2013 (UTC)

• You're right. We could rename this property "triple-point solid-liquid-gas"? What can we do with the other triple points? --Tobias1984 (talk) 15:11, 10 June 2013 (UTC)

• When we create a property for one of the triple points, all of them should have one, but I think that's the wrong approach since we could end up creating a property with only one use. We have items for the different phases, e.g. Template:Q (at least for water, I don't know about other materials' phases, so we might have to create them), so something like this structure could be better:

triple point (item): [liquid, gas, solid]

temperature (number): XXX K

pressure (number): XXX Pa

triple point: [liquid, Ice Ih, Ice III]

temperature: XXX K

pressure: XXX Pa

We might be able to replace Ice Ih, etc. by hexagonal, etc. to avoid creating items, as Ice Ih is just the name of the water phase with a hexagonal crystal system. —★PοωερZ_talk 18:29, 10 June 2013 (UTC)

Not in favor of a string datatype for triple point: I agree for the idea of T and P as qualifier, but I would propose to use 3 times the property phase as qualifier each time to describe one phase of the triple point. Ex.:

Template:Q

phase point (item):triple point

temperature (number): XXX K

pressure (number): XXX Pa

Template:P (item):solid

Template:P (item):vapor

Template:P (item):liquid Snipre (talk) 22:07, 10 June 2013 (UTC)

Discussion

• Template:Support - I think this is the way to go for all the other cases of triple points. The solid-liquid-gas triple point might be special enough to warrant a separate item. Also, we should create separate items for all the phases of ice. We do the same for all the minerals and there are a lot of physical statements that can go into those items. --Tobias1984 (talk) 18:39, 10 June 2013 (UTC)

The way qualifiers work, Snipre's system is better. —★PοωερZ_talk 22:16, 10 June 2013 (UTC)

This proposal will be deleted: this proposal is merged. Snipre (talk) 19:29, 12 June 2013 (UTC)

edition (2)

Discussion

Alternative to 'edition' with datatype 'string' instead of 'item'.
Property is used to list editions of a book whether or not the edition has it's own item. If an edition does not have an item the qualifiers such as 'date of publication', 'place', 'language', 'title', 'subtitle' etc. can add info.
If an edition does have it's own page then qualifier 'dedicated page' can link to that page or 'edition of' can provide a reverse link.

• Template:S Filceolaire (talk) 20:38, 11 June 2013 (UTC)
• Template:O If done this way it won't be possible to point to a specific edition of an item, besides there are many other fields associated with the edition that should be "packed" together (isbn, publisher, date, etc.).--Micru (talk) 18:14, 12 June 2013 (UTC)

I'm going to withdraw this proposal, as Micru's comment. Also we have property Template:P which has string datatype and can do this. Filceolaire (talk) 08:03, 13 June 2013 (UTC)

This proposal will be deleted: proposal withdrawn Snipre (talk) 08:34, 15 June 2013 (UTC)

edition of

Done as Property:P629, archived. This message can be deleted in a few days once people have seen it :). --Zolo (talk) 07:49, 15 June 2013 (UTC)

Motto

Template:Question - (1) Does a university in Bejing really have an English motto? (2) How will translations be available in monolingual-texts? --Tobias1984 (talk) 16:11, 8 June 2013 (UTC)

(1) Yes it really does, see University Introduction. (2) No idea. Danrok (talk) 19:50, 8 June 2013 (UTC)

Template:Comment there is also a similar proposal at Wikidata:Property_proposal/Place#Motto_.2F_Wahlspruch_.2F_Devise. --  Docu  at 20:16, 9 June 2013 (UTC)

This proposal will be deleted: redundant with Wikidata:Property_proposal/Place#Motto_.2F_Wahlspruch_.2F_Devise. Snipre (talk) 19:00, 10 June 2013 (UTC)

Years active

Discussion

• Template:Comment Some Wikipedias use both, turnedpro and retired parameters (including en-wiki), and some only active parameter (e.g. 2000–2010). So I'm not sure what we should do with that, and if this is duplicate with from time (since) and to time (until). --Stryn (talk) 16:23, 1 May 2013 (UTC)
• Template:Support If both years are stored in wikidata, specific infoboxes may choose to display them on the same line or not. Vinkje83 (talk) 10:02, 7 May 2013 (UTC)
• Template:Wait This is better accomplished with a date datatype, and 'from/start' and 'to/end' properties will be amongst the first date properties available. Joshbaumgartner (talk) 10:09, 9 May 2013 (UTC)
• Template:Oppose as "number" datatype. We should have qualifiers of "datetime" type (not available yet), or maybe a "date-interval" datatype. --Ricordisamoa 07:26, 14 May 2013 (UTC)

• Template:Comment I think we can express this with default date-range-qualifiers (from time ... to time) on Template:Property = Template:Q.--Kompakt (talk) 14:24, 28 May 2013 (UTC)

• Sounds good IMO. --Stryn (talk) 08:18, 30 May 2013 (UTC)

Without any new comment this proposal will be deleted: the trend is to use qualifers Template:P and Template:P and we need to use an unique system to indicate time interval for data extraction reason. Snipre (talk) 02:14, 7 June 2013 (UTC)

Twitter account

• Description: Personal Twitter account
• Datatype: Monolingual text
• Domain: Person, Organisation
• Source: External links section in biography articles in Wikipedia
• Example item and value: <Toomas Hendrik Ilves> Twitter account <IlvesToomas>
• Comments: Should be verified somehow. Link in personal webpage is good, Twitter account verification is better. --Papuass (talk) 13:36, 12 March 2013 (UTC)

Template:Comment with or without starting '@'? -- MichaelSchoenitzer (talk) 22:38, 13 March 2013 (UTC)

I propose without the '@' (helps saving storage, can be automatically formatted+linked later) --Ricordisamoa 22:49, 13 March 2013 (UTC)

Template:Support --Goldzahn (talk) 10:44, 14 March 2013 (UTC)

Template:Oppose. This would open the door to facebook-page, google-plus-page, tumblr, myspace, and many many more. Also I dont think that such property has any relevance in say 20 years.--Svebert (talk) 15:28, 14 March 2013 (UTC)

What's wrong with those? It's relevant data. It doesn't matter whether our data will be relevant in 20 years, or 100000 years. Legoktm (talk) 15:40, 14 March 2013 (UTC)

If find it awkward to say Person xy has the property twitter-account=xyz. Also I do not understand why twitter and not -say- myspace. Why twitter and not any email-address--Svebert (talk) 15:50, 14 March 2013 (UTC)

Propose a myspace property then. I would support that too. Email address is also a valid property, but might be harder, since people tend to keep their email address private compared to say, a twitter account. It's no less valid though. Legoktm (talk) 15:54, 14 March 2013 (UTC)

how about postal address? Or GPS-coordinates of the bedroom used in the month of may?

how about color of bed sheets or favourite car manufacturer?

how about length of distance to workplace in winter when streets are icy?

Why are these proposals obviously ridiculous but not “twitter account“?

My hint: Nobody on earth would describe somebody with the property “twitter account“. If you are talking about a person with a friend who doesn't know this person, do you say: “This person has the twitter-account xyz”? You propably stick to the more objective properties like “This persons sex is female“, “She works at ...“, ”She is at age 36” etc.--Svebert (talk) 16:32, 14 March 2013 (UTC)

All the stuff you said is non-notable. Twitter accounts are added to biographies in the External links section. Emijrp (talk) 12:31, 16 March 2013 (UTC)

Template:Support without the "@". Legoktm (talk) 15:40, 14 March 2013 (UTC)

I don't know how much this property will be relevant in 20 years, but at the moment, I feel that this information could be useful; however, including all names and codes for personal accounts will lead to edit wars (due to poor references) and overclaimization. --Ricordisamoa 16:44, 14 March 2013 (UTC)

Template:Oppose - I do not believe Wikidata should be a repository for external links, only personal information. The problem with linking any third-party service is that these services change and some go obsolete. In addition, I fear that some living people might see this as a privacy violation (even if it technically isn't).--Jasper Deng (talk) 00:48, 15 March 2013 (UTC)

This isn't a URL property, it's text. Legoktm (talk) 03:25, 15 March 2013 (UTC)

Template:Comment Svebert, the intention of nominating only Twitter property was to check general response. If this is considered OK property, then "personal website", "facebook page", "cyclingarchives.com profile ID" (for professional cyclists), "national-football-teams.com profile ID" (for professional football players), "nhl.com profile ID" and lots of other useful resources could be added. Notability guidelines can be established (I think they exist for external links section). These properties are not useful for infoboxes (maybe website link is used), but they are used in most Wikipedias in external links section. These links could be gathered from Wikidata and displayed in every Wikipedia, just like the Phase 2 for infoboxes. Anyway, if property is found to be outdated (Twitter decides to shut down the service), technically it is very easy to remove all references to it. --Papuass (talk) 09:42, 15 March 2013 (UTC)

Template:Oppose Wikidata is not a directory of personal information. This kind of information doesn't help to describe or to inform about the person. Snipre (talk) 12:21, 15 March 2013 (UTC)

• Template:Comment official website is already accepted? Why not to rename it something like "official sites" where to put every notable links, including Twitter? --Stryn (talk) 08:57, 16 March 2013 (UTC)

Template:Oppose. Official website is accepted, due to the fact that it does not run on another platform (like Twitter or Facebook) and provides relatively formal information, whereas Twitter pages display more personal information about the entity. --Wylve (talk) 09:56, 16 March 2013 (UTC)

Template:Comment many people/band don't have official websites, but official twitter/facebook/google+/myspace account. --Stryn (talk) 10:25, 16 March 2013 (UTC)

I propose not to create this property, but to use the entity's twitter profile URL as the value of the official website property only when the entity does not have an official website. Same goes to Facebook, myspace, linkedin, etc. --Wylve (talk) 06:33, 17 March 2013 (UTC)

Template:Support see. Emijrp (talk) 12:33, 16 March 2013 (UTC)

• I'd Template:Support an "official media" property, which could include official website and social network accounts, but also magazines, television shows, etc. But I Template:Oppose having a property for each social network. --NaBUru38 (talk) 19:17, 19 March 2013 (UTC)

Template:Oppose per NaBUru38's reason for opposing. But something like "social media" property would be good. --Stryn (talk) 21:40, 19 March 2013 (UTC)

It doesn't have to be a social media, it can be an old-school media like an official website, radio / television show or magazine. --NaBUru38 (talk) 18:51, 20 March 2013 (UTC)

• If a person or organization has a relevant public account on a social network related to whatever it is they're notable for, I could see it making sense to have that data on Wikidata. (I'm picturing someone using Wikidata to analyze Twitter text output of all people elected to X position who also have attributes X...) However, we should specify that the account has to be relevant, though I'm not sure what criteria we would need for this. We probably wouldn't, for instance, want to list the account of someone who has a Wikidata item on account of being related to someone. This needs further consideration. --Yair rand (talk) 00:29, 20 March 2013 (UTC)
• Template:Oppose Per Snipre. --Sannita - not just another it.wiki sysop 14:05, 23 March 2013 (UTC)
• Template:Oppose Wikipedia has achieved a consensus that articles about Twitter accounts of persons/organizations are not notable for inclusion. So, how do we'd link to them from here if they don't exist and an item about those Twitter accounts cannot be created? Also, they can change of account name when they wish, so we would have to be be updating the info each and then, which will make this more trouble than benefit. And additionally, I agree with what someone said above that this would open the door to facebook-page, google-plus-page, tumblr, myspace, and many many more. — ΛΧΣ²¹ 04:40, 26 March 2013 (UTC)
• Template:Comment Bear in mind that Wikidata is not Wikipedia. It may be that other users of Wikidata would want this information to be available. Danrok (talk) 13:06, 1 April 2013 (UTC)
• Template:Comment ΛΧΣ: there is no propositon to create items about Twitter acounts, but use them as properties instead. And I do not see much difference between this proposal and already confirmed property Property:P345. --Papuass (talk) 09:14, 2 April 2013 (UTC)
• Template:Oppose There are many websites, many hosting websites, and many social networking websites and networks of them. IMDB is an old database (23 years); OpenStreetMap is a free database (and integrated in Wikipedia). Twitter is a microblog hosting and a social networking service that appeared in 2006 (7 years ago). It is popular, but is neither old, nor free or integrated with Wikipedia; how is it different from StatusNet, Diaspora etc., except that it always has the same domain name (which means the specific service can be inferred from the address)? Maybe create an item for blogs and social networks, and use with qualifiers: Wikidata:Project_chat#Property_qualifier_release_on_Wednesday. But what if people start adding e-mail addresses? --AVRS (talk) 18:18, 17 April 2013 (UTC)
• Template:Oppose Many other social media and other website should be consolidated in a common attribute like member of "Twitter" then qualifier for media id.

e.g. Eric Schmidt Q92747 => Twitter Q918, qualifier "social media address" => "ericschmidt" (string data type) --Napoleon.tan (talk) 13:27, 30 April 2013 (UTC)

• Template:Support, as it is a widely used and very influential website. I have nothing against creating properties for social media but would oppose a general "social media" property, as it would make things substantially more complicated for no clear benefit. --Zolo (talk) 08:58, 2 May 2013 (UTC)
• Template:Support as comments above. Filceolaire (talk) 19:42, 14 May 2013 (UTC)
• Template:Comment How do we ascertain that added account is the original one and not spoof? because there are a ton of spoof accounts.--Vyom25 (talk) 14:17, 23 May 2013 (UTC)

Perhaps it could be verified accounts only? Danrok (talk) 21:37, 23 May 2013 (UTC)

• Template:Support Let's say, hypothetically, that I've created my own AI running off of Wikidata, and am giving it away for free as an app. (This is, of course, what we hope will eventually become one of the primary purposes of this database.) So, what is the average person talking into their smartphone more likely to ask my AI: "What's so-and-so's VIAF identifier?" or "What's so-and-so's Twitter handle?" It's all well and good that we're turning this project into a useful resource for librarians, statisticians, and what-not, but don't forget the Everyman! — PinkAmpers&^{(Je vous invite à me parler)} 11:19, 30 May 2013 (UTC)
  • Huh. Turns out we had, in fact, forgotten the Everyman. Lol. — PinkAmpers&^{(Je vous invite à me parler)} 11:24, 30 May 2013 (UTC)
• Template:Oppose, redundant to Template:P. --Yair rand (talk) 12:28, 30 May 2013 (UTC)

---

There're already Template:P. This request is archived.--GZWDer (talk) 03:07, 19 June 2013 (UTC)

together with / gemeinsam mit

Template:Property proposal The together with qualifier allows an easy way to indicate that some property or relationship is shared with someone else. This is especially useful if the meaning of the relationship is influenced by it's shared nature, e.g. in the case of parentship. Note that this qualifier is not necessarily limited to people, but seems especially useful in that context. Duesentrieb (talk) 10:46, 25 April 2013 (UTC)

Template:Question Is it useful to have properties/qualifiers inferable from neighbouring items? If there are exceptions, could you show an example? Thanks. --AVRS (talk) 10:56, 25 April 2013 (UTC)

In theory yes, but we'll not have automatic inferred parameters on Wikidata soon, and even when we do, we still need a qualifier property to represent them. I could imagine such qualifiers being added by bot, though.

I'm not sure what kind of example you mean... maybe, if Serge Haroche has Nobel Prize (in Physics) (in 2012), and David J. Wineland also has Nobel Prize (in Physics) (in 2012), we could infer the "together with" qualifier for that... but it already needs a bit of special knowledge to decide which qualifiers need to be taken into account for this match.

Anyway, no matter whether this is going to be maintained manually, by bot, or fully automated based on rules, we need to define the property to be able to use it as a qualifier. -- Duesentrieb (talk) 12:30, 25 April 2013 (UTC)

Template:Comment This should be listed as a generic property because it applies to more than just people, but also organizations or even other items: Bell manufactures the V-22 Osprey together with Boeing; Idaho borders Oregon together with Washington; B-17 Flying Fortress maiden flight was in 1935 together with Douglas DC-3; etc. Joshbaumgartner (talk) 09:04, 9 May 2013 (UTC)

As far as manufacturing goes, we can already claim this kind of thing. Just list the manufacturers involved, add the qualifier Template:P to indicate which parts they made. Danrok (talk) 23:29, 8 June 2013 (UTC)

done -- Duesentrieb (talk) 13:37, 21 May 2013 (UTC)

Template:O I'm not sure this is needed for any of your examples.

Aldous Huxley has Template:P Leonard Huxley

Aldous Huxley has Template:P Julia Arnold.

Illluminatus has author Robert Anton Wilson.

Illuminatus has author Robert Shea.

Nobel prize:

year: 2012

subject: Physics

winner: Serge Haroche

winner: David J Wineland.

Putting one of the property items into a qualifier is relegating it to second place where it may well be missed in a search. We should just list both parties as above, giving each equal billing. Filceolaire (talk) 20:29, 6 June 2013 (UTC)

Template:Oppose per Filceolaire Snipre (talk) 15:59, 8 June 2013 (UTC)

• Template:Oppose I can't see what this property would achieve which cannot already be achieved using existing properties, qualifiers, etc. Danrok (talk) 23:23, 8 June 2013 (UTC)
• Template:Comment I would like to point out that while this property can easily be derived from existing properties, for it to be derived visibly and usably within wikidata, it must exist! It's redundant in the sense that the brother/sister relationships are redundant, since they are implied by a shared parent: they are redundant and can be derived, but they are non the less useful to have, no matter wither they are entered explicitly, maintained by bot or derived by the system itself. I think that it is useful to be able to express the notion that some property is shared in cases where the "shared-ness" is relevant (like when having children, or sharing a prize). -- Duesentrieb (talk) 20:02, 10 June 2013 (UTC)

---

Consensus against. Request is archived.--GZWDer (talk) 03:11, 19 June 2013 (UTC)

together with / gemeinsam mit

moved to Wikidata:Property_proposal/Generic#together with / gemeinsam mit as per Joshbaumgartner's suggestion -- Duesentrieb (talk) 13:36, 21 May 2013 (UTC)

brother-in-law (spouse's brother)

Template:Property proposal Isn't this redundant since this data is already stored with Property:P7 in the spouse's item? —★PοωερZ_talk 13:11, 25 April 2013 (UTC)

No, usually there is no separate item for the spouse, but there may still be a brother-in-law with an item. --  Docu  at 14:54, 25 April 2013 (UTC)

Wikidata:Notability: "An item is acceptable [...] if it fulfils at least one of these two goals: [...] 3. It fulfils some structural need, i.e. it is needed to make statements made in other items more useful." If there is a relevant brother-in-law, wife becomes relevant. —★PοωερZ_talk 14:59, 25 April 2013 (UTC)

Template:Oppose, per 23PowerZ. --Yair rand (talk) 16:14, 25 April 2013 (UTC)

Template:Comment What if sources only say "X is Y's brother-in-law" and nothing more? In this case we even don't know what "brother-in-law" means, should we use "brother-in-law (sister's husband)" or "brother-in-law (spouse's brother)"? --Stevenliuyi (talk) 17:37, 25 April 2013 (UTC)

Template:Comment I proposed merging P:P7 (brother) and P:P9 (sister) at Wikidata:Project chat. User:Izno pointed out to me quite well the current family relationship system is a mess. So I created User:23PowerZ/Stuff for a more general discussion. —★PοωερZ_talk 02:59, 26 April 2013 (UTC)

Template:Oppose Snipre (talk) 17:24, 21 May 2013 (UTC)

---

Consensus against. Request is archived.--GZWDer (talk) 03:14, 19 June 2013 (UTC)

Nephew (en) / Neffe (de)/ Neveu (fr)

Discussion

Apparently this has never been proposed. If the property is already on its way, please revert… Btw, niece would be helpful as well. Alexander Doria (talk) 22:11, 30 May 2013 (UTC)

• Template:Oppose per Wikidata:Requests for comment/Kinship. —★PοωερZ_talk 22:47, 30 May 2013 (UTC)
• Template:Oppose, redundant. See also: Wikidata:Properties for deletion#Property:P29 + Property:P139. Mushroom (talk) 12:32, 4 June 2013 (UTC)
• Template:Oppose, per above. --Ricordisamoa 13:32, 4 June 2013 (UTC)
• Template:Oppose. --Yair rand (talk) 19:18, 10 June 2013 (UTC)

---

Consensus against. Request is archived.--GZWDer (talk) 03:14, 19 June 2013 (UTC)

BPN (en)

Discussion

Template:Support --Ricordisamoa 02:35, 17 June 2013 (UTC)

RKD artists (en)

Discussion

We already have Template:P, also by Template:Q, for objects but there is a different database for people, and I do not think it is possible to use the same property to generate external links. --Zolo (talk) 06:34, 5 June 2013 (UTC)

Template:Support Jane023 (talk) 08:08, 19 June 2013 (UTC)

NRHP reference number (en)

Discussion

Template:Support --Ricordisamoa 02:33, 17 June 2013 (UTC)

Template:Support--Zolo (talk) 08:44, 17 June 2013 (UTC)

Template:Support Jane023 (talk) 08:07, 19 June 2013 (UTC)

UNII

Template:Property proposal Template:Support identifier of FDA. Snipre (talk) 23:44, 4 June 2013 (UTC)

Template:Support --Kaligula (talk) 07:06, 19 June 2013 (UTC)

PubMed Health

Discussion

Template:Support Peter.C (talk) 20:53, 15 June 2013 (UTC)

Template:Support --Gambo7 (talk) 20:43, 16 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Coordination / coordinación / Koordination /coordinazione

• Description: coordination parameters which can be used in infoboxs or coord template or Location map Template
• Datatype:Geographical coordinate
• Links: en:template:Infobox settlement
• sources: we can extract these variables by bots or manually form wikipedia infoboxs or websites like google map or coordination datacenters like openstreet maps and etc.
• Infobox parameter example:en:Atlanta or en:berlin
• Comments: I suggest to make separate property for these variables. I tried to collect the vaital variabel and we can descusss for others like (map_alt ,map_caption ,pushpin_map ,pushpin_label_position,pushpin_map_alt,pushpin_map_caption,coor_pinpoint,coordinates_type,coordinates_display,coordinates_footnotes,coordinates_region) in another requests

Essential parameters for degree base coordination

• latd :latitude degree (Datatype:Number)
• latm :latitude minute (Datatype:Number)
• lats :latitude second (Datatype:Number)
• longd :longitude degree (Datatype:Number)
• longm :longitud minute (Datatype:Number)
• longs :longitud second (Datatype:Number)

• latNS :latitude direction (North or South) (Datatype:String)
• longEW :longitud direction (East or West) (Datatype:String)

Essential parameters for radian base coordination

• latitude: latitude in radian
• longitude:longitude in radian

-Yamaha5 (talk) 17:43, 28 March 2013 (UTC)

We should use the "⧼datatypes-type-geo-coordinate⧽" datatype instead. --Ricordisamoa 18:58, 28 March 2013 (UTC)

Template:DoneYamaha5 (talk) 08:55, 29 March 2013 (UTC)

Template:Comment Data entry with UTM would be a lot easier in my opinion. Two numbers instead of a lot of special characters (",',°) or multiple fields. The other values can be easily calculated from UTM. --Tobias1984 (talk) 10:41, 17 April 2013 (UTC)

"easily calculated". Well, the more technical solutions you add to this system, the fewer users will be able to use it. The threshold will be higher and higher. In some project, there is maybe only a few users with such technical skills, and they become fatigued by all requests from other users. This is simple to calculate, for those who know. More people think they know, but don't. There will be problems if a project only has the latter kind of "technically skilled" users. -- Lavallen (block) 14:22, 18 April 2013 (UTC)

I think data entry will be possible in any format. But for storage a UTM number like 23423432 is a lot simpler than 34:234'34"32 in my opinion. I also can't do the calculations in my head :) but there are a lot of converters on the internet and programs like google earth allow you to switch from one format to the other. I guess my comment was more about that UTM was still missing from the list ;). --Tobias1984 (talk) 14:32, 18 April 2013 (UTC)

I'm full agree with Tobias1984, there is no need storing six entries instead of two. I really think that these entries will mostly be imported from Wikipedia using Bots (like User:Geobot) and so there is no problems about having homogeneity in the database. I really think that is better to have one standard in a database (simplify the reuses). Beside if we multiply the entries we increase the number of typos. Otourly (talk) 16:26, 22 April 2013 (UTC)

~Template:Comment There is no need to to discuss the format here. That's up to the developers. --Zolo (talk) 16:35, 22 April 2013 (UTC)

---

Coordination datatype is supported. move to archive.--GZWDer (talk) 10:10, 20 June 2013 (UTC)

date retrieved (proposal #2) (en)

Discussion

Relation to other properties:

• Template:P: Use P577 if the accessed webpage states a date of publication (either instead of this property or together with it).
• Template:P: "date retrieved" is redundant as P585 could easily serve this way for references. But some Wikidatans have expressed that they want a separate property for use in references to avoid any possible confusion even though that qualifiers and references are distinct things in a statement. Byrial (talk) 07:48, 9 June 2013 (UTC)

• Template:Neutral – I see no need for another redundant property, but if the community prefers that, I can live with it without problems. However they should know what they do, and the property should have a description that makes sense. What's why I made this alternative proposal for a "date retrieved" property. Byrial (talk) 07:48, 9 June 2013 (UTC)

• Template:Support, I think it is what was meant by the previous proposal, but I can only support a more precise terminology. --Zolo (talk) 21:30, 9 June 2013 (UTC)
• Template:Comment previous proposal amended as this wording. Filceolaire (talk) 22:22, 9 June 2013 (UTC)

The previous proposal is better now than before, but it still uses the word qualifier which is misleading and contrary to Wikidata's datamodel. And the motivation talks about a need. There is no need. It would be better to motivate a wish for a redundant property than to deny the redundancy. So I will keep this alternative proposal for now. Byrial (talk) 06:21, 10 June 2013 (UTC)

AH. I missed your wording for the infobox parameter section. Your wording is better and I would like to merge into the proposal above. Filceolaire (talk) 18:15, 10 June 2013 (UTC)

Please do! Also under "Robot and gadget jobs" and in the motivation you call it a qualifier. Byrial (talk) 18:51, 10 June 2013 (UTC)

• This proposal is hereby withdrawn by the proposer – The proposal above for the same property have been changed so the two proposals are now nearly identical, and there is no reason to keep this proposal anymore. Byrial (talk) 08:35, 12 June 2013 (UTC)

year (en)

Discussion

"year" and "volume" shouldn't coexist. If there are "year" and "volume" for a specific "issue" of a magazine, use the "volume" and record the "year" ( and possible more detailed month, day) on "date of publication". --凡其_Fanchy 15:14, 6 June 2013 (UTC)

Or the meaning of "volume" need to be extended to "volume number". These magazines in fact regard the "year" as "volume number" to distinguish "issues". In this way the "volume" could be 1999, 2000, 2001 ... rather than 1, 2, 3, ... --凡其_Fanchy 15:55, 6 June 2013 (UTC)

Template:Oppose extend the concept of volume and use this property with the year as value. Snipre (talk) 02:00, 7 June 2013 (UTC)

OK, don't create this property and it is better to add a claim <volume> "no value" for magazines not using volume and a claim <volume> "unknown value" when you don't know the volume. --凡其_Fanchy 09:07, 7 June 2013 (UTC)

Subdivisions / /

• Description: Number of subdivisions of varios types (neigborhoods for municipalities)
• Datatype: value, item
• Links:
• Infobox parameter example:
• Comments: In Czech republic every municipality have in infobox numbers of three types of subdivisions (villages, cadastral areas and statistical parts (often are all similar)), might be with links too.
  • Template:Oppose, this can be derived from P:P131 and P:P150. --NaBUru38 (talk) 20:01, 27 March 2013 (UTC)
  • Template:Oppose per NaBUru38 Snipre (talk) 19:09, 10 June 2013 (UTC)

---

Consensus against. Request is archived.--GZWDer (talk) 12:29, 21 June 2013 (UTC)

Historical land / /

• Description: Historical subdivision of state
• Datatype: item
• Links: Q45551
• Infobox parameter example:
• Comments:

Shouldn't this just be the standard (Administrative division) item with (From date) and (To date) properties. Filceolaire (talk) 00:40, 25 February 2013 (UTC)

Agree with Filceolaire. --NaBUru38 (talk) 20:02, 27 March 2013 (UTC)

Template:Oppose This is covered by P:P150 though appropriate qualification properties may need to be developed. Joshbaumgartner (talk)

---

Consensus against. Request is archived.--GZWDer (talk) 12:29, 21 June 2013 (UTC)

Administrative center

• Description: Administrative center
• Datatype: StringValue
• Links:
• Infobox parameter example:
• Comments: useful for the divisions which have a seat which is specifically not referred to as "capital" (e.g., in Russia). Alternatively, we might combine the capital property with this into a generic "seat" and create another property called "seat type".—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:56 (UTC)

Could you give an example of this kind of seat? --Stevenliuyi (talk) 20:11, 8 March 2013 (UTC)

The city of Ufa is the capital of the Republic of Bashkortostan and the administrative center of Ufimsky District. In general, only the republics of Russia have capitals; all other entities only have administrative centers: Vladivostok, for example, is the administrative center of Primorsky Krai; it is incorrect to call it its "capital".—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 20:28 (UTC)

Thanks for the example. I prefer a generic property, because otherwise we may also need properties like "county seat" for US, "county town" for UK, "chef-lieu" for various countries, and many more properties for many different kinds of seats of government in different countries. --Stevenliuyi (talk) 21:20, 8 March 2013 (UTC)

Well, the intent of my example was more to illustrate that there are cases where one generic moniker is not going to work because multiple terms are used within the context of the same infobox (as opposed to within the context of different countries). I feel that the best solution is to have both a "seat type" and a "seat" property; this way one can be easily customize for any country. But while that's unavailable, creating a generic property (be it called "seat" or "administrative center", but definitely not "capital") and allowing it to hold multiple values is probably the best solution.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 21:30 (UTC)

I agree that we need to specify the "seat type" if we use a generic "seat" property (I have no idea how we should call it), but I think it's better to let the "seat type" be a qualifier (when it's available) of the "seat" property, instead of creating two separate properties. --Stevenliuyi (talk) 22:02, 8 March 2013 (UTC)

I, too, agree that it'd better be a qualifier... it's just that we don't know when those are going to be implemented! By the looks of it Phase II might very well go live before that happens... Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 22:21 (UTC)

Sure. I have no problem with creating a temporary "seat type" property, since it's easy for bots to transfer the data when qualifiers are available. --Stevenliuyi (talk) 22:35, 8 March 2013 (UTC)

Template:Oppose I would prefer that the existing capital cover this. While the exact name 'capital' may not be fully accurate itself in all situations, the description provides coverage for administrative seats. If the label is the problem, then it should be altered to broaden its coverage. If we have a different property for every different local way of considering its seat, it will be messy and hard to use for clients. The label we use won't matter to the template querying it, as client-side, an appropriate title can be provided. If it is really notable, a qualifier can be used to give the official 'title' of the seat. Joshbaumgartner (talk) 06:06, 16 May 2013 (UTC)

I would support relabelling P36 to "administrative seat". I think Template:P can be used for "type of seat". --Zolo (talk) 07:39, 16 May 2013 (UTC)

Template:Oppose We have capital property, which description says that it can be seat of government of state or administrative division.--Ahonc (talk) 11:31, 17 May 2013 (UTC)

---

Consensus against. Request is archived.--GZWDer (talk) 12:30, 21 June 2013 (UTC)

Translator / Übersetzer / Traducteur

Discussion about the property "Translator"

• Template:Support I think the role of translator is usually quite clear in any work and having a property "Translator" will convey useful information. Another option could be "secondary author", but in a work with several "secondary authors", then it would be unclear which one took the role of translator.--Micru (talk) 19:46, 2 June 2013 (UTC)

• Template:Support, if we do not have this property, we can use qualifiers. I think Template:P XX Template:P: Template:Q would be technically correct, though perhaps a bit odd. But I "translator" is such a customary role, that I think it deserves it own property, just like author, illustrator, etc. --Zolo (talk) 20:06, 2 June 2013 (UTC)

• Template:Support --Stevenliuyi (talk) 20:34, 5 June 2013 (UTC)
• I don't quite understand how this property would be used. Could someone give an example? --Yair rand (talk) 10:40, 6 June 2013 (UTC)

• According to Wikidata:Books task force, "translator" is an "edition item property" instead of "work item property", so I think this property would only be used for specific editions. --Stevenliuyi (talk) 11:46, 6 June 2013 (UTC)
• Stevenliuyi is right, for instance let's take this item: Template:Q. It represents a work written by Jonas Jonasson in Swedish language. This book has different editions, some of them are in Swedish, some of them in other languages, including English. Usually there is a person called "translator" that takes the responsibility of translating from one language into another. So for that general item there will be linked items for each edition, the item representing the Chinese edition will have as translator "Zhaoyan Fan", the item representing the English edition will have as translator "Rod Bradbury", for the Italian edition the translator is "Margherita Podestà Heir". Later on, each language Wikipedia will use in their book infobox the main work item (containing the author, title, etc), and the edition item (containing the details regarding the translated edition, like ISBN, publisher, and the translator) so the readers have all the information that it is relevant in their language. Hopefully now it is more clear how important this property is.--Micru (talk) 15:57, 6 June 2013 (UTC)

Discussion on translations

The following discussion has been archived for the following reasons: translations will be stored as a separate item (see: guidelines for sources). In the light of this new circumstances I will ask the participants to share their opinion again on this property.--Micru (talk) 19:46, 2 June 2013 (UTC)

• Template:S this property is needed however the details of the translated edition are stored. Filceolaire (talk) 08:21, 13 June 2013 (UTC)

The can be done two ways. For instance, either as a property of the original work:

• QXX Hamlet, a play by Shakespeare. Property: French translator, François Victor Hugo (1865), Yves Bonnefoy (1958)

or in a separate item:

• QXY Hamlet, translation of Shakespeare's play by François-Victor Hugo.

The latter sounds better to me, as it will be easier to add properies about the translation itself (date, publisher, isbn, etc.) --Zolo (talk) 07:57, 3 February 2013 (UTC)

+1. I favor a separate item for the edition. --Kolja21 (talk) 22:18, 3 February 2013 (UTC)

This is important (see my Comments III above), because as I understand it we are confusing different levels. If we are willing to have a wikidata page per work (eg. Hamlet), we need to set all the properties minding all the manifestations and expressions of that work (plays, books, translations movies). We we prefer to have different Wikidata pages (Hamlet the play, Hamlet the movie(s), etc.) we'll have other properties (or, at least, same properties with different syntaxes, I suppose). Furthermore, if we set the Translator property like this we should be coherent for all the other properties.

We could actually have w:FRBR properties isWork, isManifestation, isExpression... --Aubrey (talk) 09:45, 19 February 2013 (UTC)

Anyway, Template:Support for the latter form also for me, it's easier and more wiki-like to have different items/pages. We just need a way (ie properties) to link these pages together. --Aubrey (talk) 09:45, 19 February 2013 (UTC)

Am I blind ? I see a "Translator" for a book, but where is the "Author" property ? --Hsarrazin (talk) 21:10, 7 March 2013 (UTC)

Template:P--Micru (talk) 19:46, 2 June 2013 (UTC)

Creating a separate item for each translation will, I believe, put Wikidata out of synch with WikiPedia for no good reason since we can deal with this by having a statement for each translation, just as we have for each edition. Translator would be a qualifier for the statement describing the translation. Filceolaire (talk) 11:56, 6 April 2013 (UTC)

Separate items for translations raises some issues, but I think it is a better long-term solution. An important usecase would be en:Template:Cite book. If we have an item for each edition, we would just need the item's ID to cite it. By contrast, if several editions are listed in the same property of the same items, choosing the right one would be much more complicated and brittle. I think a similar case could be made for other uses, both by Wikipedias or external clients. --Zolo (talk) 12:24, 6 April 2013 (UTC)

RefSeq

Template:Support part of protein infobox and important for a GSoC project. --Tobias1984 (talk) 15:13, 18 June 2013 (UTC)

Template:Support Andrew Su (talk) 17:48, 21 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:54, 22 June 2013 (UTC)

GenLoc_chr

Discussion

• Template:Support -- though we also need to allow "X" and "Y" chromosomes. Andrew Su (talk) 21:47, 10 June 2013 (UTC)
• Template:Support - Can we handle the x and y chromosome as a qualifier? Best to propose them together. --Tobias1984 (talk) 19:46, 13 June 2013 (UTC)

• And is also needs the Template:P qualifier. --Tobias1984 (talk) 19:57, 13 June 2013 (UTC)

• Template:Comment apparently, the datatype should be string, as X and Y are not compatible with a number datatype. --Zolo (talk) 18:07, 18 June 2013 (UTC).
• Template:Comment 'Number' is a problematic datatype for the reasons cited above. However, 'string' isn't ideal either. Chromosomes are distinct objects that have properties like 'accession', 'length', etc. and should thus be represented as 'items'. I suggest changing the 'datatype' to 'item' and having claims of the form Template:Q GenLoc_chr Template:Q. Emw (talk) 01:31, 27 June 2013 (UTC)

GenLoc_start

Discussion

• Template:Support Andrew Su (talk) 21:47, 10 June 2013 (UTC)
• Template:Support - needs Template:P qualifier. --Tobias1984 (talk) 19:58, 13 June 2013 (UTC)
• Template:Comment In addition to a species qualifier, when defining a gene's location I think we also need to include qualifiers for:

• Which genome assembly the coordinates are derived from (e.g. GRCh37/hg19, NCBI36/hg18, etc).
• The accession of the sequence (including a version, if applicable). This would make it unambiguous which gene variant or alternative placement is being used.

The same information would be needed in GenLoc_chr and GenLoc_end, since all three properties would be needed to define a chromosome coordinate. Emw (talk) 04:37, 19 June 2013 (UTC)

GenLoc_end

Discussion - Using the above three properties we can specify "genomic coordinates" in UCSC. Ex

Reelin = http://genome.ucsc.edu/cgi-bin/hgTracks?org=Human&db=hg19&position=chr7:103112231-103629963

• Template:Support Andrew Su (talk) 21:47, 10 June 2013 (UTC)
• Template:Support - needs Template:P qualifier. --Tobias1984 (talk) 19:59, 13 June 2013 (UTC)

• Template:P, Template:P, Template:P --Tobias1984 (talk) 21:32, 18 June 2013 (UTC)

RTECS number (en)

Discussion

• Template:Support --Tobias1984 (talk) 09:36, 6 June 2013 (UTC)
• Template:Support Snipre (talk) 22:27, 6 June 2013 (UTC)
• Template:Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
• Template:Support--Saehrimnir (talk) 15:46, 24 June 2013 (UTC)

Tracklist

Discussion

• It's very useful, but should we create sub-properties for doing this? At the time it's not possible (I think) --Viscontino ^talk 10:07, 2 March 2013 (UTC)
• Template:Support Needed. — ΛΧΣ²¹ 20:48, 18 April 2013 (UTC)
• Template:Comment 1. Since it's an item, we should create an article for each song. 2. We should add qualifiers such as the order number. --Viscontino (talk) 11:20, 19 April 2013 (UTC)
  • Template:Comment 1 & 2 sounds good for me. I would do it that way, yeah. --Nightwish62 (talk) 15:58, 19 April 2013 (UTC)
• Template:Support. Conny (talk) 14:28, 28 April 2013 (UTC).
• Template:Support. I'm new to wikidata, but I would sure like this. It would be nice if it could be made in such a way that we have (or could later add) a link to the "canonical" version of the song. For example, there are many versions of Dream A Little Dream. And one artist might have several versions of a songs (e.g. live album and studio album). Somewhat related, it would also be nice with a way to say if a song samples a different song (i.e uses a clip of a song to make a new song). —Bajsejohannes (talk) 05:40, 30 April 2013 (UTC)
• Template:Support --Napoleon.tan (talk) 12:28, 30 April 2013 (UTC)

Don't understand to what this property should link? To an item linked to Wikipedia pages containing a tracklist? Not useful. To all Tracks? Maybe useful but an item has to be created for every song. Don't know what you mean by "Every track must have…" that wouldn't be part of the properties value. -- MichaelSchoenitzer (talk) 23:59, 10 May 2013 (UTC)

• Template:Oppose - Oppose the datatype. Track names don't have to be translated. A property called "tracks" could hold a string for each song with a qualifier for the number on the album. --Tobias1984 (talk) 12:39, 24 May 2013 (UTC)
  • Template:Comment It's not about the point to translate a track name, it's about the point to have the possibility to enter more information to a track. --Nightwish62 (talk) 15:53, 30 June 2013 (UTC)

group

Discussion

This property was briefly discussed at Wikidata:Properties for deletion#Property:P265. If it is created it will obsolete several other properties which should be deleted. (4 properties which can be replaced are mentioned in the examples section above, and there may be more). "Group" is clearly redundant with Template:P, but it will be easier to use in infoboxes than P361 because of the constraint on the value type. Byrial (talk) 09:32, 10 June 2013 (UTC)

Template:Oppose Redundant with Template:P Snipre (talk) 12:08, 10 June 2013 (UTC)

Template:Oppose as Snipre --Paperoastro (talk) 12:20, 18 June 2013 (UTC)

instances of (en)

Discussion

This property is similar to Template:P, but is used when the item is not one, but several instances of a class. The subject should not be a list of instances selected by some criteria (use Template:P for that), but should be about a few instances described in detail. If there also is separate items for the contained instances these can be indicated with Template:P. Byrial (talk) 10:00, 18 June 2013 (UTC)

• Template:Oppose This seems redundant with Template:P. A class is a type, which is a set of instances and the properties that those instances share. Template:Q is fundamentally a set of (two) instances and the properties that those instances share. It's clearly an unusual example of a class, but in terms of ontology components, 'Bonnie and Clyde' is a class nonetheless.

To those who might not agree: how is Template:Q fundamentally different than other, more conventional classes, like Template:Q? More to the point, how would 'instances of' be fundamentally different than 'subclass of'? Emw (talk) 11:45, 18 June 2013 (UTC)

An instance of any class is also a subset with one member of the class, and thus a subclass by that argumentation. So can we expect a deletion proposal for Template:P? The problem with this is that Template:Q do not share any properties that other persons do not have, except for being Bonnie and Clyde. And the same is valid for each of them. Byrial (talk) 12:10, 18 June 2013 (UTC)

Insofar as set theory applies to ontology components like instances and classes, Template:P (rdf:type) corresponds to $\in$ (element of) and Template:P (rdfs:subClassOf) corresponds to $\subseteq$ (subset of). So I don't see how it's valid to say that all instances of a class are sets. Is that supported by the description logics that underlay OWL DL, or the basis of some other W3C recommendation for structured data?

I also still don't see how 'instances of' would be fundamentally different than 'subclass of'. P31 and P279 are based on W3C recommendations, are implemented throughout the Semantic Web, have support in ontology toolsets, and have a substantial body of literature about them. To my knowledge, 'instances of' does not. If it does, which would presumably mean it's not redundant with Template:P, then please point me to where I can read more about that. Emw (talk) 04:07, 19 June 2013 (UTC)

A class A is a subclass of class B if all instances of A is also instances of B. So if you define a class as "the class of items which are either Template:Q or Template:Q" it is a subclass of Template:Q with 2 instances. And if you define a class as "the class of items which are Template:Q" it is a subclass of Template:Q with one instance. But if you define a class as "the class of items which are Template:Q" it is not a subclass of Template:Q as Template:Q is not an instance of Template:Q. Instead Template:Q is an instance of the class "two persons described together", but we have not created an item for that class (as far as I know). We could do that, but I think it is better to create the property "instances of". "X is 'instances of' class Y" really means "X is an instance of the class of 'instances of class Y described together'", so I do not agree that it is redundant to Template:P. I cannot point you to any literature on this, and I doubt that W3C or others who made recommendations for semantic webs considered the situation where we have the both the two items Template:Q and Template:Q, and a separate item Template:Q. Byrial (talk) 06:25, 19 June 2013 (UTC)

Template:O We don't need to tie ourselves in knots trying to write statements about Template:Q. The detailed statements are in the items about each individual and we already have Template:P which works to link Template:Q to Template:Q and Template:Q. For me that is the only statement we need to make about any page which refers to two or more items. Filceolaire (talk) 20:00, 19 June 2013 (UTC)

in language / in der Sprache

Template:Property proposal Not sure where's the right place to propose qualifiers, so I try it here. The need of this qualifier was mentioned at Property_talk:P138#Dépendance aux langues / Language dependency Šlomo (talk) 10:44, 19 April 2013 (UTC)

Template:Comment "named after" is applicable to a word or a name, not to a language. Actually "mercury" was also called "quicksilver" in English. --Zolo (talk) 12:12, 19 April 2013 (UTC)

Template:Comment The program name "Jitsi" comes from a Bulgarian word for wires, but the name "Jitsi" itself probably cannot be called Bulgarian-specific. So one side of the "named after" statement is language-specific, but the other is not… --AVRS (talk) 12:23, 19 April 2013 (UTC)

Template:Comment – There is still the problem that it not refers to the item, but to names for it. If a language have different names of different origin for an item, which of the names does the statement apply to? Examples where Danish have synonyms are some elements (like oxygen), plants (like Chamaecyparis lawsoniana), animals (like Common eland) and more. Byrial (talk) 13:58, 19 April 2013 (UTC)

This raises a question about the property itself, or about it's use. I can imagine multiple "named after" statement for one item even with the same language qualifier, especially when distinguished through other qualifiers (time etc.). I would understand a statement like this like: "There is some name for item A which is derived from some name of item B." Also, we can remove the "named after" property from the list. But if we'll have it, we'll definitely need a language qualifier for it.--83.240.94.18 =Šlomo (talk) 18:26, 25 April 2013 (UTC)

That's the beauty of qualifiers. They apply to one statement. Each 'named after' statement has it's own language qualifier that applies to that statement. Filceolaire (talk) 21:11, 6 June 2013 (UTC)

Template:Comment Is there a particular reason why we couldn't use regular properties as qualifiers where appropriate? This seems like it would be covered by Property:P407. Silver hr (talk) 19:33, 26 April 2013 (UTC)

Template:O per Silver. Redundant to Template:P Filceolaire (talk) 21:11, 6 June 2013 (UTC)

Template:Oppose Translation won't be a property: use the label with the appropriate language code. Snipre (talk) 18:45, 10 June 2013 (UTC)

Fought in conflict(s) / Gekämpft in Konflikt(en) / Combattu dans les conflits / Сражались в конфликтe(ах) / 攻防戦で戦った

Template:Property proposal This property would give specific clarity as to the conficts that the subject has fought in. The property for the branch of their military service exists already military branch. This property would serve the purpose of denoting which specific events the subject has participated in while a member of their military force. Presentime (talk) 20:14, 20 April 2013 (UTC)

Template:Comment This property seems useful! But I would tweak its title to simply 'fought in', and change the 'allowed values' field to be 'conflicts'. Conflicts are a subclass of event, and it's best for the 'allowed values' field to be as precise as possible. Emw (talk) 20:23, 20 April 2013 (UTC)

That is a good point. Perhaps this should be a qualifier of 'fought in' to specify which battles the subject was involved in. For example: fought in World War II with a qualifier of Fought in conflict Battle of Gondar. --Presentime (talk) 22:11, 20 April 2013 (UTC)

Template:Comment - If somebody fought in the Battle of Gondar and that battle is a "subclass of = World War 2" then the qualifier would be redundant? --Tobias1984 (talk) 10:26, 8 May 2013 (UTC)

Yes, I think the battle would be enough, and battles are "part of" war, rather than "subclass of". See Q83224 Battle of Hastings. Danrok (talk) 02:44, 18 May 2013 (UTC)

• Template:Support --Odejea (talk) 13:14, 5 June 2013 (UTC)
• The property has been created already, see Template:P. This discussion can be archived.--Kompakt (talk) 05:35, 14 June 2013 (UTC)

Template:Not done, since Template:P already exist. --Nightwish62 (talk) 21:36, 30 June 2013 (UTC)

drafted by

Template:Oppose We already have Property:P54 Snipre (talk) 09:23, 2 April 2013 (UTC)

No that's totally different. You can be drafted by a team and never play for them. Legoktm (talk) 10:37, 2 April 2013 (UTC)

Sorry but property member of sports team doesn't imply that the sportman has to play. I don't know if my English is too poor but draft is for me integration in a team, after if you play or not is something else. By being drafted you can play as member of the team. Snipre (talk) 17:36, 9 April 2013 (UTC)

Template:Comment Very often a player will be drafted by a Major League Baseball team and never get close to even being on that team's roster. They may be traded or fail to develop long before reaching that point, or even refuse to sign with the organization at all. This is still relevant information to know though, so a separate property for the drafting organization is valid and distinct from a property for teams a player was a member of. Joshbaumgartner (talk) 08:32, 9 May 2013 (UTC)

Template:Support, though it looks like the infobox parameter is draft_team. The date of the draft could be added as a qualifier when available. Superm401 - Talk 01:00, 6 April 2013 (UTC)

You're right, fixed. Thanks, Legoktm (talk) 06:44, 6 April 2013 (UTC)

Template:Oppose, not relevant. Being a member of a team is. --NaBUru38 (talk) 16:47, 11 April 2013 (UTC)

Relevant to what? It seems like a well-defined concept that can be easily sourced. I see no reason to exclude it. Further, this is the kind of thing a biography would mention whether or not they actually played for the team. Superm401 - Talk 04:24, 17 April 2013 (UTC)

Template:Support This property is relevant in its domain. Emw (talk) 20:52, 20 April 2013 (UTC)

Template:Support per Emw and Superm401. FrigidNinja 11:55, 27 April 2013 (UTC)

I think this should have a less ambiguous label. "Drafted by" could mean many other things. --Yair rand (talk) 16:12, 28 April 2013 (UTC)

Template:Support --Stryn (talk) 16:19, 28 April 2013 (UTC)

Template:Support this is a very useful piece of information when learning more about a player's career path, as well as studying a team's player development and scouting history. Joshbaumgartner (talk) 08:32, 9 May 2013 (UTC)

Template:Done Regards, — Moe Epsilon 21:48, 18 June 2013 (UTC)

GenLoc_assembly

Template:Support part of protein infobox and important for a GSoC project. --Tobias1984 (talk) 15:15, 18 June 2013 (UTC)

Template:SupportTemplate:Comment hg19 (i.e. GRCh37) is a genome assembly, not a 'database assembly' or 'gene assembly'. I would suggest calling this qualifier "GenLoc_assembly" and updating the documentation 'description' field. Emw (talk) 03:28, 21 June 2013 (UTC)

Updated. --Chinmay26 (talk) 17:42, 21 June 2013 (UTC)

Thanks! Another suggestion: to help avoid confusion over aliases for the genome assembly (GRCh37 vs. hg19 vs. ...), it seems like it'd be a good idea to change the "datatype" of this property from "string" to "item". Wikidata items for the genome assemblies could be created as needed. The set of relevant genome assemblies is small, so this doesn't seem like it would be a problem. Another benefit of using an "item" datatype is the assembly could also be linked to an accession. Emw (talk) 02:05, 22 June 2013 (UTC)

Handling aliases may not be a problem.I am not aware about whether there would be a need to represent assemblies as wikidata items. I will run this through the task force for some more clarification. --Chinmay26 (talk) 10:43, 22 June 2013 (UTC)

A more compelling reason to use 'item' instead of 'string' is that it would enable properties about those assemblies to be easily organized. For example, assemblies have accessions. Having this property point to an item representing an assembly rather than just a string would allow sequences to be queried by the accession of the assembly they're associated with. Assemblies also have other relevant properties, like length (i.e. the length of an organism's genome), associated chromosomes, etc. Emw (talk) 01:22, 27 June 2013 (UTC)

I think in the long term, assemblies as items make a lot of sense. However, I hesitate here because of the practicalities of Chinmay26's GSoC project. His goal of course is to model genes in sufficient detail so that the Wikipedia templates can draw most (if not all) of their content from Wikipedia. I don't want Chinmay to get too caught up in modeling all of biology correctly and never get to coding. Emw, what do you think? Can we leave this one as a string for now in the name of simplicity, and move toward assemblies as items later? Cheers, Andrew Su (talk) 20:09, 27 June 2013 (UTC)

Will any of the ported PBB template parameters use properties with an item datatype? If not, then it seems that many of the properties put forward for the GSoC work will need to be remapped to item-based properties in the long term. (And how will the kind of EC class discussed here be handled?) With this particular property, it seems claims would involve only two items: either the item for the human assembly or the item for the mouse assembly.

If handling item-based properties would be a big impediment to the progress of the GSoC project, then I agree it's better to have string-based claims than no claims at all. If that's the case, I agree it'd make sense to use strings now and update these claims to use item-based properties later. Emw (talk) 01:21, 28 June 2013 (UTC)

Good questions, as usual. I think the majority of the PBB parameters are modeled as strings (current first-pass list: HGNCid , Symbol , AltSymbols, Homologene, EntrezGene , Ensembl, RefseqmRNA(qualifier to protein ID) , GenLoc_db /start/chr , GeneAtlas_image, species , Uniprot ID). But on second thought, it probably doesn't matter from Chinmay's point of view if hg19 is an item rather than a string. I think as long as we let him create that as a bare-bones item and leave populating statements on that item to others (accessions, length, etc.), then that won't hold him up at all. I was getting worried that Chinmay would have to do that, but of course that's not strictly necessary just for changing the data type here. Bottom line, I'm happy with changing the data type to item. Anyone else (especially Chinmay) have any objection? Cheers, Andrew Su (talk) 07:11, 28 June 2013 (UTC)

As Andrew pointed it out, I dont have any issues regarding this. I have updated it to item datatype. Chinmay26 (talk) 17:36, 28 June 2013 (UTC)

Template:Support Andrew Su (talk) 21:32, 21 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 12:18, 2 July 2013 (UTC)

EC classification

Template:Support This property is the outcome of the discussion at Property_talk:P591#Distinguishing enzymes and gene products. Open questions:

• How should statements using this property be sourced?
• How should enzyme classes that have no "full" name be labeled? For example, according to http://www.chem.qmul.ac.uk/iubmb/enzyme/EC2/1/, EC 2.1 has the name "Transferring one-carbon groups". Should such enzyme classes be labeled by taking the next-highest EC classes name (e.g. EC 2, "transferase") and prepending it to the "incomplete" name to give labels like "transferases transferring one-carbon groups"? The official EC name could be an alias of the item in these cases.

RNA molecules with EC classifications, like Template:Q (EC 3.1.26.5), also need to be considered. Emw (talk) 17:40, 29 June 2013 (UTC)

Template:Support I agree that the edge cases mentioned above need some thought and discussion, but I'd suggest not holding up the property proposal before those are resolved. One way or another, we're going to need this property... Cheers, Andrew Su (talk) 17:47, 29 June 2013 (UTC)

Template:Support – I took the liberty of adding EC-IUBMB as the source. In addition, the "name" parameter of the enzyme infobox should be set to the EC accepted name, hence this parameter should be appropriate for this property. Boghog (talk) 00:02, 30 June 2013 (UTC)

I agree that the names themselves should come from EC-IUBMB (and occasionally adjusted per the second question above?), but what source should be used to support the assignments of those EC names to gene products? For example, what source supports the claim that reelin is a serine endopeptidase (EC 3.4.21)? And when the EC name differs from the Wikipedia article name -- e.g. with the EC name serine endopeptidase corresponding to the Wikidata item Q420032 (currently labeled 'serine protease') -- should the Wikidata item label change, or should the EC name be added as an alias, or what? Emw (talk) 03:21, 30 June 2013 (UTC)

I think UniProt should the ultimate source of the annotation (e.g., [1]). For the latter question, I think the Wikipedia article should stay at "Serine protease" (because that's how most scientists would probably refer to it), and the Wikidata label should be "serine endopeptidase" (because that's the official label). And then we can use redirects and aliases to make sure either search resolves correctly on both ends. (The Wikipedia redirect is already in place.) My two cents... Cheers, Andrew Su (talk) 04:09, 30 June 2013 (UTC)

Great, having UniProt as the source for these claims seems good to me. If the EC classification for a gene product can be supported by simply referring to a URL of the formhttp://www.uniprot.org/uniprot/<UniProt ID>, then that seems fairly automatable, since virtually all protein items will have a UniProt ID added as part of the GSoC project. I don't think such sourcing should be necessary for the GSoC project, but is there some place to add this task to a backlog so it doesn't get forgotten?

Regarding labels, I think it would be reasonable to change the enzyme Wikidata item's label to the EC accepted name when the Wikipedia article name differs. In these cases, I imagine we agree that the Wikipedia article name should be kept as an alias on the Wikidata item. I've mocked up Template:Q as an example. Emw (talk) 04:38, 30 June 2013 (UTC)

I agree that UniProt would be a good source for the protein → enzyme mappings. In addition, UniProt can supply a list of all proteins with a given EC number/accepted name (see for examplehuman serine endopeptidases) if that is needed. Boghog (talk) 09:43, 30 June 2013 (UTC)

Regarding task tracking, we don't have a running list anywhere. You're welcome to start one on Wikidata:Molecular Biology task force if you like, but I'm pretty sure we'll catch this one when we systematically do our uploading and sourcing... (and Template:Q looks great to me!) Cheers, Andrew Su (talk) 15:40, 30 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 12:28, 2 July 2013 (UTC)

ChemSpider

Template:Oppose but weak: it's a open database so not an authority.Snipre (talk) 23:38, 4 June 2013 (UTC)

Template:Strong support: The ChemSpider (UK) database is similarly important as the PubChem (USA) database. --Leyo 11:17, 24 June 2013 (UTC)

• Template:Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
• Template:Strong support. If the connection is wrong this will get fixed very soon. --Saehrimnir (talk) 14:57, 24 June 2013 (UTC)
• Template:Support useful --Holmium (talk) 16:15, 24 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 12:37, 2 July 2013 (UTC)

PubChem

• Template:Support - Authoritative and stable. Boghog (talk) 19:25, 17 June 2013 (UTC)
• Template:Support --Kaligula (talk) 07:06, 19 June 2013 (UTC)
• Template:Support Danrok (talk) 14:51, 22 June 2013 (UTC)
• Template:Support A must have. --Leyo 11:19, 24 June 2013 (UTC)
• Template:Support --Cvf-ps (talk) 12:03, 24 June 2013 (UTC)
• Template:Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
• Template:Support --Saehrimnir (talk) 15:46, 24 June 2013 (UTC)
• Template:Support --Holmium (talk) 16:16, 24 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 14:53, 2 July 2013 (UTC)

DSM IV

Discussion

Template:Support --Wouterstomp (talk) 10:04, 6 June 2013 (UTC)

Template:Support --Gambo7 (talk) 20:43, 16 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Done - --Tobias1984 (talk) 19:14, 2 July 2013 (UTC)

Organizer / Veranstalter / organisateur

Discussion

I haven't found this property in an infobox as yet, still I think it's a necessary property to describe an event, and can be useful for queries and generating lists (as soon as this functionality is available). The property would have several values in many cases; like in Eurovision Song Contest 2013, e.g., this would be not only the EBU, but also [[Q215363|Template:Label]]. It's the same with international sports events that are not only organized by the international body, but (usually for the most part) by local organizations or committees.--Kompakt (talk) 07:37, 20 May 2013 (UTC)

I agree with the general idea. But how would it work exactly? Events, especially large events, are often organised by more than one entity, with each taking control of different aspects of the event. Danrok (talk) 22:54, 8 June 2013 (UTC)

You're right, I think we can simply add all organizers to the property. For Eurovision 2013, e.g., we'd add both the EBU and Sveriges Television.--Kompakt (talk) 16:00, 11 June 2013 (UTC)

• Template:Support Danrok (talk) 19:19, 23 June 2013 (UTC)

KEGG

Template:Property proposal Template:Comment Better move this proposal under the biochemistry section. Snipre (talk) 23:49, 4 June 2013 (UTC)

Template:Support --Kaligula (talk) 07:06, 19 June 2013 (UTC)

• Template:Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
• Template:Support--Saehrimnir (talk) 15:46, 24 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 12:43, 3 July 2013 (UTC)

ICPC 2

Discussion

Template:Support --Wouterstomp (talk) 10:04, 6 June 2013 (UTC)

Template:Support --Gambo7 (talk) 20:43, 16 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 13:00, 3 July 2013 (UTC)

GeneReviews

Discussion

Template:Comment - not sure what we should do with the second field that describes the entry. It could be a separate string or multilingual string? --Tobias1984 (talk) 16:50, 1 June 2013 (UTC)

Template:Support --Wouterstomp (talk) 10:04, 6 June 2013 (UTC)

Template:Support --Gambo7 (talk) 20:43, 16 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 13:16, 3 July 2013 (UTC)

MeSH Code

Discussion

Is it different from Property:P486 (MeSH ID) ? Snipre (talk) 22:15, 8 May 2013 (UTC)

The MeSH code is the structure of the classification. MeSH ID is the ID that each MeSH Code has in the database. The diseases infobox included the ID rather than the code. I think it would be better to store the code and put the database ID into the source information (so this is actually more of a proposal to change Property:P486. --Tobias1984 (talk) 10:17, 9 May 2013 (UTC)

I suggest to use only one parameter from MeSH DB: the code or the ID but not both. Put the suggestion in the talk page of the property and try to contact the contributors who supported the initial property to see what is the best solution Snipre (talk) 09:47, 12 May 2013 (UTC)

Template:Weak support Because I have no background knowlenge about this only weak support. This property can be used in w:en:List of MeSH codes and subpages. But we also need the MeSH ID to link to a special medicine term because diseases can appear in different regions of the hierarchy. --Pyfisch (talk) 16:37, 12 May 2013 (UTC)

Template:Support --Wouterstomp (talk) 10:04, 6 June 2013 (UTC)

Template:Support --Gambo7 (talk) 20:43, 16 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:34, 4 July 2013 (UTC)

eMedicine

Discussion

Template:Comment - I don't know if we should use the old or the new formatting. --Tobias1984 (talk) 16:50, 1 June 2013 (UTC)

Definitely the new, the old one only exist anymore as redirects. Also, for many diseases multiple emedicine pages exist, how is this dealt with? --Wouterstomp (talk) 19:00, 1 June 2013 (UTC)

We have that problem with many pages on Wikipedia and items on Wikidata that they can have multiple entries in other databases. Currently the "infobox disease" just represents them as a list without any qualifiers. If you can think of a way on how we could improve this we could start a discussion at Wikidata:Medicine_task_force. --Tobias1984 (talk) 19:17, 1 June 2013 (UTC)

Template:Support --Wouterstomp (talk) 10:04, 6 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 22:39, 5 July 2013 (UTC)

ÚSOP ID (en) / kód ÚSOP (cs)

Discussion

Template:Support--Shlomo (talk) 17:50, 30 June 2013 (UTC)

Template:Done JAn Dudík (talk) 21:11, 6 July 2013 (UTC)

Qualifier incertae sedis (en)

Discussion

• It took me a while to understand your proposal. :) Template:Support --Succu (talk) 16:25, 25 June 2013 (UTC)
• Template:Support --Tobias1984 (talk) 09:23, 4 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 19:14, 7 July 2013 (UTC)

ZVG number (en)

Discussion

• Template:S: Well maintained database with reviewed properties. --Leyo 14:50, 24 June 2013 (UTC)
• Template:Strong support crucial for references to safety data. --Saehrimnir (talk) 15:46, 24 June 2013 (UTC)
• Template:S: Required for German Wikipedia's crusade to have reputable secondary sources on every chemical safety information provided. Also useful for other Wikipedias that show EU warning labels in their chemboxes. Matthias M. (talk) 20:52, 24 June 2013 (UTC)
• Template:S very useful source for safety data. --Cvf-ps (talk) 10:56, 26 June 2013 (UTC)

has_molecular_function

Template:Comment - Can this be an item datatype? We can create items for e.g. "lipoprotein particle receptor binding". This will reduce the amount of translation and I'm sure that these processes can hold plenty of statements of their own. Some of them might already have Wiki articles. --Tobias1984 (talk) 18:51, 2 July 2013 (UTC)

Template:Support - agree with Tobias1984; made the change to item-datatype and supporting. Cheers, Andrew Su (talk) 22:46, 3 July 2013 (UTC)

Template:Support --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

Template:Comment A few suggestions:

• Change label from 'has_molecular_function' to 'molecular function', which matches the GO term on which this property is based.
• A link to guidelines for this property's use -- http://www.geneontology.org/GO.function.guidelines.shtml -- would help to have in the documentation. Having it in the 'Description' field seems to make the most sense.
• In the 'Source' field, specify the more source more precisely: http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0003674
• Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.

I have similar suggestions for the other GO properties. Emw (talk) 21:26, 5 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 08:40, 9 July 2013 (UTC)

occurs in cell component

Template:Comment - we have an item for Template:Q. Can we use item-datatype instead of string? --Tobias1984 (talk) 18:42, 2 July 2013 (UTC)

Template:Support - agree with Tobias1984; made the change to item-datatype and supporting. Cheers, Andrew Su (talk) 22:46, 3 July 2013 (UTC)

Template:Support --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

Template:Comment A few suggestions:

• Change label from 'occurs in cell component' to 'cell component', which matches the GO term on which this property is based.
• In the 'Source' field, specify the more source more precisely: http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0005575.
• A link to guidelines for this property's use -- http://www.geneontology.org/GO.component.guidelines.shtml -- would help to have in the documentation. Having it in the 'Description' field seems to make the most sense.
• Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.

I have similar suggestions for the other GO properties. Emw (talk) 21:31, 5 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 08:55, 9 July 2013 (UTC)

participates in biological process

Template:Comment - We have items for many of those processes: e.g. Template:Q. I think this should be an item property. --Tobias1984 (talk) 18:56, 2 July 2013 (UTC)

Template:Support - agree with Tobias1984; made the change to item-datatype and supporting. Cheers, Andrew Su (talk) 22:46, 3 July 2013 (UTC)

Template:Support --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

Template:Comment A few suggestions:

• Change label from 'participates in biological process' to 'biological process', which matches the GO term on which this property is based.
• In the 'Source' field, specify the more source more precisely: http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0008150.
• A link to guidelines for this property's use -- http://www.geneontology.org/GO.process.guidelines.shtml -- would help to have in the documentation. Having it in the 'Description' field seems to make the most sense.
• Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.

I have similar suggestions for the other GO properties. Emw (talk) 21:33, 5 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:01, 9 July 2013 (UTC)

ChEBI

• Template:Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
• Template:Support--Saehrimnir (talk) 15:46, 24 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:36, 9 July 2013 (UTC)

ortholog

Template:Support --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

Template:Support Andrew Su (talk) 01:10, 9 July 2013 (UTC)

Template:Support Salvatore Loguercio (talk) 17:50, 9 July 2013 (UTC)

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

Template:Support. We should probably encourage (and maybe require) this property to be used with a Template:P qualifier, to enable easier unambiguous statements when orthologs for multiple species are made with this property. Emw (talk) 05:23, 10 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:27, 10 July 2013 (UTC)

NCBI Taxonomy ID

Template:Support --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

Minor comment: Would you mind renaming it to "NCBI Taxon ID" or similar? Each taxonomy database defines its own "Taxonomy ID". See for example [2].  — Felix Reimann (talk) 14:03, 4 July 2013 (UTC)

Question, I wonder if we should leave the name as "Taxonomy ID" and use Template:Q as the source. Also relates to the discussion atWikidata_talk:Molecular_biology_task_force#gene.2C_RNA.2C_and_protein_identifiers. Cheers, Andrew Su (talk) 18:42, 9 July 2013 (UTC)

I may be missing something, but isn't there already is a property called Template:Q to which the name of a species can be assigned? As Andrew suggested in the MCB task force discussion, we could then have a property for Template:Q: "Taxon ID" → "9606" (Source: Template:Q) and "Taxon ID" → "180092" (Source: Template:Q) (note that the Template:Q linked above uses the NCBI Taxon ID). Boghog(talk) 19:54, 9 July 2013 (UTC)

Template:Support – and per Felix Reimann, I also suggest renaming to "NCBI Taxonomy ID". Boghog (talk) 19:06, 4 July 2013 (UTC)

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

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

Template:Support Salvatore Loguercio (talk) 18:39, 9 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 09:47, 10 July 2013 (UTC)

Gene Ontology ID

Template:Support --Andrew Su (talk) 16:41, 9 July 2013 (UTC)

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

Template:Support Salvatore Loguercio (talk) 18:39, 9 July 2013 (UTC)

Template:Support Emw (talk) 05:25, 10 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 14:11, 11 July 2013 (UTC)

BHL Page Id

Discussion

Template:Q hosts a lage amount of biological works. Each page has an unique identifier. The proposed property allows a direct link to a scientific discription of a taxon. Succu (talk) 14:27, 26 June 2013 (UTC)

Template:Support --Tobias1984 (talk) 09:42, 9 July 2013 (UTC)

Template:Support  — Felix Reimann (talk) 19:55, 10 July 2013 (UTC)

Template:Support - Hard to see how this could hurt. In some cases this will be extremely useful. - Brya (talk) 11:12, 11 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 10:20, 12 July 2013 (UTC)

Encodes

Template:Support but I don't know if we should have both properties (encodes, encoded by) or just one. --Tobias1984 (talk) 07:49, 4 July 2013 (UTC)

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

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

Template:Support Template:Wait I think this property description should be modified to allow it to be used on the gene product encoded by the gene, which can be either a protein or an RNA molecule. Consider for example HOTAIR, which encodes an ncRNA molecule. Emw (talk) 05:16, 10 July 2013 (UTC)

Agreed! Great point, changed... Cheers, Andrew Su (talk) 17:09, 11 July 2013 (UTC)

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

Template:Done --Tobias1984 (talk) 10:41, 12 July 2013 (UTC)

afflicts

Discussion

I was editing Q5788570, and wanted to enter that it is a disease of birds, in fact of galliformes. There does not seem to be a property for this (or indeed an infobox in enwiki). I haven't found a really good name for the property, though ColinFine (talk) 21:35, 16 June 2013 (UTC)

Template:Support This property seems useful. A few things could be adjusted in the documentation template:

• Domain: just 'taxon'; 'term' is too imprecise
• Allowed values: any Template:Q

I would also change the label to simply 'afflicts'. "Gout afflicts humans" is much more natural than "Gout disease afflicts humans". The 'disease afflicts' label is putting the range constraint in the label, when it's enough to have it in the range field of documentation template (i.e. "allowed values"). Emw (talk) 00:18, 17 June 2013 (UTC)

Reply from proposer: thanks for the comments.

• I didn't realise that the name was supposed to be read directly as part of an English sentence: in that case, "Afflicts" is probably the best we'll get.
• I'd change the description to "type of organism which this medical condition afflicts" ("disease" is too narrow, I think).
• I put "term" in because the comment in the template I copied says "type of items that may have this property. Mention main types (person, place, organization, event, creative work, term)". I think you're saying that this instruction is wrong.
• I don't see where in the template there is a place so specify that the Q1 should be a disease or medical condition. Am I missing something? --ColinFine (talk) 15:49, 17 June 2013 (UTC)

Template:Support --Kaligula (talk) 06:59, 19 June 2013 (UTC)

Template:Question - Can this also be used to say that a certain organ is targeted by the disease? --Tobias1984 (talk) 18:05, 20 June 2013 (UTC)

Template:Comment I have updated the proposal according to the comments above: changed the name and description, and added the organ as a possible target. --ColinFine (talk) 16:34, 9 July 2013 (UTC)

Template:Comment I added the organ according to Tobias' suggestion, but I see that he has proposed a separate property for this, so I have removed it from "afflicts" again. --ColinFine (talk) 01:00, 12 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 07:44, 13 July 2013 (UTC)

Species

• Template:Comment - Can we just use Property:P89 as a qualifier or will that mess up that property? --Tobias1984 (talk) 20:43, 18 May 2013 (UTC)
• Right, I will delete the proposal.Snipre (talk) 19:07, 10 June 2013 (UTC)

Wait till this RfC is closed, maybe species will be deleted.—★PοωερZ_talk19:11, 10 June 2013 (UTC)

Template:Done --Tobias1984 (talk) 07:54, 13 July 2013 (UTC)

Space group

• Template:Comment - Property proposed by the Wikidata:Chemistry task force and the Wikidata:Mineralogy task force.
• Template:Comment - I also propose to create the 230 space groups as "Space group 1" through "Space group 230". The other notations could be put into the aliases because they require special letters to be non-ambiguous which are not available for the name (horizontal bars above letters and subscript). --Tobias1984 (talk) 08:25, 20 May 2013 (UTC)
• Template:Comment - In theory we could say that "Albite" is "space group 2" and because space group 2 has the crystal class "pinacoidal" and the crystal system "triclinic", those two things could be queried. So each mineral would just get one statement, if we don't want any redundancies. --Tobias1984 (talk) 16:31, 20 May 2013 (UTC)

:Template:Oppose to the current solution of "space group #" items. The best datatype is string with value numbers between 1 and 230. Later when complex formulas will be possible we can change numbers by the formulas. Snipre (talk) 18:34, 23 May 2013 (UTC)

Template:Comment - I have thought about this for some time and I think we need those 230 space group items. (1) We need them to make the symmetrical classification complete. (2) Space groups have many different string designations (one string would be insufficient) (3) They have different physical properties that can't be stored with other items (e.g. phyisical, chemical, spectroscopy, deformation, magnetic, (super)conductor). (4) some already have their own commons category (5) they can link to each other by common symmetry elements. --Tobias1984 (talk) 18:34, 24 May 2013 (UTC)

Is it possible to have other label than "space group #" ? Something a little more explicit. Just a question. Snipre (talk) 23:52, 4 June 2013 (UTC)

The problem is that the other names of the space groups are full of symbols that we can't use in the labels (yet). --Tobias1984 (talk) 06:07, 5 June 2013 (UTC)

I know about the symbols but it is just to be sure that we can't use a term even scientific and difficult to understand but which is a little more descriptive than space group 1.Snipre (talk) 11:16, 5 June 2013 (UTC)

I really can't think of any other way to name the space groups. Apart from the 7 crystal systems I don't find any of the symmetry terms particular descriptive. Everybody knows what cubic symmetry is about, but when I read about a point group like "ditrigonal-scalahedral" I always have to look at a picture or the Hermann-Mauguin notation to know what it looks like. The space groups to my knowledge don't have any names, but those would be very long and equally non-descriptive. I did take a look at how WolframAlpha handles this. A search for space group 210 returns the correct space group. But searching for the other notations which can't be inputted unambiguously returns weird results. --Tobias1984 (talk) 11:37, 5 June 2013 (UTC)

Template:Support Snipre (talk) 12:09, 7 June 2013 (UTC)

Template:Question: what to do with those who are in multiple spacegroups? There are two forms of Tin, e.g., water can be crystallised in several groups, other compounds crystallise depending on the solvents or circumstances in different ways. Can a record link to multiple 'data'? --Beetstra (talk) 13:05, 24 June 2013 (UTC)

Single items having properties that can have multiple values is a general problem of Wikidata and propably any database. We just have to find a good solution for items we don't want to split or find out which items we should split into multiple items. Probably we need a qualifier for the symmetry properties that says "valid for = cubic phase" or "valid for = iron rich phase". A similar question would be, if chirals should have separate items. --Tobias1984 (talk) 15:21, 2 July 2013 (UTC)

Template:Comment I see that the German de:Vorlage:Infobox_Mineral has a target for this, however most of the English chemistry pages use en:Template:Chembox which doesn't currently have a dedicated option for space group. actually strike that, it does but it's rarely used en:Template:Chembox_SpaceGroup. The strucutre is noramlly described in the text - is that likely to be a problem? Also does this mean that we'll need to make 230 new pages on each space group?Project Osprey (talk) 13:35, 24 June 2013 (UTC)

230 items are not very much and they will ensure that we keep translation to a minimum. Also the 230 symmetry groups have many properties themselves. So we need to create the items anyway. I don't know if a bot can gather this information from a text. Otherwise we just have to try to import this information from a crystallographic database. --Tobias1984 (talk) 15:21, 2 July 2013 (UTC)

Template:Support--Sbisolo (talk) 10:08, 15 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 10:49, 15 July 2013 (UTC)

Gene Atlas Image

Discussion

• Template:Support Andrew Su (talk) 21:47, 10 June 2013 (UTC)
• Template:Support --Tobias1984 (talk) 10:17, 11 June 2013 (UTC)
• Template:Support Emw (talk) 13:16, 6 July 2013 (UTC)
• Template:Support Salvatore Loguercio (talk) 18:30, 9 July 2013 (UTC)
• Template:Wait - We should wait for this RfC first: Wikidata:Requests_for_comment/Image_properties:_many_properties_or_many_qualifiers. --Tobias1984 (talk) 12:14, 10 July 2013 (UTC)

This property is needed for the GSoC project to put Gene Wiki infobox data onto Wikidata. The schedule here notes that deployment of Wikidata work onto Gene Wiki articles is intended to begin on July 20 -- three days from now. Given that RFCs can take several months to close and Chinmay's project depends on being able to put Gene Atlas image data into Wikidata properties, I propose that we not wait for the linked RFC to resolve itself and, absent a specific alternative for how this property should behave, work with this property as it's proposed above. Determining how image annotation should work on Wikidata is important, but that wider discussion should not block the GSoC project. Emw (talk) 02:43, 17 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 08:40, 17 July 2013 (UTC)

Monotypic taxon

Template:Property proposal Sometimes there is only 1 genus in family (for example). In such cases Wikipedia have 1 article for both of them, and the taxonbox infobox shows both the family and the genus in bold + taxonom author. I think that in Wikidata should handle such cases by creating seperate entity for the family, and declaring with some property that it is monotypic. Currently boolean data type isn'tsupported, but once it would... Eran (talk) 20:41, 26 April 2013 (UTC)

• Template:Oppose – No need, we can use instance of: monotypic taxon. And we still need items for the all ranks to indicate taxon name etc. Byrial (talk) 10:41, 9 May 2013 (UTC)
  • I agree, so I'm dropping my proposal for "Monotypic taxon" property. Eran (talk) 14:28, 10 May 2013 (UTC)

As long as the different ranks are in fact one and the same taxon, I am not thrilled about the prospect of creating separate entities for it. That would be like having one item for Germany and a different item for Deutschland. I think it would be better to list all ranks, all taxon names, and all authors in one item, and separate them with qualifiers. But first we'd have to agree on a standard for that. -Soulkeeper (talk) 14:35, 10 May 2013 (UTC)

"list all ranks, all taxon names, and all authors in one item" - but all the taxon ranks properties expect entity - so for a monotypic species, do you expect to define itself as both genus and species? (e.g: in Q30847 set genus and species to be Q30847 (and not a seperate entity for the genus?)

Template:Done --Tobias1984 (talk) 17:53, 17 July 2013 (UTC)

Order of magnitude / Größenordnung / Ordre de grandeur

• Comments: Alternative might be to have a more general property "scale". --OldakQuill (talk) 15:20, 2 March 2013 (UTC)

Template:Comment I would suggest naming this to something like "times bigger than" and then have the datatype as an Item that defines how much does the subject have to be multiplied to get the object in it's qualifier. So a centimeter would have meter with a qualifier 100. And meter could have centimeter with a qualifier 0.01. Janjko (talk) 16:48, 19 March 2013 (UTC)

I think a more simple solution would be "SI equivalent" (or whatever label also applieas to nanosedond). "nanosecond. SI equivalent: 10^-9 s", "mile. SI equivalent: 1609 m".--Zolo (talk) 16:58, 19 March 2013 (UTC)

I agree, that's better. Janjko (talk) 21:20, 20 March 2013 (UTC)

Template:Oppose Treat 'nanosecond' like a physical constant with value>0.0001 and SI units>seconds or better yet wait to see if we can have a datatype with both value and units. Filceolaire (talk) 19:16, 16 May 2013 (UTC)

Template:Done--Tobias1984 (talk) 17:55, 17 July 2013 (UTC)

Linguasphere

Template:Comment - Needs a lot more explanation. --Tobias1984 (talk) 12:58, 16 May 2013 (UTC)

Template:Comment should be monolingual string. What is a "Linguasphere". "language code" is clearer. Filceolaire (talk) 17:37, 17 May 2013 (UTC)

Template:Done --Tobias1984 (talk) 17:59, 17 July 2013 (UTC)

Cleavage (crystal) / Spaltbarkeit/ Clivage/ Спайность / Sfaldatura

Template:Property proposal Useful for infoboxes and for queries. --Tobias1984 (talk) 18:31, 30 April 2013 (UTC)

Template:Support used in fr:mineral infobox too Snipre (talk) 17:46, 21 May 2013 (UTC)

Template:Support --Chris.urs-o (talk) 12:08, 22 May 2013 (UTC)

Template:Support - using "halite = {001} + Qualifier = good" --Sbisolo (talk) 12:51, 22 May 2013 (UTC)

Would "string" be the more appropriate datatype then. I don't know if items for Miller indices would be a good idea. --Tobias1984 (talk) 07:03, 25 May 2013 (UTC)

On the other hand some of these miller indices also have names. So it might be a good idea after all. --Tobias1984(talk) 13:52, 26 May 2013 (UTC)

Template:Done --Tobias1984 (talk) 18:15, 17 July 2013 (UTC)

Replaced synonym (nom. nov.)

Discussion

Helps to bring together otherwise not linked taxon names. Similar to Template:P but author and epithet are replaced. Succu(talk) 12:30, 21 May 2013 (UTC)

Template:Support  — Felix Reimann (talk) 19:55, 10 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 19:07, 17 July 2013 (UTC)

UN number

Discussion:

Template:Support --Tobias1984 (talk) 18:43, 8 July 2013 (UTC) Template:Done --Tobias1984 (talk) 19:15, 17 July 2013 (UTC)

Neurolex ID

Discussion

Template:Support -- Andrew Su (talk) 21:19, 11 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 20:19, 17 July 2013 (UTC)

Ex taxon author(s)

Discussion

Missing property which allows to construct author citations like Magnoliales Juss. ex Bercht. & J.Presl. Succu (talk) 12:30, 21 May 2013 (UTC)

Template:Support required for many plant taxons.  — Felix Reimann (talk) 13:39, 9 July 2013 (UTC)

Clearly, something needs to be done about author citations. Most likely the best thing would be a text field, as in the "description", as there are many permutations (see here). However if an itemized data structure is desired the following will go a long way:

---

basionym ex-author1

basionym ex-author2

basionym ex-author3

etc

basionym author1

basionym author2

basionym author3

etc

basionym year

valid ex-author1

valid ex-author2

valid ex-author3

etc

valid author1

valid author2

valid author3

etc

valid year

Template:Comment With Template:P you can add an infinite number of authors and qualify Template:P with Template:P. You can do this with Template:P too. --Succu (talk) 19:26, 9 July 2013 (UTC)

---

Andinobates Twomey, Brown, Amézquita & Mejía-Vargas, 2011

[ animal ]

valid author1 = Twomey

valid author2 = Brown

valid author3 = Amézquita

valid author4 = Mejía-Vargas

valid year = 2011

---

Kniphofia uvaria (L.) Oken (1841)

[ plant ]

basionym author1 = L.

valid author1 = Oken

valid year = (1841)

---

Andinobates daleswansoni (Rueda-Almonacid, Rada, Sánchez-Pacheco, Velásquez-Álvarez, and Quevedo-Gil, 2006)

[ animal ]

basionym author1 = Rueda-Almonacid

basionym author2 = Rada

basionym author3 = Sánchez-Pacheco

basionym author4 = Velásquez-Álvarez

basionym author5 = Quevedo-Gil

basionym year = 2006

[ Note no "valid author" as the zoological Code omits the author(s) of the combination ]

---

Lithocarpus polystachyus (Wall. ex A. DC.) Rehder (1919)

[plant]

basionym ex-author1 = Wall.

basionym author1 = A.DC.

valid author = Rehder

valid year = (1919)

---

Gentianales Juss. ex Bercht. & J.Presl (1820)

[plant]

valid ex-author1 = Juss.

valid author1 = Bercht.

valid author2 = J.Presl

valid year = (1820)

---

Bacillus subtilis (Ehrenberg 1835) Cohn 1872

[ prokaryote ]

basionym author1 = Ehrenberg

basionym year = 1835

valid author1 = Cohn

valid year = 1872

---

But most likely, very many users will think this is too hard to understand, and will get tangled in it. Safest is a normal text field. - Brya (talk) 16:53, 9 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 08:49, 18 July 2013 (UTC)

Pubmed ID (PMID)

Discussion

Template:Strong support Will be used extensively in our efforts to import Gene Ontology annotations... Cheers, Andrew Su (talk) 21:12, 11 July 2013 (UTC)

Template:Support Emw (talk) 03:30, 18 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 08:56, 18 July 2013 (UTC)

Disease Ontology ID

Discussion

Template:Support -- Andrew Su (talk) 21:19, 11 July 2013 (UTC)

Template:Support Emw (talk) 03:32, 18 July 2013 (UTC)

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

Hazard Identification Number or Kemler code

Discussion:

Template:Support --Tobias1984 (talk) 18:56, 8 July 2013 (UTC)

Template:Done --Tobias1984 (talk) 13:23, 18 July 2013 (UTC)