Wikidata:Property proposal/Archive/9

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

→ Property:P625

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

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

 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)

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

 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)

 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)

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)

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

 resolved, 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)

Discussion

•  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)
•  Support --Stevenliuyi (talk) 20:32, 5 June 2013 (UTC)
•  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)
•  Support Filceolaire (talk) 18:00, 10 June 2013 (UTC)

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

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

Discussion

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

Discussion

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

Discussion

Useful as not all the properties inscribed in the Répertoire du patrimoine culturel du Québec (Q3456276) are present in Canadian Register of Historic Places ID (P477). --Fralambert (talk) 03:19, 26 May 2013 (UTC)

 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 Canadian Register of Historic Places ID (P477) and Mérimée ID (P380) was in creative work. --Fralambert (talk) 13:08, 28 May 2013 (UTC)

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

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

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

 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)

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

 Done - Created at team captain (P634). Superm401 - Talk 19:10, 16 June 2013 (UTC)

 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 instance of (P31).--凡其_Fanchy 19:17, 2 June 2013 (UTC)

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

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

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)

Discussion

 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)

Discussion

 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)

Discussion

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

 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)

Discussion

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

 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)

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

•  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. ice Iₕ (Q1051773) (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:

water (Q283)

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.:

water (Q283)

phase point (item):triple point

temperature (number): XXX K

pressure (number): XXX Pa

phase of matter (P515) (item):solid

phase of matter (P515) (item):vapor

phase of matter (P515) (item):liquid Snipre (talk) 22:07, 10 June 2013 (UTC)

Discussion

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

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.

•  Support Filceolaire (talk) 20:38, 11 June 2013 (UTC)
•  Oppose 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 edition number (P393) 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)

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)

 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)

 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)

Discussion

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

•  Comment I think we can express this with default date-range-qualifiers (from time ... to time) on occupation (P106) = tennis player (Q10833314).--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 start time (P580) and end time (P582) and we need to use an unique system to indicate time interval for data extraction reason. Snipre (talk) 02:14, 7 June 2013 (UTC)

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

 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)

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

 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)

 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)

 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)

 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)

 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)

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

 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)

 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)

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

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

 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)
•  Oppose Per Snipre. --Sannita - not just another it.wiki sysop 14:05, 23 March 2013 (UTC)
•  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)
•  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)
•  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)
•  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)
•  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)

•  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)
•  Support as comments above. Filceolaire (talk) 19:42, 14 May 2013 (UTC)
•  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)

•  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)
•  Oppose, redundant to website account on (P553). --Yair rand (talk) 12:28, 30 May 2013 (UTC)

There're already website account on (P553). This request is archived.--GZWDer (talk) 03:07, 19 June 2013 (UTC)

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)

 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)

 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 applies to part, aspect, or form (P518) to indicate which parts they made. Danrok (talk) 23:29, 8 June 2013 (UTC)

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

 Oppose I'm not sure this is needed for any of your examples.

Aldous Huxley has father (P22) Leonard Huxley

Aldous Huxley has mother (P25) 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)

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

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

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

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)

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

 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)

 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)

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

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

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)

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

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

Discussion

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

Discussion

We already have RKDimages ID (P350), also by Netherlands Institute for Art History (Q758610), 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)

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

Discussion

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

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

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

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

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

Discussion

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

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

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

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

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

 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)

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

Discussion

Relation to other properties:

• publication date (P577): Use P577 if the accessed webpage states a date of publication (either instead of this property or together with it).
• point in time (P585): "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)

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

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

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)

 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)

• 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.
  •  Oppose, this can be derived from P:P131 and P:P150. --NaBUru38 (talk) 20:01, 27 March 2013 (UTC)
  •  Oppose per NaBUru38 Snipre (talk) 19:09, 10 June 2013 (UTC)

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

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

 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)

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

 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 instance of (P31) can be used for "type of seat". --Zolo (talk) 07:39, 16 May 2013 (UTC)

 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)

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

•  Support, if we do not have this property, we can use qualifiers. I think creator (P170) XX applies to part, aspect, or form (P518): translation (Q7553) 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)

•  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: The Hundred-Year-Old Man Who Climbed Out the Window and Disappeared (Q3793400). 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)

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)

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

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

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

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

Discussion

•  Support -- though we also need to allow "X" and "Y" chromosomes. Andrew Su (talk) 21:47, 10 June 2013 (UTC)
•  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 P89 (P89) qualifier. --Tobias1984 (talk) 19:57, 13 June 2013 (UTC)

•  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).
•  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 RELN (Q414043) GenLoc_chr human chromosome 7 (Q657319). Emw (talk) 01:31, 27 June 2013 (UTC)

Discussion

•  Support Andrew Su (talk) 21:47, 10 June 2013 (UTC)
•  Support - needs P89 (P89) qualifier. --Tobias1984 (talk) 19:58, 13 June 2013 (UTC)
•  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)

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

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

• P643 (P643), genomic start (P644), genomic end (P645) --Tobias1984 (talk) 21:32, 18 June 2013 (UTC)

Discussion

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

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)
•  Support Needed. — ΛΧΣ²¹ 20:48, 18 April 2013 (UTC)
•  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)
  •  Comment 1 & 2 sounds good for me. I would do it that way, yeah. --Nightwish62 (talk) 15:58, 19 April 2013 (UTC)
•  Support. Conny (talk) 14:28, 28 April 2013 (UTC).
•  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)
•  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)

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

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 part of (P361), 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)

 Oppose Redundant with part of (P361) Snipre (talk) 12:08, 10 June 2013 (UTC)

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

Discussion

This property is similar to instance of (P31), 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 is a list of (P360) 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 has part(s) (P527). Byrial (talk) 10:00, 18 June 2013 (UTC)

•  Oppose This seems redundant with subclass of (P279). A class is a type, which is a set of instances and the properties that those instances share. Bonnie and Clyde (Q219937) 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 Bonnie and Clyde (Q219937) fundamentally different than other, more conventional classes, like person (Q215627)? 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 instance of (P31)? The problem with this is that Bonnie and Clyde (Q219937) 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, instance of (P31) (rdf:type) corresponds to ${\displaystyle \in }$ (element of) and subclass of (P279) (rdfs:subClassOf) corresponds to ${\displaystyle \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 subclass of (P279), 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 Bonnie Parker (Q2319886) or Clyde Barrow (Q3320282)" it is a subclass of person (Q215627) with 2 instances. And if you define a class as "the class of items which are Bonnie Parker (Q2319886)" it is a subclass of person (Q215627) with one instance. But if you define a class as "the class of items which are Bonnie and Clyde (Q219937)" it is not a subclass of person (Q215627) as Bonnie and Clyde (Q219937) is not an instance of person (Q215627). Instead Bonnie and Clyde (Q219937) 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 subclass of (P279). 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 Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282), and a separate item Bonnie and Clyde (Q219937). Byrial (talk) 06:25, 19 June 2013 (UTC)

 Oppose We don't need to tie ourselves in knots trying to write statements about Bonnie and Clyde (Q219937). The detailed statements are in the items about each individual and we already have has part(s) (P527) which works to link Bonnie and Clyde (Q219937) to Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). 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)

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)

 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)

 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)

 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)

 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)

 Oppose per Silver. Redundant to language of work or name (P407) Filceolaire (talk) 21:11, 6 June 2013 (UTC)

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

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)

 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)

 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)

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

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