Latest comment: 11 years ago24 comments17 people in discussion
Description: Local Name (The name of sth in its native country, Language)
Datatype: StringValue/MultilingualTextValue
Domain: Everything (can be a place, food, ....)
Infobox parameter: Local Name (In Persian wiki نام محلی)
Comments: this is used a lot. For Items that are foreign or have different name locally, than what is well-known. (I don't know if it is possible to query in another language, than wiki's own).
Question: Native country = place of birth? People move, borders change. What should we do with non–Latin characters? Can you give a link to the infobox? --Kolja21 (talk) 04:25, 9 March 2013 (UTC)
I wasn't here for a long time, sorry to answer you a little bit late. it is diffrenet as in alias I think you use the same language not local language.--Pouyana (talk) 10:10, 21 March 2013 (UTC)
Comment: I guess it could be in StringValue/MultilingualTextValue datatype. This is useful in Infobox country, as native name is usually shown at the top. It would be great if language code can also be added on StringValue datatype in the future. --Ericmetro (talk) 10:01, 9 March 2013 (UTC)
Comment It is used in many infoboxes, but it may not be better to use more technically accurate property names here. For instance the native name of a company should probably be the name under which it is registered, while the original title of the book is probably the title under which it was first published, and I am not convinced it makes logical sense to use the same property. --Zolo (talk) 06:59, 12 March 2013 (UTC)
Official Name is better for names companies were registered under, with time parameters if it changes. Local Name is still useful with language or geographic qualifiers where companies have local nicknames or operating names in different locations. Filceolaire (talk) 07:07, 5 April 2013 (UTC)
Comment Arabesque is an art originated from our country. But no one has ever heard this word in our country.We call it "islimi" designing. "Islimi" is a word never heard by foreigners.Hence it wont be considered even as an alias for "arabesque". That's the difference between "alias" and "local name".
Does any one of you know the native name for "Mount Everest", the Erath's highest mountain? It is called "Sagarmatha" by Nepalis but its "local names" are "Deodungha" ("Holy Mountain") and "Chomolungma" ("Holy Mother") as mentioned in Chinese Wikipedia infoboxes Mount Everest Naming. So this property should be considered as a language-specific property. -- دوستدار ایران بزرگ (talk) 11:38, 14 March 2013 (UTC)
Oppose: If you have a name of the item in all languages (the name of wikidata item on the top of page) then a local name is a duplicate. It would be better to have a property "native country" of the item, and to get the native name that way. Janjko (talk) 14:39, 19 March 2013 (UTC)
Oppose: No automatic way of collecting this data from Wikipedia or an external source is provided. No concrete example is provided. Mange01 (talk) 08:28, 20 March 2013 (UTC)
We can have bot collecting the data from for example fawiki, and example it using is country info template in every wikipedia that use this template.--Pouyana (talk) 10:10, 21 March 2013 (UTC)
I don't think this would be a good property if it were tied to language, instead of place. We already have built-in capability to specify aliases in different languages. This property might provide value if it were qualified by place--so for example, the item for "elevator" could have the statement "local name: lift (country: UK)" which would carry more information than simply stating "lift" as an alias for "elevator". Silver hr (talk) 02:26, 31 March 2013 (UTC)
Support as string. Multilingual text makes no sense for this property. If there are different names in different local languages then each should get it's own statement with its own language, location, pronunciation etc. qualifiers, as required. It could even have a translation qualifier which could be multi-lingual text as for the Mount Everest example above. Filceolaire (talk) 07:07, 5 April 2013 (UTC)
Oppose – the description is too unclear, no examples provided. Both country and language are mentioned in the description without clarification. A more precise prososal is needed. Byrial (talk) 17:26, 20 April 2013 (UTC)
Oppose not because this wouldn't be useful, but because the proposal doesn't make clear whether this would be tied to language or place, and also because there's a better way of doing it now that we have qualifiers: a generic name property with a place qualifier. Silver hr (talk) 13:47, 25 April 2013 (UTC)
Support Very useful, even if this property is not associated to any infobox parameter. A small suggestion: perhaps it could be better use an integer datatype with the unicode number. --Paperoastro (talk) 15:31, 28 March 2013 (UTC)
Comment I think this is too special, what about a general property for unicode symbols? That would cover this property, currency signs, sybols like for airplanes and others... --Pyfisch (talk) 18:16, 7 April 2013 (UTC)
Motivation. Property certainly useful for a lot of astronomical items, but probably it could be useful also as "generic property". I chose the "not translated string" datatype because the nomenclature of this name is rigorously established by IAU and I verified for some satellites of Jupiter that no Wikipedias transliterate provisional names (even if I'm not totally sure for Persian language!). --Paperoastro (talk) 08:52, 18 April 2013 (UTC)
Motivation. It is a poorly used parameter of the English template "Infobox planet", but in Commons there are more than 300 images (and animated gif) of asteroid orbits. Wikidata can help other Wikipedias to manage them. --Paperoastro (talk) 09:47, 18 April 2013 (UTC)
Support I oppose the qualifier idea because ICD-9 & ICD-10 codes are very different and nobody will search for "code X in any ICD version" . Things would only be harder with a compulsory qualifier. By the way is ICD-9 still useful ? Ske (talk) 09:18, 13 April 2013 (UTC)
I think these two are best kept separate, because the scenarios are quite different. For example, not all software is OS specific, some software runs in web browsers. Danrok (talk) 19:47, 5 March 2013 (UTC)
We don't have properties to deal with wars and battles yet, and I think this one can connect smaller events (battles, attacks, offensives, sieges) into larger events (wars, revolutions, coups d'état, etc). Pikolas (talk) 11:23, 26 April 2013 (UTC)
In our articles about satellites we say where something launched from. We have been saying pad as well as area, but just linked to an article on the area. In the above example Baikonur 81/23 is pad 23, at Baikonur site 81. I think we need an object for each pad. Secretlondon (talk) 14:36, 27 April 2013 (UTC)
We have launch vehicle but that seems just to be for things like Proton-K, not mentioning the upper stage which we always do when we write about a launch. In the infobox we will write something like Molniya-M/2BL with Molniya-M as the rocket and Blok 2BL as the upper stage. I think we need to capture the upper stages. Secretlondon (talk) 15:07, 27 April 2013 (UTC)
I've been playing with this on Kosmos 2485. I think we can get the barebones of a wiki satcat with this. I can have more than one entry for launch vehicle so I've added both the Soyuz and the Frigat as launch vehicle. We lose some specifics as we do not have an article for GLONASS-M (yet), only GLONASS. We have an article for Soyuz-2, not Soyuz-2-1b so the launch vehicle loses that detail. We have an article for Plesetsk Cosmodrome Site 43, not site 43 pad 4 so we lose the pad detail. However this looks really powerful. Secretlondon (talk) 14:31, 28 April 2013 (UTC)
I've now worked out how to make entries link to things without Wikipedia articles and as we can have two entries for launch vehicle I don't think we need upper stage anymore. Secretlondon (talk) 10:01, 6 May 2013 (UTC)
ISO 4217 code
Latest comment: 11 years ago2 comments2 people in discussion
Oppose Who is the first is seen from other data. If you give a person the property "held this position from 1980 to 1985" then you can find the first one with a query. So, this is duplicate data. The same for two properties beneath. Janjko (talk) 15:53, 19 March 2013 (UTC)
Latest comment: 11 years ago1 comment1 person in discussion
Description: territory is legally or politically attached to a main territory with which it is not physically contiguous because of surrounding alien territory. It may also be an enclave.
Datatype: item
Support this is a useful piece of data for such places. Joshbaumgartner (talk)
tropical cyclone items within the Atlantic, eastern Pacific, and central Pacific tropical cyclone basins
Allowed values
letters "AL," "EP," or "CP" followed, without a space, by a six-number string, the first two numbers indicating the storm number, and the last four indicating the year (e.g. CP021959, AL182012, EP061967). "WP" entries for the western Pacific exist as well, though only four, and those entries have been updated only for 2012. Regex: ^[AEC][LP]\d{6}$
I'm not sure if I fully understand the concept of authority control...if I've made a mistake in proposing it, just let me know. Hurricanefan24 (talk) 18:54, 28 March 2013 (UTC)
It does not seem to be used in Wikipedias, and I do not understand anything about it, but a bit of googling suggests that it is a standard reference, and I do not see any harm in adding it. --Zolo (talk) 19:43, 6 May 2013 (UTC)
Support per above. With general manager (often abbreviated as GM in North America), we would now have the owner, president (those two non-specific to sports), GM and head coach hierarchy all in place. Shawn in Montreal (talk) 17:44, 8 March 2013 (UTC)
Support an notable role in the organization. Maybe can also allow people with a different title, but the same job description to be claimed with a qualifier indicating official job title. Joshbaumgartner (talk) 10:35, 9 May 2013 (UTC)
We already have killed by i.e. assassin so this seems logical as it has a larger scope and is of more statistical etc. relevance Macadamia1472 (talk) 01:50, 30 April 2013 (UTC)
Do we have any guidelines about re-proposing properties? That proposal underwent some substantial revision after it was originally proposed in response to early objections. I'm a bit biased, having been a supporter of the previous proposal, but this seems like a broader question. Emw (talk) 03:00, 30 April 2013 (UTC)
Comment I would think that if the proposal was re-worked to address the concerns raised in the previous discussion, and those who opposed it before are notified where possible that it is back on the docket, then I think it is reasonable to bring something back to the floor. That is probably something for an RfC, and outside of the scope of this page I would presume. Joshbaumgartner (talk) 09:24, 9 May 2013 (UTC)
Comment This is very similar to noble title which I was asking for comments on here. I think this suggestion and noble title should be used for the same purpose but not called Honorific Prefix nor Noble Title, something more general that applies in both situations, then qualifiers can say how each title is used (spoken address, written address, honorific prefix, noble title etc), and it should probably be MultilingualText rather than Item. /Ch1902 (talk) 11:15, 25 February 2013 (UTC)
Comment: also needed for #Italian Wikipedia person data. Examples: "Lord, Sir, padre, dott., santo". Generally they're not abbreviations, but they can be, and they have an article. More general name could be "prefix"; confusing it with other stuff like full name of the office/title that are not prefixes (e.g. w:it:Camillo Benso, conte di Cavour) would be rather messy. --Nemo09:21, 1 March 2013 (UTC)
Support, but I think academic degree should be used as a qualifier to alma mater. The field of work is not necessarily related to the degree a person has, so I don't see why field of work is used as a qualifier for academic degree in the proposal. --Wylve (talk) 12:17, 20 April 2013 (UTC)
Because the field of work can express his/her major. Well we should determine which method to express their major: a) Use every item to express their major (e.g. Bachelor of Journalism) or b) add qualifier "field of work" that can express their major. I prefer b) to a) because all types of degree by major could not be listed as item. Usually types of degree by major are listed only in enwiki, and even in enwiki, some types of degree (e.g. w:en:Bachelor of Economics) redirect to just w:en:Bachelor's degree. Kwj2772 (talk) 07:55, 21 April 2013 (UTC)
Comment, separating "education" from "alma mater" would create a rather confuse structure, espacially for people who have studied at various places. I think the "alma mater" property should be renamed to "education", with recommended format:
Paul Krugman:
education:
PhD
institution: MIT
date: 1974-1977
topic: eonomics
doctoral adivsor: Rudiger Dornbusch
PhD thesis: Essays on flexible exchange rates
Birth name
Latest comment: 11 years ago4 comments3 people in discussion
I realize that many people may think that this is redundant with aliases, but I consider it necessary for inclusion in infoboxes. Remember also that aliases are not multilingual. FrigidNinja23:00, 24 April 2013 (UTC)
Support I would also be willing to extend the naming convention. Especially women with several marriages undergo several name changes. Often it would be meaningful to know the time span of a name. --Susannaanas (talk) 04:22, 9 May 2013 (UTC)
Comment I think that P131 is so general and at least we need a specific qualifier to narrow the concept. Province is a specific kind of administrative units. If you want to generalize P131 to all types of administrative units then there would be no need to properties like Property:P500 and Property:P17 supposing that in the same way these can be conveyed by a possible generalizing property like "inside continent". Having this assumption in mind we may say "Moscow is inside continent Asia" instead of saying "Moscow is in country Russia". دوستدار ایران بزرگ (talk) 19:46, 12 May 2013 (UTC)
interleaves with / verzahnt mit / FRENCH / RUSSIAN / OTHERS
Latest comment: 11 years ago3 comments3 people in discussion
used for stratigraphic formations to indicate if the interleave with other formations Interleaving can be observed between sedimentary units of any scale and composition.
The property name "Location of scientific description" could be misconstrued to refer to the geographic location where the type specimen was found.-Soulkeeper (talk) 16:01, 6 February 2013 (UTC)
@Soulkeeper. Sorry about putting you in the proposal. I assumed that you were the creator. I think this can be archived now anyway unless somebody still wants to add something. --Tobias1984 (talk) 15:12, 10 May 2013 (UTC)
Host country / Austragungsland
Latest comment: 11 years ago4 comments2 people in discussion
I reconsidered my proposal and now agree with Joshbaumgartner. The already existing property P17 seems to be sufficient.--Kompakt (talk) 09:37, 12 May 2013 (UTC)
I'm not sure whether this property could also be expressed using "number of participants" along with some sort of qualifier. In this case the property would be obsolete of course.--Kompakt (talk) 19:08, 29 April 2013 (UTC)
Oppose. As you're mentioned itself, a more generic property "number of participants" should be used, together with qualifiers. Or, at all: No such property because the number can be calculated by the sum of entries of "participants" easily. --Nightwish62 (talk) 10:20, 11 May 2013 (UTC)
Comment I agree with you that the paired properties are probably not appropriate until and if support for automatic pairing is added. Joshbaumgartner (talk)
Oppose can be queried from property "powerplant". Might be implemented when bi-directional properties are created. --Tobias1984 (talk) 14:11, 30 April 2013 (UTC)
Comment I totally agree that qualifiers will be useful, and should be added. There are a lot of different scenarios that can play out for this so perhaps once the 'powerplant' property is being used, it will become more clear exactly what they should be. Joshbaumgartner (talk)
I think it has been proposed before but I cant find it. It would be useful in many contexts (for instance, a part of a building is protected, or is owned by a particular company). --Zolo (talk) 09:26, 4 May 2013 (UTC)
When discussing items and properties, could you please provide labels for items and properties? It's nice to be able to reason about a discussion without having to click on an item or enter http://www.wikidata.org/wiki/Property:P156 into a new tab to understand what's being discussed. Emw (talk) 11:37, 4 May 2013 (UTC)
That would have some good sides, but in some cases, in some cases I am weary that things would go complicated. For instance, French protected buildings like the Gare de l'Est are listed in a database, with a paramter stating which part are protected ([1]). That would be relatively easy to copy that here: "Gare de l'Est: instance of monument historique. Datbabase ID XX. Parts concerned Roof (using the generic roof item). But linking it to the database / official protection decree may become more redundant and intricated if we use separate items for the protected parts. Another example would be a painting with Painter X doing the characters and Painter Y doing the landscape (though arguable, a "role" qualifier may be more appropriate for this case). --Zolo (talk) 11:46, 4 May 2013 (UTC)
I see your point, and I didn't think of using generic items before. For the ownership, I suppose that you can also use generic items for the halls and platforms. That will probably be better than creating a new item for each concerned part. Byrial (talk) 12:14, 4 May 2013 (UTC)
What about values that don't have items, like 'black figure ceramic' and 'red figure ceramic' in the Belly Amphora example above? Emw (talk) 12:32, 4 May 2013 (UTC)
If there where no items, (and that is the case frequently), then I would have used "North", "Central" and "South" as items in my example. But that does not work in Byrials version. -- Lavallen (block) 13:06, 4 May 2013 (UTC)
Actually, for red-figure ceramic we have Q633683, but it is true that there are cases that seem more complicated (for listed buildings, there are plenty of things like: protected part: second window from the right). --Zolo (talk) 13:35, 4 May 2013 (UTC)
ORCID
Latest comment: 11 years ago2 comments2 people in discussion
The ORCID is an open identifier for researchers. It is linked to ISNI (P213) but the two identifiers currently exist in parallel and it is possible for individuals to have both, so we need a seperate identifier. Andrew Gray (talk) 12:33, 11 April 2013 (UTC)
CBDB is a respectable database of ancient Chinese people, developed by Peking University, Academia Sinica and Harvard University. --Stevenliuyi (talk) 19:00, 29 April 2013 (UTC)
Oppose can be queried from property "powerplant". Might be implemented when bi-directional properties are created. --Tobias1984 (talk) 14:11, 30 April 2013 (UTC)
Comment I don't know how that works with airplanes. Is the whole series fitted with these "AIM-120 AMRAAMs" or would qualifiers be needed to distinguish between different series/types/models/makes of "Boeing F/A-18E/F Super Hornets"? --Tobias1984 (talk) 07:54, 30 April 2013 (UTC)
Comment Armament can be even more complicated than powerplants. They can run the gamut from simple fixed armament that is standard throughout a family or series, to highly configurable complex weapon systems (becoming more the norm these days). I figure best to start with a simple 'item' datatype so that any weapon system or element notable enough to warrant an item and which is used (standard or optionally) on an aircraft can be listed. Qualifiers would become very useful to further define how many can be carried, ammunition loads, optional load-outs, version compatibility, operator-specific systems, etc. Joshbaumgartner (talk)
Comment: This brings the data maintained in destination tables on airport articles to wikidata. Qualifier 'operator' can indicate airlines operating to destinations. Other qualifiers can be developed to add details such as frequency, seasonal adjustments, cargo-only service, operated dates, etc. Joshbaumgartner (talk) 09:21, 1 May 2013 (UTC)
Comment I think it would be better to make two properties: "temporal range start" and "temporal range end". Otherwise one would have to add quite a few items to certain species. --Tobias1984 (talk) 22:29, 26 April 2013 (UTC)
Comment - The same property could also be used for all things that have a start and end that can be expressed by the geologic time scale. E.g. start and end of sedimentation, ice ages, planetary stages (Late Heavy Bombardment, quaternary glaciation), orogenies, etc... We should probably make two additional properties that have the same meaning with radiometric ages (when number become an available data type). --Tobias1984 (talk) 14:31, 11 May 2013 (UTC)
Latest comment: 11 years ago5 comments3 people in discussion
Not done
Description
The subitem is an item which is part (subtheme, branch) of the current item. E. g. Lefthandedness is subitem of Handedness, Geometry is subtheme of Mathematics, Androphilia is subitem of Androphilia and gynephilia, Saint Cyril is subitem of Saints Cyril and Methodius, Rail transport is subitem of Track transport (Drážní doprava in Czech, including trolleybus and aerial cableway transport) etc. Complementary to "Upper item".
abstract terms, branches and discpilines of study, science, work or other activities etc., two-item and multi-item articles (in cases where formulation "part of" or "member of" is unsuitable), imperfectly synonymic terms etc.
Comments: proposed to compensate (at least partially) disabled functionality of anchors (#) in interwikis and to capture this specific type of relation between items. --ŠJů (talk) 01:51, 13 March 2013 (UTC)
Latest comment: 11 years ago5 comments4 people in discussion
Not done
Description
The upper item is an item (subtheme, branch) which covers (includes) the current item. E. g. Handedness is upper item to Lefthandedness, Mathematics is upper item to Geometry, Androphilia and gynephilia is upper item to Androphilia, Saints Cyril and Methodius is upper item to Saint Cyril. Complementary to "Subitem".
abstract terms, branches and discpilines of study, science, work or other activities etc., two-item articles (in cases where formulation "part of" or "member of" is unsuitable)
Comments: proposed to compensate (at least partially) disabled functionality of anchors (#) in interwikis and to capture this specific type of relation between items. --ŠJů (talk) 01:51, 13 March 2013 (UTC)
Explicitly stating each member of a class seems it could get very problematic. For example, the list of "upper item" claims for "person" would have hundreds of thousands of entries. Emw (talk) 02:38, 3 April 2013 (UTC)
Municipality code in Sweden
Latest comment: 11 years ago1 comment1 person in discussion
Q10433566 (Boteå landskommun) was a municipality in Sweden 1952-1970. The nothern part became a part of Sollefteå Municipality and the sothern part became a part of Kramfors Municipality. I have no good name for this property (not even in my own language), but I see a need for something like this. -- Lavallen (block) 05:13, 22 April 2013 (UTC)
Maybe it also can be used for the succession of titles in for example Charles V, who was replaced by Ferdinand in Austria, and Filip in Spain. Another example is Elisabeth II who has already been replaced as chief of state in several nations. -- Lavallen (block) 06:44, 22 April 2013 (UTC)
I was also wondering about a qualifier in Q1878978 (property: creator), to mean Painter A made the red ceramic part and painter B the black ceramic part. Do you think it would be ok to use this property as well ? --Zolo (talk) 08:46, 24 April 2013 (UTC)
Comment If I understand correctly, you want to express for example that an administrative unit A with administrative subunits A1, A2, A3, A4 no longer exists and that A1, A2, and A3 are now parts of administrative unit B, and A4 is part of administrative unit C. If I'm correct, then this, although it's a slightly complex case, can be inferred if you record the relevant data: A1, A2, A3, A4 is in the administrative unit A (+temporal qualifier 1952-1970); A1, A2, A3 is in the administrative unit B; A4 is in the administrative unit C. Silver hr (talk) 20:26, 26 April 2013 (UTC)
No, it's not completly correct. A1, A2, A3 and A4 are not always administrative subunits, they are a geographic description. I could have used items like Q659 as A1/A2/A3/A4. And I cannot add Q659 as a part of anything like A. -- Lavallen (block) 16:14, 27 April 2013 (UTC)
In my example above, A1/A2/A3/A4 stoped to act as an administrative unit 1862 (if there ever where any, since local administration outside cities where introduced 1862), but they still exists as a geographic units. -- Lavallen (block) 16:20, 27 April 2013 (UTC)
Qualifier property to use with catalog code property to manage the huge number of catalog names of astronomical objects. The "ideal" datatype should be item, but this would limit the catalogs to those available in Wikidata. Paperoastro (talk) 14:31, 7 May 2013 (UTC)
You won't add each time the catalog name and the catalog code: if they are linked better add the code in the item of the catalog. Then can the catalog be the source of other informations ? If yesso you can use the catalog item to source data of the astronomic object and you don't need to specify the catalog as a property of the astronomic object. Again the catalog is not a real property of the astronomic object but only a place where you can get information so it is a data source. Snipre (talk) 22:50, 8 May 2013 (UTC)
Use catalogs as sources is a good idea: they can be used also for sourcing other informations. I'm sorry, but I don't understand the meaning of your sentence <<if they are linked better add the code in the item of the catalog.>> Could you explain me, please? After your explanation, I will close this proposal. --Paperoastro (talk) 09:28, 11 May 2013 (UTC)
Catalog code
Latest comment: 11 years ago1 comment1 person in discussion
year, "|date" in Infobox earthquake, next_year and previous_year can be easily calculated and used in Infobox election, "| This (single|song|album)" in infoboxes of musics (in chronology part). I didn't check other wikis' infoboxes
Domain
events and creative works
Allowed values
years
Example
2010 for "category:2010 (singles|songs|films|albums|books)", 2009 for [[w:2009 Iranian election]]
I think it's a common data and can be updated and used very easily and rapidly in so many infoboxes and other contents. Amir (talk) 14:10, 24 April 2013 (UTC)
Oppose The events and creative works should have some statements about their duration or creation, which should be of Time datatype (not yet available, though). For other uses, the name of the property leaves to much uncertainty about how it should be used.--83.240.94.1818:11, 25 April 2013 (UTC)
Oppose – Use the Time datatype for all kind of times with as much precision as relevant (for the 2009 Iranian election that would be the date: 12 June 2009, and a Wikipedia catagory is neither an event nor a creative work) -- Byrial (talk) 21:49, 25 April 2013 (UTC)
Oppose, per Yair rand. This proposal is good idea, but 'related item' is a more generic solution, and thus preferable. Emw (talk) 02:54, 8 May 2013 (UTC)
Oppose and merge into proposal for subject of (renamed since proposed as 'related item'). Otherwise we will have a plethora of 'Foo description' properties for every type of sub-topic given an article on Wikipedia. Joshbaumgartner (talk) 09:16, 9 May 2013 (UTC)
items of persons which are chairs of a deliberative body an organisation or body
Example
On the item of the Bundestag: Norbert Lammert, president; On the item of the US House of Representatives: John Boehner, speaker; On the item of CDU: Angela Merkel, chairperson; etc.
Weak oppose. It's not that clear, unless the person is literally called Chairperson/Chairman/Chairwoman by reliable sources. As one example, who's chairperson of the Senate, the Vice-President (also president of the Senate), president pro tem, or Senate Majority Leader? All have some degree of power, and none are literally called chairperson. Superm401 (talk) 05:02, 9 April 2013 (UTC)
Well, it's the same with Property:P6, the title may vary around the world, I just chose 'chair' as the most neutral expression. In most cases, "President" will be the title anyway. For the Senate, it's of course the Vice-President, since he formally presides. --MF-Warburg (talk) 09:52, 9 April 2013 (UTC)
Fully support, but I would make this broader: the presiding member (president/chairperson) of a deliberative body, or of a political party, or why not of any organisation. SPQRobin (talk) 18:28, 4 May 2013 (UTC)
Comment: Runway identifiers and notes are key information about an airport. Qualifiers 'length', 'width', and 'surface' can be used (when available) to further enhance data. Joshbaumgartner (talk) 09:21, 1 May 2013 (UTC)
Diplomatic relation
Latest comment: 11 years ago3 comments3 people in discussion
We are organizing the insertion of few thousands links in Italian Wikipedia, in a collaboration with the National Library of Florence (BNCF). Thus we are proposing a property in Wikidata, because we think and hope that this would be useful also to other projects: there are of course other national thesauri out there, and they are likely to be matched with Wikipedia items as does the italian one. Aubrey (talk) 10:04, 17 April 2013 (UTC)
I also want to add that this could be a great opportunity to test Wikidata in the Italian Wikipedia, as this property would be added in around 11'000 pages. On it.wiki the template is almost ready, as the bot to add the template, so we are actually waiting for the wikidata property to be approved. --Aubrey (talk) 12:51, 17 April 2013 (UTC)
Just to make sure what you are trying to do: you'd use the string "7253" on item "Artificial intelligence" (Q11660) and you would want this to link to http://purl.org/bncf/tid/7253 ?
Maybe the sample above should be adapted to illustrate this better, if this is what is proposed. BTW I'm not sure if links can be done based on qualifiers. -- Docu at 15:34, 21 April 2013 (UTC)
Hi Docu. The aim is simply to be able to link a Wikipedia entry to the same entry in the BNCF Thesaurus. There are IDs available, so I figured out that it was a good idea to propose a property in Wikidata/Authoirity Control. Moreover, this could be useful for other wikipedias in the future... A thesaurus is a specific work, different from other authority control tools. That's the rationale. But I'm not sure it's the best idea. Aubrey (talk) 10:26, 24 April 2013 (UTC)
I think there could be 2 possibilities: one is to have a general property Thesaurus, in which we put the ID and generate the link. With the qualifier, we can state that this relation is from the item and the BNCF Italian thesaurus. So qualifiers will discriminate between different thesauri.
Support Would this be distinct from country of registry, or could country be used for ships where the exact port is not known? Joshbaumgartner (talk) 05:56, 16 May 2013 (UTC)
Target
Latest comment: 11 years ago4 comments3 people in discussion
events such as terrorist attacks or military operations/battles
Allowed values
locations for attacks, individuals for assassinations (importantly, notable individuals killed in a general attack where they weren't the target are not included); intended target is given, whether or not the attack/operation was successful
I would note that instances of other types of attacks, e.g. cyber attacks like DDoS attacks during the October 2011 South Korean by-election, seem to be applicable subjects for this property. (Wikidata likely won't have items about the particular websites or web services attacked, but specifying the targeted organization or person seems like a reasonable alternative in that case.) Emw (talk) 13:53, 21 April 2013 (UTC)
I am positive, but the description needs to be discussed. If the allowed values are only locations and individuels, you cannot link the Boston Marathon bombings to the Marathon (as that is an event, not a location) but have to use Boylston Street, Boston as target. Is that what you want? Should 2011 Norway attacks link to Utøya (location) or Workers' Youth League (69 members were killed)? Byrial (talk) 14:48, 30 April 2013 (UTC)
streak / Strichfarbe / trait
Latest comment: 11 years ago15 comments5 people in discussion
Comment Please also look at the related request ofcolor (as an item). What should be done with color descriptions that don't have an item? Should "brownish white" and "yellowish white" be items? Would multilingual string be more appropriate? What should the qualifiers do? --Tobias1984 (talk) 20:35, 18 April 2013 (UTC)
I changed datatype to multilingual string as you are right about the silliness of having items like greenish-black.23PowerZ (talk) 10:11, 19 April 2013 (UTC)
Color circle by Johannes Itten.
HSL color solid.
I actually don't think that items are such a bad idea. User:Chris.urs-o send me the picture on the right. If we use this or a similar scheme there would be very few items that would describe a lot of colors. In this scheme we would have 12 items for colors. Betweenyellow and green we have an item that can be either yellowish green or greenish yellow. Between yellow and orangewe have an item that can be either yellowish orange or orangy yellow. The nice thing about these color wheels is that a search for "yellow" would return three colors, yellow itself and the two neighboring colors. I think done consistently this would be a very good way of doing colors as items. We just need to find a good scheme that everybody will agree to follow. We should have the same for greyscale, brown colors and pastel colors too. --Tobias1984 (talk) 13:01, 19 April 2013 (UTC)
Well, this particular scheme won't work, brightness is missing. When we generalize this much, precise information like dark cherry red for w:Pyrargyrite will be lost. 23PowerZ (talk) 18:28, 19 April 2013 (UTC)
I think that it is good enough, dark is an adjective. Lustre, brightness, saturation and hue are different things. I like the hexadecimal code for colors (en:Web colors). The brightness isn't missing, color space: white → grey → yellow → green → cyan → blue → magenta → red → brown → black. --Chris.urs-o (talk) 06:50, 20 April 2013 (UTC)
I would strongly oppose color as multilingual string. It would mean that the string had to be translated to all languages for each item using the property. If the value is an item, each color only has to be translated once. There is no sillyness about having items for "greenish-black". We can create items for every nuance of color, it would still avoid a lot of unnecessary translation work.Byrial (talk) 22:22, 26 April 2013 (UTC)
Only if we introduce a qualifier for "streak color". Mixing up these two sets of colors would be really confusing for mineral queries. I would also support the idea of this property being a qualifier. I am not sure what would be better in the long run.--Tobias1984 (talk) 15:16, 30 April 2013 (UTC)
I see the need to distingiush streak from the ordinary color. I guess that it will be more simple to have a separate property for streak color to avoid they are mixed up. Byrial (talk) 15:39, 30 April 2013 (UTC)
Hi, streak color and crystal color do not really correlate. A lot of minerals can differ in color eg. quartz from green to red, from yellow to violett. But the streak is always white, thats the trick. Up to now, I do not believe that it is possible to put it to RGB-Values to to Cie-Lab. Some minerals differ in brownish colors to black (Ilmenite or other iron containing minerals.) If I did not understood the discussion right, please ignore this part. BR --Krizu (talk) 09:30, 21 May 2013 (UTC)
Extinct
Latest comment: 11 years ago9 comments6 people in discussion
Comment IUCN status extinct isn't the same: IUCN gives extinct status for species that became extinct in the modern times (-500 years), and not for dinusaurus for example. User:132.65.153.50
Comment – Yes, it is the same. The problem is that species which became extinct in prehistoric time are not in the IUCN Red List, and thus doesn't have an IUCN conservation status. The same may also be true for some historic species. So a more general conversation status property could be needed, but I Oppose just to have a boolean property. More than two categories may be useful as in the IUCN list. Byrial (talk) 11:06, 9 May 2013 (UTC)
Comment Fossil species that have a temporal range that ends before the Holocene are automatically extinct. Same is true for Holocene species that have a temporal range beginning and ending in the Holocene. If the end of a temporal range is not set, then a species is not extinct. This property is probably useful, if one knows a species went extinct, but doesn't know when that happened.--Tobias1984 (talk) 05:51, 29 April 2013 (UTC)
Oppose – If it is not present on the official IUCN Red List, then there aren't sources, and nobody could effectively prove that dinosaurs are extinct (we all know that they are extinct, but everything is subjective without official sources). --Ricordisamoa11:24, 9 May 2013 (UTC)
Oppose I agree that IUC status should be up for the task but may need to be broadened a bit if their are taxons with a status that are not specifically IUC listed. Change name to 'conservation status' or some such and have IUC as a source? Probably that is a matter for P141's talk page, but I think a solution along those lines is better than adding extra properties.Joshbaumgartner (talk) 06:51, 13 May 2013 (UTC)
Code, Acronym or Abbrevation
Latest comment: 11 years ago12 comments7 people in discussion
Description: Internationally used acronym, code, abbrevation or symbol text. The code or acrynom should be the same in many languages. Usage: May be shown in for example in infoboxes and tables when linking to the item, instead of the items full name.
en:Infobox planet Spectral type = [[S-type asteroid|S]], for item 433 Eros. It would be possible to include the "S" if S-type Asteroid had the statement "Code" = "S".
Domain: Generic. (For example organisation, place, or term.)
Allowed values: Latin character text. Only one value should be assigned to an item.
Source:
Other information:
Instead of creating a lot of different text properties, we may use this generic property whenever there is only one code standard that should be shown in most Wikipedias.
Later a multi-lingual version called "Acronyms" may be created:
Support with the suggestion to extend this property to abbreviations of more than one letter: for example it would be very useful for the abbreviation field of the Infobox constellation (three letters) --Paperoastro (talk) 17:34, 7 March 2013 (UTC)
Oppose "code" (but updated, support "abbreviation", see below) -- I am generally for properties that are as generic as possible, but this is quite generic! Look at an infobox for an element or molecule and tell me that "code" is descriptive against other string values. I'm not sure I can support a property called "code" in any context -- I can't think of a case where the expected value would not be ambiguous. Espeso (talk) 15:16, 8 March 2013 (UTC)
Very different. This suggestion corresponds to a comon infobox name "symbol", or "code". It is useful if we in an infobox wants to link to the item, while an alias is not usefeul because we can not know that the alias shows a standard code. – The preceding unsigned comment was added byMange01 (talk • contribs) at 02:06, 10 March 2013 (UTC).
Ok. "Acronym" seemes to be an even more common parameter name in infoboxes. "Code" is quite uncommon. "Symbol" is not a good name, because in some infoboxes that parameter name refers to an image, in others, it is a linked item, and in other a single character or a text, for example "chemical symbol". Mange01 (talk) 02:11, 10 March 2013 (UTC)
I Support"abbreviation" as a more general variant of "acronym" and much more realizable than "code", which I opposed. The abbreviation property must reflect an accepted abbreviation of the topic name itself, in the relevant language. This implies that the property should not have a monolingual data type so can't be created yet. Such a property would, by definition, duplicate part of what aliases often contain, which is fine. Finally, contradicting the original proposal, there can be more than one abbreviation: on "United States of America" you could have "USA, U.S.A., US, U.S."! Espeso (talk) 17:52, 19 March 2013 (UTC)
Oppose – This is not about the item, but about the names of the item. Even in the same language the item can have several synonymous names. Any abbreviation for a language is best decided in the Wikipedia of language. -- Byrial (talk) 17:37, 20 April 2013 (UTC)
Oppose Abbrivations are not always the same in different languages. This should rather be ISO codes, or similar.--Snaevar (talk) 13:14, 22 May 2013 (UTC)
Dewey Decimal Classification / DDC / Classification décimale de Dewey
Latest comment: 11 years ago10 comments7 people in discussion
Description: proprietary library classification system created by Melvil Dewey in 1876
Qualifier (future): Version (DDC 1, DDC 22ger etc.)
Support I don't know if we can adopt DDC in full depth (due to copyright reasons) but we could use the ten classes, each divided into ten divisions. --Kolja21 (talk) 05:29, 9 March 2013 (UTC)
Oppose until proceeding questions are answeredQuestions: The Dewey Decimal Classification is not freely licensed, as you allude to. Given that, could Wikidata use even the 10 classes? If so, could it use the additional 100 derived divisions? If so, could it use the additional 1000 derived sections? Where is the line, if one exists? How does fair use apply to structured data like Dewey classifications? Would Wikidata allow fair use, since its structured data is in the public domain? Emw (talk) 14:19, 9 March 2013 (UTC)
These seem like relevant questions. Anyone up for answering them, or at least discussing them? Emw (talk) 17:09, 31 March 2013 (UTC)
Support At least in my country, compiling a selection of entitities from a list or catalogue is to my understanding below the threshold of originality. Mange01 (talk) 22:02, 13 March 2013 (UTC)
Note that we will need some kind of qualifier as to version (DDC 1... DDC 23). There have been pretty major changes over time, especially at the three-digit level, and as DDC 23 only came out a year ago most people will still list 22 if not older. Andrew Gray (talk) 11:51, 14 March 2013 (UTC)
Neutral. A point that looks not clear in this proposal: is the property done to be used in all items (with, by example, <Art of computer programming> DDC <005>) or only in items that has an id in DDC (by example <Philosophy> DDC <100>). I prefer the second solution (with an other property like "topic" (<Art of computer programming> topic <Computer programming>)) because that will allow us to support easily all classification (DDC, Universal Decimal Classification...). Tpt (talk) 08:37, 16 March 2013 (UTC)
Oppose due to copyright. foundation:Resolution:Licensing policy states that projects without an fair use policy (more specifically an Exemption Doctrine Policy (EDP)) have to follow the Definition of Free Cultural Works (http://freedomdefined.org/Definition). If we are going to allow fair use material, then such an policy should be proposed and approved first, not the other way around. And even then, if Wikidata had an fair use policy, then it would be problematic to use the data on the wikipedias, as the use of the DDC would also need to comply with the EDP there.--Snaevar (talk) 15:17, 22 May 2013 (UTC)
IPA / ΜФА
Latest comment: 11 years ago12 comments8 people in discussion
Oppose per Infovarius until either we won't deserve Wiktionary, or the property's target was specified more concrete, e.g. pronounsation local name of a place (from ex., seems to be supposed).
Until this information is included in many Wikipedias, including English one, it is worth to be centralized in Wikidata. And IMO a part of information from Wiktionary should be moved to Wikidata anyway, but it is another story. --DixonD (talk) 05:24, 5 April 2013 (UTC)
For instance, the article en:Lviv has two pronunciations: Ukrainian and Polish. French Wikipedia (fr:Lviv) has French pronunciation. So the multilingual text datatype makes more sense than a qualifier to mentioned names as theoretically every language may have different pronunciation for some particular term. --DixonD (talk) 06:58, 5 April 2013 (UTC)
Another "contra": Pronunciation is for words, but here we collect terms, whose names can be (almost arbitrarily) changed - thar's why they are numbers. Let's wait until we include interwiki-links for Wiktionary (Phase 4+?). Infovarius (talk) 19:43, 11 April 2013 (UTC)
Oppose – This is dictionary stuff about words, not something related to items. Which words are used and how they are pronounced even within one language depends on time, age, status, location, dialect etc. It could be covered as support for wiktionary, but for now I think it is outside the scope of Wikidata. -- Byrial (talk) 19:23, 20 April 2013 (UTC)
Support Items are words, and their pronunciation is an important piece of structured data. Different languages (and variants of languages) typically have their respective "received pronunciations" represented in dictionaries and used relatively consistently by reliable sources in their language variants (e.g. representative news organizations). These various pronunciations could use qualifiers to specify language codes like en-US, en-GB, en-AU, de-DE, etc. to indicate how some item is pronounced in various languages and variants within a language. Emw (talk) 02:26, 26 April 2013 (UTC)
Well, "Abisko, Linköping" isn't pronunced in the same way as "Abisko, Kiruna", it is not because they are located 1000 km from each other, it's because they are two different localities (read items). -- Lavallen (block) 10:27, 8 May 2013 (UTC)
en:Main type of item (entity type)/ru:тип элемента (основной тип)/de:Entität (Typ)/fr:type principal (entité)
Latest comment: 11 years ago12 comments7 people in discussion
all items. Should be endorsed in an official guideline.
Allowed values
may be some controlled but expandable vocabulary
Example 1
MISSING
Example 2
MISSING
Example 3
MISSING
Source
common sense, categories of Wikipedias
Robot and gadget jobs
Initial values can be estimated and filled with ones from P:P107 and P:P31.
While GND main type has been controversially used as "main type", recently it was understood as not, we need a proper replacement. From the other hand, "is a" is a quite vague. Wikidata needs the main property to build its own ontology (its own category system). I propose number P1 for this property. Infovarius (talk) 19:18, 14 April 2013 (UTC)
First we need a clear onthology and once we have it we can create the property. An "empty" property (without a clear definition of its use) is dangerous and if a good onthology is accepted we can perhaps recycle the GND property. Snipre (talk) 17:17, 17 April 2013 (UTC)
Universal ontology is too complex thing to be built in advance. It can be refining (and even constructing) with the time. Infovarius (talk) 04:24, 22 April 2013 (UTC)
I agree with that point, Infovarius. I actually find it to be an argument in favor of using properties that support increasingly refined classification, which is a primary feature of P31/P279. (P31/P279 can be as high-level, or as low-level, as needed.) Emw (talk) 12:20, 22 April 2013 (UTC)
Oppose "Main types" are a taxonomic kludge for systems that don't support multiple levels of hierarchical classification. In a project to structure all knowledge -- which Wikidata is -- restricting items into a small set of types will inevitably lead to classifications that are either A) too broad to be useful or B) simply incorrect. In other words, whether it is based on the GND or not, an ontology that classifies things with "main types" will inevitably end up with problems like the uselessly broad "term" main type in GND main type (P107), or simply incorrect classifications like families and literary figures as GND main type 'person'. Again, to emphasize: the fact that P107 is based on "main types" is a bigger problem than the fact that it is based on the GND. Let's not repeat that mistake.
There is a better solution: use "type" properties recommended for the Semantic Web by the W3C -- that is, use rdf:type and rdfs:subClassOf. These properties exist in Wikidata as instance of (P31) and subclass of (P279). These properties have been part of W3C recommendations for the Semantic Web for almost a decade. They are fundamental properties used in large controlled vocabularies to structure data into knowledge. They enable the important distinction between a type (class) and a token (instance). They facilitate classification at an arbitrary granularity; together 'instance of' and 'subclass of' can classify all subjects and be used to determine precisely where each subject exists in the hierarchy of knowledge. Not only do they solve those structural problems of P107 and other "main type" properties, but by being based on W3C recommendations, instance of (P31) and subclass of (P279) also make Wikidata more interoperable with the rest of the Semantic Web. Emw (talk) 00:19, 18 April 2013 (UTC)
The answer to that question seems independent of whether a main type property or P31/P279 is used. I personally don't think it makes sense to have Wikipedia lists and categories on Wikidata in the long term (since Wikidata should be used to create those lists and categories), but in the near future whatever 'main type' applies to lists, categories etc. could be applied via P31/P279. Emw (talk) 12:17, 22 April 2013 (UTC)
Comment The main type (GND) property is good to do a general classification. I would support a renaming to "main type/type principal/Haupttyp" to show the indepedendece of Wikidata and maybe customize it more for the needs of Wikidata as done with the extra type disamigulation. --Pyfisch (talk) 15:36, 8 May 2013 (UTC)
Comment. I initially thought that a general "type" property could be good, but I see more and more problems, and less and less uses with that. For instance, I think we should have an easy way to identify people, but I think it should be simply done by setting P31 to person in each case, rather than "politician", "man" or "charming lady"). But still, if we want a high-level "type" property, I would favor devising a home-made system over assigning GND main types to things that do not have a GND entry. --Zolo (talk) 16:18, 8 May 2013 (UTC)
Yes, I thought about some high-level type (may be 2 or 3 levels of classification). While P31 is usually used as a lowest level ("politician of USA", "TV-actor" and so on), P1 can be used as a main type more useful for bots than GND. Infovarius (talk) 18:49, 8 May 2013 (UTC)
Given that we now approved having items about files that are locally stored (e.g. are not on Commons), we need to create a sibling to P18 to allow linking those images with their respective subjects. — ΛΧΣ2106:56, 19 April 2013 (UTC)
And how will we fix that? Properties cannot have more than one datatype and point to items and Commons files at the same time. — ΛΧΣ2120:00, 19 April 2013 (UTC)
Oppose – Why do we need to link to unfree images? They can only be used by the Wikipedias which have them locally, so it seems natural that these Wikipedias handle the link themselves -- Byrial (talk) 20:17, 20 April 2013 (UTC)
Comment I am concerned about any property called 'latest foo', 'current foo', 'active foo', etc. I think it would be much better to have a property that was simply 'release version', 'development version', etc. and use qualifiers to attach a date to. So Super Cool Gamerelease version6.7.8Bon date12 May 2013. That way you would know how 'fresh' that information is, but we wouldn't be in the inevitable position of have something claimed as the 'latest' when it no longer is. Joshbaumgartner (talk) 06:51, 13 May 2013 (UTC)
Oppose - The latest version can be queried from a property "Software version" that has many entries with qualifiers for "release date". --Tobias1984 (talk) 07:23, 13 May 2013 (UTC)
Oppose per Tobias1984. Don't create time dependent property. Use qualifier to add additional data. Snipre (talk) 11:57, 18 May 2013 (UTC)
The word may sound unfit, but the idea is the same so I think it is better to add one property, as it should be easier to manage, and avoid useless questions about fringe cases (say, comic books). Perhaps, we could rename it to "subject", but we can probably never find perfect labels that work in all languages. --Zolo (talk) 12:04, 25 April 2013 (UTC)
Oppose Having a broader "depicts" property like this is a great idea, but I agree with Zolo that it would make more sense to relabel "depicts" to "subject" than to create a new property to accomplish that. Having multiple properties that describe the same thing in different domains is not a good idea. Emw (talk) 15:25, 27 April 2013 (UTC)
Here your classification reaches its limits: if you have different classifications using "subclass of", how do you want to differentiate them in the infobox ? Just an example. A ship is define according to its purpose, "subclass of": military ship and by its propulsion type, "subclass of": nuclear propulsed ship, how do you do the extraction in the infobox with only "subclass of" ? Snipre (talk) 14:53, 29 April 2013 (UTC)
Please mention that there is a second property "watercraft type" Property:P288. Short/simple answer: It would be both. Uhm.. I think the template could split up both items, so that they could displayed as e.g. "Invincible-class aircraft carrier" (en:HMS Illustrious (R06)). --#Reaper (talk) 20:32, 29 April 2013 (UTC)
Snipre, how does your comment relate to my statement that this proposed 'class' property is redundant with P31 and P279? It seems like your comment is more of a general question about 'subclass of', and thus better suited for Property_talk:P279. It's a reasonable question that's worth discussing, but it seems independent of this particular proposal. Emw (talk) 02:51, 30 April 2013 (UTC)
Perhaps we can move this discussion but this proposal with its generalization concept gives me elements about limitations of general properties for classification so I just wrote here. Snipre (talk) 08:08, 30 April 2013 (UTC)
Oppose I agree that with "instance-of" and "subclass-of", we already have properties to express this. Plus, it doesn't provide a solution to the problem of differentiating between values in infoboxes, for an item can belong to several classes as well. The underlying problem remains the same, and eventually, we would need further properties like "sub-class" and "sub-sub-class", or "class 1", "class 2", "class 3", and so on. Instead, differentiating should be implemented with qualifiers (perhaps "of-item", as proposed below), which makes it a lot more flexible.--Kompakt (talk) 10:59, 17 May 2013 (UTC)
Venue / Veranstaltungsstätte
Latest comment: 11 years ago3 comments3 people in discussion
стыковочный узел при первой стыковке, стыковочный узел при второй стыковке и т. д./docking port for the first dock, docking port for the second dock etc
Strong support for both. Qualifiers are avaible, so we can use them to distinguish which version type we have. But please define an exact set of allowed parameters for Versiontype property. --Pyfisch (talk) 08:44, 18 May 2013 (UTC)
Comment - If the name is so generic people are going to use it for different stuff. If it should be only for software then it should be called "software version". --Tobias1984 (talk) 17:08, 19 May 2013 (UTC)
The place where the person is, or has been, resident. As seen in infoboxes on Wikipedia (Infobox person). Not to be confused with the Official Residence property.
what is the difference with Official Residence property ? Old official residence can be described with Property:P263 with qualifiers and what are the definition of residence if it isn't the official one ? To live 3, 6, 12 or month ? To have a house or to rent a flat is suffisant ? For me that is not relevant. Snipre (talk) 09:28, 2 April 2013 (UTC)
As said in the description "Not to be confused with the Official Residence property". These are not the same. The Official Residence property is used with office articles, not person articles, and is used to specify buildings which are official residences. This information already exists in infoboxes on wikipedia, as shown in the proposal. Danrok (talk) 16:18, 7 April 2013 (UTC)
Support If it is allegedly not relevant as to the location of a living residence why is this information currently hosted in wikipedia? As this information is currently viewed as revelant on the wikipedias it should be assumed to be relevant for wikidata as well.
Support This property is clearly relevant; Wikipedia is full of residence information. Of course, that doesn't mean it needs to specify a person's street address. Emw (talk) 20:50, 20 April 2013 (UTC)
Support - maybe it's not that relevant, it's a field in many infoboxes, and therefor a logical property. Edoderoo (talk) 11:16, 21 May 2013 (UTC)
Comment seems very relevant to me, good to know the list of places where a person has taken residency. Many towns and cities put up memorials to say this person lived here, so it must be significant. Not to be confused with citizenship, not everyone becomes a citizen of the country where they're living and working. Danrok (talk) 11:22, 21 May 2013 (UTC)
Significance: Victor Hugo (French) resided in Guernsey (British), 1855 until 1870, where he wrote his most famous works. Danrok (talk) 11:46, 21 May 2013 (UTC)
Maybe, but in ice hockey, if he shoots from right, he is often left-handed. In tennis most of players who are right-handed players also play with right hand, except some like Rafael Nadal. --Stryn (talk) 15:54, 14 April 2013 (UTC)
Comment - I think we should make a qualifier "type of activity" that links to items. handedness could then be for example "right handed" & activity = "writing" & "left handed" & activity = "throwing" etc... --Tobias1984 (talk) 17:43, 6 May 2013 (UTC)
Support -- This could be used for many things, including, of course, baseball. TCN7JM 20:29, 6 May 2013 (UTC)
Comment - I'm still trying to find out how such a change of meaning is handled at Wikidata_talk:Property_creators. I was thinking that we could just move this discussion to the properties talk page and then change the description of the property. --Tobias1984 (talk) 12:37, 12 May 2013 (UTC)
A social network that the person has an account on, to be supplemented by a qualifier property "social media address" (Property:P554) indicating the account name on that social network.
I'm not completely sure this is a good idea, but it's probably better than creating separate properties for individual social networks, as was proposed earlier. There probably is lots of interesting data one could get from this (as I mentioned under the Twitter account proposal, one could use this to analyze Twitter text output of all people elected to X position who also have attributes X). If this is done, I think this property's use should be limited to those individuals who are already public figures, and not those who are only on Wikidata because of their association to someone else. --Yair rand (talk) 16:32, 28 April 2013 (UTC)
SupportNice hack to use one property for multiple websites. Note that you need to propose the creation of the "social media address" property as well to complete this. Filceolaire (talk) 21:06, 14 May 2013 (UTC)
This properties value can change in time, and needs to be updated on many language articles for active tennis players. Doing this on a centralised place on WikiData makes the most sense. Edoderoo (talk) 20:09, 29 April 2013 (UTC)
Support - Would this property also be used for point groups and space groups? E.g. Diploidal {crystal system = cubic} or Point group 200 {crystal system = cubic}. Or would it be better to say "point group 200" {subclass of = diploidal} and "diploidal" {subclass of = cubic}. --Tobias1984 (talk) 13:04, 18 May 2013 (UTC)
Support If there is no problem with no latin alphabet. Or we can think about qualifiers to specifiy to which alphabet the unit symbol refered. Snipre (talk) 09:58, 21 March 2013 (UTC)
Comment I think we should rethink the datatype. AFAIK a multilingual string datatype is planned. This would fit nicely for this property, since it needs to be translated, but creating an item for each unit symbol seems a bit over-administrated. --Faux (talk) 21:31, 26 March 2013 (UTC)
As far as SI units are concerned, unit symbols are language-independent (See). "30 kilometres" in English is translated into Chinese as "30公里" whereas "30 km" remains the same. (I don't know Russian.)
Since Unicode supports μ, superscripts and a middle dot (See and see), all SI symbols can be written in plain text (without TEX syntax): μm, km/h, m², N⋅m, J⋅K⁻¹,… --F705i (talk) 12:35, 25 April 2013 (UTC)
I don't quite understand the opposes but another concern is that there should be a way to get this for any administrative entity, such as a state, province or territory. Shawn in Montreal (talk) 23:59, 30 March 2013 (UTC)
It's because this property represents a very plausible use case for Wikidata queries. If information like "largest city" can be obtained with a query, it would be best to not create a property for it. Emw (talk) 00:12, 31 March 2013 (UTC)
Comment Usually a country's "largest city" means its "most populous city", and query surely can do the job. But it's not that simple. For instance, there was a prolonged discussion in Chinese Wikipedia of whether or not Shanghai is the largest city of China. It's not the largest city based on population. But finally the community accepted that Shanghai is the largest city of China even though we don't know the criteria, because it's a widely accepted statement, which is stated in enormous sources, including sources from Chinese government and many mainstream media all around the world. --Stevenliuyi (talk) 16:33, 31 March 2013 (UTC)
Comment In Upplands Väsby Municipality, Stockholm is the most populated "City", but not a single person in the City of Stockholm lives in Upplands Väsby. The city has 2 ha of land, and 0 population in that municipality, the rest of the city is located in 11 other municipalities. How is such an anomaly handled by queries? -- Lavallen (block) 15:23, 16 April 2013 (UTC)
Oppose See en:World's largest cities for some discussion on how ill-defined the simple term 'largest city' is--essentially both 'largest' and 'city' require clear definition first before it can have any meaning. The preferred method is for cities to have 'population' and 'is in..' properties and a query can determine which is 'largest' per the parameters selected by the query's author. Joshbaumgartner (talk)
This will allow the addition for information about terminus information to linear features like roads and rail lines. It will use the property "is in the administrative feature" as a qualifier to denote the geographic location of the terminus, and "terminus direction" (proposed below) as a qualifier to denote which end of the feature this is (northern, southern, etc.) —Scott5114↗[EXACT CHANGE ONLY]06:44, 18 May 2013 (UTC)
Indeed, while cardinal directions will be the usual (and thus "suggested") values, there would be no reason things like "up" or "down" couldn't be used. We need the flexibility to use other ways to describe termini, so I don't support outright restricting it to cardinal directions. There are some complicated examples of roads in the US having three or four ends (as an example, Oklahoma State Highway 63A, which is Y-shaped, having three ends). —Scott5114↗[EXACT CHANGE ONLY]22:09, 20 May 2013 (UTC)
Comment Could this be renamed to just 'direction'? That way it could be used as a qualifier for 'adjacent station' on circular routes which have no termini, such as the Glasgow Subway. Gareth (talk) 08:13, 25 May 2013 (UTC)
Info NATO reporting names are officially assigned by NATO and the Air Standardization Coordinating Committee to provide references to Soviet, Warsaw Pact, and Chinese aircraft, missiles, submarines, and military equipment. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
ORCID
Latest comment: 11 years ago2 comments2 people in discussion
Done
Description
ID for researchers, other contributors to published works (including Wikimedians!), etc. Already used in en:Template:Authority Control. See en:ORCID.
Comment I think "issuing authority" is a better name, since some currencies are not issued by "central bank". --Stevenliuyi (talk) 15:36, 9 May 2013 (UTC)
Comment on further reflection, I am thinking just a generic 'quantity' property would be fine as such a qualifier. But since we don't have numbers yet anyway, I'll leave it for now. Joshbaumgartner (talk) 05:41, 16 May 2013 (UTC)
This property can change in time, and needs to be updated on many language articles for active tennis players. Edoderoo (talk) 20:26, 27 April 2013 (UTC)
Comment how to handle with differents values? Will every wiki use the same "design" (of course if they want to use this property)? Some examples: en-wiki: 579–110 (84.03%) de-wiki: 577:110, it-wiki: 577 - 110 (83,99%) --Stryn (talk) 15:48, 1 May 2013 (UTC)
In theory, the numbers should be the same. We could add the percentage as a separate property, then every language can decide to show it or not. The main reason that the numbers are not the same today, is that it is far too much work to keep all tennisplayers up to date on all languages. Edoderoo (talk) 07:17, 2 May 2013 (UTC)
Support, but not percentages as a separate property. Even ATP/WTA/ITF don't have those percentages, so we don't have any realiable sources for them. --Stryn (talk) 09:36, 2 May 2013 (UTC)