Wikidata:Property proposal/Archive/3

From Wikidata
Jump to navigation Jump to search

Generic / Allgemein / Général

Universal Authority File / Gemeinsame Normdatei / GND

Status:    Done

→ Property:P227

✓ Done as P:P227. — PinkAmpers&(Je vous invite à me parler) 23:14, 6 March 2013 (UTC)


Library of Congress Control Number / Numéro de contrôle de la Bibliothèque du Congrès (LCCN)

Status:    Done

→ Property:P244

Union List of Artist Names (ULAN)

Status:    Done

→ Property:P245

hashtag / hashtag / mot-dièse / OTHERS

  • Description:
  • Infobox parameter:
  • Datatype: StringValue
  • Domain:
  • Allowed values:
  • Source:
  • Use case: for wikipedia: #wikipedia. For the Egyptian Revolution: #jan25 At en:Sina_Weibo#Features you will find, that Weibo uses hastags too. The format is: #HashName#
  • Robot and gadget jobs:
 Comment I like the idea. On the first look this property is even worse than "is a" (since both properties have no controlled vocabulary), but on the other side "hashtag" implies a subjective view. No reader expects "the truth". It's clear, that it's a kind of personal comment and not part of a scientific work. --Kolja21 (talk) 06:09, 12 March 2013 (UTC)
I see this property and its values used by apps, outside of Wikipedia. As you can see here en:Hashtag#Use outside of social networking websites a lot of websites using hashtags. --Goldzahn (talk) 15:34, 12 March 2013 (UTC)
 Support This is a very relevant identifier. Emw (talk) 23:12, 12 March 2013 (UTC)
 Oppose Not mapped to an infobox parameter, and no other simple way of extracting the info from Wikipedia or an external source. Mange01 (talk) 22:05, 13 March 2013 (UTC)
 Oppose Grouping things with one certain value of hashtag is not objective. To stem this one has to predefine a huge list of hashtags by defining: if this and that and this, this item gets the hashtag-value xyz. But these would be redundant to existing properties or to a combination of existing properties. Imagine the hashtag-value #wikipedia this could mark all items with the properties is-a Perso==True + employer==Wikimedia or field of work==Wikipedia etc. This means all entities marked with the same hashtag-value could be retrieved with a specific database query. Such a query is highly subjective thus the hashtag-property cannot be classified as a factual based property.
I thought only item Q52 (Wikipedia) should have hashtag #wikipedia, no one else. Q29198 (Wikimania) would have more hashtags. Google says there are #wikimania and #Wikimania2012. At the moment, I don´t think there is an Infobox using this. For example en:Academic Book Writing Month tells that its hashtag is "#AcBoWriMo" in the lead section. --Goldzahn (talk) 23:14, 14 March 2013 (UTC)
 Oppose useless. --Stryn (talk) 08:52, 16 March 2013 (UTC)
 Support Hashtags are a fact of life on social networks (eg Twitter), which are hugely popular. Just because they're not controlled (being a "folksonomy") and because people often use duplicate tags or make mistakes, doesn't make them useless. They're important in NLP tasks over social news (an important clustering feature for posts, amongst many other features).
Just because currently there's no source that wikidata can load, doesn't mean that a smart NLP researcher can't create such. In the meantime, people can crowd-source them on wikidata. --Vladimir Alexiev (talk) 22:45, 18 December 2014 (UTC)

Authority control / Normdaten / Autorité

BNF

Status:    Done

→ Property:P268

Reference authority control number of th French National Library − relies on the ARK system. Jean-Frédéric (talk) 11:16, 8 March 2013 (UTC)

SUDOC

Status:    Done

→ Property:P269

en:Système universitaire de documentation − Reference authority control number of th French academic libraries. Jean-Frédéric (talk) 11:16, 8 March 2013 (UTC)

CALIS

Status:    Done

→ Property:P270

--Stevenliuyi (talk) 18:53, 8 March 2013 (UTC)

CiNii

Status:    Done

→ Property:P271

  • Description: authority records of CiNii (Scholarly and Academic Information Navigator, pronounced like "sigh-knee")
  • Infobox parameter: ja:Template:Normdaten
  • Datatype: StringValue
  • Link: http://ci.nii.ac.jp
 Support Not part of VIAF. --Kolja21 (talk) 05:01, 9 March 2013 (UTC)
 Support it is issued by National Institute of Informatics, an authoritative source, and covers many scholars based in Japan and other parts of the world. See http://ci.nii.ac.jp/author/DA0040532X (Noam Chomsky) for example. --whym (talk) 12:03, 9 March 2013 (UTC)
 Support --Jarekt (talk) 02:02, 10 March 2013 (UTC)


Person / Person / Personne

Virtual International Authority File / VIAF / Fichier d'autorité international virtuel

Status:    Done

→ Property:P214

  • Description: Meta authority file (collection of GND, LCCN, BnF etc.)
  • Datatype: StringValue
  • Link: http://viaf.org/viaf/...
  • Infobox parameter example : See above
  • Infobox parameter example:
  • Comments: Not as up-to-date and reliable as the original authority files, but very useful. --Kolja21 (talk) 21:45, 31 January 2013 (UTC)
    About datatype, it should be StringValue or a custom datatype for links to authority files. I'll talk to Denny if it's possible to implement a such datatype in Wikibase quickly. Tpt (talk) 15:50, 1 February 2013 (UTC)
    User:Denny answers me that the StringValue type should allow in the future validation of the content using a regex and output of an URI. So, we could use the StringValue type. Tpt (talk) 17:36, 1 February 2013 (UTC)
    What does that mean? Will it be possible to enter the VIAF no. "89798474" and the field is adding the link: [1]? That's would have two advantages: 1. We can easily use the number for the templates (import/export). 2. If the general link is changing, we just need to adapt it once.--Kolja21 (talk) 18:17, 1 February 2013 (UTC)
    Yes, you enter the numerical id in the field and the UI shows this id with a link to VIAF. It is like the authority template (you input an id and the template output a link). Tpt (talk) 18:58, 1 February 2013 (UTC)

International Standard Name Identifier (ISNI)

Status:    Done

→ Property:P213

 Support --ThorstenX1 (talk) 11:33, 11 February 2013 (UTC)
 Support --Viscontino talk 17:00, 14 February 2013 (UTC)
 Support Tpt (talk) 17:03, 14 February 2013 (UTC)

included

Unclear. Infobox parameter example missing. --Kolja21 (talk) 19:46, 19 February 2013 (UTC)
  • I can see the value of this property in scenarios like yours, and also to attach an article like "List of Season 1 Foo [television] episodes" to the television show item itself. And numerous other examples I can't think of right now. However, I think it needs a more descriptive name: "Subtopic of"? But that could be used very broadly (which actually might not be a bad thing). Espeso (talk) 19:52, 22 February 2013 (UTC)

Successor / Nachfolger / successeur

 Question I also thought about predecessor and successor, but then I thought, that this should be a feature of lists of phase 3. Are lists of phase 3 ordered? If yes, it would be possible to model these kind of properties. --Faux (talk) 18:38, 18 February 2013 (UTC)
Well Phase II is for collecting data and properties for infoboxes and the predecessor/successor fields are used in many infoboxes so we don't need to wait for Phase III before creating and using these properties. I have no idea when qualifiers will be available, but lots of existing properties need qualifiers too. /Ch1902 (talk) 11:51, 19 February 2013 (UTC)
This is not a property but a qualifier: so a property like office hold will have 4 qualifiers instead of 3 properties with 4 qualifiers. Snipre (talk) 12:18, 19 February 2013 (UTC)
I see, just so I understand properly, do you mean, for example, Queen Victoria would have one property (offices held) with two values (Queen of the United Kingdom and Empress of India) and those two values have one qualifier each (succeeded by Edward VII)? That makes sense now, but what about the more complex case where a person holds an office more than once in non-consecutive terms (e.g. Edward IV or Vladimir Putin), wouldn't that need a qualifier to the qualifier (succeeded by X, first time, succeeded by Y, second time) assuming that office held also has qualifiers saying when it was held? So isn't it easier to have a successor property with two qualifiers of who and when? /Ch1902 (talk) 15:15, 19 February 2013 (UTC)
Just repeat the statement with the same property but with different qualifiers. I assume it is possible to add several times the same property. Snipre (talk) 14:14, 20 February 2013 (UTC)
Exactly. (Office held) twice, each with qualifiers (Preceded by), (Succeeded by), (From date), (To date). Filceolaire (talk) 22:05, 24 February 2013 (UTC)
OK then. On a related note, taking monarchy/nobles in particular is office held really suitable? Office held: King, Office held: Prince of Orange don't sound right since they aren't electable positions. I asked for comments here but would like some more input before I take the property to RFD. /Ch1902 (talk) 11:06, 25 February 2013 (UTC)
Also against, having a property for each person will create a conflict when the person hold two office, like a deputy and a primer. We need a more complex model. Guillcote (talk) 20:53, 5 March 2013 (UTC)

Predecessor / Vorgänger / prédécesseur

Racing championships

I don't think something like this can be implemented as data type: Item. Not at this point in time. Danrok (talk) 19:03, 25 February 2013 (UTC)
Well, it's possible I'm misthinking what the datatype should be, so I've changed it to "?". Basically you would put "champion" in the first 'statements' box, then "(year) (series)" in the second? - The Bushranger (talk) 19:17, 25 February 2013 (UTC)
Right now the only data type we can create is Item. So, this and many other properties (e.g. date of birth) can't be created until new data types are in place. Danrok (talk) 19:40, 25 February 2013 (UTC)
Correction: Data types: Item and commons media are they only usable types right now. Danrok (talk) 19:43, 25 February 2013 (UTC)
    • The value could be the championship itself, like 2012 Formula One season. But I think that the results should be applied to the championship, not the driver / team. --NaBUru38 (talk) 23:08, 25 February 2013 (UTC)

Official residence / Amtssitz / résidence officielle

Status:    Done

→ Property:P263

 Support--Shawn in Montreal (talk) 00:56, 2 March 2013 (UTC)

 Support Danrok (talk) 22:40, 5 March 2013 (UTC)
✓ Done, Property:P263. Four supports (w/me), about one week old. Espeso (talk) 04:36, 9 March 2013 (UTC)

Monuments

Monuments
Monuments erected, buildings, streets named, etc., in honour of the subject.
Type: item

 Comment keep in mind that things named for people already exist, too: Property:P138. Shawn in Montreal (talk) 19:25, 1 March 2013 (UTC)

Member of learned society

See also #Post-nominals
  • Description: learned society (such as National Academy of Sciences, Royal Society, etc.) memberships that a person holds
  • Datatype: Item
  • Links:
  • Domain: Person
  • Infobox parameter example:
  • Comments: property used by biographical infoboxes for academics--Stevenliuyi (talk) 18:35, 5 February 2013 (UTC)
    This should probably be more complex - for example, being a Member of the Royal Institution isn't the same as being a Fellow - so really you want to link to <Fellow of the Royal Institution> rather than <Royal Institution> elements. Maybe call it "has learnèd society membership" and make this clear in the description?James F. (talk) 20:51, 5 February 2013 (UTC)
Yes. The problem is that usually we don't have items labelled <Fellow of XXX>, shall we create new items to deal with this situation? (if so WD:N should also be changed) --Stevenliuyi (talk) 13:02, 8 February 2013 (UTC)
I think we will need to create them, yes, much the same as for the British Honours system (there are normally articles like <Order of the Bath> rather than<Knight Commander of the Order of the Bath>). Of course, we'd also want to use qualifiers to give the date that it was awarded (and/or removed?) and so on.James F. (talk) 18:38, 8 February 2013 (UTC)
Needs Qualifiers Grade of membership and From date. Where the person has achieved various grades of membership over the years then (Member of learned society) will appear more than once for the same society. Filceolaire (talk) 21:44, 24 February 2013 (UTC)
  •  Comment I see that Fellows of the Royal Society, for one, use the post-nominal "FRS" after their names. So in cases like that, it's covered by the proposal for post-nominals, elsewhere on this page. Shawn in Montreal (talk) 14:00, 27 February 2013 (UTC)
  •  Comment I would support a more general property "Member of society/order" which would encompass learned societies, military/civil orders, and religious orders, since these things tend to be structured similarly. Also agree with User:Filceolaire that qualifier for rank would be needed. As an example of each type: the Royal Society has two ranks, Fellow and President, with different post-nominal initials; the Légion d'honneur has six ranks; and the Order of Saint Benedict has one rank (?) with post-nominal initials. --OldakQuill (talk) 17:48, 6 March 2013 (UTC)
  •  Oppose -- unnecessarily specific (and contains a value judgment). Whether the thing that a person is a member of is "learned" does not need to be exposed in the property name. See my proposal for "member of" under "generic" at the top of this page. Espeso (talk) 15:34, 8 March 2013 (UTC)

Organization / Organisation / Organisation

Business divisions

Status:    Done

→ Property:P199

✓ Done as Property:P199. Danrok (talk) 22:44, 5 March 2013 (UTC)

Chairman

  • Description: The owner of the athletic club
  • Datatype: Item
  • Source: Official website or reliable third party sources
  • Domain: People
  • Infobox parameter: en:template:Infobox football club: chairman
  • Comments:

en:Chairman says "highest officer of an organized group". In my view, an owner is something different than a chairman. By the way, there is also the term "Chairwoman" (Im not a nativ english speaking person) Wiktionary says hypernyms are for example: chair and chairperson. --Goldzahn (talk) 13:29, 23 February 2013 (UTC)

  • According to the "terminology" section of en:Chairman, the chairman can often be the "CEO". Unless this is some term specific to association football (soccer), I'd recommend an owner field and a CEO field for all industries, not just sports, with these discussions moved out of Sports on this proposal page. Shawn in Montreal (talk) 14:52, 23 February 2013 (UTC)
By the way, Property:P165 ("the legal owner of the entity") could be used for athletic clubs too. Thefor, I would say this proposal is already done.--Goldzahn (talk) 10:57, 28 February 2013 (UTC)
Chairman and CEO are two different roles. I think they should be two properties. Danrok (talk) 23:07, 3 March 2013 (UTC)
They are often two different roles, I would agree. --Shawn in Montreal (talk) 23:14, 3 March 2013 (UTC)


IATA airline designator

Status:    Done

→ Property:P229

✓ Done as P:P229. — PinkAmpers&(Je vous invite à me parler) 23:14, 6 March 2013 (UTC)

ICAO airline designator

Status:    Done

→ Property:P230

✓ Done as P:P230. — PinkAmpers&(Je vous invite à me parler) 23:14, 6 March 2013 (UTC)

Military branch / Teilstreitkraft / Branche militaire

Status:    Done

→ Property:P241

  • Description: Unit is part of military branch (e.g. Carrier Strike Group Three is part of Navy)
  • Datatype: Item
  • Infobox parameter example: {{:en:Template:Infobox military unit}} field branch
  • Comments:
  •  Support badly needed, as are a great many military related fields, I'm sure. Shawn in Montreal (talk) 15:29, 5 March 2013 (UTC)
✓ Done added as Property:P241. Danrok (talk) 11:07, 7 March 2013 (UTC)

ticker symbol

Status:    Done

→ Property:P249

  • Description: A stock symbol or ticker symbol is an abbreviation used to uniquely identify publicly traded shares of a particular stock on a particular stock market.
  • Datatype: String
  • Links:
  • Infobox parameter example: en:Template:Infobox company
  • Comments: Value MSFT would be for Microsoft. Danrok (talk) 16:59, 24 February 2013 (UTC)
 Comment Is datatype item correct? Or should that be datatype string? --Goldzahn (talk) 17:20, 24 February 2013 (UTC)
Yes, string. Thanks! Danrok (talk) 19:41, 24 February 2013 (UTC)
Should this be a url of some type? Filceolaire (talk) 22:54, 24 February 2013 (UTC)
I don't think so, but the code could be used to build a URL, such as http://www.nasdaq.com/symbol/msft. We would also need a item for market (e.g. NASDAQ). Danrok (talk) 23:25, 24 February 2013 (UTC)
  •  Support Sven Manguard Wha? 04:56, 26 February 2013 (UTC)
  • support as string. Wrapping it in a URL to {wherever} is up to the person using the data. The "source" field for the ticker symbol could be a link to the most relevant exchange's page for the ticker, which would be the convenience link. Espeso (talk) 20:50, 26 February 2013 (UTC)
    Qualifer required: ticker symbol and stock exchange are a package. If there were two properties, one for each, and a company was listed on two or three markets, you wouldn't be able to determine from the data which symbol went with which market. As such ticker needs to be a qualifier of market, or vice versa. Then the question is, do qualifiers support "item" property types? If so, I would make symbol the property and exchange/market the qualifier. Espeso (talk) 04:01, 2 March 2013 (UTC)
✓ Done as string Property:P249. Danrok (talk) 16:05, 8 March 2013 (UTC)

Party chief

Status:    Done

→ Property:P210

  • ✓ Done as "Communist Party Secretary" in Property:P210. I am not quite sure about the scope (individualize by country ? Extend to non-communist countries ?) but that should not be very difficult to change later on. --Zolo (talk) 09:17, 6 March 2013 (UTC)
Perhaps we should use the lowercase "communist party" instead of the uppercase, 'cause some communist parties have other names, such as Lao People's Revolutionary Party. --Stevenliuyi (talk) 10:06, 6 March 2013 (UTC)
Right, done. I was hesitating but it probably makes more sense. --Zolo (talk) 11:27, 6 March 2013 (UTC)
It should not be very difficult to change later? Wikidata has 286 languages. I really would be nice, if we first do the basic work. Translating this property and use it - and then thinking about the scope and a label that fits is pretty frustrating. The en:Template:Infobox settlement has a parameter "leader_name". In the article en:Peking University there is no "Zhu Shanlu". The property is listed under "organization", but Beijing is not a company. --Kolja21 (talk) 13:23, 6 March 2013 (UTC)
There may be no way to know right now whether it is better to have the same property for China and Vietnam, or two separate properties. Practice will tell. What I mean is that it should not be difficult for a bot to split this property into contry-specific ones, or to merge it with another. Obviously, we cannot get everything right from the beginning and some translations will have to be done anew.
There is no "party chief" property in en:Peking University but there is one one in en:Beijing. We can't use "leader" because Beijing has both a mayor and a party chief, Peking University, both a president and a party chief. --Zolo (talk) 14:10, 6 March 2013 (UTC)

If we want to make it as general as possible, which seems to be the current trend, it would probably be "chief representative of the ruling party". I think the communist case is by far the most important, but there has probably been others, at least it is certainly a logical possibility. Should I change the to that ? --Zolo (talk) 19:21, 6 March 2013 (UTC)

Sounds reasonable: it's close to the use in the infoboxes ("leader_name"). Since the property is in use already, we have to decide if we should delete labels like 党委书记 (something like "party secretery"?) or leave a note to the editors. --Kolja21 (talk) 01:51, 7 March 2013 (UTC)
Ok, yes it is probably better to leave a note to the editors, are there are not yet many. I wish I could find a more concise label, but I cannot think of any. --Zolo (talk) 09:28, 7 March 2013 (UTC)
There is another way to generalize it. If we adopt "chief representative of the ruling party", we can improve the flexibility on one side, but also have more restrictions (only ruling parties are allowed) on the other side. This may cause other issues. For example, the Communist Party of China had party chief positions long before it became the ruling party of China.
In contrast, another way to generalize is to allow all communist parties, whether it's a ruling party or not. The advantage is that there are many coummunist parties are/were not ruling parties, but they all have very similar party chief positions (all influenced by the "секретарь парткома" of the Communist Party of the Soviet Union). --Stevenliuyi (talk) 09:31, 7 March 2013 (UTC)
Thre are at least different two meanings to "party chief".
  1. the chairman or president of a party, for instance, the president of the US Democratic Party, and also the Secretary of the Chinese Communist Party.
  2. the main representative of a party in another institution.
I think this property should only be used for case 2, and that property makes most sense when the party is in power or has an official status. But there may be other cases as well. Case 1 seems to me to be essentially the same thing as the chairman of a company or any other institution. --Zolo (talk) 06:52, 8 March 2013 (UTC)
Yes, case 2 is what I mean. What I said is that appointing chief representatives to other institutions is a common practice of all communist parties, ruling or not. So "chief representative of the ruling party" can't handle situations that the party is not a ruling party. Perhaps we can just use "party chief representative", and use a qualifier to identify the party, e.g. Beijing <party chief representative> Guo Jinlong (qualifier: Communist Party of China). --Stevenliuyi (talk) 10:05, 8 March 2013 (UTC)
That could be a solution, though we will need to check that people do not use it for case 1. If we do it this way, I would rather wait until qualifiers are available. It makes it at least theoretically possible to have several parties, and even several competing communist parties with a chief representative in the same organisation, which would make the property rather ambiguous. --Zolo (talk) 10:15, 8 March 2013 (UTC)
Yes, I agree. We should wait qualifiers if we adopt this approach. --Stevenliuyi (talk) 12:30, 8 March 2013 (UTC)
Ok, should I temporarily delete it to acoid confusion ? I guess Kolja was right that I was a bit hasty here ;). --Zolo (talk) 12:39, 8 March 2013 (UTC)
Sure. It seems reasonable. --Stevenliuyi (talk) 18:48, 8 March 2013 (UTC)
Deleted. --Zolo (talk) 09:26, 9 March 2013 (UTC)

Classical economic sector

  • Description: the classical sector to which this organization belongs; primary, secondary, or tertiary.
  • Datatype: Item
  • Links: See Economic sector and Three-sector hypothesis.
  • Infobox parameter example:
  • Comments: Simple enough by the look of it. Danrok (talk) 09:04, 1 March 2013 (UTC)
  •  Oppose grouping organizations by this particular hypothesis. While we do have an article by this name in English Wikipedia, it is not a category structure, indicating that it is not considered to be sufficiently defining. We very much need to be able to group organizations by type, however, and it is where I think we should begin. Shawn in Montreal (talk) 19:33, 1 March 2013 (UTC)
  • I  Oppose the proposal, but  Support a more specific criteria. So Microsoft is a computer company, Volkswagen an automobile company, and Pixar a film company. Of course, we would need to discuss the list of valid sectors. But the good thing is that we can include several to an organization. So for example Apple can be a software, hardware and electronics company. --NaBUru38 (talk) 20:42, 1 March 2013 (UTC)
    • en:Category:Organizations by type has a lot of options, and of course, we need remember that "organizations" include non-profit and government agencies, etc. NaBUru38, would our property for "Field of work" not cover things like "hardware and electronics", allowing us to be a little more focused on the type of organization rather than the market or product? Shawn in Montreal ***Shawn, the proposal is called "classical economic sector" and mentions primary, secondary and tertiary. That's very different from type of organization (government, non-profit, company). I agree that "field of work" sound similar. --NaBUru38 (talk) 18:37, 8 March 2013 (UTC)
  •  CommentI have found this, North American Industry Classification System, which is a list/database of official codes for industries, millions of them by the look of it. Danrok (talk) 21:43, 1 March 2013 (UTC)

Manager

Status:    Done

→ Property:P286

  • Description: The person who manages the team
  • Datatype: Item
  • Source: Official website or reliable third party sources
  • Domain: People
  • Infobox parameter: en:template:Infobox football club: manager
  • Comments:
  • In this usage, "manager" of an association football team is synonymous with en:Manager (baseball). However in some other sports it's called a en:Head coach, and as that article states in the lead, apparently a "senior coach" in Australian rules football. Could we have a single property name that could be applied to all sports? Shawn in Montreal (talk) 14:59, 23 February 2013 (UTC)
 Comment I'd suggest that a generic field called say "managed by" would work for sports clubs, and would also work with other entities. Some cities have city managers, for example. Danrok (talk) 19:49, 25 February 2013 (UTC)
I don't think so, Danrok, as there is also en:General_manager#Sports_teams, a higher level position in many North American sports leagues, that might be closer (but still different) from the sort of city manager you mean. Anyway, I think this is all quite doable, we'd just need one for head coach/manager for the onfield operations, general manager, then CEO, owner, etc. as per all such company templates. Shawn in Montreal (talk) 19:55, 25 February 2013 (UTC)
 Support as a specific type of manager, not for all organisations. Danrok (talk) 23:47, 28 February 2013 (UTC)
 Support a head coach/manager property. Other forms of "manager" to be dealt with separately, as per above.Shawn in Montreal (talk) 22:42, 3 March 2013 (UTC)
 Support --Fawkes d 18:03, 10 March 2013 (UTC)
✓ Done created as Property:P286. Danrok (talk) 13:28, 13 March 2013 (UTC)

Coach / Trainer / Entraîneur

Status:    Done

→ Property:P286

 Support --Viscontino talk 17:08, 14 February 2013 (UTC)
This will be done with Qualifiers attached to the Property, when these are implemented (From date), (To date). Filceolaire (talk) 23:03, 24 February 2013 (UTC)

 Comment We'd need to be clear that this is for head coach or manager, not just "coach," of which there may be many on a team. Shawn in Montreal (talk) 16:43, 27 February 2013 (UTC)

 Comment the infobox label is manager. Is coach the exact same thing? Danrok (talk) 17:33, 27 February 2013 (UTC)
Head coach is a much more precise match, and less likely to be misused, imo. The "trainer" part worries me. On sports teams they are fairly low level positions, often, helping athletes in some cases with fairly menial things. Shawn in Montreal (talk) 17:48, 27 February 2013 (UTC)
Don't worry about the "trainer" part, that's just the German translation for "coach". --Carport (talk) 17:28, 8 March 2013 (UTC)
Coach can be personal coach or coach of sports team. Head coach can't be personal coach I think. --Stryn (talk) 09:54, 28 February 2013 (UTC)
 Comment note that an identical proposal is being discussed above, as "manager." Shawn in Montreal (talk) 22:44, 3 March 2013 (UTC)

 Support As head coach. Maybe a property "assistant coach" could also be added? --Carport (talk) 17:28, 8 March 2013 (UTC)

 Support --Fawkes d 18:32, 12 March 2013 (UTC)

Frequent-flyer program / Vielflieger-Programm / ...

Notable Accidents

Livery

 Comment Perhaps it would be useful to have another item for "livery colour"? Multiple coulors could be specified, e.g. red, blue. Danrok (talk) 19:39, 24 February 2013 (UTC)
 Oppose If this is supposed to simply be an image showing one of the airline's aircraft, then I think the existing "image" statement is sufficient. After all, the "logo image" statement exists, so the "image" statement will presumably always be available. - Ssolbergj (talk) 00:28, 2 March 2013 (UTC

Event / Veranstaltung / Évènement

Member of series / Mitglied der Reihe / Membre de la série

  • Description: An instance of a regular/recurring series of events (e.g. 2008 Summer Olympics is a member of series Summer Olympics; 2008 US presidential election is a member of series US presidential elections)
  • Datatype: Item
  • Links:
  • Domain: events
  • Infobox parameter example:
  • Comments:
  •  Comment. Are you aware of the existing property "series"? It is generic, and I think that's good. It could be used to relate specific instances of an event to the recurring event, relate episodes (with articles!) of television shows to the television show entry, and so on. As such I oppose the addition of this very similar new property. Renaming "series" as "member of series" might be a good idea, though. Espeso (talk) 18:46, 4 March 2013 (UTC)

Creative work / Werk / Œuvre créative

Art / Kunst / Art

Creator

Status:    Done

→ Property:P170

  • Description: creator of a work of art (e.g. painting, sculpture)
  • Datatype: item
  • Links: getty
  • Domain: Painting, sculpture, other works of art
  • Infobox parameter example: commons:Template:Creator
  • Comments: Aude (talk) 18:36, 8 February 2013 (UTC)
    • Support, as long as it's restricted to works of equal members. Films and plays should get actors / directos / producers, songs should get vocalists / guiterrists / painists / drummers / etc. --NaBUru38 (talk) 21:35, 8 February 2013 (UTC)
      • We should chose a unique name. For Commons "creator" is o.k. But Wikidata has already other creators like: author, composer, librettist, screenwriter, architect etc. --Kolja21 (talk) 00:14, 13 February 2013 (UTC)
      • There seem to be so many kinds of creators that can participate in a work. Think of "engraving by XX of a painting by Delcroix after Titian", or look for "Design and construction" at en:Burj_Khalifa. I would think the best solution would be to have just one property:Creator, and many qualifiers. BUt it may not be the most intuitive for an occasional user. --Zolo (talk) 11:19, 14 February 2013 (UTC)
        • Agree about having more specific properties (director, author, etc.) but think it also helps to have a more generic property that can cover other works. Aude (talk) 03:03, 15 February 2013 (UTC)
 Support for use with artists - creators of paintings, sculpture. Danrok (talk) 22:33, 27 February 2013 (UTC)

Ok, I will create it. Do I call it creator ? I think it is the best solution, as anyhow, other people like "author" or "pianist" may be considered subsets of "creator. We can also use "artist", but it is not as neutral, and may not be always relevant. --19:51, 28 February 2013 (UTC)~

✓ Done as Property:P170. Espeso (talk) 06:47, 1 March 2013 (UTC)

Meant for artists and should be called "artist" (Property talk:P170). --Kolja21 (talk) 00:53, 2 March 2013 (UTC)

Accession number

Status:    Done

→ Property:P217

  • Description: a string that identifies an object within a museum's collection
  • Datatype: string
  • Links:
  • Domain: museal objects
  • Infobox parameter example:
  • Comments: used by most museums, although some use a different name
✓ Done as "inventory number". It is not the most common way to call it in English but it is a correct, more general term very commonly used in other languages. --Zolo (talk) 21:10, 6 March 2013 (UTC)

Written works

International Standard Book Number / ISBN / ISBN

Status:    Done

→ Property:P212

  • Description: Numeric commercial book identifier, used since the 70s
  • Datatype: StringValue
  • Link:
  • Infobox parameter example :
  • Comments: Is it ok, if we just use ISBN-13 (ISBN Online Converter)?
    •  Support Definitely needed. I think we should use either ISBN-10 or ISBN-13, whichever one the work was originally issued in, because the software can handle it either way. But that's just me.
    • The data type should not be StrinValue, but ExternalID, with an appropriate pattern for validating, and a pattern for building URIs. That type is not in the spec (yet), but we'll get it before we'll get free text, I think. -- Duesentrieb (talk) 13:43, 8 February 2013 (UTC)
    • Support. --NaBUru38 (talk) 21:38, 8 February 2013 (UTC)
    • Support, but there will normally be multiple ISBNs for a book, and in most cases all of them will be given in any library metadata we use. Not just is there the ISBN-13 vs ISBN-10 question, but there are different ISBNs for paperback vs hardback, or for any different format under which the book is sold (this is in original bookseller's number, not a library number, though libraries use it as well.) There is in my opinion no simple solution here. (in enWP, there seems to be no standard practice. I note that in searching a library catalog, any ISBN is enough to retrieve the record,since libraries include all the ones possible.) DGG (talk) 16:22, 15 February 2013 (UTC)
      • As DGG says: moreover, there will be another ISBN for the ebook. I think we should use it just when we are referring to a particular edition, but avoid it when unnecessary. (it's gonna be complicated). --Aubrey (talk) 20:18, 16 February 2013 (UTC)
      • Can't we just store as many of a work's (or edition's) ISBNs as we can find? It doesn't seem that complicated to me, but maybe I'm missing something. --Avenue (talk) 17:33, 17 February 2013 (UTC)
        • Page 25 from one edition does not have to be the same p. 25 from an other. So it's important that we add the correct ISBN. (In many countries the paper back edition is different from the hard cover edition.) --Kolja21 (talk) 01:07, 18 February 2013 (UTC)

ISSN/International Standard Serial Number

Status:    Done

→ Property:P236

 Support --Aubrey (talk) 09:32, 19 February 2013 (UTC)
ISSNs and ISBNs have been to some extent combined and superseded by EANs. How should we treat this? Filceolaire (talk) 23:15, 24 February 2013 (UTC)
IMHO, ISBN and ISSN are very common and easy to find. They would be my first choice for an identifier. I'd add every identifier available, if needed and informative. Maybe we can have directly a repeatable property called "identifier" and different qualifiers called ISBN, ISSN, etc. Not sure how to implement it though. --Aubrey (talk) 07:28, 25 February 2013 (UTC)
ISBNs are now a subset of EANs. However, I can't imagine many circumstances in which we would be using EANs - they're very much "product codes". ISSN has not been merged into the EAN system as far as I understand it. Andrew Gray (talk) 23:27, 6 March 2013 (UTC)

 Support Shawn in Montreal (talk) 22:47, 3 March 2013 (UTC)

OCLC/Online Computer Library Center Control Number

Status:    Done

→ Property:P243

  • Description: Numeric book identifier, similar to ISBN but withou date restriction, and aggreates above the edition level.
  • Datatype: StringValue
  • Link: Official site
  • Infobox parameter example : en:Template:OCLC English example
  • Infobox parameter example:
  • Comments: this is needed, because most older books before about 1970 do not have ISBNs. Any book cataloged in the US will however have an OCLC number. The problem remains of how to handle books not cataloged there. DGG (talk) 16:28, 15 February 2013 (UTC)

 Support --Aubrey (talk) 09:31, 19 February 2013 (UTC)

License

Status:    Done

→ Property:P275

 Support I guess it could be useful, don't see a reason why not to have it. Regards, — Moe Epsilon 20:32, 28 February 2013 (UTC)
 Support Danrok (talk) 23:46, 28 February 2013 (UTC)
 Support Shawn in Montreal (talk) 22:43, 3 March 2013 (UTC)
 Comment Nothing against the property itself, but it should like to mainstream items, that refer to real contents, not to items like Q3910767 and Q2013 that just gather links to the Wikipedia and template namespaces. --Zolo (talk) 16:41, 4 March 2013 (UTC)
I  Support the property but I strongly  Oppose linking to Q3910767 (en:Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License) and similar. Instead we should create an item for each Creative Commons-license (7 items) and use them, then we can do Q14579 (Linux) <licensed under> Q7603 (GNU General Public License). So it would be consistent. We have items for all relevant licenses, only for the different CC-licenses there are not different items yet. -- MichaelSchoenitzer (talk) 15:12, 9 March 2013 (UTC)
I strongly agree with MichaelSchoenitzer. --Ricordisamoa 15:15, 10 March 2013 (UTC)
 Comment I've also proposed the creation of those seven items at Wikidata talk:Notability. Please comment, I'd like to create them soon and start to using them. -- MichaelSchoenitzer (talk) 21:30, 11 March 2013 (UTC)
 Support, but I'm not sure I understand its scope. The description says "content", but MichaelSchoenitzer suggests using it for software, which I wouldn't usually class as content. I wouldn't object to using it that way, but then I think the description should be revised. Are we just talking about copyright licenses (i.e. not about trademarks or other rights)? I'd also quibble about the word "organization", since much content is produced by individuals, or at least unorganised groups of individuals (Wikipedia being a good example). Would this be a better description: "License under which this copyrighted work is released"? --Avenue (talk) 03:30, 12 March 2013 (UTC)
You're right that description would be clearer. Since there are a lot of Pros and none Cons here and the items for the CC-licenses have been created recently, I'm going to create the Property. -- MichaelSchoenitzer (talk) 11:29, 12 March 2013 (UTC)

✓ Done Created. -- section can be archived. Please help translating the property name & description. -- MichaelSchoenitzer (talk) 11:46, 12 March 2013 (UTC)

Place of publication / Erscheinungsort / Lieu de publication

Status:    Done

→ Property:P291

Musik

Label (record)

Status:    Done

→ Property:P264


Film

Production company

Status:    Done

→ Property:P272

  • Description: Company or companies that are credited as having produced a film (not to be confused with people who serve in the role of "producers")
  • Datatype: Item
  • Source:
  • Domain: Organizations
  • Infobox parameter: en:Template:Infobox film (studio)
  • Comments: As a member of the Film WikiProject, I'd been meaning for some time propose a change to the "Studio" field in the infoxbox, to "Production company." "Studio" is an ambiguous and inaccurate term. Ambiguous, because as en:Film studio states, "Film studio" can refer both to a "major Entertainment Company or Motion Picture Company" that historically has owned its own studio spaces -- in other words, like "Hollywood" itself, a en:metonym -- or it can simply refer to "studio facilities, who have never produced a motion picture of their own." en:Production company (though in need of references) is both more precise and encompassing: "production company provides the physical basis for works in the realms of the performing arts, new media art, film, television, radio, and video." And as one can see, has the advantage of being used not just for works of cinema. It also reflects the fact that a great many films in this day and age are not made by the "major studios." We are in an age of independent cinema and small production companies that cannot be called "studios" are also making a great many more films. Some might wish to preserve Studio as a separate field in cases where a film has been made by a recognized "studio." I have no take on the viability of that but would not be opposed. thank you, Shawn in Montreal (talk) 15:37, 22 February 2013 (UTC)

 Support Could be used for broadcasting as well. --Kolja21 (talk) 20:08, 22 February 2013 (UTC)

Good point, yes, I see that en:Template:Infobox television already lists it merely as "company", which displays in the template as "Production company(s)." Whereas on the cinema side of things we're forced to mis-identify an indie film house like en:EyeSteelFilm -- to choose an example from my hometown -- as a "studio" if we wish to list it in film infoboxes for its productions. Shawn in Montreal (talk) 20:56, 22 February 2013 (UTC)
 Support Danrok (talk) 19:33, 24 February 2013 (UTC)
 Support, and let's use it for all works that have production companies. --NaBUru38 (talk) 23:25, 25 February 2013 (UTC)


Term / Sachbegriff / Terme

Products

Designer / Designer / ...

Status:    Done

→ Property:P287

✓ Done Property:P287 --Goldzahn (talk) 00:45, 14 March 2013 (UTC)

Astronomical objects

Stellar classification

Status:    Done

→ Property:P215

 Support --Paperoastro (talk) 14:57, 8 February 2013 (UTC)
 Support -- MichaelSchoenitzer (talk) 01:19, 9 February 2013 (UTC)
Could we limit this to a regex (like /[OBAFGKM][0-9](I|II|III|IV|V)/) or some kind of semantic way of specifying this? I guess a string would be okay, but you could also set the value to "jndjkvndfjkv". πr2 (t • c) 16:37, 9 February 2013 (UTC)
 Comment It is a good idea, but I don't know if it is technically possible. --Paperoastro (talk) 00:41, 14 February 2013 (UTC)

Galaxy morphological type

Status:    Done

→ Property:P223

 Comment We should be restrictive to string types, so please do not create them as fast. Is the allowed values a limited set - meaning that we can create items for each of them? Mange01 (talk) 02:21, 7 March 2013 (UTC)

Minor-planet group

Status:    Done

→ Property:P196

✓ Done as P196 Inductiveload (talk) 23:42, 6 March 2013 (UTC)

Type of astronomical object / Astronomisches Objekt / Objet céleste

Status:    Done

→ Property:P60

 Support Useful, see en:Astronomical object. --Kolja21 (talk) 01:12, 2 March 2013 (UTC)
 Support --Goldzahn (talk) 21:42, 7 March 2013 (UTC)
✓ Done --Paperoastro (talk) 23:24, 7 March 2013 (UTC)

Languages / Sprachen / Langues

ISO 639 / ISO 639 / ISO 639

→ Property:P218 → Property:P219 → Property:P220 → Property:P221

  • Description: ISO 639 codes
  • Datatype: String
  • Links:
  • Infobox parameter example:
  • Comments: Please create one for ISO 639-1, -2, -3, and -6.

Please notice that a language can have several ISO 639-1 codes, several ISO 639-2 codes, several ISO 639-3 codes. Visite fortuitement prolongée (talk) 21:37, 2 March 2013 (UTC)

✓ Done P:P218 -> P:P221. We can add several values to a property when needed. --Zolo (talk) 21:46, 6 March 2013 (UTC)

Biology

Taxon name

Status:    Done

→ Property:P225

You're right. "taxon name" or "scientific name", then. - Soulkeeper (talk) 09:44, 1 March 2013 (UTC)

 Support - Basic unit. No need to divide this property into ranks, because rank should be a property on its own. (currently "is a" is used for rank). I suggest calling the property "taxon" instead of "taxon name". - Soulkeeper (talk) 17:18, 8 February 2013 (UTC)

    • The point is that the same species name can be used for different organisms, but is never used for different organisms within the same genus. The problem is that these names change from time to time, and it is quite common that what may be called the traditional taxon name, & is the name most likely to be known to non-spoecialists--even non-specialist biologists, is not the current taxon name in formal use. DGG (talk) 16:41, 15 February 2013 (UTC)
  •  Support, but a less ambiguous name would be Latin binomial. --OldakQuill (talk) 23:02, 4 March 2013 (UTC) PS. Might it not be possible, with software modifications, for a property to be an automatic concatenation of two other properties? So that the {Taxon name} would be a concatenation of {Genus}+" "+{species}? --OldakQuill (talk) 23:08, 4 March 2013 (UTC)
  • "Latin binominal" is a bit inaccurate/misleading, as binominal names can contain words from all languages, from Greek to Old Norse to Native American languages. Maybe "Latinized binominal" would be more accurate, but I personally prefer "Taxon name". Anyway, making aliases for properties is not a problem. Automatic concatenation would be useful only for species and subspecies, and would require us to store the epithet(s) by itself. An epithet has no utility value by itself, and if the genus name changes, the epithet might have to be updated with a new grammatical gender anyway, so I don't really see any gain in storing it separately. - Soulkeeper (talk) 16:38, 5 March 2013 (UTC)

✓ Done - Property:P225. - Soulkeeper (talk) 22:54, 6 March 2013 (UTC)

 Comment This is redundant if it will be possible to use Latin-language content from wikidata on e.g. English wikipedia. If that is the case, i propose this property is deleted. Users who want to add Latin names should add Latin interface (at least a babel user information box makes it appear), or switch to it, which is exceptionally simple. This property misses the reason behind making Wikidata, namely to avoid unnecessary duplication of work. I reckon this is a win-win situation, or synergy if you like, that should be taken advantage of. - Ssolbergj (talk) 02:51, 7 March 2013 (UTC)
'Taxon name' is the scientific name and it is NOT Latin. At most it can be considered like 'Latinized scientific name'. Wolf taxon name is 'Canis lupus' when latin is 'lupus'. Domestic dogs taxon name is 'Canis lupus familiaris' when latin is 'canis'.
Also, 'Taxon name' == 'scientific name' which can be used for any rank (order,family) NOT only for species like 'binomial name' Liné1 (talk) 13:22, 8 March 2013 (UTC)

ships

ship class

Status:    Done

→ Property:P289

  • Description: Ship class
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments:
 Support --Goldzahn (talk) 15:46, 12 March 2013 (UTC)
✓ Done as Property:P289. Danrok (talk) 21:39, 14 March 2013 (UTC)

ship type

  • Description: type
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments:
 Support --Goldzahn (talk) 15:46, 12 March 2013 (UTC)
✓ Done Property:P288 --Goldzahn (talk) 11:00, 14 March 2013 (UTC)

ship designer

  • Description: Designer of the ship/yacht
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments:
 Support --Goldzahn (talk) 15:46, 12 March 2013 (UTC)
We have now Property:P287 (designer). --Goldzahn (talk) 00:54, 14 March 2013 (UTC)

mountain

Mountain range / Gebirgszug / Cordillère

Status:    Done

→ Property:P295

✓ Done Property:P295 --Goldzahn (talk) 18:27, 17 March 2013 (UTC)

Place / Geografikum / Lieu

Buried here

Coat of arms description / / Description des armoiries

Status:    Done

→ Property:P237

Shouldn't this be a media item from commons? Filceolaire (talk) 00:35, 25 February 2013 (UTC)
No. There are articles about flags. Same situation with anthem: we have media and item properties for it. --EugeneZelenko (talk) 01:58, 25 February 2013 (UTC)
 Comment How about creating an additional property blazon / Blasonierung / blason as a MultilingualText value, for when there is no article on history/usage but a blazon (description) exists? /Ch1902 (talk) 11:33, 25 February 2013 (UTC)
 Comment Many of the coats of arms have multiple variants, and individual variants rarely have their own article. Greater coats of arms, for instance, often have lengthy blazons, which describe various degrees of achievement, in addition to the escutcheon. So a single "Coat of arms description" (or rather: "coat of arms blazon") property could create confusion, unless there are properties for greater, middle and lesser arms, along with separate properties for their respective blazons. If this proposal goes through, a blazon item with a more specific purpose could be "Escutcheon blazon". - Ssolbergj (talk) 00:44, 26 February 2013 (UTC)
In that case we could have one property (coat of arms) added multiple times for each variant and a qualifier for each variant specifying its type or usage (greater arms, escutheon, father's arms, arms before marriage, etc). I think (or I hope) it will be possible to query using qualifiers, so you could still select just the escutheon or the greater arms instead of all coats of arms properties. /Ch1902 (talk) 13:42, 26 February 2013 (UTC)
Do you know if it is currently possible to have qualifiers for each image within the "coat of arms" property, that are to be selected from a set of common types/variants (lesser, greater, escutcheon, before marriage etc.)? The potential usefulness of such an arrangement would of course also depend on whether (as you mentioned) it's possible to query each of them. It would also be a bonus if a link to the wikipedia article of the property as a whole (such as Coat of arms of the Netherlands) could be added, and each of the images made space for the blazon to be typed. Unfortunately I'm not yet fluent in wikidata jargon. -Ssolbergj (talk) 00:07, 27 February 2013 (UTC)
Qualifiers aren't currently implemented, we're waiting patiently for them for many existing properties, but that doesn't stop us from using the properties multiple times now, just have to go back and qualify them later. The most I could find on their use was at Meta, Data model primer#Statements and following sections. I have read somewhere that qualifiers can be used in queries, but I'll be damned if I can find it right now. The notes on meta do mention Ranks too, so the escutcheon version of a CoA property could be set as the "Preferred Statement" so that it would still be returned for queries first. As for using a qualifier to link to an article, I don't know, I think we'd have to see how qualifiers get implemented first. /Ch1902 (talk) 11:21, 28 February 2013 (UTC)
Thanks for the answer! - Ssolbergj (talk) 22:14, 1 March 2013 (UTC)

 Support The infoboxes of countries, regions and cities etc. need links to the description articles of their respective arms. I.e. similar to the "Flag description" property. Description: Wikipedia article describing subject's coat of arms - Ssolbergj (talk) 22:14, 1 March 2013 (UTC)

locator map image

Status:    Done

→ Property:P242

✓ Done created as Property:P242. Danrok (talk) 16:09, 7 March 2013 (UTC)

Lakes

lake_sections
sections and sub-basins of the lake.

✓ Done Property:P224 --  Docu  at 22:39, 6 March 2013 (UTC)

frozen
Information about lake freezing: e.g. usual freezing date, months the lake is frozen, last years the lake was frozen, never, etc.

✓ Done Property:P222 --  Docu  at 22:39, 6 March 2013 (UTC)

Should these be multi-lingual or monolingual? Mange01 (talk) 02:22, 7 March 2013 (UTC)

From w:Template:Infobox_lake#Parameters:

lake group
group the lakes is part of

Airports

Airport codes

Status:    Done

→ Property:P238 → Property:P239 → Property:P240

✓ Done Property:P238 (IATA), Property:P239 (ICAO), Property:P240 (FAA) Sven Manguard Wha? 04:58, 7 March 2013 (UTC)

Train Station / /

next station

Status:    Done

→ Property:P197

 Support --Sakoppi (talk) 06:26, 24 February 2013 (UTC)
I guess it is done with Property:P197 --Goldzahn (talk) 12:32, 6 March 2013 (UTC)

Station code

Status:    Done

→ Property:P296

 Support --Sakoppi (talk) 06:26, 24 February 2013 (UTC)
 Comment Is the description correct? Danrok (talk) 01:50, 25 February 2013 (UTC)
Fixed and  Support. --Stryn (talk) 10:25, 25 February 2013 (UTC)
✓ Done as Property:P296. Danrok (talk) 21:38, 17 March 2013 (UTC)

Rivers / Flüsse / rivières

Russia State water register code of water object / Код водного объекта

  • Description: Russia State Water Register code of water object
  • Datatype: string
  • Allowed values: numbers
  • Link: w:en:State Water Register
  • Use case: Cross-checking Wikidata data with the Russian State Water Register.

For an example code, see http://textual.ru/gvr/index.php?card=174254&bo=0&rb=0&subb=0&hep=0&wot=0&name=%C2%EE%EB%E3%E0&loc= (after "Код водного объекта"). Nikola (talk) 16:46, 7 March 2013 (UTC)

Agreeing. And there is a batch of similar registers, e.g. in AT, BE, CH, CZ, DE, FI, FR (SANDRE), NO (REGINE), LU, US, perhaps others --Matthiasb (talk) 10:58, 8 March 2013 (UTC)

crosses / traverse

  • Description: name of the river crossed by a bridge / nom du fleuve traversé par un pont
  • Datatype: item / élément
  • Domain: subject is a bridge, object is a river / le sujet est un pont, l'objet est un fleuve
  • Allowed values
  • Infobox parameter: en:Template:Infobox_bridge: Crosses
  • Source:
  • Consistency check: if another property is created to list the bridges that cross a river / si un jour une propriété liste les ponts qui traversent une rivière
  • Comments: would it be really useful to create its reverse property ? / Y aurait-il une réel intérêt à avoir la propriété réciproque ?
 Support --Ricordisamoa 15:36, 6 March 2013 (UTC)
Already there, Property:P177 ;). I dont think the reverse propert would be very useful, and some lists would be rather lengthy. --Zolo (talk) 16:59, 6 March 2013 (UTC)
You're right, already there!
Comment ai-je pu la rater ? Un accès facilité aux propriétés et la structuration de tout ça ne deviendra-t-il pas important dans un avenir proche ?
--Gloumouth1 (talk) 20:37, 6 March 2013 (UTC)
On pourrait retravailler WD:List of properties, mais je n'ai pas trop d'autres idées (et plus tard, on devrait aussi pouvoir traduire cette page automatiquement. --Zolo (talk) 21:07, 6 March 2013 (UTC)

Unsorted

Current location

Status:    Done

→ Property:P276

  • Description: place where the object is currently located, for instance a museum or a private collection
  • Datatype: Item
  • Links:
  • Domain: Creative work
  • Comments:
 Support Danrok (talk) 15:20, 4 March 2013 (UTC)
Support as "[museum] collection". That is the standard term. Espeso (talk) 18:05, 4 March 2013 (UTC)

done (Do not archive as of March 5) I've gone ahead and created this rather obvious property at Property:P195. Please do improve the name and description if needed, but the property's concept is clear. :) Espeso (talk) 18:21, 4 March 2013 (UTC)

Thanks. Actually the concept is not totally clear to me :p. It seems to make sense, as an object can be part of a museum's collection even when it is on deposit on or temporary exhibition somewhere else. For instance many artworks that are officially part of the Louvre's collection have been on dipslay in another French State museum for decades. Are they part of the Louvre or of the other museum's collection. Note that the Louvre is not the owner, the French State is. It might still make sense to have a location property in addition to this one. --Zolo (talk) 10:37, 5 March 2013 (UTC)
Example here: The Death of Major Peirson, 6 January 1781. Collection: Tate. On loan to Jersey Museum and Art Gallery. This suggests another property "on loan to" which could apply to other things. But, we still need a property for the actual location, which would also apply to many things, the "locale". At present we can only say located in admin unit. We need something more specific. Danrok (talk) 16:20, 5 March 2013 (UTC)
OK Zolo, I will remove the "done" mark from this item so it doesn't get archived. Does "on loan to" resolve your concerns? Or should there be a property for locations that has a more broad use, like Danrok suggests? Surely there is a need for it, but the moment it gets created people will start using it in place of "located in administrative division..." or whatever it is called now. :-) Espeso (talk) 03:21, 6 March 2013 (UTC)
Location would still be needed for cases like "the Luxor Obelisque is on the Place de la Concorde". I do not see any property name that would ensure it is not used in place of "located in administrative division". The best solution to avoid the confusion might be to have bots fill as as many P:P131 as possible, as quickly as possible :|. Perhaps "current object location" ("object" to discourage its use for places and "current" to make it sure it is not used for place of production or of discovery). --Zolo (talk) 09:35, 6 March 2013 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ OK (lol).  Support "current location" as relevant to museum objects that move, or objects that are not in a "collection" per se (e.g. objects in churches); or a few other use cases that are not obvious to me right now. However, using "current location" for permanent museum collections is not idiomatic and I hope we can avoid that. Espeso (talk) 03:29, 7 March 2013 (UTC)
✓ Done P:P276. --Zolo (talk) 18:25, 12 March 2013 (UTC)

Domain (EN) / Dominio (IT)

2 supports: ✓ Done as Property:P273 --Ricordisamoa 23:42, 11 March 2013 (UTC)

Programming language / Programmiersprache / Langage de programmation / Linguaggio di programmazione

Status:    Done

→ Property:P277

  • Description: the programming language(s) in which a software is developed
  • Infobox parameter: various Template:Software
  • Datatype: Item
  • Domain: Creative work (Software)
  • Allowed values: for example C#, Perl, and all other items that are programming languages
  • Source: various Template:Software
  • Example item and value: Stockfish<Programming language>=C++
  • Robot and gadget jobs: maybe later
I think it's very important to have this property, so if nobody oppones, I'll create it soon. --Ricordisamoa 21:55, 11 March 2013 (UTC)
 Support --Goldzahn (talk) 15:53, 12 March 2013 (UTC)
 Support usefull information Amphicoelias (Talk) 17:04, 12 March 2013 (UTC)
✓ Done as Property:P277 --Ricordisamoa 21:53, 12 March 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Archive/3&oldid=1102104015"