Question What is the difference between a praenomen and a given name, and between a cognomen and a surname? Also, is there a more generic version of nomen that might be usable? (Clan name, maybe?) If avoidable, I think we should try to have as few culture-specific name properties as possible. --Yair rand (talk) 03:04, 11 November 2015 (UTC)
From a Wikidata perspective, it would be that praenomen link to items for praenomen, P735 to items for given names; P734 links to whatever it links and cognomen to items for cognomen (and nomen to items for gens). I added links to related categories and lists to the proposal. The article linked in the proposal explains how Roman naming as well as the function and selection of various parts evolved .. at some point, one or the other could be considered similar to given names and family names today, but later or earlier not. One of their characteristics is their designation as praenomen and cognomen. It's possible to use the same property for clans and Roman gens, but I don't think it helps when adding or checking values. What do you think? --- Jura13:25, 11 November 2015 (UTC)
Comment I changed the second proposal to "Roman nomen gentilicium". This should avoid potential issues with other nomen that are not for the gens. @Filceolaire, Jonathan Groß: is this ok with you? Potentially, we might need an other property for names that are not any of the four. Shall we add this now as well? --- Jura07:44, 13 November 2015 (UTC)
Discussion of proposal format - comment here on the proposal format
Comment the second format for proposals was chosen to view them concurrently and simplify property creation by admins. --- Jura12:12, 10 November 2015 (UTC)
Support Indipendently of the survey, I recently ran across the need for such a property when trying to represent in Wikidata the structure of the Government of Romania, in light of the recent change of the cabinet.Andrei Stroe (talk) 07:59, 19 November 2015 (UTC)
Could you provide English translation for your Russian texts? I can't read Russian, so I have no idea what you're proposing. And please provide a correct example. Mbch331 (talk) 10:39, 27 October 2015 (UTC)
Oppose This might be a useful piece of information, but the data type and example need to be specified, as well as a more detailed description and motivation for why it is useful.Josh Baumgartner (talk) 19:01, 28 October 2015 (UTC)
Support it's not appropriate to oppose a proposal merely because it's written in Russian .. seems to be part of series of problematic property creator actions by Joshbaumgartner. --- Jura23:16, 30 October 2015 (UTC)
@Jura1: My opposition has nothing to do with the proposal being in a particular language. Mbch331 was asking for a translation (a perfectly valid request). My opposition is that there is no valid example or datatype listed. Until they are provided, this proposal cannot be properly considered and so until it can be, I oppose its creation. Josh Baumgartner (talk) 22:42, 6 November 2015 (UTC)
Well, you opposed it because you don't understand it as it's being written in a language you apparently don't understand. --- Jura00:49, 7 November 2015 (UTC)
@Jura1: The example is (as of this edit) Universe (Q1) → Earth (Q2), which is not in Russian, and it clearly says "invalid datatype (not in Module:i18n/datatype)", also not in Russian, so please stop claiming your own reasons why I oppose this, and instead refer to what I wrote above. We need to know how a proposed property is going to be implemented before we can complete a discussion of its merits. Josh Baumgartner (talk) 21:52, 16 November 2015 (UTC)
If you set your interface to Russian and look at the form to copy-and-paste, you will notice that he did choose a datatype. We know well that the formatting of the template is quirky and doesn't work well. This is probably the reason why we ask property creators to complete it in if it wasn't done during the proposal process. Not sure if we really should expect a ru-only user to write you a translation in English .. Logically, we would need to ask him that in Russian. What do you think? --- Jura11:46, 17 November 2015 (UTC)
Using Google Translate I understand most of what's entered and I've cleaned the documentation. Still need a valid example though. Mbch331 (talk) 22:05, 17 November 2015 (UTC)
Ballotpedia is a MediaWiki site with a domain of American political entities. Its culture is very similar to the Wikimedia Foundation sites: neutral, accurate, verifiable, free and open information. Its text is licensed under GNU Free Documentation License (Q22169). Ballotpedia combines volunteer contributions with writing paid by Lucy Burns Institute (Q16949612). In addition to its large size (hundreds of thousands of articles), Ballotpedia is comprehensive and more granular in its domain than even Wikipedia and Wikidata are right now. We would be well-served linking to Ballotpedia as a knowledge model for American politics. Runner1928 (talk) 22:01, 18 November 2015 (UTC)
Click on the example source provided. Then download the excel sheet 'U.S. Summary & Alabama -Missouri'. Then for state fiscal expenditure look at the 'State Government Total' column and the 'Expenditure' row. Other sources will be needed for country government expenditure. We plan to use data from the OpenSpending project in the future. Mcnabber091 (talk) 20:44, 5 April 2014 (UTC)
@Pasleim: Hi Pasleim, a qualifier for fiscal expenditure could be 'education spending' or 'interest payments'. I am not too familiar with Wikidata but this is my suggestion for how we can organize this information. Mcnabber091 (talk) 13:19, 21 September 2015 (UTC)
Comment @Joshbaumgartner: I am confused what happened with this property? Is there a an exisitn expenditure property? Would the 'expenditure' property work for both corporate expenditure and fiscal expenditure?Mcnabber091 (talk) 05:48, 15 December 2015 (UTC)
Done - @Mcnabber091: it looks like this was united to be a general expenditure property, there seems to be general support, so I've added it. You should be able to edit the property further if needed (for example set constraints) and of course you can use it now! ArthurPSmith (talk) 16:38, 15 December 2015 (UTC)
Artsy Genes are a generalization (some might say unholy admixture) of artwork type, technique, material, genre, movement, etc. They are assigned to an artwork not as binary values, but as a grade (0-100). They allow for very interesting associative artwork search, see this sequence.
GRID is a recent free (CC-BY-4.0) offering from Digital Science that provides a global database of about 50,000 education and research institutions. There is considerable metadata provided including some relationship information, and it would be useful to link this with wikidata records for those institutions. ArthurPSmith (talk) 18:08, 11 November 2015 (UTC)
@Pigsonthewing, Runner1928: I'm not certain they will always use that prefix though it is likely and is true now - however removing the 'grid.' prefix leaves what looks like a floating point number but is actually a string, and may be subject to misinterpretation/parsing trouble. I think it is better to keep it clearly a string with the prefix, even if there's a slight redundancy there. ArthurPSmith (talk) 14:54, 24 November 2015 (UTC)
I'm not persuaded by these arguments. It's clear that the sting "grid" is a label, not part of the identifier, I therefore Oppose the property as proposed, but will drop that if the format is changed as I suggest Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits09:42, 11 December 2015 (UTC)
(from the GRID team) just seen this discussion, glad it's looking useful for people. To clarify, the grid. prefix is part of the identifier, it's what appears in all the API responses and database downloads. The rest of the format is correct, \d+\.[a-f0-9]+ should match all the ids that can be created. Let me know if there's other stuff I can answer :) --IanCalvertDsci (talk) 09:20, 14 December 2015 (UTC)
Hey @IanCalvertDsci: - welcome to wikidata! Once this identifier property is in place I was planning to put together a "bot" import to wikidata from the GRID dump file; however, I'm not sure of the best way to correlate records. It looks like only about 1/4 of your entries have ISNI ids - so that would be a start, but fairly incomplete. A similar number seem to have wikipedia URL's that should be possible to link through to wikidata id's. For the rest it would probably have to be something based on name and address and I can see that running into challenges with mismatches or overeager matching. Have you thought about adding wikidata ID's to the grid dump at some point so the link can be made more reliably? ArthurPSmith (talk) 14:59, 14 December 2015 (UTC)
Research Papers in Economics is one of the largest repositories for academic preprint manuscripts. It provides open access links to hundreds of thousands of articles. For authors included in the database in provides disambiguation as well as rankings and many other features. Over 50,000 researchers have a RePEc Short-ID. Many Wikipedia articles for economists link to RePEc pages. ChrisSampson87 (talk) 15:31, 2 December 2015 (UTC)
The International Fencing Federation (FIE) is the governing body for the Olympic sport of fencing. This database includes all fencers holding a FIE licence, mandatory for all major competitions. Jastrow (talk) 11:36, 13 December 2015 (UTC)
Oppose use as proposed but Support as a qualifier to string and text properties in other languages. The hanja version of the name for Pyongyang should be given by official name (P1448) and/or native label (P1705) and/or name in native language (P1559), not by this property (but use the "Romanisation" qualifier to give the Latin script version of each of these names). This property could however be used to give the hanja name for "London" in a qualifier to the official name (P1448) property for use in Korean language infoboxes. I have changed the example as my version of this property. Nikki please check and confirm you copy. Filceolaire (talk) 01:01, 27 June 2015 (UTC)
@Filceolaire: Your example is incorrect, that's not en:Hanja, it's en:Hangul (the way Korean is normally written). This property would be very similar to name in kana (P1814) (which you supported without requiring it to only be used as a qualifier - has something changed since then?) - like Japanese is not primarily written in kana, Korean is not normally primarily written in hanja, and like kana is often included in name templates, in brackets in opening sentences, etc, hanja is too, so it should be allowed anywhere that name in kana (P1814) is allowed, i.e. as a qualifier if it's the hanja version of a Korean name in a statement using properties like native label (P1705), name in native language (P1559) and official name (P1448) or as its own statement if it refers to the hanja version of a Korean label (since labels can't have qualifiers themselves). - Nikki (talk) 06:40, 27 June 2015 (UTC)
You raise a good point Nikki. Thinking about it some more. There is a difference between a property called "name in Hanja" and a property called "hanja".
"name in Hanja" could be a property specifically for names. It is similar to all the other multiple "name" properties we have and it can be used as a primary property just like official name (P1448), native label (P1705) or name in native language (P1559). This is based on the assumption that if an item has multiple names then the hanja name just another, additional name independent of the other names.
If, on the other hand, each of the multiple names needs a it's own hanja version then it seems the "hanja" is an alternative way of writing those names rather than being a separate name (and should be used as a qualifier). Which case applies? Filceolaire (talk) 02:31, 28 June 2015 (UTC)
@Filceolaire: I feel like I have already explained it as best I can so I don't really know how to continue this discussion without getting frustrated by going round in circles and repeating myself. If you're still opposed to the property, then we might as well reject it and revisit it when people who have experience with Korean are willing to contribute to the discussion. Alternatively, if changing the label to "name in hanja" makes it acceptable, let's do that. - Nikki (talk) 13:01, 18 September 2015 (UTC)
I'm sorry Nikki. I didn't mean to harass you. I've done some more reading and I think I understand the difference now. Hanja is the name written using 'chinese' characters. I think a better way to handle this is to have two different values for the various monolingual text proeprties - one in hangul and one in hanja with different codes to indicate if it is 'ko-hanja', or 'ko-hangul'. Unfortunately this is not allowed at the moment (I tried something like this on Park Geun-hye (Q138048) but I think you had better check I got it right). There are bugs on manifest for this T74590 and T95286. I'm afraid I do not think that a separate property like this is the way to go so I will Oppose this proposal. Joe Filceolaire (talk) 16:14, 18 September 2015 (UTC)
CommentP:P364 used to have the label "language". To match more closely its description, it's now labelled "language of the original work". This leaves a gap for cases like the above. --- Jura04:52, 12 December 2014 (UTC)
SupportComment One day we will have also wictionary linked, so every word must have a language. Not only names, but also radio/tv stations broadcast in languages. However names are a bad example, because names tend to move between languages, sometimes unchanged over centuries and sometimes more or less modified.--Giftzwerg 88 (talk) 05:14, 12 December 2014 (UTC)
Can you explain why this should have an impact? The properties you mention are about works, this proposed one is explicitly not for works. --- Jura12:35, 18 April 2015 (UTC)
I don't see that discussion going anywhere, nor is the merge proposal formulated that way. The result is that we still haven't sorted out this issue. --- Jura13:03, 18 April 2015 (UTC)
Support. The specialised properties are worth having but it is good to have this more general property for cases where those don't apply. Filceolaire (talk) 17:55, 18 June 2015 (UTC)
Oppose. We don't need specific properties, even two is too much. Single "language" property is enough. P364 shall be merged with P407 to such single property. -- Vlsergey (talk) 16:08, 26 June 2015 (UTC)
Oppose. Agree with Vlsergey here. One language property is enough for works and other items. It's different for people who need to differentiate native language and other spoken languages. --Hsarrazin (talk) 17:53, 1 August 2015 (UTC)
I think you might have misunderstood the proposal. We lack a generic property for languages. This is the proposal for it. --- Jura19:44, 29 September 2015 (UTC)
If that is true, then it should simply be 'language' and lose the 'except for...' part. Those more specific properties can then be marked as sub-properties of this one. Josh Baumgartner (talk) 17:51, 27 October 2015 (UTC)
So basically this is for entries where a word or name in and of itself is being discussed (i.e. in etymology and usage), and this is inescapably linked to one or a few languages? Circeus (talk) 23:51, 29 October 2015 (UTC)
Property might be useful for automatic generating readable descriptions from statements if object name is not available in any readable script in user language. This might be a standard way to provide transliteration or transcription of the name between many languages. The examples above are biased because they show romanization only, but other direction is also possible. Unfortunately I am not able to provide any such example. Paweł Ziemian (talk) 17:50, 27 June 2015 (UTC)
If the conversion is some kind of international standard like Hepburn romanization (Q667558) or ISO 9 (Q913336) it can be promoted to separate property. However, there are cases where such translation is country/language specific and generating N×N - N (country/language) properties is ridiculous. One generic property should serve for all relatively rarely used cases. If some of them became popular it can be always promoted later to dedicated property and converted by bot. Paweł Ziemian (talk) 19:10, 27 June 2015 (UTC)
One item can have multiple names, even in one language (via aliases). To be clear as to which name you are transliterating this property needs to be a qualifier to one of the other name properties. Unfortunately if this property is a qualifier then it can't have it's own qualifiers to tell you which transliteration system was used. This indicates that we need multiple properties - one for each transliteration system. Fortunately we don't need to transliterate all names since for most items, in most languages, the transliterated name will be in the label. I think. Filceolaire (talk) 03:00, 28 June 2015 (UTC)
I am not so sure about that! The Swedish transcription of for example Russian names are not always in the label, but rather the German or English, since those transcriptions are sometimes more spread in common media. And I would prefer to see a monolingual datatype in those cases, i.e. when the transcription is langauage dependant. -- Innocent bystander (talk) 10:56, 28 June 2015 (UTC)
It is not unusual that there exist a few methods for transcription from one language to another. I agree with argument that it should be a qualifier, but with requirement for auxiliary and mandatory qualifier it is impossible to implement this. This is the weakness point in my proposal. I think I should withdraw the proposal and introduce set of new proposals for specific transliterations, what was mentioned above. Paweł Ziemian (talk) 13:33, 28 June 2015 (UTC)
Support. Even if we end up with specific properties for every transliteration in wikidata we will still need this property for the transliteration properties to be 'sub-property of' so search can do generic transliteration searches. Joe Filceolaire (talk) 22:37, 2 August 2015 (UTC)
Oppose Transliteration properties make only sense as qualifier on name properties. This proposed property also requires a qualifier. We don't have qualifier on qualifier, so how can you use that? --Pasleim (talk) 19:32, 4 October 2015 (UTC)
Support as a qualifier (for properties such as titles or birth name) or property (for name items) when there is no more specific property available or if we just know it's transliterated, but we don't know for sure if it corresponds to a specific version of a transliteration standard. --- Jura13:49, 19 December 2015 (UTC)
So your idea is to drop the name of the transliteration standard? I'm not sure if in that case anyone will be able to reuse the claims as one will not even know if it's a translitaration to latin script or maybe a transliteration from cyrillc to Georgian script. --Pasleim (talk) 22:58, 19 December 2015 (UTC)
Isn't the script defined with the characters used in the string? What alternatives do you suggest? --- Jura13:43, 21 December 2015 (UTC)
Transliteration depends not only on script, but also on language. The same Cyrillic name transliterates differently into French/German/English. --Infovarius (talk) 15:06, 21 December 2015 (UTC)
That is probably good alternate proposal. I suppose we could implement both. Would you do the property request? --- Jura13:28, 22 December 2015 (UTC)
I don't quite understand what it adds. If the literal translation is used, it should be the label, otherwise it's non-official and shouldn't be added to Wikidata. If somebody wants to know what something is literally translated, I suggest using a translation tool. Mbch331 (talk) 13:30, 20 July 2015 (UTC)
Kraftwerk (German pronunciation: [ˈkʀaftvɛɐk], "power station") is a German electronic music band formed by …
Neither of these should have the literal translation as an alias because its simply not an alias. In order to generate the introductory phase of an article this information could be useful --15:15, 20 July 2015 (UTC)
Support only as a qualifier, because some info just don't go in label/alias... like the rough translation of a newspaper title :) --Hsarrazin (talk) 10:34, 24 December 2015 (UTC)
Depends on how much inference you want to do. There are some units (inches) that convert nicely (thanks, Queen of England) to SI, and some (pounds-force) that don't. --Izno (talk) 01:26, 1 September 2015 (UTC)
A more general conversion property might be better anyway though i.e. to get feet to yards to miles. I don't see a reason for the notion of "standard" vice not standard. Maybe the conversion property could have a qualifier of "unit standard" or perhaps use the "specified by" property as a qualifier. Actually, I like that idea. --Izno (talk) 02:32, 7 September 2015 (UTC)
An alternative would be to set a goal of always expressing quantities in a chosen set of SI units, and then having a property "source units" which preserve how the quantity was written in the source that supports the value. Ideally such a property would be attached to the reference, since several different references might express the same value in different units. If someone sets the quantity in an undesired unit, someone can always fix it later and preserve the source value with the new property. Jc3s5h (talk) 13:22, 18 September 2015 (UTC)
I am not very sure it would be very failsafe to write "m2" instead of "barn" here. And it would make it more or less impossible to use non-convertible units. -- Innocent bystander (talk) 07:30, 8 October 2015 (UTC)
Comment I suppose the question is if there should be single value constraint on this property. I'd tend to say yes, but we might need a second property to convert into a SI base unit. --- Jura22:31, 4 October 2015 (UTC)
This property should be used for measurement units to convert them to S.I. units so every units for measuring length would have this property for converting to 'meter'. Every unit for measuring energy (from kilotons of TNT to barrels of oil) would use this property to give the equivalent in 'Joule'. This is the crucial middle man that will let us compare any measurements. I suggest we rename this property as 'conversion to SI unit'.
For other conversions just use the general properties we already defined so "foot" is <length:12(unit=inch)>and <conversion to SI unit:0.3048(unit=meter)>. Joe Filceolaire (talk) 18:53, 12 October 2015 (UTC)
Support, but I would broaden the use to simply 'conversion to alternate units'. The units that are entered will determine inherently whether it is a conversion to a standard unit, SI unit, or whatever other kind of unit. We don't need separate properties for each type of unit you want to convert to. Josh Baumgartner (talk) 18:15, 27 October 2015 (UTC)
The property would be good to generate better search results. For example "Letters that look similar to H". I guess we could also make the property more general and call it "has very similar appearance". Although that is always a matter of judgement or opinion it could be used for things like 30 St Mary Axe (Q191161) and Torre Glòries (Q336246). --Tobias1984 (talk) 11:01, 24 October 2015 (UTC)
Discussion
Support also useful to fight domain name squatting. Also OK to generalize, the classes of the elements are enough to filter the results. author TomT0m / talk page11:06, 24 October 2015 (UTC)
Within ceiling exposure limits there are "maximum peaks" where exposure above the usual limit is permitted for five minutes within a certain time window. To facilitate this, I would like a generic "time interval" property to specify lengths of time. (The permissible exposure limit property included in the example does not yet exist; I am working with WikiProject Chemistry to determine how exactly we should model this information.) James Hare (NIOSH) (talk) 02:00, 17 October 2015 (UTC)
Discussion
Oppose with this name. James: A property called "Time Interval" is too likely to be abused for things that need a start time and an end time. Can we change the label to Duration? Joe Filceolaire (talk) 18:34, 19 October 2015 (UTC)
At its creation this property was called "duration" but some contributors modified it for their own purpose. We should see if this is a problem to keep a more general definition for this property. Snipre (talk) 15:42, 29 October 2015 (UTC)
@Snipre, James Hare (NIOSH): I can see extending the use of duration (P2047) for the duration of tracks on LPs but using it for exposure limits seems a step too far so I would be in favour of a separate property for this. The question then is if we have a specialist property for 'exposure limit time intervals' or if we have a generic 'duration' property used for exposure limits and other places where we need a qualifier to specify duration (then duration (P2047) probably gets classified as a 'subproperty of' such a generic property, along with some specialist property for race times). Personally I would go with using a generic 'duration' property for exposure limits since it is a qualifier to the important info - the dose in mg. Joe Filceolaire (talk) 22:12, 29 October 2015 (UTC)
@Filceolaire: Please look at the translated labels for duration (P2047): Dauer in German, duración in Spanish, durata in Italian. Only English has a special definition for this property. I can understand to have specific properties when you use the generic property several times in the same item and if you need then to use qualifiers to distinguish who is who. I can understand specific properties if you want to track errors by using a tight range for values or only one unit. But in the current property this is not the case. Right now I asked the extension of the application of duration (P2047) to all field using the label "duration"~on the talk page of duration (P2047). I propose to discuss this case there. Snipre (talk) 12:40, 2 November 2015 (UTC)
Oppose Not only was duration (P2047) labelled specifically only in English, it has been used widely already as a more generic 'duration' not specific to films. I have fixed the label to fit its current usage, and it should work fine for this purpose as well. Josh Baumgartner (talk) 21:44, 5 January 2016 (UTC)
Allows a community or project to make a list of items that are of interest to them. This opens WD as a data integration/editing platform to such projects: a prerequisite is to be able to get all relevant items back in a reliable way. I participate in 2 projects (see example values) that can use that, and in the process can contribute important info to the items of interest. Checked in "Generic" properties, and IMHO there's nothing appropriate. Vladimir Alexiev (talk) 14:09, 17 December 2015 (UTC)
Comment: I find it of less use as it a link that doesn't seem to go anywhere, nor have any references to where the data on the pages was sourced. There is also readily information about the scope or how complete is the list. The pages are not without value, just limited value without a ready means to lookup authors. — billinghurstsDrewth13:26, 21 January 2015 (UTC)
The aim of MAME is to be a reference to the inner workings of the emulated arcade machines; the ability to actually play the games is considered "a nice side effect". The project also documents the history, service manuals, screenshots, cabinet art/marquee, and related marketing materials. Thanks to some talented people the Internet Archive has made some of these games playable in the browser such as Targ which is free for non-commercial use. As games can have multiple version (bugfixes) you can expect a one-to-many relationship. Dispenser (talk) 22:49, 19 January 2015 (UTC)
I've emailed the collection's curator Jason Scott asking him over the process used. I imagine it's simply easier for him to reuse the existing scheme. This property is intended to represent MAME internals and IA links should probably use formatter URL (P1630). Dispenser (talk) 16:34, 24 February 2015 (UTC)
625746 WD items have GeoNames ID (P1566), and 117301 of them don't have instance of (P31). If "GeoNames feature code" is created, these "instance of" can be added automatically. Furthermore, we can use this property to check for agreement with GeoNames. Since GeoNames is dedicated to geo info, I'd trust it more than WD on this aspect.
Furthermore, this can be used to compare the GeoNames type hierarchy (which is only 2 levels) to WD's, and add more types to WD. Vladimir Alexiev (talk) 17:22, 16 October 2015 (UTC)
As it is, I think I have to say Oppose, because I have some concerns which make me question how useful it would be:
I'm not an expert on licensing, but GeoNames is licensed as CC-BY, which (as far as I understand) means it's incompatible with Wikidata's license and we can't use it to automatically add instance of (P31). The only purpose of adding this seems to be for using GeoNames' data and if we can't do that, there doesn't seem to be any point in spending time adding and maintaining it.
I don't think it's clear that it's not designed to be used for individual instances. I can imagine people adding "GeoNames feature code: H.LK" to individual lakes, because it wouldn't seem wrong, the feature code for something which is a lake is indeed "H.LK".
I'm also questioning how well we can really map the two. There are a number of differences and how someone wants to handle those really depends on what they're trying to achieve. For example, GeoNames has H.STM which it uses for both streams and rivers. If you want to convert H.STM to a single Wikidata ID (e.g. for adding instance of (P31)), you should probably use watercourse (Q355304) because you can't tell whether it's a stream or river. If you want to find all items which should use H.STM (e.g. to check whether Wikidata's data matches GeoNames), you want river (Q4022) and stream (Q47521) but not watercourse (Q355304), because watercourse (Q355304) is broader than H.STM. It's often more complicated than simply mapping feature codes to items too, for example, A.PCLH, which can be an instance of country (or any of its subclasses) with an end date qualifier, or P.PPLA2, which would be an instance of human settlement (or any of its subclasses) located in a second-level administrative division (or any of its subclasses) which is the capital of the same administrative division it's located in. -- Nikki (talk) 01:12, 19 October 2015 (UTC)
@Nikki: All these are good considerations about difficulties, but I don't thin they render the property useless. 1. I'm not saying we can map everything automatically and one-to-one. But we can still do useful checks. Eg H.STM would be mapped to Watercourse, and we can expect all its subclasses to also match H.STM. So if we find a subclass with *another* feature code, that would be an error to flag. 2. Adding a class (instance of) to 117k Wikidata places that don't have it, seems like a good first step, since that's better than no class at all, agree? 3. You're right regarding temporality: Geonames doesn't have historic info (and is missing historic places that are in DBpedia, such as Roman Empire aka Ancient Rome; for the Europeana Food and Drink project we're grafting them into the Geonames place hierarchy). But doing checks for current places is still very useful. 4. PPLA2 can be used not only to check type correspondence, but also to check (or insert!) capital (P36) (in this case, using gn:parentFeatureADM2). --Vladimir Alexiev (talk) 08:13, 26 October 2015 (UTC)
1: Not all subclasses of watercourse are H.STM, only some of them, e.g. canal is a subclass of watercourse here, but the Geonames code is H.CNL - like I said, the best mapping depends on what you want to do with it. 2: Of course I agree that it would be good to add instance of (P31), but where will we get the data from? Geonames is under an incompatible license, so we can't import data from there. 3: I didn't mention anything about temporality, I'm not sure who or what you're responding to there. - Nikki (talk) 14:02, 26 October 2015 (UTC)
@Pigsonthewing, Nikki: I fixed the links above so you can see feature code hierarchy and stats. But unfortunately there isn't a separate page for each code. That kind of matches Nikki's concern that these codes are applicable to place types not specific places. --Vladimir Alexiev (talk) 08:13, 26 October 2015 (UTC)
Support. I agree with Nikki that we cannot import info from a CC-BY database but we can identify correspondences like these. There may not be an exact correspondence in every case but that can be managed - including creating new item in some cases if we feel it worth doing. A bot can then be used to identify discrepancies between our info and theirs for humans to check against base data. This, I believe, is compatible with the licenses. Joe Filceolaire (talk) 21:43, 25 October 2015 (UTC)
ID of an artist in Artprice (Q2865858)' database. The database main purpose is to provide results of auction sales, but it sometimes also contains other details about the artists. Example for Van Gogh here
Two issues:
technical) Not sure what the identifiers should be. For Van Gogh, the URL is http://www.artprice.com/artist/11598/vincent-gogh-van It would seem that Van Gogh's identifier is 11598, contrary to other databases stripping the / does not appear to work. There may be another URL format that works but I could not find it. Unless someone finds it, I would suggest that we use longer identifiers: van Gogh's would be 11598/vincent-gogh-van
it is a for profit database, and much of the content is under paywall.
As I said, I removed the property proposal template because it was not quite fit for explaining things with the level needed for this proposal, if that is what you mean. More substantial arguments welcome. -Zolo (talk) 08:50, 25 October 2015 (UTC)
Some opportunities for this, or at least to come up with cases for humans to consider -- see below. However, the number of incidences of this property is likely to be quite limited.
Motivation
The motivation for this property grew out a discussion at Project Chat about the nature and characteristics of metaclasses.
Some further current examples, which may be surprising at first glance:
Arguably some of these relations might be better expressed as properties on the underlying subclasses. However, for the moment the relations between the underlying classes of the two sets of metaclasses are expressed by subclass of (P279) -- which means that the relation between the two metaclasses is indeed currently a metasubclass relationship.
An example of where a property has been introduced, and many of the relations have been changed to use it, can be seen in
Most television series classes use genre (P136) to express their relationship to instances of television genre (Q15961987). However, as a look at the "from related items" section of the Reasonator entry for soap opera (Q23739) reveals, there are still many television series classes using subclass of (P279) -- which should probably be discouraged, given the relationship can instead be expressed by a property.
Some further notes:
The property is intended to capture relationships other than those already captured by subclass. Therefore it should not be applied if metaclass A is genuinely a subclass of metaclass B -- ie if it should be understood that all instances of metaclass A are also instances of metaclass B.
Due to the transitive nature of subclass of (P279), all subclasses of a metasubclass A are also metasubclasses of the metaclass B. So the property should be applied to the highest item for which it is valid in the class tree on the domain side.
Similarly, a metasubclass A is also a metasubclasses of all superclasses of a metaclass B. So the property's value should be the lowest item in the target class tree for which it is valid. In this way the levels on the two sides of the property should match -- engine metaclasses with engine metaclasses, generic manufactured item metaclasses with generic manufactured item metaclasses.
It is possible that in future either metaclass (Q19361238) or metaclass (Q19478619) may be used to manage a controlled vocabulary of metaclasses -- a set of metaclasses that had been 'signed off' as okayed by being made a subclass of one of these items, so that any attempt to use instance of (P31) from a class item to any item not in this 'approved' class would throw a constraint violation. If that happens, then any attempt the "metasubclass of" property on or to an item not in that class should also throw a constraint violation.
I've found the above candidates for the property using this query tinyurl.com/pazxyf4 to throw up potential matches. It could be refined, as at the moment it only has quite a low true positive rate. My main motivation for suggesting the property is therefore simply to record what of these quite curious relationships exist -- because even with the query, there's no obvious way to generate such a list algorithmically, it currently relies so much on manual validation. So given that it's hard to recreate such a list, it seems proportionate to introduce a property to be able to record it.
I should also emphasise that my intention would be for the property to be descriptive rather then prescriptive -- ie to try to identify and make accessible some relationships that are in the database currently, rather than to be proposing any relationships that should be in the database.
Of course, having identified such relationships, one can then look for gaps in them -- what classes that are instances of the metaclass on the domain side appear to be missing superclasses that are instances of the metaclass on the target side? (This is analogous to looking to see which items appear to be missing a particular property) Or, are there items that might be created to make structures more systematic -- for example, should a manufactured object family item be created, to be a superclass for aircraft family (Q15056993) and engine family (Q15057020), a "metasubclass of" target for product model (Q17444171) ?
But my main motivation is simply to identify and have a way to be able to capture these patterns, which are currently implicit in the database, but not easily accessible. I think that's worth a property.
Support (after discussion) : captures something actually. Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page10:12, 23 October 2015 (UTC) Needs a little more thinking after discussion.
@TomT0m: I hope you find the explanation above now a little more complete and detailed. :-)
The thing I should stress is this is not an attempt to replace subclass of (P279), and I see no purpose that would need a meta version of instance of (P31). The aim is simply to capture some relationships that simply can't be expressed at the moment.
I don't think it really complicates the model much, as the number of instances of the proposed property would be vanishingly few. Remember, it is not intended to be applied where subclass of (P279) can be applied. So rather than being a heavy complication, I think a better way to view the property is as simply identifying a handful of curiosities -- which already exist in the model, they're just not easy to extract.
I think it will therefore hardly impinge on contributors or practices at all, as its domain of application will be so very very limited.
But I think it does have interest, and some potential for usefulness, so I do hope you might reconsider your initial oppose. Jheald (talk) 12:15, 23 October 2015 (UTC)
(ec) One way to look at the property is to see it in some ways analogous to properties for this type (P1963). For attributes of items that are expressed as properties, P1963 indicates what properties one might expect to find on a particular class of items. Analogously, for attributes of items that are expressed through subclass relationships, the proposed property indicates what sort of "subclass of" targets one might expect to find on a particular class of items. Jheald (talk) 12:35, 23 October 2015 (UTC)
@Jheald: So a good description would be "subclasses of instances of the subject metaclass's are instances of that metaclass" ? I think I'm beginning to understand : a typical car family subclass is a car models indeed. There may be other kinds of car famylies. But what's the value added to simply say that "car model" is a subclass of "car family" ? The "likely to be" in your description ? author TomT0m / talk page12:46, 23 October 2015 (UTC)
Because "subclass of" requires that every instance of a "car model" is an instance of a "car family". But that's not true: the two are considered different things. Jheald (talk) 12:59, 23 October 2015 (UTC)
@Jheald: Sorry, but I fail to understand this proposal. Can you expand one or two of the example relation between two metaclasses: instances of this metaclass are likely to be subclasses of classes that are instances of the target metaclass wrt. say, the element example ? I can't understand the relationship beetween elements and rows in the table. author TomT0m / talk page12:32, 23 October 2015 (UTC)
But an instance of a Hydrogen is not an instance of a Period. subclass of (P279) is therefore not an appropriate way to model the connection between chemical element (Q11344) and period (Q101843). So I suggest this new property, and then the relationship could be captured.
Note that I'm not claiming that this is necessarily the right (or best) way to represent which period of the periodic table Hydrogen is found in -- I merely wish to be able to note that this appears to be how the relationship is seemingly being modelled, currently. Jheald (talk) 12:50, 23 October 2015 (UTC)
If we take the "atomic" definition of hydrogen (for simplicity) : «type of atom with number 1 atomic number», so the item may be hydrogen atom (Q6643508), then this would make period 1 (Q191936) a subclass of atom, so a class of atom. period 1 (Q191936) is then "atoms of elements in the first row of the periodic table". This would make period (Q101843) a metaclass of atoms as well.
So if we say that:
«level 0» is the instance level,
«level 1» is the class of atoms level
«level 2» is the class of class of atoms level (so the first metaclss level
It's a bit tricky. There are rather few examples, and they're not particularly easy to find.
To take the example you raise: one would be looking for instances of horse breed (Q3745054) to also be subclasses of instances of horse (Q726). That doesn't work, because instances of horse (Q726) are individual horses, which have no subclasses. It's also the case that there aren't may instances of horse breed (Q3745054) that are subclasses of anything.
@Yair rand, Jheald: I got one more example : see . "Tritium atom" is a class of atoms, as "Hydrogen atom" is. We have SubType|Tritium atom|Hydrogen atom}} because any tritium atom is an hydrogen atom. But we don't have "isotope" (defined as a metaclass of atom) subclass of "element" (defined as a metaclass of atom as well) because "Tritium atom" does not belongs to the class of elements, only "Hydrogen atom" does. With those definitions, we would have "Isotope" metasubclass of "element". author TomT0m / talk page14:42, 2 November 2015 (UTC)
@Yair rand, Jheald, TomT0m: Please read that document before supporting or not this property. The use of metaclass and all related properties have a strong impact on the type of ontology we want to have for WD. This is typically the kind of decision which will have some impact later when we will build tools to extract information (not only data) from WD or when we will build tools to check data consistency. For me the use of metaclass or not should be a choice of the community with a clear description of the consequences, advantages and drawbacks of each option. If you have time this is another document comparing both structures. Snipre (talk) 15:53, 2 November 2015 (UTC)
You're a little late, this thing talk of metaclass in (object oriented) programming. A relevant notion would be Liskov substitution principle (Q957386) is that case. But we are not doing programming, and you can read metaclass (Q19478619) to see there is a lot more documentation for metaclasses on knowledge representation. But this precise property is far from being structuring for the use or not of metaclasses and will have a very low impact. If we really don't use metaclasses, which is really not true in current situation, then this property will just stay unused. No fear to have for ... what ? author TomT0m / talk page16:09, 2 November 2015 (UTC)
The essential question is do we want to allow a more automatic way to generate relation and in that case we will go towards some programming logic. I am not a specialist but I think this is a question which will have some consequences later or even nowas we are developping some query tools.
I don't agree with you about creating metaclass structure and decide later if we will use that system: creating that kind of structure will just allow parallel structures to be used and we will have to convert later all that workbecause we were not able to ask the good question at the good time. Snipre (talk) 18:52, 2 November 2015 (UTC)
@Snipre: You don't seem to understand. That property won't have any influence on us using Metaclasses or not as we simply don't need it to do so. The project about reasoning is WikiProject Reasoning, created by Markus who always have been supportive on my views about all these. He's an expert, so if this was anything of a problem to use metaclasses, we would know (I think I saw a draft from him and/or Denny about pushing metaclass modelling possibilities on OWL2). found it see Markus' edit on the history. author TomT0m / talk page19:12, 2 November 2015 (UTC)
So IF
Class A is an instance of metaclass B AND
Class A (and most other instances of metaclass B) is a subclass of Class C AND
Class C instance of metaclass D
THEN
metaclass B is a 'metasubclass' of metaclass D.
Is that it?
The bit I don't like is the "most" in the description above and the "likely to" in the property description. How to queries spot the exceptions?
@Filceolaire: A good argument could be that it allows to represent some kind of "ordering hierarchy", for example in the case of "elements/isotope" metaclass couple, clearly isotope classes are "smaller" than their corresponding atom classes. An analog property for hierarchies of administrative division this is useful as well : regions/states whatever can be divided into smaller parts, which can be expressed by located in the administrative territorial entity (P131) more or less, but the order beetwen units type cannot (City<departement<region<country for example in france). A more convincing example could by taxons rank in biology : kingdom >...> genus> species, with taxons defined as classes of organisms. Then with "metasubclass of", we could express the rank hierachy : kingdom metasuclass of ... genus metasuclass of species. author TomT0m / talk page18:33, 8 November 2015 (UTC)
The narrator is such an essential aspect of storytelling that we should not leave characters (P674) to deal with it. First because there are extradiegetic narrators (non-character narrators). Then also because the narrator may change in one story, so we need to be able to use qualifiers on the names we associate with the property. And the new property will let us call specific items that qualify the storyteller such as unreliable narrator (Q650118) or protagonist (Q215972), as suggested above. Thierry Caro (talk) 02:29, 9 August 2015 (UTC)
Discussion
Thierry Caro Can you fix the examples? the "->" represents the proposed property so the second item should be the value of the property - the item the property links to; in this case the character who acts as narrator. Joe Filceolaire (talk) 22:59, 11 August 2015 (UTC)
The examples are fine as they are but I admit they can be a bit misleading. So please let me explain them. The first example is to show that the value of the property can be a character and I chose In Search of Lost Time (Q464928) as an example because it is one of the most commonly used examples in narratology (Q382451) after Gérard Genette (Q266247) developed key concepts using that work as his main source material. Narrator (Q3336121) is both the narrator of the story and a character in the novel but we don't really know his name, except for one passage, and so critics usually call him Narrator (Q3336121). So In Search of Lost Time (Q464928) → Narrator (Q3336121) is correct. As for the second example, it is here to show that the property could be used out of the literary field - for instance for movies - but also to show that we might use it with a value that would not be a character but instead one of those items about narrator-related concepts that we have here and that are used in narratology (Q382451), such as unreliable narrator (Q650118). At some point I think there will be more options because I think I will soon create entries for 'homodiegetic narrator', 'heterodiegetic narrator', 'intradiegetic narrator' and 'extradiegetic narrator', etc. All these concepts, again devised by Gérard Genette (Q266247), are the common way to describe a narrator in the discipline. And so The Usual Suspects (Q132351) → unreliable narrator (Q650118) is also correct! Thierry Caro (talk) 17:16, 12 August 2015 (UTC)
If an actor is widely credited as a narrator I see no reason why they should not be accepted. Whatever, your question is interesting because there might be, for these kind of situations, a potential overlap with voice actor (P725). Maybe the latter one should change its English description? All other languages might use this only for people who dubbed a movie originally in another language while English users, with the current description set as 'voice actor', might also use it for actors who only use their voice but don't appear in a movie shot in their language. The property discussion page suggests that it was created to deal only with changes of language but the English description seems looser creating a potential collision with the property I suggest. The problem has been raised by a user back in 2013, with no answer. Thierry Caro (talk) 23:18, 12 August 2015 (UTC)
I oppose this if it is to be used in the way described by Thierry above. Instead I propose
If the narrator is a character then the item for that character should be the value for this property.
If the narrator is not a character in the book then don't use this property.
If the character is in the book but not named then create an item named 'unnamed narrator' with description "of <name of the book>" and refer to 1. above
If there is a narrator in a film or a play then name the actor and use the "Character role" property (or the "as" property) to say that this actor played the narrator. This might use a generic 'narrator' item.
I don't object to seperate "set in period" and "set during event" properties, but I'm not sure the distinction between "era" and "event" is going to be meaningful in all contexts. For example while we could say Dad's Army (Q659575) → 1940s (Q36561) (as well) that's less precise and/or duplicative so I think I prefer just one, especially as if Wikidata:Property proposal/Unsorted#period is created, we can infer the period a work is set in from an event if the event has a period property. Thryduulf (talk: local | en.wp | en.wikt) 01:16, 23 November 2015 (UTC)
Answer In my opinion, that is too fragile and restrictive an approach. It is much more straightforward to reference a claim of a straight season count. Dancter (talk) 19:07, 27 November 2015 (UTC)
Support. Not every series is going to have an item for every season (long running radio programs on obscure local broadcasters for example) Joe Filceolaire (talk) 17:29, 26 November 2015 (UTC)
"Don't have" is not the same as "won't have". There is no good reason why those series of Butterflies should not have items created. I was looking for an example of the claim of the later class ("long running radio programs on obscure local broadcasters"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:24, 27 November 2015 (UTC)
Support As I pointed out in my motivation I'd love to have this new property to make "nominated for" statements more explicit. --Jobu0101 (talk) 08:26, 28 December 2015 (UTC)
Support I'm fine with that solution, too. Actually, I think it is reasonable to use one property for both cases. But I wouldn't rename winner (P1346) (what User:Mbch331 proposed) because that property is not only used as quantifier. I think the correct way is User:ValterVB's solution to introduce a new qualifier only property to. --Jobu0101 (talk) 09:52, 28 December 2015 (UTC)
Support to this proposal. For the more generic property to I prefere waiting. I don't like the actual solution for winner/candidate, I would like to have a single group for both. --ValterVB (talk) 18:34, 31 December 2015 (UTC)
@Mbch331: @ValterVB: I realised that it is useful to restrict the new property not only to instance of (P31) of human (Q5). For example, in the early years the Academy Award for Best Picture was given to the production company and not to the producers. So here companies were nominated and we should use the new property also for them. Do you agree? Then I'd change the allowed values above. --Jobu0101 (talk) 12:05, 1 January 2016 (UTC)
This is a specialized computer science bibliographic database. It is wide-ranging and has over 3 million entities. The organizations behind the database are respected. Runner1928 (talk) 19:45, 1 November 2015 (UTC)
@Pigsonthewing: dblp has four entity types: persons, conferences, journals, and series. I had thought we could combine them all into one Wikidata property and have the entity type present in the value. But four properties would also work. If the formatter URL ends with /pers/hd, then this property will only be valid for person types. Runner1928 (talk) 21:37, 24 November 2015 (UTC)
To record grammatical gender of generic names. Seems like a very basic property (I cannot think why it is not here. Apparently grammatical gender is mostly used for inhabitants of countries: countries are inhabited by nouns with masculine grammatical gender and nouns with feminine grammatical gender). A lot of problems with adjectival epithets can be prevented by recording gender of generic names. It would seem handy to use this as a qualifier, but often it should be referenced. Brya (talk) 05:40, 19 July 2015 (UTC)
Yes, in nomenclature there are only the three genders. For other uses it would be possible to add more genders (not that I have knowledge of any language requiring more). Less genders does not sound problematic. - Brya (talk) 15:13, 19 July 2015 (UTC)
Comment Rename taxonomic gender then. I would oppose a generic grammatical gender property as it's an open door to a mess. Genders are languagues dependants and belongs to wikitionary. I won't oppose but I won't support, seems more cosmetic than really useful and authoritative. Is there a taxonomic database with this information ? author TomT0m / talk page15:27, 19 July 2015 (UTC)
@Succu: Absolutely. that's what I define as cosmetic, this have nothing to do with the properties of the taxon itself and is totally arbitrary. The author would have chosen the other possibility this would have not changed anything. In such cases I personnaly would render a label a/us without losing more time for nothing :) Anyway, I don't understand, the terminations are not hardcoded into the labels of the names ? And if there is any plural to have, don't you refer to all the members of the taxon (that is to say, are not the instances all the organisms instances classified in this taxon) ?author TomT0m / talk page15:49, 19 July 2015 (UTC)
OK, go on guys :) I'm hermetic to such problems, and I don't understand why people still want to keep these rules and try to strictly enforce them, but if you really want to do the job why not ? But I don't really understand if some name are decided non correct, why it's not enough. Do you want to double check ? author TomT0m / talk page16:29, 19 July 2015 (UTC)
'grammatical gender' is a wiktionary property. we must not have a property with that name on wikidata or it will be terribly abused. I can only support this if the property name is changed to "gender of taxon name". Can someone reassure me that once this property is added then some basic logic will be able to generate all versions of a taxon name? Filceolaire (talk) 04:05, 21 July 2015 (UTC)
I don't understand the users who object because they would not use the new property themselves. But I have changed it to be restricted to generic names. The "some basic logic will be able to generate all versions of a taxon name?" suggests a misunderstanding: a taxon name has only one version (that is why a database is needed in the first place). To some degree the correct name can be generated by "some basic logic", but it will need more components (gender only applies to adjectives). - Brya (talk) 05:15, 21 July 2015 (UTC)
@Brya: I did not oppose, and you did not get the whole page : if gender of people is in the scope of Wikidata, gender of name is in the scope of Wiktionary, not Wikidata, so we're reluctant to vote for properties for names in general, and there is quite a few proposal about these. Taxonomy is a special case, but I did not understand your real use case I don't understand how it would be used for example in an infobox, so I'm still reluctant, although I did not oppose. author TomT0m / talk page07:46, 21 July 2015 (UTC)
There is no telling how popular this will be in an infobox, but there is no real reason not to include this. There are not all that many databes that include this information, but there are some. Mostly this would serve a structural function, to help in other items. - Brya (talk) 10:38, 21 July 2015 (UTC)
Brya I don't say I object because I won't use it. I say that I object because others will use it for all kinds of purposes for which it is not appropriate. If "a taxon name has only one version" then this property is not needed and I Oppose it.
If it a taxon name has a second version when it is used as an adjective and this property will enable us to automatically generate that adjectival version AND the name is changed to make it clear what it is for then I would reluctantly support it. Which is it? Your reply above says both. Can we change the property to "taxon name used as an adjective" and make it a string property with the adjectival version of the name as the object? Joe Filceolaire (talk) 16:22, 22 July 2015 (UTC)
Well, the "taxon name used as an adjective" does not exist at all. The taxon names that have a gender are generic names. Say, the name Schinus, which is feminine, but much of the literature assumes it is masculine. The gender is relevant for names below the level of species, which consists of two or three parts. For example, Schinus terebinthifolia is the name of a species, but those who assume Schinus is masculine will write Schinus terebinthifolius. At the moment lots of names in the genus are subject to great confusion, with several having a separate "masculine" item and a "feminine" item. Recording the gender of the generic name will make it doable to bring this in order. - Brya (talk) 16:45, 22 July 2015 (UTC)
(out of topic) this is not really a surprise to me, fighting for correction into such an arbitrary concept is doomed to fail because people won't really care for good reasons. This is like fighting a windmeal. So my personnal advice would be ... let it go. author TomT0m / talk page13:01, 23 July 2015 (UTC)
@Succu: Mmmm, a lot of scientists have created this database especially to store the gender of names ? That's weird, it says that it's a database of name. author TomT0m / talk page14:14, 26 July 2015 (UTC)
Thanks Brya that is much clearer. If you just change the name of this proposed property to make it clear it only applies to the latin names of taxa (and not to common names or anything else) then I will support. Joe Filceolaire (talk) 15:54, 2 August 2015 (UTC)
Thank you for getting back to this, Joe Filceolaire: I had already adjusted the name of the property. I have now adjusted it again, hoping to have blocked any way of reading that might lead to confusion. - Brya (talk) 05:18, 3 August 2015 (UTC)
Sorry Brya but this is still misleading. Some applications drop all information in brackets so you shouldn't use these for essential info in labels. Can the label be "gender of the latin name of a genus" so it's clear it isn't to be used for common names.
There is also a problem with the description since 'generic' in English doesn't just mean 'name of a genus' it also means 'general'. Can we change the description to "used in taxonomy to generate names for species and sub-species".
This property should only be used on an item for a genus so the domain should be genus (Q34740). The items we have for 'generic names' are for human names and this property should not be used on those. Joe Filceolaire (talk) 13:18, 3 August 2015 (UTC)
OK, Joe Filceolaire, tried again. As Succu said, the name of a genus need not be derived from Latin. But genus (Q34740) is something entirely else, conceptually speaking, from the scientific name of a genus. There seems to be no need to make a special item for a generic name? - Brya (talk) 18:31, 3 August 2015 (UTC)
Thanks Brya. 'Scientific name' is much better than 'Latin name' but I have edited it to remove the comma.
Your description is pretty much a repeat of the label. In my proposal for the description I was trying to include some of the info you gave above about how this is used and why it is important so I think my proposed label was better so I have replaced your description. Hope my understanding of what you said is correct.
While it is true that this is a property giving info about the name it is also true that it will only be used on wikidata items for genera. The domain field defines the class of wikidata items that can use this property. Technically I suppose this should be items with <'taxon rank':'genus'> so I have put that as the domain for this property.
Thank you Joe Filceolaire. Well yes, the description was very close to the label, as this concerns a basically very one-dimensional property, but I will see if I can rephrase it to make its import more clear.
The use of the property is likely to be restricted to Wikidata, but there is no intrinsic reason why it could not be included in an infobox (see the example above of the database that has a field for it). In practice, this is useful and interesting information.
I am fairly bewildered by the taxon rank (P105):genus (Q34740). Although there are many who will use a generic name to stand for a genus, the reality is more complicated than that. There are many more generic names than these are genera (ten times as many?), and of course there may be genera without a name. More than that, conceptually they are very different things. Generic names are subject to formal rules (and names do not have ranks), while genera are subject to scientific considerations. - Brya (talk) 18:41, 4 August 2015 (UTC)
@Brya: I don't understand. Did not you say that the gender was important because of the gender of the name of the corresponding genus ? Would the domain then be "names who are name of a genus taxon" then. It's not important that all genus won't have name, "domain" do not impose every instance of the class domain to have this property at all. And of course there probably is more name than there is generas, but if I understand correctly, one genus only have one name ? author TomT0m / talk page19:09, 4 August 2015 (UTC)
@Brya: The description should add extra information to help users decide if the property is appropriate to use in a particular case. I think my description does that.
All properties on wikidata can be used all over the place. That's the point of Wikidata. All the more reason why we need to be completely clear about what each property is for and what it is not for.
What is a generic name? I am a well educated native English speaker with a large vocabulary and you have managed to confuse me. I suggest you avoid using the phrase "generic name" or define it (the definition can be as long as needed to make it clear what it is and what it is not).
<Domain taxon rank (P105):genus (Q34740)> means this property should only be used with items which have the statement "taxon rank (P105)->genus (Q34740)" that is it should only be used on an item for a genus. If this is not what you meant then you have failed to be clear about how this property will be used. Don't tell me the property is to specify the gender of scientific names - we don't have any items for scientific names so specifying that as the domain is the same as saying that this property should not be used - instead specify what items this property may be used on. This property could be restricted to only be used as a qualifier to taxon name (P225) but I would not recommend that.
Instead of writing me another paragraph of explanation I suggest you have a close look at the Label, Description and Domain statements above and rewrite these to be clearer, taking account of all of the comments by others above. The property will not be approved until these make clear what the property is used for and what it is not to be used for. Joe Filceolaire (talk) 22:46, 4 August 2015 (UTC)
@Joe Filceolaire: well, "generic name" is the existing term, used throughout the several Codes of nomenclature. Has been for a long time (a lot longer than computers have been in existence, anyway).
The label is misleading. The property is not for 'general nomenclature'. This property is only used to specify the gender of the scientific name of a genus. Nothing else (unless I have misunderstood you). The label should make this clear. The fact that the information contained in statements using this property can be used in nomenclature is info to put in the description - as you have done - not in the label.
The description uses the phrase 'generic name'. This phrase may be well understood in biology but the description is not for biologists; it's for non-biologists and for them this phrase is misleading. Delete the first 6 words and you would have a good description.
The domain has that phrase 'generic name' again. Just put a full stop after the word 'genus' and delete the rest. Then you would have a clear unambiguous definition of the wikidata items that can use this property. Joe Filceolaire (talk) 15:44, 5 August 2015 (UTC)
Succu In biology it is "the scientific name of a genus" but item Generic name (Q5532676) links to a disambiguation page with lots more meanings. "Generic" has come to mean 'general, common, typical' in common English usage (based it's usage in 'generic medicine') so 'generic name' is likely to be misinterpreted as 'common name', 'given name', or 'family name'. Joe Filceolaire (talk) 16:03, 5 August 2015 (UTC)
@Joe Filceolaire : well, I am OK with "gender of a scientific name of a genus" (much better than "the"). And I can also do without the first six words of the description. Shorter anyway. I don't follow your argument that the existence of "generic medicine" or "generic statement" means that "generic name" will be misread, although it will no doubt be unfamiliar to many. It is possible to use "generic name" in English for something like "hoover has become a generic name for a vacuum cleaner, no matter the brand of the machine", but I don't see why that should involve a grammatical gender. - Brya (talk) 16:48, 5 August 2015 (UTC)
Support This is a crucial piece of information in Biology. I realise not so interesting elsewhere. Under the ICZN code there is the Principal of Coordination which basically mandates that the gender of a genus and species name must be the same, hence names sometimes get alterred after recombination. Cheers Faendalimas (talk) 02:14, 15 December 2015 (UTC)
How is that possible, when names of species (and other taxa below genus) are not within the scope of Wiktionary? - Brya (talk) 05:29, 19 December 2015 (UTC)
? What do you consider these to be? Linguistic data is Wiktionary's domain. Wikidata deals with content about the species themselves, Wiktionary deals with content regarding the names. --Yair rand (talk) 22:35, 20 December 2015 (UTC)
No, it's not. Statements (such as gender data) about lexemes is a major part of the main Wiktionary-integration proposals. Even before integration, this data is being handled by Wiktionaries using templates. --Yair rand (talk) 22:35, 20 December 2015 (UTC)
I never understood why Wiktionary has included some scientific names, apart from a desire to push some PoV or other. Anyway, the gender of a scientific name of a genus is not necessarily set by linguistic considerations. It may also be set by a rule, or by a decision of an International Botanical Congress. - Brya (talk) 17:54, 29 December 2015 (UTC)
Whenever it uses pictures, these are derived from Wikimedia. Has an unfinished look, also some errors. I suppose it would not hurt, although there are databases I would rather add. - Brya (talk) 17:23, 3 November 2015 (UTC)
This database is the only place to find reliable information on the distribution of Arctic plants. Older literature is difficult to use because the circumscription of the taxa varies between North American, Scandinavian and Russian sources. Papaver radicatum is a good example. --Trurl (talk) 21:23, 3 November 2015 (UTC)
No existing property is known to exist, however one could be added to the template en:template:Taxobox, mimicing the "status_ref" parameter which already exists
SPRAT IDs could be scraped from the Species Profile and Threats Database and then imported into Wikidata using mix-and-match
Motivation
The Species Profile and Threats Database is designed to provide information about species and ecological communities listed under the Environment Protection and Biodiversity Conservation Act 1999. This property proposal is similar to IUCN conservation status (P141) except that the Species Profile and Threats Database is the authoritative source for information on flora (Q131449) and fauna (Q104021) endemic to Australia (Q408). This Species Profile and Threats Database also contains a more detailed conservation status (Q82673) on a state-by-state basis throughout Australia (Q408). The database additionally contains a vast number of other fields of information (including pictures) which could greatly assist in understanding flora (Q131449) and fauna (Q104021) linked to the Species Profile and Threats Database via this property. Dhx1 (talk) 10:48, 22 November 2015 (UTC)
If I'm right there are nearly 5,500 taxa at species rank and below. Support, but the datatype should be string. --Succu (talk) 21:08, 22 November 2015 (UTC) PS: No need for mix-and-match. My bot can make the additions.
Comment Thanks for checking. How did you get to 5,500 taxa though? I can only find 2537 entries in the database as per this query. And so I know for next time, should all numeric identifiers be treated as strings with a string pattern allowed value of "\d+"? Cheers Dhx1 (talk) 23:01, 22 November 2015 (UTC)
Comment the link for the Lyrebird is down - and all searches on the database fail with an error message right now. I was about to create the property but I'm going to wait until I see the database actually working... ArthurPSmith (talk) 20:48, 29 December 2015 (UTC)
No infobox property is known to exist at present, however it would be possible to add a new property to en:template:infobox ship career (or new infobox)
Shipwreck IDs could be scraped from the database, and mix-and-match used to import into Wikidata
Proposed by
43
Motivation
The new Australian National Shipwrecks Database (ANSDB) was launched in December 2009. This database includes all known shipwrecks in Australian waters. New features of the ANSDB include many extra fields of information, the capacity to attach images to shipwrecks, the ability to link shipwrecks to relics recovered from shipwreck sites, site environment information for divers and site managers and a history field with the ability to attach documents that include names of passengers and crew. The information in the ANSDB has been collected by each of the State and Territory historic shipwreck agencies or supplied by collecting institutions holding historic shipwreck objects. This is the authoritative database of shipwreck information for Australian waters, compiled by and operated by the Australian Government (Department of the Environment).
Addition of this property would significantly enhance the information on the career and final resting places for over 10,000 vessels laying in Australian waters. Dhx1 (talk) 09:21, 22 November 2015 (UTC)
PAA (Persons of Ancient Athens) is the most important catalog of ancient people related to Athens (Athenians or foreigners which were honored by Athenians), with more than 100,000 entries: although it isn't online gratis, it's cited by an increasing number of publications, so users can sometimes find references to it in recent achademic articles about ancient Athens and thus add them to Wikidata items. Epìdosis10:39, 26 December 2015 (UTC)
All Athenian citizens where mentioned in official documents with name, patronymic and demotic, so having the demes of all Athenian citizens is really important; the main source is Prosopographia Attica (Q2113277), online at Internet Archive. Epìdosis17:31, 25 December 2015 (UTC)
This would be useful as an authority control ID for British people. Oxford University Press's "Who's Who", unlike many of the subsequent publications which have stolen its name, is a widely-used reference work for British people since 1849 and this would help bring together a number of individuals who otherwise do not have reasonable authority control schemes for them, like sportspersons and politicians. James F. (talk) 00:12, 18 January 2015 (UTC)
This is an interesting one. OUP have an identifier system (which we've taken in as Oxford Dictionary of National Biography ID (P1415)). However, this is currently only used for people with Oxford Dictionary of National Biography entries - if they also have a Who's Who entry the index page will point to it, but no identifiers are assigned for ~90% of the people in Who's Who. It's possible it may be extended in future, in which case we could certainly merge the two identifiers - it'll be easy to switch from one to the other.
Motivation: Currently, it’s unclear whether the prefix should be included in the catalog code (P528) value or not. I propose that the best solution is to remove the redundant prefix from the catalog code (P528) values and extract it into a statement on the value of the catalog (P972) qualifier instead. This also allows language-specific prefixes to be displayed correctly (for instance, Köchel catalogue (Q162478) is abbreviated “K. ” in English but “KV ” in German).
Question Are there any catalogues where the prefix is not separated from the code by a space? If we could make the space implicit, we’d probably avoid an otherwise common mistake where people wouldn’t be aware that they need to include a trailing space in the value in most cases. —DSGalaktos (talk) 17:49, 30 March 2015 (UTC)
I don't think we should store the space in the value of the catalog prefix property; this is a formatting decision. Whoever wants to display the (prefix, code) pair should decided whether they want to format it with a space or not. –Hardwigg (talk) 18:37, 13 April 2015 (UTC)
The most catalogs that I know have language independent prefix. For example HD prefix of Henry Draper Catalogue (Q111130) is written as "HD" in all languages. So string datatype is looked more preferred for this property. Also usually prefix is inseparable part of identifier. I never seen "HD 39801" identifier without HD prefix. So Oppose removing prefixes from catalog code (P528) or other properties. Issue with Köchel catalogue (Q162478) can be resolved using some other way, for example creating separate property for this catalog. — Ivan A. Krestinin (talk) 14:53, 12 April 2015 (UTC)
I’m not familiar with astronomical catalogues, but via German Wikipedia I found this lookup page for HD: VizieR – and there, you must enter the number without the HD prefix (with the prefix, you get this error: Unrecognisable token in: HD 39801). So if a template wanted to automatically link to VizieR results, it would presumably be easier if the value stored didn’t include the prefix. In addition to that, adding a separate property for any “problematic” catalog doesn’t scale at all. And regarding the language / data type, yes, most catalogues would only have a single value (presumably in English (en), unless there’s some special “global” language code that I’m unaware of), but that’s no reason to oversimplify the property to the point where it can no longer accurately represent all data. —DSGalaktos (talk) 16:01, 12 April 2015 (UTC)
Support I think separating out the prefix represents the data more accurately. The catalog code is just the number; the prefix represents the catalog. If you had the catalog in front of you, it would (most likely) not have the prefixes. On more pragmatic terms:
Pros:
removes duplication
allows for internationalization (K. vs. KV)
allows for simpler display customization: if you want to display the catalogue code in a special way, you don't have to to do any manual parsing to remove the prefix
Makes prefixed catalog code parsing possible: if you want to determine what catalog "HD 39081" belongs to, you could get a list of items with the catalog prefix property, and find the one which has "HD". This is currently not possible.
Cons:
more complicated to display data with prefix: in order to display "HD 39081", for example, you would have to get the catalog code (P528) value, then get its catalog (P972) qualifier value, find its prefix, pick the correct language, and then append the code to the prefix. However the fact that this is currently simple is a limitation in terms of internationalization and display customization. Furthermore, if you are only displaying certain catalog codes, this isn't an issue since you can store the prefixes locally.
possible duplicate of short name (P1813)? All of these could be achieved by using short name (P1813) with some qualifier specifying its purpose.
monolingual text would be annoying since most prefixes would be identical in many languages. However this is a problem that short name (P1813) faced when it was P743 (P743) with plain string, and the end decision was to convert it to a monolingual. I think the extra complication is worth the internationalization.
Comment I’m having second thoughs on the data type, since I’ve recently discovered that in Hoboken-Verzeichnis (Q739093), the catalog of Haydn’s works, even the catalog code itself is written differently across languages. For instance, Symphony No. 94 (Q276768) is „Hob. I:94“ in German but “H. 1/94” in English: category and item are separated by a colon in German, but a slash in English. To fully represent this, catalog code (P528) would have to be changed to Monolingual Text, too. I don’t think this would be a reasonable thing to do, though: the vast majority of catalog codes are language independent, and it would be overkill to introduce the additional complexity of Monolingual Text just to deal wtih this one special case. And perhaps the same argument goes for catalog prefixes themselves, too; that really depends on how frequently the prefix is language-dependent. —DSGalaktos (talk) 21:30, 19 April 2015 (UTC)
Oppose This prefix is just part of formatter URL, which is used for all authority control properties. Don't see its separate value. --Vladimir Alexiev (talk) 06:23, 30 April 2015 (UTC)
Wikis need to display the prefix. Especially for astronomical objects, there seems to be half a dozen different catalogues – displaying the catalog codes without the prefix would be very confusing. —DSGalaktos (talk) 12:13, 30 April 2015 (UTC)
Beethoven for instance is not pathological: There exist only one catalogue (Kinski-Halm, maybe several editions or undisputed later amendments), there are two prefixes namely "op." and "WoO" (work without opus number, counted postumously). Both of these are "generic" prefixes and do not include a short name for the catalogue (since there is essentially only one it is implied as long as one agrees on the composer). And thirdly the display at http://viaf.org/viaf/184686463/ may give a gist how much variation different national (library) cultures can introduce into something as simple as "op. 27,2": Captialization of "op.", colons (se), commas, different abbreviations for "number" as the name for the subunit, even if one leaves the other components of the "usual reference forms" out of the equation and just focuses on the "catalog number". So if we talk about musical works, catalog code (P528) is highly language dependent and it does not make much sense to split some prefixes like "BWV" or "Hob." from the "number" itself: Those who don't now much about Bach would think "oh, it's opus 1248" and those who know so deeply are conditioned for "BWV 1248" that they probably would have a very hard time to grasp the meaning of an insulated "1248" in some data element. -- Gymel (talk) 12:54, 30 April 2015 (UTC)
I mostly agree with you, actually. My main issue with catalog code (P528) is that I strongly feel like the prefix should not be stored in that value. Most of what you say supports this, I think: If there are so many different ways to write a catalog code (K., KV, op., Op., etc.), then we need to strip away as much as possible of this representation data, because there’s no “one true representation”, and because we can’t possibly hope to be consistent in which representation we choose. But wikis still need to display the correct, pretty, full catalog code: Somehow,
needs to be turned into “K. 620” (English), or “KV 620” (German), or the proper representation for other languages. Do you have a better solution than the property I suggest? —DSGalaktos (talk) 13:41, 30 April 2015 (UTC)
I rather see similarities to "numbers with units" e.g. 1 m³ which even require a datatype of their own. Strings like "op. 27,2" and "BWV 1248" as notations I consider equally atomic (within their contexts and all language specific variations notwithstanding) and your and my examples above illustrate that language specifics are not restricted to some prefix but rather are found throughout the whole "number". So perhaps the problem lies only in an improper naming of catalog code (P528) for some languages, where the label uses "number" instead of "code" or "mark" and therefore implies something that could or should be simple and unstructured? I'm not sure what problem the proposal actually tries to solve, but I would say there is no way in the general case to use properties like catalog code (P528) for sorting nor searching. Some problems like unambigously identifying the work in question might be solved by providing a semantic web URI pointing to a linked data version of exactly that catalog entry evoced by the string value of catalog code (P528), but I'm not aware of any catalog in that form (but there are probably examples in STM areas). -- Gymel (talk) 14:37, 30 April 2015 (UTC)
WikiManche is an encyclopedia based on Mediawiki that is entirely focused on everything related the French department of Manche. WikiManche is becoming for me the best reference on this subject, the quality of content being really perfect, it can be used as an authority control. genium⟨✉⟩08:33, 16 August 2015 (UTC)
Oppose A wiki is not an authority control and the titles are too unstable. If we are going to link to sites like this, it should be done the same way we link to Wiki articles, not through statements. Josh Baumgartner (talk) 21:56, 6 January 2016 (UTC)
Question: Should this property be specified to be about biathlete-people, since there are a possibility to use the same website for event-results too from biathlon championships and world cups ? Migrant (talk) 23:45, 21 December 2015 (UTC) adding a question-Icon at front of my commentary. Migrant (talk) 20:31, 23 December 2015 (UTC)
Footballer ID to Mackolik.com which contains detailed information about most of the footballers that played in Turkey, as well as the most of the other football leagues around the world
Mackolik.com contains detailed information about most of the footballers that played in Turkey, as well as the most of the other football leagues around the world. Their database is the largest database in Turkey for such information.Rapsar (talk) 10:15, 26 December 2015 (UTC)
elibrary.ru contains detailed information aboutrganisation ID which contains detailed information about most of the science , education, government organization in Russia. Their database is the largest database in Russia for such information. Ochkarik (talk) 07:56, 29 December 2015 (UTC)
Its a primary database for footballer articles. Contains detailed information about footballers. Wikis use this as a primary source. --Mavrikant (talk) 16:54, 29 December 2015 (UTC)
Its a primary database for manager articles. Contains detailed information about managers. Wikis use this as a primary source. --Mavrikant (talk) 16:54, 29 December 2015 (UTC)
Its a official database for professional footballers in Turkey. Contains detailed information about footballers. Wikis use this as a primary source. --Mavrikant (talk) 19:43, 29 December 2015 (UTC)
Its a official database for professional managers in Turkey. Contains detailed information about managers. Wikis use this as a primary source. --Mavrikant (talk) 19:48, 29 December 2015 (UTC)
Netflix is one of the largest streaming media providers. Despite the fact that information is available only to subscribers, I think we still should have links to its pages. —putnik13:11, 7 January 2016 (UTC)
[Google Translate] After the participant (P710) to build the list of participants of a cycling race, and have called for the creation of property general classification to define the final classification of a bike race, I come back here to request the creation of a property classification step that would allow us to rank the riders at the end of a stage. At the same element, the property would general classification to establish this classification at the end of stage (it varies over days). Moreover, it is already scheduled on the french Wikipedia (other versions will follow) to extract this property the first three riders, see Module:Infobox/Étape (and as time and average speed when possible). It would be interesting that each time a user clicks on "Add", qualifying ranking (P1352) and the property that show the time or the gap displays and to be filled, which be a time saver. Jérémy-Günther-Heinz Jähnick (talk) 13:36, 4 June 2015 (UTC)
@TomT0m: participant (P710) sera déjà utilisé pour définir la liste des partants (les programmations se serviront déjà de cet élément). J'ai donc besoin de cette propriété à implanter dans les éléments d'étapes. classement général a été demandé, et je dois également demander classement par points, classement par équipes... Ces propriétés devront être simples et rapides à remplir pour que le commun des Wikipédiens puisse le faire. Des fonctions seront rédigées pour prendre les premiers dans les infoboxes. Jérémy-Günther-Heinz Jähnick (talk) 19:37, 7 June 2015 (UTC)
@Jérémy-Günther-Heinz Jähnick: Ben clairement pour une étape, le rang fait référence à l'ordre d'arrivée de l'étape non ? De toute façon seul un participant peut être classé. Pour moi c'est plus simple d'avoir un truc du genre
Pour le remplissage, c'est au contraire plus facile de répéter, tout en sachant que ce ne sont pas forcément les mêmes personnes qui prendront les classements. J'ai fait quelques tests pour les listages d'équipes, et il serait bien plus rapide pour moi de taper un classement par équipes que d'ajouter un rang à la liste des équipes participantes, tout simplement parce qu'il faut aller chercher les équipes unes à unes, tandis que pour définir un classement il faut simplement mettre les deux documents côté à côte. Lister les équipes participantes ne me prend plus que 3 minutes. Tant que je n'aurais pas la propriété pour le temps et l'écart ce ne sera pas intéressant. Jérémy-Günther-Heinz Jähnick (talk) 20:19, 7 June 2015 (UTC)
@Jérémy-Günther-Heinz: C'est à courte vue ça ... c'est pas forcément une bonne idée de se baser sur l'état actuel pour prendre des décisions de ce genre, ça demandera des efforts de maintenances après coup genre recoder toutes les infoboxes et faire tourner un bot pour migrer les données ... J'aurai plus tendance à te mettre en relation avec un codeur de script qui prendrait un tableau de tableur que tu remplirais à ta convenance ou te coderait une interface adpatée et qui viendrait modifier Wikidata en conséquence automatiquement ... TomT0m(talk)18:09, 8 June 2015 (UTC)
@TomT0m: ce que tu me dis là m'intéresse : une interface adaptée qui permettrait une saisie aisée pour tous ceux qui travaillent sur le cyclisme (en ce qui me concerne, je ne fais pas souvent des classements, je suis plus souvent à la production des photos et à la promotion de Wikipédia dans le cyclisme) et qui mettrait les données de la façon la plus adaptée du point de vue des programmateurs serait quelque chose d'extrêmement intéressant. Quitte à évoluer, autant faire un bond en avant. Jérémy-Günther-Heinz Jähnick (talk) 07:02, 9 June 2015 (UTC)
@TomT0m: J'y repensais il y a quelques jours : la question est un petit peu plus complexe dans la mesure où les courses à étapes comportent généralement quatre classements finaux différents, qui varient à chaque étape. Sur un autre plan, pour les très vieilles courses, nous n'avons bien souvent que le top ten, quand ce n'est pas juste un top 3. Jérémy-Günther-Heinz Jähnick (talk) 08:00, 12 June 2015 (UTC)
@Joshbaumgartner:. Yes. For example, this race has a result for the third stage, that modify the general classification. This general classification evolve all the days. And even for the first stage it is different from the classification of the stage, because we have "bonifications" (a time property asked below). The leader of the general classification wear a special jersey, yellow on the Tour de France, pink for the Quatre jours de Dunkerque, for example. Jérémy-Günther-Heinz Jähnick (talk) 09:53, 8 December 2015 (UTC)
No, that wasn't what I was thinking of. My view is that there needs to be a generic property for "duration" and I'm not too fussed about whether we create a new one or genericise duration (P2047), I just recall a discussion where the latter option was rejected. Thryduulf (talk: local | en.wp | en.wikt) 22:47, 1 January 2016 (UTC)
Oppose: duration (P2047) works fine for this. It had been labeled 'running time' but only in English. It has been widely used beyond the specific English description, so I fixed the description to allow the broad use it currently has. Josh Baumgartner (talk) 21:42, 5 January 2016 (UTC)
Ok, I'm new to wikidata so I hope I filled out the above correctly, but in a nutshell I'm trying to build a new type of infoboxes for companies that would include essential information such as number of employees, operating income (there already is a pending / accepted request for that) and debt rating, amongst others. In the present case, credit rating is an essential element of economic publication these days, and with all the talk about indebted countries there really is a demand for such information. 95% of the credit rating market is dominated by only three agencies (Fitch, Moody's, Standard & Poor), which makes their evaluation a de facto standard (and it is already, to some extent, a standard by law)
Discussion
Welcome to Wikidata. :) I know absolutely nothing about economics, so I can't really say whether or not I think we should add this, but I do have a few more general comments:
Please don't remove the TranslateThis sections in property proposals - that's there so that people can add the name/description in other languages.
For fixed lists of values we normally use items for each value, rather than strings, see the allowed values on the talk pages of PEGI rating (P908) or MPA film rating (P1657) for example.
This seems to be three separate systems for credit ratings, if so, I think three separate properties would be better, one for each system, in the same way that we have separate properties for separate film/game rating systems. - Nikki (talk) 18:52, 9 July 2015 (UTC)
Thanks! Yes I think three five separate properties (three long-term; two short-term) would be best indeed (and I've changed string to item in the request). Leo Fischer (talk) 13:37, 10 July 2015 (UTC)
Fralambert: We can have external identifiers without formatter URLs and there can be formatter URLs that are more complicated than $1. --- Jura07:17, 7 January 2016 (UTC)
Support helps implement phase 2. Provides context specific guidance. --- Jura 12:12, 10 November 2015 (UTC)
Comment Nothing to add :) This similar to the properties for Chinese names. --- Jura 12:12, 10 November 2015 (UTC)
Question What is the difference between a praenomen and a given name, and between a cognomen and a surname? Also, is there a more generic version of nomen that might be usable? (Clan name, maybe?) If avoidable, I think we should try to have as few culture-specific name properties as possible. --Yair rand (talk) 03:04, 11 November 2015 (UTC)
Oppose
Done as teaching method (P2392) for now. Feel free to re-label, but I suggest something more specific than just "method", which is vague. Perhaps "methodology"? Feel free to discuss on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:06, 11 December 2015 (UTC)
⟩ expenditure Search ⟨ 13,000,000,000 United States dollar (Q4917) ⟩
On hold Pending currency data type. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:22, 23 March 2015 (UTC)
Done - @Mcnabber091: it looks like this was united to be a general expenditure property, there seems to be general support, so I've added it. You should be able to edit the property further if needed (for example set constraints) and of course you can use it now! ArthurPSmith (talk) 16:38, 15 December 2015 (UTC)
Support --Jane023 (talk) 15:25, 20 December 2015 (UTC)
Not done due to lack of support (may be revisited in the future)
Archived by Josh Baumgartner (talk) 17:26, 5 January 2016 (UTC)
Archived by Josh Baumgartner (talk) 21:41, 6 January 2016 (UTC)
Not done due to lack of support, 
→ engine configuration (Q2576663) 
Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page 10:12, 23 October 2015 (UTC)
Answer In my opinion, that is too fragile and restrictive an approach. It is much more straightforward to reference a claim of a straight season count. Dancter (talk) 19:07, 27 November 2015 (UTC)
Neutral Why not just using ⟨ Happy Tree Friends (Q207627)? --Pasleim (talk) 13:13, 27 November 2015 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Info If you want to know how this problem is influencing our data quality then have a look at Possible duplicates (wissenschaftlicher Name (P225)). --Succu (talk) 20:26, 21 August 2015 (UTC)
Comment These guys don't seem to be very open, or things are behind a paywall. There are a few examples on the home page, and the URL for Jenson Button (Q10510) is http://www.ukwhoswho.com/view/article/oupww/whoswho/U254416/Jenson_Button?&p=bdayAIDa4srTXXP.o&d=U254416. If you remove any one of the cryptic parameters, you get the home page. Not very coreference-friendly, I'm afraid --Vladimir Alexiev (talk) 15:56, 19 January 2015 (UTC)
Oppose This prefix is just part of formatter URL, which is used for all authority control properties. Don't see its separate value. --Vladimir Alexiev (talk) 06:23, 30 April 2015 (UTC)