Support Can we have a complete list of possible values ? Just to be sure that this property won't be used as crystal system property.Snipre (talk) 10:06, 26 May 2013 (UTC)[reply]
I will create a list of items from these lists: en:Crystal habit, de:Kristallhabitus, nl:Habitus_(kristal) and add those items to the constraints of the property. Having the "habits" as items will also ease the translation. Also once we have all those items we can generate "habit-lists" for every Wikipedia language. E.g. fr:Habitus_(minéralogie) is missing a nice list with images. --Tobias1984 (talk) 10:21, 26 May 2013 (UTC)[reply]
Helps to bring together otherwise not linked taxon names. Makes it possible to generate the correct author citation: Opuntia ficus-indica (L.) Mill.Succu (talk) 12:30, 21 May 2013 (UTC)[reply]
Support - Especially because it is needed for citations. --Tobias1984 (talk) 13:37, 21 May 2013 (UTC)[reply]
Support as two separate properties, overlies and underlies, at least until there are bidirectional properties.Superm401 - Talk 16:30, 8 April 2013 (UTC)[reply]
Comment of course we could also use the properties preceded by and followed by for these relations. I'm not really sure how that would influence possible querries in the future. --Tobias1984 (talk) 15:42, 9 April 2013 (UTC)[reply]
Well, preceded and followed imply a temporal relation, and there are certain processes which can move older layers on top of newer ones, so overlays =/= follows. Chris857 (talk) 19:29, 25 April 2013 (UTC)[reply]
The terms overlies and underlies are being used here in their normal stratigraphic sense, I don't think that we should be including tectonic layering here. Mikenorton (talk) 13:57, 28 April 2013 (UTC)[reply]
The default should be stratigraphic succession. We could introduce qualifiers for things like unconformities and tectonic contacts. --Tobias1984 (talk) 14:17, 28 April 2013 (UTC)[reply]
Comments: Basic property used by all biographical infobox. Tpt (talk) 20:31, 30 January 2013 (UTC)[reply]
That may not sound very important -nor the right page to talk about that- but what about fictional worlds with fictional dates (see this infobox). Any way to escape the TimeValue datatype ? --Zolo (talk) 08:54, 3 February 2013 (UTC)[reply]
It is not a real person so it will be simpler to crate a new typ of item for fictional figures. Snipre (talk) 10:21, 3 February 2013 (UTC)[reply]
+1 it is very important --Viscontino (talk) 17:22, 5 February 2013 (UTC)[reply]
Support absolutely necessary. There will be a solution for the fictional World someday.
Support It existed a few hours ago (probably Property:P67 but was deleted !! --Eric-92 (talk) 02:44, 6 February 2013 (UTC)[reply]
Support once possible. @Eric: P67 was deleted because it used the "item" datatype, when it should've used "TimeValue". For that reason, of course, this property can't be created until TimeValue is enabled as a possible datatype. — PinkAmpers&(Je vous invite à me parler) 07:47, 6 February 2013 (UTC)[reply]
I think there's consensus for hacking this; I am putting this in a hidden block so it doesn't distract from others that are on-going conversations, whilst we wait for the datatype to be created. James F. (talk) 18:12, 6 February 2013 (UTC)[reply]
Property:P95 was created (not by me), maybe should be removed. --Eric-92 (talk) 22:24, 6 February 2013 (UTC)[reply]
Removed by someone. Ajraddatz (Talk) 12:46, 9 February 2013 (UTC)[reply]
Date of death / Sterbedatum / Date de décès / Data di morte
I think there's consensus for this; am hiding from the list of on-going discussions to avoid distractions. James F. (talk) 18:13, 6 February 2013 (UTC)[reply]
Foundation or Creation Date / Gründungsdatum / Date de fondation
the time taken for a given astronomic object to make one complete about another object. A qualifier can distinguish different definitions of orbital period (i.e. sidereal period, or synodic period).
Comments: general property useful for lots of items --Paperoastro (talk) 23:36, 6 March 2013 (UTC)[reply]
SupportComment Why not have a more succinct label like "discovery date"? Label wording aside, this property seems useful. Emw (talk) 03:40, 9 March 2013 (UTC)[reply]
Good idea! I have changed the name of the property. --Paperoastro (talk) 10:01, 9 March 2013 (UTC)[reply]
Support But it should be made clear that America wasn't "discovered" in 1492. Maybe add something like "discovered by mankind" in the description. --FA2010 (talk) 21:48, 15 March 2013 (UTC)[reply]
It is not so simple: in some cases two or more people discover something independently, and all of them are recognized as "discoverer". In these cases the discovery date will result to be not unique! --Paperoastro (talk) 16:06, 20 March 2013 (UTC)[reply]
Support Please provide more infobox examples. We should follow the infobox definitions. Mange01 (talk) 08:30, 20 March 2013 (UTC)[reply]
I add some other infobox examples. --Paperoastro (talk) 16:06, 20 March 2013 (UTC)[reply]
Support --Faux (talk) 07:45, 22 March 2013 (UTC)[reply]
I don't believe we have a date dissolved property pending, but we will need to wait for the timevalue datatype. I think this should be broadened to any organization. --Jfhutson (talk) 18:48, 5 May 2013 (UTC)[reply]
I agree. Thats why i named it Organization dissolved. Xaris333 (talk) 19:09, 5 May 2013 (UTC)[reply]
OK, sorry bout that. I guess the domain field and the section heading made me think these were intended just for football clubs. --Jfhutson (talk) 19:17, 5 May 2013 (UTC)[reply]
Comment It can just be named 'dissolved' with a date datatype. Joshbaumgartner (talk) 03:36, 10 May 2013 (UTC)[reply]
We should distinguish between the year a work was first published (Kafka: Der Process, 1925) and the date of a specific edition (El proceso, Madrid 2009). --Kolja21 (talk) 22:05, 31 January 2013 (UTC)[reply]
I think that there will be an item for each version of the book in order to allow people to easily quote them in the reference part ofstatements. In that case I'm not sure (but I may have wrong) that the two properties are needed. Tpt (talk) 17:44, 1 February 2013 (UTC)[reply]
I'm not a proper librarian, but I know there are a lot of cases for "dates". Data of publication, date of the edition, date of reprint... Maybe we want a general "date" property with several qualifiers? As I said in Comment III up here, it really depends by the purpose of the metadata. We'll probably have a Wikipedia page for the "work" (FRBR-like) Der Prozeß, but we'll have also different scanned books on Commons, (ie translations, different editions, reprints, etc.). I think that Wikidata would be absolutely usefule especially for Commons and Wikisources, so I wonder how should we design the list of properties for books in Wikidata. --Aubrey (talk) 10:37, 18 February 2013 (UTC)[reply]
Support --Aubrey (talk) 09:32, 19 February 2013 (UTC)[reply]
Support and we'll need similar functions for all creative works, I should think. Shawn in Montreal (talk) 04:24, 27 February 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think testing bots should not be done on the productive Wikidata, except in the sandbox.--Faux (talk) 17:04, 23 March 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Sounds good! (+1) Thanks for the idea! Greetings --DrTrigon (talk) 22:41, 23 March 2013 (UTC)[reply]
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)[reply]
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)[reply]
So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:
Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
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)[reply]
9 possible inputs per language (approved, grandfathered, redefined, renamed, questionable + approved, questionable + grandfathered, questionable + discredited, published without approval, discredited)
Example
e.g. Abelsonite = approved, Abernathyite = grandfathered
Oppose the datatype. With only few possible values, item would be much better, because then you only have to translate the values to all languages once pr. value instead of once pr. mineral. Byrial (talk) 22:32, 26 April 2013 (UTC)[reply]
datatype changed to item. --Tobias1984 (talk) 14:58, 28 April 2013 (UTC)[reply]
I'd like 9 possible outputs. We have already spodiosite (discredited 2003) (Q3966942) and pimelite (Q3905061). Maybe, the IMA status should be parted in two. --Chris.urs-o (talk) 17:39, 28 April 2013 (UTC)[reply]
Note that in cases like population, where change in the real-world value is effectively continuous but is only measured in discrete intervals, this qualifier would indicate the range of time the value was valid according to a given source. Here, that would be the official census of India.Emw (talk) 13:48, 20 April 2013 (UTC)[reply]
A good point was made in the proposal for the 'to time' qualifier that because census results typically represent a snapshot (i.e. an instantaneous measurement), it's incorrect to assert that the sources say claims about population counts are valid for a range of time. So I've added an 'as of' alias to this qualifier, and adjusted the 'domain' of this property to reflect that. Emw (talk) 15:32, 20 April 2013 (UTC)[reply]
Support This is a really common qualifier for a lot of property, any idea when the time datatype would be created? --Napoleon.tan (talk) 13:51, 20 April 2013 (UTC)[reply]
Comment. Maybe an other property for "as of": "from time" is for the beginning of a time range and "as of" for a specific date time. Tpt (talk)
Are you suggesting that the 'from time' qualifier would only be valid if the 'end time' qualifier were also applied to the claim? (And the converse, that 'end time' would only be valid if 'from time' were applied?)
In that case, claims that have begun but not ended, e.g. 'India instance of sovereign state since 26 January 1950', 'Universe instance of physical body since 13.8 billion years ago' would presumably also only be valid for 'as of' and not this 'from time' qualifier. Emw (talk) 16:30, 20 April 2013 (UTC)[reply]
Yes, I'm suggesting that the 'from time' qualifier would only be valid if there is an 'end time' qualifier. That will allow us to move easily to a time range (value of the 'as of' qualifier) if the range feature is added in the future. So Support now. Tpt (talk) 16:46, 28 April 2013 (UTC)[reply]
Support – Now that it is separated from "as of", it is clear and unambiguous. And it is also very much needed. -- Byrial (talk) 05:51, 21 April 2013 (UTC)[reply]
Support. Conny (talk) 13:58, 28 April 2013 (UTC).[reply]
Support Note that we require such a "start date"-property for all kinds of events, too. I think there's no need to create another property, but instead we can use this one. So the domain should include events as well.--Kompakt (talk) 09:05, 23 May 2013 (UTC)[reply]
Created as start time (P580), as "start date" considering the above comments that it need not always be a qualifier.
Description: I think that office held should be augmented with the dates during which the subject held that office. In that way, we could specify that e.g. George W. Bush was Governor of Texas from 17 Jan 1995 until 21 December 2000, and then President from 20 Jan 2001 to 20 Jan 2009 (dates taken from enwiki). Inputting the dates that way could also end disputes over how to format them (DMY, MDY, etc.): they could be automatically displayed in the format that users chose, without you having to change anything in edit mode in Wikipedia itself.
Comment. I'd like to see how "qualifiers" work before this type of property is made. This property can't be entered as its own statement as it would have no meaning without reference to some other statement. Espeso (talk) 06:06, 15 March 2013 (UTC)[reply]
(See comment from Lavallen below.) Note that in cases like population, where change in the real-world value is effectively continuous but is only measured in discrete intervals, this qualifier would indicate the range of time the value was valid according to a given source. Here, that would be the official census of India.Emw (talk) 13:48, 20 April 2013 (UTC)[reply]
I understand the Mexico and US-example, but not the India-example. A census is normally made a certain day, or a at least a certain year. Such numbers are very seldom in a very long range of time. Would it not be better to search for the latest census-date (2001) if you want to know the numbers for 2010? -- Lavallen (block) 14:29, 20 April 2013 (UTC)[reply]
Great point! You're right at least about the United States census; the census makes a point of noting that it represents things as they were on precisely April 1. So at least the US census is a snapshot, i.e. an instantaneous measurement. I'm not familiar with the details of the Indian census, but I assume it's the same in that regard.
The broader clarification seems to be this: if a statement represents a fact tied to a specific date, then it should have a "from time" qualifier but not an "to time" qualifier. Population counts and estimates are a good example of this: the sources are only asserting that their claim is valid for one specific date, not a range of time. Emw (talk) 15:22, 20 April 2013 (UTC)[reply]
Question – How would you distinguish between a statement for a specific date, and a statement for a state that has not yet ended, and thus is still valid? -- Byrial (talk) 20:31, 20 April 2013 (UTC)[reply]
'to time' not needed for population time stamps. 145.53.76.181 15:12, 20 April 2013 (UTC)[reply]
Support – needed together with "from time" -- Byrial (talk) 05:52, 21 April 2013 (UTC)[reply]
Support. But how to handle two not crossing timelines for an object? From 1992-1999 and 2001-2005 -> will this work? Conny (talk) 14:00, 28 April 2013 (UTC).[reply]
It will most likely work, even if it will look like: From: 1992, 2001; To: 1999, 2005; But it will be a challenge to make templates who can make it look nice. -- Lavallen (block) 14:19, 28 April 2013 (UTC)[reply]
Wouldn't it be better to just set it as two separate statements, each with their own from-time/to-time qualifiers? --Yair rand (talk) 15:51, 28 April 2013 (UTC)[reply]
Should we decide in advance whether the values of this are inclusive or exclusive (ie does September 1-September 20 include the 20th?) ? --Yair rand (talk) 15:51, 28 April 2013 (UTC)[reply]
Good question. I think we should decide that before this qualifier (and from time) is created. In George W. Bush, the subject's presidency is shown as January 20, 2001 – January 20, 2009. According to First inauguration of George W. Bush, he was in office as of 12:01 p.m. January 20, 2001. So those 'from date' and 'to date' values are inclusive. I'm not sure if this is standard for that field's use for all politicians, though.
For what it's worth, popular SQL implementations of "BETWEEN" make that operator inclusive, see e.g. BETWEEN in MySQL. Perhaps that indicates that this qualifier should be inclusive.
Are there any prominent counterexamples, where 'from date' or 'to date' are used in the exclusive sense in a certain domain?
Should this be limited to use as a qualifier? Some main items could use this, too. For example, Q1719918. --Yair rand (talk) 15:51, 28 April 2013 (UTC)[reply]
There have been property proposals for 'date', 'start time' and 'end time' awaiting feedback for over a month (over three months for 'date') at Wikidata:Property_proposal/Event, which would apply to things like Presidency of George W. Bush (Q1719918). The labels 'start time', 'end time' and 'date' seem more idiomatic to apply to events than 'from time', 'to time' and 'as of', with 'date' and 'as of' seeming especially awkward to interchange. (Saying 'Tenerife airport disaster <as of> March 27, 1977' is clearly worse than saying 'Tenerife airport disaster <date> March 27, 1977'.) Emw (talk) 18:38, 28 April 2013 (UTC)[reply]
Support As mentioned above, the domain should include events, too (where this wouldn't be used as a qualifier but a "top-level"-property).--Kompakt (talk) 09:07, 23 May 2013 (UTC)[reply]
Created as end time (P582), "end date" considering the above comments that it need not always be a qualifier.
Any claim that is supported by a source for a specific point in time, but not a range of time
Allowed values
Any time
Example
United States of America population 308,745,538 as of April 1, 2010
Proposed by
Emw (talk) 21:15, 20 April 2013 (UTC), originally suggested by Tpt[reply]
Support – It seems clear to me that we need a separate qualifier for point of time. (Compare to the discussions for "from time" and "to time" -- Byrial (talk) 06:00, 21 April 2013 (UTC)[reply]
Support - Complete the set of qualifier properties for "time". --Paperoastro (talk) 16:08, 21 April 2013 (UTC)[reply]
Support - So how can qualifier be created? --Napoleon.tan (talk) 06:09, 22 April 2013 (UTC)[reply]
SupportThey are not. Qualifiers are just properties of properties so every property can be used as Qualifer. That means if the property proposals for 'date', 'start time' and 'end time' are succesful this is not needed anymore.--Saehrimnir (talk) 10:39, 8 May 2013 (UTC)[reply]
I would prefer a more general "date" property, as it would be applicable both as an "as of" qualifier and as a stand-alone statement for punctual events. --Zolo (talk) 12:24, 30 May 2013 (UTC)[reply]
Comments: --Faux (talk) 13:41, 18 February 2013 (UTC)[reply]
Some events span periods of time, days, weeks, etc. So, this would need to be start and end date/time. Probably applies to almost all events. Danrok (talk) 20:11, 21 February 2013 (UTC)[reply]
Obviously Support. I can't believe that we have over 300 properties, but none to say that the 2004 elections were held in 2004. --NaBUru38 (talk) 19:26, 19 March 2013 (UTC)[reply]
Well, Wikidata doesn't actually support the Date data type yet...
Should this be split into start date/end date, or does the data type handle that by itself? --Yair rand (talk) 00:11, 20 March 2013 (UTC)[reply]
Support: Essential property for events. Emw (talk) 02:40, 27 March 2013 (UTC)[reply]
Oppose Once the date datatype is available, it seems clear we will quickly have generic 'from/start' and 'to/end' properties which should cover this when used as qualifiers for 'member of team' claims. Joshbaumgartner(talk) 09:33, 9 May 2013 (UTC)[reply]
Ok. But when will be available? Xaris333 (talk) 17:07, 9 May 2013 (UTC)[reply]
Comment They are working right now on this data type (see Wikidata:Status_updates). However, no idea how long it would still take. --Nightwish62 (talk) 09:51, 11 May 2013 (UTC)[reply]
Oppose as user Joshbaumgartner. --Nightwish62 (talk) 09:51, 11 May 2013 (UTC)[reply]
Oppose per Joshbaumgartner and Nightwish62. --Ricordisamoa 12:14, 22 May 2013 (UTC)[reply]
Comment - We should probably rename this to "club" and then add time qualifiers. Queries can return the current club. --Tobias1984 (talk) 13:54, 7 May 2013 (UTC)[reply]
The player's most common position or positions. If a player is known for playing in multiple roles then explain the point more fully within the article.
Oppose redundant with Position (on team) which is perfectly suitable for association football positions as well as any other sport. Joshbaumgartner (talk) 09:49, 9 May 2013 (UTC)[reply]
Oppose I am sure we are going to have a "height" property and I don't see that this property could have a different value. --Tobias1984 (talk) 08:24, 4 May 2013 (UTC)[reply]
I don't think "height" is use out of sports templates. But, we can change the title as height. Xaris333 (talk) 12:52, 4 May 2013 (UTC)[reply]
there is already Property:P185, but that does not apply to older times. In greek philosophy the relationship between a student and teacher is most important. For instance, Q859 => Q913 or Q1287486 => Q317947. In fact Student of could even replace P185 as it covers a broader set of situations.
Oppose Subjective property: which criterion is used to determine the largest parameter ? This can be deduced by multiple parameters query like "city of XX with the biggest population" or "city of XX with the biggest GNP". Snipre(talk) 09:17, 12 May 2013 (UTC)[reply]
Oppose This is not necessary. Simply use continental confederation with a qualifier from/start (e.g. My Favorite Team - continental confederation - CONCACAF - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:14, 10 May 2013 (UTC)[reply]
Oppose as above Snipre (talk) 09:06, 12 May 2013 (UTC)[reply]
Oppose covered by P:P131, and this broadens it to be able to cover events hosted in counties, provinces, etc, not just cities. Joshbaumgartner (talk) 04:47, 10 May 2013 (UTC)[reply]
type (of school, university, ...)
Not done
Description
the type of school (all schools, universities, colleges)
Comments: Values would include public, business school, music school and many others. Danrok (talk) 15:58, 24 February 2013 (UTC)[reply]
I'm a bit worried about the range of types. Public vs priavate is binary. Arts vs business vs technical is an axis. University vs universitary institute vs God knows what depends on legislation. --NaBUru38 (talk) 23:15, 25 February 2013 (UTC)[reply]
Perhaps it could be limited to public, private and national? Are there any other main types? Danrok (talk) 15:28, 26 February 2013 (UTC)[reply]
If it's truly "all schools," then primary, secondary, and post-secondary would seem necessary. Shawn in Montreal (talk) 22:40, 3 March 2013 (UTC)[reply]
Oppose Start by using Is a(n). There is only one "type" field in that infobox, so there is no risk of conflict. The allowed item objects is not a limited list, so the bots don't need another type property. Mange01(talk) 02:27, 7 March 2013 (UTC)[reply]
Looks a little to country-specific to be usefull in a global perspective. It is always difficult for me as a Sweede to describe what kind of education I have, since we normally starts in University later than other in other nations and our time in school is normally shorter. Also post-graduate students have another kind of relation to the school than in other countries, even if the exam is the same. Lavallen (block) 09:05, 20 April 2013 (UTC)[reply]
it can be easily excluded from other certain ceremony templates or categories eg.,and
Domain
subject domain is ceremonies, celebrations, festivals and holiday; object domain is song(s) or pieces of songs or poem(s) name(s) recently or traditionally sung or written
Example 1
MISSING
Example 2
MISSING
Example 3
MISSING
Comments: Some cultural events are traditionally accompanied by several old songs eg. you cannot consider Persian Nowruz ceremony separable from Doa-ye-Tahvil song in Iran. Sometimes there are songs improvised on a ceremony eg. Nowrouz Album, by Iranian singer, Shahram Nazeri, is dedicated exclusively to Nowrouz festival. Another example of this type is Happy Holiday, a popular Christmas song composed by Irving Berlin. As well as, "The Christmas Song" written in 1944 by M. torme & B. Wells and "stay cool by thinking cool", the most-performed Christmas song, together are some other samples for the proposed wikidata property. Doostdar (talk) 20:34, 8 March 2013 (UTC)[reply]
Oppose, the relation between the two subjects is too weak it me. --NaBUru38 (talk) 19:27, 19 March 2013 (UTC)[reply]
Oppose, I think this should be replaced with 'theme' as this would allow a less niche property whilst also helping ensure a better world view (they have different Christmas songs in Spain vs. U.K.). Basically I think this should be a property attached to the song etc. not the event.
This property would allow us to list championship seasons in items about sports teams. AutomaticStrikeout 15:35, 11 May 2013 (UTC)[reply]
Oppose Use the title of the competition or the name of the cup with the year as qualifier. Wikidata is not Wikipedia linking article between them. Or the best is to used the below proposal Wikidata:Property_proposal/Organization#Standings positionwith the first position in order to determine the years when the team won the competition. Or use the propertyaward receivedSnipre (talk) 09:43, 12 May 2013 (UTC)[reply]
Oppose This is not necessary. Simply use member of with a qualifier from/start (e.g. My Favorite Team - member of - FIFA - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:05, 10 May 2013 (UTC)[reply]
Oppose as above Snipre (talk) 09:07, 12 May 2013 (UTC)[reply]
Actually I had created P:P357 as "title", par another discussion (about journal articles, I think). It was renamed to "original title" afterwards, so that we stil need a "title" property. We can really not assume that the label will always be the same as the title. For instance, old books may have very long titles, that do not fit into a label, or a book may have two titles (for instance translations), or an article in non-latin script may have a transliterated label (which would follow a rather common practice) that would obscure the real title. I think the simplest solution would be to rename P:P357 back to "title", as using a qualifer for "original" would be more flexible, and much clearer books that were never translated, and where title and original title are the same. In any case, a "title" property is needed. I don't see any use to restricting to books though, as the property is even more needed for journal articles cites in sources, and for some artworks. --Zolo(talk) 21:36, 14 April 2013 (UTC)[reply]
Sub continental confederation affiliation (en)
Not done
Description
The year the association joined the subregion (i.e. CECAFA, CEMAC, COSAFA, UNAF, WAFU))
Oppose This is not necessary. Simply use subcontinental confederation with a qualifier from/start (e.g. My Favorite Team - subcontinental confederation - UNAF - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:14, 10 May 2013 (UTC)[reply]
Oppose as above Snipre (talk) 09:07, 12 May 2013 (UTC)[reply]
Subsidiary
Not done
Description
An organisation which is a subsidiary of another organisation
several infoboxes use this, like the ones given above, and probably others
Robot and gadget jobs
Should presumably be reciprocal with parent company, proposed above.
have left the German/French names blank because the interwiki links for subsidiary both link to articles called "filiale" which translate as "branch", and I'm not 100% if that's exactly the same meaning. (After all, branch can also mean two branches of the same bank, for example.) Buttons to Push Buttons (talk) 09:59, 10 March 2013 (UTC)[reply]
Comment I don´t know, but Property:P127 (owner of the subject) seems to be rather similar. "The owner of British Airways is International Airlines Group". --Goldzahn (talk) 23:36, 11 March 2013 (UTC)[reply]
You're right, for some reason I was under the impression that property was for people only. Would it be an issue to use a field called owner for infoboxes which use parameter subsid? Not something I'm qualified to answer. And is there a need for distinction between ownership by people and ownership by organisations? Not sure on this one, but perhaps not. Buttons to Push Buttons (talk) 23:43, 11 March 2013 (UTC)[reply]
I think, that at the moment only the developers are qualified to answer. In my view,this shows that the property name is used only in the infoboxes, but will not be displayed. --Goldzahn (talk) 00:16, 12 March 2013 (UTC)[reply]
Actually, P127 should be on the above property, "subsidiary" is the opposite :). I dont know if there is any benefit in having a different property for people and for companies, but the current trend is toward rather general property, so it would sound more consistent to have just one. And the current property is already used for companies. --Zolo (talk) 18:38, 12 March 2013 (UTC)[reply]
Oppose: One property is enough. With checking for a second property e.g. gnd-type or something else one can conclude if the property means subsidiary or something else. I added this name as alias
I don't know if other creative works besides film and television series use this property. It would also be possible to reuse theProperty:P17, if the description is slightly adjusted, but I would prefer to seperate the "country of origin" from a the location of an item (Property:P17). Please comment what your opinion is!--CENNOXX (talk) 16:33, 11 April 2013 (UTC)[reply]
Done Created the Property:P495 – Country of origin. nearly a month without any objections.--CENNOXX (talk) 17:29, 6 May 2013 (UTC)[reply]
Helpful for the info boxes. Especially scientific work tend to have pretty long subtitles, that are not always suitable to print in full length.--Kolja21 (talk) 01:29, 4 February 2013 (UTC)[reply]
Support, although I'm not familiar with works with subtitles. --NaBUru38 (talk) 19:31, 19 March 2013 (UTC)[reply]
Support, should also be used for movies and other creative works --Nightwish62 (talk) 17:59, 26 March 2013 (UTC)[reply]
Indeed, documentary films in particular often have use a subtitles, after the main title. Shawn in Montreal (talk) 23:08, 9 April 2013 (UTC)[reply]
Comment Maybe, when qualifiers will be available, we could use them to add more subtitles adding a "qualifier" like "language edition". --Viscontino (talk) 10:09, 18 April 2013 (UTC)[reply]
As it is indicated in the infobox writer, the era will be calculated according to time from first publication to last. For a sample refer to English wikipedia article w:en:Ferdowsi -- دوستدار ایران بزرگ (talk) 19:30, 12 March 2013 (UTC)[reply]
Oppose You probably mean "period", but this should be clear by the list of publications. Description: "Dates from first publication to last publication." (w:en:Ferdowsi use this field in a special way.) --Kolja21 (talk) 15:29, 17 March 2013 (UTC)[reply]
Comment Ferdowsi's 40 year life had coincided with a change in governing regime i.e. the substitution of two dynasties of Samanids and Ghaznavids in Iran but for most of poets, writers, etc. it's not difficult to conceive the period in which he or she has lived. There won't be even any necessity for searching the date of his or her publications. دوستدار ایران بزرگ (talk) 11:22, 18 March 2013 (UTC)[reply]
Oppose This is a property of the author, not a property of the work. Filceolaire (talk) 16:09, 15 May 2013 (UTC)[reply]
Inspired by a discussion in #wikimedia-office :) Legoktm (talk) 17:50, 25 April 2013 (UTC)[reply]
Oppose Sorry, but this property would be the same as P:P407 (language). P407 is btw itself more or less a duplicate (the other way around) of P:P364 (original language). Qualifiers could be used here if necessary I think. --#Reaper (talk) 20:52, 25 April 2013 (UTC)[reply]
Oppose If each edition (including translations) gets a statement on the wikidata page for the book then P:P407 (language) will work as as a qualifier. We don't need this. The seem applies if each edition and translation is a seperate item.Filceolaire (talk) 17:14, 15 May 2013 (UTC)[reply]
Oppose, can be easily queried. --Nightwish62 (talk) 09:38, 6 April 2013 (UTC)[reply]
I don't understand what "can be easily queried" means. Could you explain that? --★ → Airon 9018:46, 6 April 2013 (UTC)[reply]
Basically, it means we will be able to automatically get the number of items that are e.g. instances of live album (Q209939) and have a particular performer (P175). So, there is no need to hand-calculate it and add it ourselves. That would only be redundant and get out of date. I presume at some point such queries will be available for infoboxes, but I don't know the details. Superm401 - Talk 21:55, 6 April 2013 (UTC)[reply]
Strong oppose per Nightwish62 and Superm401. --Ricordisamoa 22:22, 6 April 2013 (UTC)[reply]
Isn't possible to make it by hand now and then by bot or by database queries? --★ → Airon 9010:59, 7 April 2013 (UTC)[reply]
I don't think that's really in the spirit of Wikidata. We don't to put in a lot of info we know we'll have to take out when queries arrive. For now, the Wikipedias can keep doing what they're doing. Superm401 -Talk 19:31, 7 April 2013 (UTC)[reply]
Planned road length / Straßenlänge in der Planung / longueur de la route planifié
Not done
Description
length of the planned part of the road / Länge des geplanten Teils der Straße
Oppose as this is not manageable for most situations. In those cases where it is feasible to have this data, it can be done under 'length' (see above proposals) with a qualifier 'status' or some such. Joshbaumgartner (talk)
The list of studios can be found on the recording's booklet, or the artist's website. This information usually appears on the infobox of WP articles about the recording
Support, but it would be nice if we could set "item" DataType in case there's a WP article (not only for this case). --Viscontino (talk) 11:25, 19 April 2013 (UTC)[reply]
Comment agree. Item is better. --Nightwish62 (talk) 16:01, 19 April 2013 (UTC)[reply]
I'd like to create items to all studios and change the type to item. Let me see if this can be done :) — ΛΧΣ21 17:59, 19 April 2013 (UTC)[reply]
Everything should be clear I think. #Reaper (talk) 14:24, 21 April 2013 (UTC)[reply]
Support Mostly because many games have additional specific input devices, like the Dance Dance Revolution or Kinect games.— ΛΧΣ2116:41, 22 April 2013 (UTC)[reply]
Support I don't know exactly how to call the English label (TV = Show's creator; film = ?), but there should be a distinction between an artist like Leonardo da Vinci and the creator of a show's. (Right now both have the same property.) --Kolja21 (talk) 07:46, 16 March 2013 (UTC)[reply]
Comment Please also have a look at en:Princess Zelda, "created by Shigeru Miyamoto". Should cases like this be included or is designer (Property:P287) suitable? --Kolja21 (talk) 07:52, 16 March 2013 (UTC)[reply]
Oppose There already is Property:P170, creator. Creator is a tv-thing, or do you mean the author of Property:P144, or something like that?--CENNOXX (talk) 00:34, 26 March 2013 (UTC)[reply]
Support "An original idea by" is a common phrase in many works, not just television programs. I prefer the "idea by". --NaBUru38 (talk) 19:45, 27 March 2013 (UTC)[reply]
Exactly, that's a different role. --NaBUru38 (talk) 18:51, 18 April 2013 (UTC)[reply]
Oppose Duplication. Already exists as Property:P170, which expressly includes creators of creative works. Shawn in Montreal (talk) 18:47, 5 April 2013 (UTC)[reply]
Oppose, clearly a duplicate of "creator (P170)"; this proposal should be archived soon. --Ricordisamoa 00:17, 11 May 2013 (UTC)[reply]
ID in database / Primärschlüssel in Datenbank
Not done
Description
For referencing of items that have entries in databases.
Currently Lupus has the MeSH ID instead of the MeSH code. So MeSH ID = D008180. I propose to move this meaning ID into the source and rename MeSH ID to MeSH code which would be C17.300.480 and C20.111.590 for Lupus and ID = D008180.
Format and edit filter validation
If it is used for a lot of different databases we can't apply any filters.
Strong oppose since we have already many properties for the ids in different databases this is not necessary. As you say we can't use filters here which makes it much more difficult and complicated to find wrong values. Also it will be more difficult to add ids for users because they have to set the database in the qualifier section (you should not use sources for that). --Pyfisch (talk) 15:21, 12 May 2013 (UTC)[reply]
Thanks for the review Pyfisch. I am still a little confused on how to best handle this kind of things. Could you maybe review this proposal Wikidata:Property_proposal/Term#MeSH_Code. I would like to know your opinion on 1) the creation of a second property 2) if one of the two properties should be a qualifier for the other one. --Tobias1984 (talk) 15:33, 12 May 2013 (UTC)[reply]
Support Indeed. We have so many artists that are members of musical groups, and this will be useful. — ΛΧΣ21 06:08, 4 April 2013 (UTC)[reply]
Support, rename to "member of artistic group" to include other forms of art. --NaBUru38 (talk) 16:53, 11 April 2013 (UTC)[reply]
That seems like a good idea. Then we could use it for ballet, theatre troupes, etc. Superm401 -Talk 06:29, 12 April 2013 (UTC)[reply]
Oppose, redundant with part of (P361). Emw (talk) 13:49, 13 April 2013 (UTC)[reply]
Oppose per Emw. Also, if there were a "member of" property, then it should be used instead of creating "member of X" for every X, which is redundant and pointless. Silver hr (talk) 00:46, 19 April 2013 (UTC)[reply]
Comment I don't see a redundancy with Property:P361 (from it's discussion page I gather the proposed use in cases where no more specific property for a part-whole-relationship is applicable). However "Member of a (musical) group" should be considered a special case of the "affiliation" relation between persons and organizations and as such is qualified by a period of time and roles. The domain of useful roles is influenced by the kind of organization. Affiliation itself would allow statements like "Sam Cutler was Tour manager for The Grateful Death in 197[?])" (or think of other roles like "legal representative", agent, ...) and there probably would still be the need to determine a narrower set of roles expressing bandmembership proper (what about "supporting musicians" anyway: "Tim Bonhomme is (employed as) keyboarder for the Beach Boys since 1993" vs. "David Marks ws guitarrist and vocalist of the Beach Boys from 1962-1963 and in 1997"). So maybe it would be best to keep the musical roles and the membership roles ("bandleader", "lead guitarist", does one really need them) completely separated, but all of them as datatypes strongle need a qualifier for the interval(s) of time this connection was valid. -- Gymel (talk) 07:24, 19 April 2013 (UTC)[reply]
The problem with this property and properties like it is that it's essentially creating a domain-specific property where a generic one suffices. It sets a precedent for an explosion of "member of X", "type of X", etc. properties. The expressivity of the statements given above is fully achievable by using generic properties like 'part of' instead of domain-specific versions of those generic properties. Emw (talk) 20:40, 20 April 2013 (UTC)[reply]
However this generic one shouldn't be Property:P361 for membership and roles (more general: relations between persons and organizations). My left thumb by transitivity is part of the matter in the universe but David Marks' thumb IMHO shouldn't be considered a member of the Beach Boys. -- Gymel (talk) 22:49, 23 April 2013 (UTC)[reply]
The relation seems even broader than just a "part of" relation between persons and organizations. For example, Germany is a member of the EU, but Berlin is not a member of the EU. I think what your use case is searching for is a way to get thehighest-level parts of some item. I think this use case would be better to support with one simple query technique involving part of, rather than a proliferation of "member of" properties that users would need to look up individually. Emw (talk) 04:31, 24 April 2013 (UTC)[reply]
Comment Now that we have member of, this property would be really redundant. Silver hr(talk) 18:38, 26 April 2013 (UTC)[reply]
Basic piece of information for several engines, electronics, weapons, and other items which produce heat as a by-product.Joshbaumgartner (talk) 08:00, 19 May 2013 (UTC)[reply]
There are 32 point groups that subdivide the crystal systems. They are derived from crystallographic symmetry operations. Every macroscopic crystal and mineral belongs to one of these point groups. The point group is equivalent to "crystal class".
Comment - We need more than 32 point groups: we need 'crystal system xy, undefined point group' as well. --Chris.urs-o (talk) 09:25, 24 May 2013 (UTC)[reply]
Nõ, if it is unknown, we let empty. Snipre (talk) 19:08, 27 May 2013 (UTC)[reply]
Comment: Default unit should be changed to km/h since this property will most often be used for powered aircraft which do not us m/s as a normal unit for speed. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)[reply]
Oppose - speed is too generic. Things like "maximum" should be solved with qualifiers. --Tobias1984(talk) 14:01, 16 May 2013 (UTC)[reply]
Support -- Phoebe (talk) 20:00, 25 February 2013 (UTC)[reply]
Support but there are some difficulties. 1) Incorporated places do have two different GNIS codes, one for the populated place and another for the incorporated subject, the GNIS does have different codes for e.g. Hibbing, Minnesota and the City of Hibbing, Minnesota. The issue is that neither in the EN nor in the DE Wikipedia (refer to de:Vorlage:Infobox Ort in den Vereinigten Staaten) one can be sure that in every case the "right" code was used; I even am not aware that this issue has been discussed before in the EN:WP. 2) GNIS also exists for the US Minor Outlying Areas and Puerto Rico. 3) There exist also GNIS codes in another databas for antarctic objects. At the moment I do not know wether only for those objects which have been named by the BGN or for any antarctic feature. --Matthiasb (talk) 13:24, 7 March 2013 (UTC)[reply]
Support But as Matthiasb said above, there's also a separate GNIS database for antarctic features with its own IDs. We probably need a separate property for those. --Kam Solusar (talk)
Enzyme Commission number (EC number) is a numerical classification scheme for enzymes, based on the chemical reactions they catalyze. As a system of enzyme nomenclature, every EC number is associated with a recommended name for the respective enzyme. (See: en:Enzyme Commission number
Can be usefull for creating navbox for articles about geographical areas. Šlomo (talk) 19:40, 25 April 2013 (UTC)[reply]
Seems useful, but unsure about the values. Why not allow further subdivisions (NNE, ENE, ESE etc.) for cases where further precision may be needed. Or even just use degrees to measure the direction? --Byrial (talk) 21:56, 25 April 2013 (UTC)[reply]
Well, I chose the 8 directions that have their items to make the extraction of data in various languages easier. Also, having in mind Property:P47, the neighbouring countries, states, regions, counties a.s.o. won't usually be in an exact direction from each other. But I agree that a numeric value can be comparably useful and it has potencial of another use in situations where more precise values would be possible and needed.--Šlomo (talk) 01:08, 26 April 2013 (UTC)[reply]
Support. Conny (talk) 14:01, 28 April 2013 (UTC).[reply]
Comment It seems there's consensus that this property should not be restricted to the cardinal directions -- i.e. north, east, south and west. So I think this property should renamed to something like "direction". Also, the documentation should clarify whether the values for this qualifier are based on true north or magnetic north, and which coordinate reference system is used. Emw (talk) 16:49, 28 April 2013 (UTC)[reply]
Comment Having looked at the example (in the future, please give the actual labels so it's possible to read without going to each individual page), it's unclear to me why this property would use degrees 0-360 as values. Stating that "United States of America shares <0, 90 degrees> border with Canada" seems odd compared to "United States of America shares <north> border with Canada". So I think the original choice to use cardinal directions (and maybe intercardinal directions like NE, NNE) would be better than allowing degrees 0-360. Emw (talk) 17:03, 28 April 2013 (UTC)[reply]
Translating <0, 90 degrees> to <north and east> can be easily done by the software. I found the idea of azimuth values more useful, because it doesn't limit as for the future to use it more precise. If we use Item datatype, we are at this moment limited to cardinal and intercardinal directions - at least I didn't find items for NNE, NbE etc.--Šlomo (talk) 10:54, 1 May 2013 (UTC)[reply]
Ah, OK, thanks for the clarification. I think that should be made clear in the proposal. It should also be made clear that this qualifier handles exclaves of its subject. For example the United States shares a significant border on the east with Canada only in Alaska, which is not contiguous with the rest of the United States. Would this qualifier handleenclaves like Lesotho, which is an enclave of South Africa? If so, how? The list of enclaves and exclaves provide more edge cases that might be worth considering. Emw (talk) 00:12, 2 May 2013 (UTC)[reply]
Support the 8 item idea. Everything else with more detail has to be done with geopolygons in my opinion. --Tobias1984 (talk) 21:04, 20 May 2013 (UTC)[reply]
Support But with cardinial directions, per Emw and Tobias1984. I would allow 16 items (north, north-east, north-north-east), but that's enough. The full 360 degrees really aren't needed here. On the contrary, it would only pretend to have a precision that the claim in most cases can't have; e.g. is the US-Canadian Border at 89, 90 or 91 degrees from the US?--Kompakt (talk) 09:32, 23 May 2013 (UTC)[reply]
16 would be OK too. If anybody want to know the azimuth angle between New York and Rome then that anyway can be calculated from the GPS coordinates of both cities. Everything more complex than a GPS-point will have to wait until geo-lines and geo-polygons can be implemented. --Tobias1984 (talk) 09:46, 23 May 2013 (UTC)[reply]
Is everybody Ok with me creating this property with "item"-datatype and 16 possible inputs? The reference system would be geographic and not magnetic. --Tobias1984 (talk) 16:52, 2 June 2013 (UTC)[reply]
I'm OK with the property being created, but I think its label should be changed. Cardinal direction refers to only north, south, east and west. If this properties allows more values than those, its label should not indicate it only allows those four values. Emw (talk) 21:26, 2 June 2013 (UTC)[reply]
Taxon publication year (withdrawn)
Description: The year of the publication.
Datatype: Date (Precision: Year)
Allowed values: 1753 - present year
Infobox parameter example: "1755" for Prunus avium
There is already a property covering that kind of data: publication date (P577). Just see if this can't be used. Snipre(talk) 12:34, 30 May 2013 (UTC)[reply]
I'm not sure. It seems too generic. The property description is "date when this work was published" (or "Date of the publication of the book"), but strictly speaking the taxon description (a work) is not the same as the taxon (which is what the item is about). But maybe it's close enough, I don't know. - Soulkeeper (talk) 14:14, 30 May 2013 (UTC)[reply]
The reason to create it is the same as for ATP player ID (P536) (see old discussion here). The id is appended to the urlhttp://www.wtatennis.com/players/player/. It will make it possible for bots to update data automatically from the WTA website.--Kompakt (talk) 09:44, 30 May 2013 (UTC)[reply]
Support and identifiant can be transfered to Wikidata by my bot if you want. — Hawk-Eye (talk) 13:49, 30 May 2013 (UTC)[reply]
This would be really great!--Kompakt (talk) 07:15, 31 May 2013 (UTC)[reply]
Support - analog to the ATP_id parameter we recently introduced. This IFT parameter leads to more player statistics, and is pretty essential. Edoderoo (talk) 07:32, 31 May 2013 (UTC)[reply]
Comment - Why does en:Heart attack give 3 values in the field eMedicine that redirect to 2 different pages? What is the meaning of that formatting, e.g. "emerg/327"? --Tobias1984 (talk) 07:38, 18 May 2013 (UTC)[reply]
Until maybe one or two years ago, all articles were categorized by specialty and urls were formatted in that way. The old urls will still redirect to the new articles, however some have been merged on emedicine and some articles now have several links to the same emedicine page. Maybe they can be updated with the help of a bot one day.--Wouterstomp (talk) 19:20, 26 May 2013 (UTC)[reply]
I am not sure I understand what your meaning, but we can create items that have no Wikipedia page. --Tobias1984(talk) 20:06, 26 May 2013 (UTC)[reply]
It may be a good idea to look at switching to pubmed health from medline plus. There are slightly better IMO even though both are similar.Doc James (talk · contribs ·email) (if I write on your page reply on mine) 21:20, 1 June 2013 (UTC)[reply]
I think we could do both. Do you want to open a request for pubmed? --Tobias1984 (talk) 22:24, 1 June 2013 (UTC)[reply]
if it is there, it's always notable, because the artwork is notable, so for example the artwork probably influenced another younger artist somewhere who saw it in an exhibition, etc. Though the Mona Lisa was "seen" in print by many artists before travel became easier to do, recording its whereabouts is definitely notable for other reasons (security issues, influences on modern artists or public opinion, art history publications, etc.) --Jane023 (copied from Wikidata:Artworks task force/Properties)
Comment could possibly use a more general property but I cannot think of any (it is distinct from location)--Zolo (talk) 12:55, 31 May 2013 (UTC)[reply]
Code for different levels of territorial units. --Monsieurbecker (talk) 14:50, 12 March 2013 (UTC)[reply]
Support This would be useful. - Ssolbergj (talk) 00:10, 13 March 2013 (UTC)[reply]
Support Documentation above okay. (I changed datatype.) Mange01 (talk) 19:30, 13 March 2013 (UTC)[reply]
Question We probably should distinguish different versions of NUTS: NUTS 1995, NUTS 1999, NUTS 2003, NUTS 2006 and the current NUTS 2010 in order to facilitate the later automatic integration of statistic data. What do you think? --Monsieurbecker (talk) 07:14, 22 March 2013 (UTC)[reply]
Oppose We should name every property as accurate as possible to prevent confusion. If there are really diffrent NUTS versions, we should a.) create multiple properties for every version b.) name it with the version. --Nightwish62 (talk) 21:26, 23 March 2013 (UTC) [reply]
Support, but please let us wait one or two weeks till qualifiers are available. Ok? What we also need is a new generic property 'version' (Data value: String). At moment there is only a property 'stable version' for software. However, I even think this property should be deleted/renamed to 'version' and use qualifiers for 'stable/unstable' status also. --Nightwish62 (talk) 15:19, 30 March 2013 (UTC)[reply]
Question What about the three properties for the ISO 3166-1 country code (Property:P297, Property:P298, Property:P299)? Will they be merged to one property as soon as qualifiers are available? --Monsieurbecker (talk) 06:40, 31 March 2013 (UTC)[reply]
In my opinion they should, yeah. It's the same situation. --Nightwish62 (talk) 08:43, 31 March 2013 (UTC)[reply]
Support once qualifiers are available. James F. (talk) 11:15, 13 April 2013 (UTC)[reply]
with version (example 'NUTS 2010')
Support, perhaps as a temporary solution until qualifiers can be used to differentiate sources, dates and versions of Nuts data from each other.Mange01 (talk) 13:44, 30 March 2013 (UTC)[reply]
Comment, qualifier will released within the next two weeks already. --Nightwish62 (talk) 15:13, 30 March 2013 (UTC)[reply]
All gliders could meaningful be caracterized by (most of) the propertis listed below. It would be nice, if after stating, that a LS4 (Q544661) 'is a' Glider (sailplane) (Q180173) the property-list below pops up for filling in.
Construction and production
Title
ID
Data type
Description
Example
Inverse
role
?
Item
the role(s) the sailplane fills, eg. trainer, acrobatic, touring motor glider, motorglider
<Glaser-Dirks DG-400> role <Motorglider>
–
class
?
Item
the classes the glider type usually competes in, eg. club class, standard class, 15 m class, 18 m class, open class
<Glaser-Dirks DG-400> class <Club class>
–
national origin
?
Item
the country, where the type was constructed or first made
Comment Maybe "type of aircraft" would be better than "role"? At least touring motor glider and motorglider should be "type of aircraft", but "trainer, acrobatic" is something else. I think, it is more what this aircraft is used for. --Goldzahn (talk) 12:49, 14 March 2013 (UTC)[reply]
Support 'role': 'Role' and 'type' can definitely be distinct properties. 'Role' generally indicates a purpose for the aircraft (i.e. what it does) while 'type' is often more a description of its design (i.e. what it is). These obviously can be hazy lines and overlap, but having the property named 'role' seems to give more indication of usage. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)[reply]
Why an opposition ? Here we have different targets for class. Instead of using the same property which will mix different types of association better use an accurate name for the property like plane class Snipre (talk) 20:26, 22 March 2013 (UTC)[reply]
In my view this class is a class in an competition. Similar to "Flyweight" in boxing. --Goldzahn (talk) 10:32, 23 March 2013 (UTC)[reply]
Comment Perhaps change 'class' to 'competition class' to better indicate such intent? Joshbaumgartner (talk) 01:10, 30 April 2013 (UTC)[reply]
Oppose 'national origin' and 'produced period' as proposed. 'National origin' should be changed to 'country of origin', as aircraft are categorized by country, not nation () and 'produced period' should be changed to 'production period' for better English readability. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)[reply]
Support 'role', 'first flight', 'number built', and 'variants' as proposed. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)[reply]
Support 'maiden flight' and 'production period' 87.54.11.4 12:10, 31 May 2013 (UTC)[reply]
This property would be used with the terminus property (which notes the feature at which the item terminates at, like a railway station or intersecting road) to indicate the location of the termini. Initially, this was thought to be able to be handled by a qualifier to the terminus property. Unfortunately, road termini often have several different roads at the terminus intersection; see Oklahoma State Highway 325 as an example, which ends at a traffic circle that five other highways pass through. As a result, the qualifier is in the administrative unit <Boise City> has to be duplicated five times. This property would eliminate the duplication, resulting in a cleaner, more maintainable database. —Scott5114↗[EXACT CHANGE ONLY] 09:28, 30 May 2013 (UTC)[reply]
Support to fix the problem. --Rschen7754 09:38, 30 May 2013 (UTC)[reply]
Support per Rschen7754. TCN7JM 02:49, 6 June 2013 (UTC)[reply]
The Diseases Database is a database that underlies a free website that provides information about the relationships between medical conditions, symptoms, and medications. (From en:Diseases_Database
Code for Ancient buildings and monuments, Ancient traditions, Astonishing human made creations in Iran enumerated by Iran Cultural Heritage, Handcrafts and Tourism Organization
Interesting queries would be possible with this property. Needs a lot of feedback from different branches of science so it we can get the most out of it. For animals there should probably be a separate food chain property. Tobias1984 (talk) 12:36, 10 May 2013 (UTC)[reply]
I think it would be most practical to treat machines and biological organisms separately. Biology is generally much more complex than mechanics. - Soulkeeper (talk) 14:22, 10 May 2013 (UTC)[reply]
SupportQuestion There are several applications for this as a generic energy source data point. Many more specific ones have been proposed, such as 'powerplant' for aircraft or similar ones for ships, etc. Is this intended to cover these, or is it only designed to be the more general basic source, and not the engine for the energy to be made available to the subject? i.e. shouldSupermarine Spitfiresource of energyaviation fuel, or should it be more specific and beSupermarine Spitfiresource of energyRolls-Royce Merlin? I think this is good property and support it, but I do think that it will take some refining in practice to get the best out of it. Joshbaumgartner(talk) 06:51, 13 May 2013 (UTC)[reply]
I was thinking that this property should only be for the fuel and not for the engine, taking your example. It would allow for such queries as "What are all the things that have wind as a source of energy" and return "Windmills, ...". A query for "aviation fuel" would return "Airplanes". For the individual airplanes we should probably be more specific as the Boeing Dreamliner for example also uses batteries as a source of power. --Tobias1984 (talk) 07:19, 13 May 2013 (UTC)[reply]
I am liking this property, and it makes sense to me to think of it as the form of energy that enters a system, vs. how that energy is translated into motive or other force. I am not sure about batteries however, as wouldn't that simply be a way of storing energy that has already entered the system or been created by the system, and be kind of like putting 'fat cells' as a source of energy for 'human'?Joshbaumgartner (talk) 05:33, 16 May 2013 (UTC)[reply]
Support I like this is a generic term which would include solar panels for satellites, nuclear reactors for submarines etc. The misnamed "powerplant" is intended for types of engines? Secretlondon (talk) 14:09, 18 May 2013 (UTC)[reply]
Oppose - Too qualitative, better handled locally. --WDGraham (talk) 00:06, 28 April 2013 (UTC)[reply]
Support - I think queries for satellites powered by RTGs or nuclear reactors would be interesting. --Tobias1984 (talk) 18:39, 30 April 2013 (UTC)[reply]
Comment - Having thought about it, this property could be used for submarines (diesel or nuclear power), cars (as in what kind of fuel, hybrids = Li-battery+fuel), airplanes (kerosine, boeing-dreamliner=Li-batteries and fuel), different toys (AA-battery, AAA-battery), cell phones (Li-battery). --Tobias1984 (talk) 07:08, 6 May 2013 (UTC)[reply]
Will be useful to create list of notable people played in film but not fitting in Property:P161. Could be used for creating list of actors/actresses in text of article. --EugeneZelenko (talk) 14:16, 24 March 2013 (UTC)[reply]
Comment Supporting actors range from bit parts to secondary leads, it's not as clear as on Property:P161 which of them should be named, only walk-on-roles, only "Over-Five"s, ...--CENNOXX (talk) 14:47, 27 March 2013 (UTC)[reply]
Support, with the definition by EugeneZelenko: actors not starring the film. --NaBUru38 (talk) 19:53, 27 March 2013 (UTC)[reply]
Sure, better name for property is possible. --EugeneZelenko (talk) 13:40, 16 April 2013 (UTC)[reply]
I suggest "role" as the name of the qualifier. --Wylve (talk) 16:55, 16 April 2013 (UTC)[reply]
I could suggest "character"? — ΛΧΣ21 00:55, 19 April 2013 (UTC)[reply]
Support such a property, but unsure which name it should have. 'as' could be used outside move/characters also, but I don't know if this is an advantage or disadvantage. --Nightwish62 (talk) 10:22, 19 April 2013 (UTC)[reply]
Support, but with another name (character/role). What if there's not a WP article for that character anyways? --Viscontino (talk) 11:29, 19 April 2013 (UTC)[reply]
In eswiki is more common to use this page instead of IMDB. Filmaffinity is in english and spanish. Most articles in eswiki already have the id and only needs to be imported. Kizar (talk) 14:40, 17 April 2013 (UTC)[reply]
The datatype can be numeric but as no operations or formats are to be applied can be a string.--Kizar (talk) 20:50, 17 April 2013 (UTC)[reply]
Since Property 306 (Operatingsystem) only lists the operating systems the software runs native, but not if the program can be used with Wine and including this information directly to Wikidata wouldn't be a good idea for several reasons (depending on versions and setting, fast changing, good database existing, no need for competition), I would suggest to make it possible to connect Wikidata to this existing Database. MichaelSchoenitzer (talk) 16:09, 18 April 2013 (UTC)[reply]
Support I think we could add Wine as value for the platform property, I think this would be work and be ok. --#Reaper (talk) 14:03, 21 April 2013 (UTC)[reply]
Support main proposal (Wine AppDB-ID). Superm401 - Talk 03:07, 27 May 2013 (UTC)[reply]
сайт NASA, launchlog, карточки в статьях, список запусков и т. д./ NASA's website, launchlog, articles etc
Robot and gadget jobs
Могу настроить бота на проверку значения свойства по какому-либо источнику, например, launchlog-у./I can set up a bot to get the value from any source eg launchlog
Comment I added the en-infobox fields above. -- Docu at 09:58, 27 April 2013 (UTC)[reply]
Comment I changed "spacecrafts" to "spacecraft", the English plural (and singular) form of the word is "spacecraft". Cheers. N2e (talk) 12:45, 27 April 2013 (UTC)[reply]
Comment - How will this support entries where the exact day or time is not known - for example listing something that happened in October 1997 but on an unknown day, something which happened at an unknown time on 15 October 1997, or something that is listed as happening at 16:01 on that date, but the exact second is not known? --WDGraham (talk) 00:05, 28 April 2013 (UTC)[reply]
Support I presume when time is implemented it will handle lack of precision. Secretlondon (talk) 10:08, 6 May 2013 (UTC)[reply]
CommentAdded decay date which use on en: for when a craft re-enters. We need to be careful with sources. Launchlog from Jonathan's space page is a good source, but is it usable? NASA's NSDDC we generally don't think is accurate enough. Secretlondon (talk) 12:27, 27 April 2013 (UTC)[reply]
дата первой стыковки, дата первой расстыковки, дата второй стыковки, дата второй расстыковки и т. д., dates of first and second docking and undocking etc.
Railway stations in post-USSR countries usually have two codes: UNL code (Russian код ЕСР) which used for cargo transportation and Express-3 code which used in pessenger transportation, e.g. in the tickets. For the UNL code we can use property P296, but for second code we need separate property.Ahonc (talk) 10:51, 2 May 2013 (UTC)[reply]
Comment: I expect it's the same data than the UIC station code I suggested above. The 3 Express-3 code I have found, Kiev(2200001) Tashkent (2900001) and Ulan Bator (3100022), share the same pattern : 7 digits beginning with the 2-digit UIC country code. Ske (talk) 12:12, 22 May 2013 (UTC)[reply]
OK, we may merge it with UIC code.--Ahonc (talk) 13:22, 22 May 2013 (UTC)[reply]
No, it's NOT the same. UIC code : Kiev 2232030 ; Tashkent 2972661 and Ulan Bator 3105819. 90.63.14.233 21:09, 23 September 2013 (UTC)[reply]
Official unique code for municipalities in Italy, assigned by national statistic institute. Same as INSEE (Property:P374) for France. β16 - (talk) 21:02, 2 May 2013 (UTC)[reply]
Support Could we use a generic "statistic code" for INSEE, ISTAT, etc.? --Ricordisamoa 11:55, 4 May 2013 (UTC)[reply]
Support Ricordisamoa's proposal, adding a qualifier like "statistic institute" to specify the one that set the code. --Viscontino (talk) 13:22, 5 May 2013 (UTC)[reply]
Support I'm agree to create a general "statistic code" property (with a qualifier property to distinguish between institutions), but until its discussion and approval, it is better to create this property to import the ISTAT code of municipality. --Paperoastro (talk) 13:08, 27 May 2013 (UTC)[reply]
route of administration (Q621636) A route of administration in pharmacology and toxicology is the path by which a drug, fluid, poison, or other substance is taken into the body.
Protein Data Bank (PDB) contains 3D structures of proteins and nucleic acids. This property will provide access to such structures and associated images for the corresponding biological molecule.
Support - important part of the protein infobox. --Tobias1984 (talk) 15:46, 10 June 2013 (UTC)[reply]
Support - though in cases where multiple PDB IDs exist, I think they should be two instances of the same property (rather than concatenating them into a single field.) Andrew Su (talk) 21:47, 10 June 2013 (UTC)[reply]
Comment I changed the proposal so that the two strings are separate. --Tobias1984 (talk) 10:19, 11 June 2013 (UTC)[reply]
Support – The filter however should be made more specific (a four letter code composed of a digit followed by three characters that can be either digits or letters, regex: "[0-9][a-zA-Z0-9]{3}"). Boghog (talk) 16:48, 15 June 2013 (UTC)[reply]
Support It's a useful database with a lot of information (date of birth, date of death, date of Legion of Honour, the resume of a person...) Pyb (talk) 11:37, 14 June 2013 (UTC)[reply]
P425 is meant to work with terms, not people or organizations. -- Docu at 05:56, 26 May 2013 (UTC)[reply]
For sportspeople, we have occupation (P106). For organizations, I would recommend to extend 425 as well, to, say, "field of activity" or something. We will need such a property not only in sports, but for all kinds of different organizations, e.g. companies.--Kompakt (talk) 10:10, 26 May 2013 (UTC)[reply]
Support I think "field of activity" is too broad and would prefer a separate property for sport to make it easier for editors to find the appropriate item. A property for "field of business" or similar can be created for businesses.
If the devs decide that a single property covering both of these would make search queries better then they can create a "subproperty" in phase 3 and define "sport" and "business activity" as subproperties of "field of activity". Filceolaire (talk) 21:35, 6 June 2013 (UTC)[reply]
It would be used also to indicate the discipline practiced for an athlete? For example, Pietro Mennea --> 200 metres. If yes, I'm Support. If not, it's the same ;-) (but something for Pietro Mennea --> 200 metres would be useful). -- Yiyi.... (talk!) 17:26, 16 June 2013 (UTC)[reply]
I'd suggest that sport = 200 metres (Q211155) would work just fine. I've claimed it as a subclass of sprinting, which is a subclass of athletics, and so on. So, the wider sport category can be found. Danrok (talk) 00:32, 17 June 2013 (UTC)[reply]
We need a way to say that X is mayor of village Y for any village. As discussed in Wikidata:Project_chat/Archive/2013/05#Political_offices, putting that in the item about the village iteself does not seem a practical solution. Creating a "mayor of village Y" item for every village does not seem really seem a sensible solution either (unless there is anything specific about the mayor of the village compared to mayors of similar villages). --Zolo (talk) 10:43, 11 May 2013 (UTC)[reply]
Maybe can also be used for captials: (if we are supposed to use "instance of" for that)
Since different kinds of capitals use different names (huvudstad, residensstad, centralort), something who tells what kind of capital is needed. -- Lavallen (block) 10:53, 11 May 2013 (UTC)[reply]
I thought the head of government property is used inverse: Rochefourchathead of local government <Jean-Baptiste Le Moyne de Martigny> – so instead I think the example should be: <Jean-Baptiste Le Moyne de Martigny> office heldmayor of Rochefourchat. Otherwise the proposal looks reasonable. Byrial (talk) 22:46, 12 May 2013 (UTC)[reply]
Support The qualifier seems useful, but meanwhile I see the potential for abuse, perhaps someone would add statements like "<X> occupation <politician> of <United States of America>". I suggest that the qualifier should only be used when the information cannot be stated using other properties. --Stevenliuyi (talk) 18:59, 14 May 2013 (UTC)[reply]
I agree, any idea to make that clear in the label ? --Zolo (talk) 19:43, 14 May 2013 (UTC)[reply]
Okay, adopting this idea would have some serious consequences, so this should be discussed thoroughly before being implemented. Having "of" as a qualifier means that the qualifier property itself isn't really adding any data, so it's basically a way to have a top-level property accept two arguments. If Lavallen's idea about "instance of" "capital" "of" X is used, that would mean that either it or P:P36 is redundant. Re use for mayor, the fact that there are some items like Q785304 complicates it somewhat. There are hundreds of potential uses for this qualifier, but we should examine whether these are generally better than using an alternative solution. Also, we might want to ask the devs whether there are any plans to deploy a proper multi-item/argument property type at any point. --Yair rand (talk) 02:26, 20 May 2013 (UTC)[reply]
Could you elaborate on the "serious consequences". I can sort of see that it seems to stretch the intended use of qualifiers, but still I think it would not really break anything. If X is the mayor Y, he is really an instance of mayor, so that it do not really make statements false.
There does not seem to be any plan for anything like that by the developers in the initial development plan, so if something gets developed, it is unlikely to be this year. --Zolo (talk) 15:44, 18 June 2013 (UTC)[reply]
Support Needed as a qualifier not only for mayors, but for many other functions (<dean> of a <faculty>, <bishop> of a <diocese>, <coach> of a <sports club> etc., as well as for some other properties (e.g. award received (P166) <honorary citizenship> of a <city/country>). On the other hand, I'm quite afraid about using a general <of item> qualifier together with a general <instance of> statement to make a statement of anything. We could help it if we make clear guidance how to use it. Stevenliuyi's idea (see above) of using it only as "ultima ratio" can be a good start, I would propose creating a list of properties which can take <of item> property as a qualifier - in a similar way as we have a list of acceptable values for some properties.--Shlomo (talk) 10:57, 11 June 2013 (UTC)[reply]
Comment As a large contributor to many other external identifiers like Slovakia (Q214), having these connections between the two can make a great bridge to draw other data across. So this could potentially be a boon to our other properties, and means that Wikipedias could include freebase properties. The reason I don't support is because I have to better understand Google's motivations before we start linking with them. Maximilianklein (talk) 19:14, 14 June 2013 (UTC)[reply]