Wikidata:Property proposal/Archive/19

→ Property:P1101

• Description: Number of floors of a building
• Datatype: Number
• Links: w:en:Template:Infobox building / w:fr:Modèle:Infobox Monument
• Infobox parameter example:
• Comments: Wylve (talk) 12:50, 8 February 2013 (UTC)

  Comment Suggesting "floor count" as the label, and to include all floors including mechanical plant floors, floors below ground. Danrok (talk) 16:06, 24 February 2013 (UTC)

  SupportFale (talk) 14:27, 10 February 2013 (UTC)

  Support, but some languages (/countries), count the ground floor, other that do not. It would be nice if we could find a label that makes it clear, which system we use. --Zolo (talk) 09:57, 11 February 2013 (UTC)

  Support, but additionally to the ground floor counting, it needs to be mentioned if floors below ground level are also counted. I would count all floors of a building (ground floor + floors below ground level), since they are all floors and a building which only a ground floor still exists. --Faux (talk) 08:35, 19 February 2013 (UTC)

What about more than one property, for instance "total number of floors" and "number of floors above ground" ? Wikidata infoboxes allow free-text, and we need to have more properties, if we want to be as detailed here. --Zolo (talk) 08:08, 1 March 2013 (UTC)

  Support Danrok (talk) 20:01, 21 February 2013 (UTC)

•   Done --Jakob (talk) 13:12, 31 January 2014 (UTC)

→ Property:P1106

• Description: any kind of values
• Datatype: QuantityValue / Number (dimensionless) - (1 Sandbox type per available data type)
• Domain: any kind of values
• Infobox parameter: any/generic (but more for testing than productive)
• Comments:

To be honest I am badly informed about wikidata, just to make that clear. I do think that I need a property to be created in order to store values, please confer Wikidata:Requests for permissions/Bot/DrTrigonBot and Wikidata talk:Infoboxes task force#Feasibility of DrTrigonBot/Subster to update Wikidata. Thanks for all your help and patience. Greetings --DrTrigon (talk) 20:54, 22 March 2013 (UTC)

Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)

In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)

Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)

Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)

I think testing bots should not be done on the productive Wikidata, except in the sandbox.--Faux (talk) 17:04, 23 March 2013 (UTC)

It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)

I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)

Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)

Sounds good! (+1) Thanks for the idea! Greetings --DrTrigon (talk) 22:41, 23 March 2013 (UTC)

Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)

I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)

So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:

1. Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
2. Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
3. Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String

any comments or thoughts on this? Thanks and Greetings --DrTrigon (talk) 10:52, 29 March 2013 (UTC)

Ok here we go:

1. Sandbox-CommonsMediaFile (P368)
2. Sandbox-Item (P369)
3. Sandbox-String (P370)

so these can be considered done but I think it makes sence to propose the future ones too and set them to the pending page:

• Label: Sandbox-Quantity / Description: Sandbox property for value of type "Quantity" / Data type: Quantity
• (and all other data types to be introduced in future...)

Thanks for all your help! Greetings --DrTrigon (talk) 01:09, 30 March 2013 (UTC)

Discussion

•   Support See Wikidata:Books_task_force#Edition_properties--Micru (talk) 01:02, 5 June 2013 (UTC)
• Wrong datatype – should be number. -- MichaelSchoenitzer (talk) 18:42, 5 June 2013 (UTC)

• Changed!--Micru (talk) 22:24, 5 June 2013 (UTC)

•   Support (with number datatype). Ayack (talk) 18:55, 5 June 2013 (UTC)
•   Support Filceolaire (talk) 08:22, 13 June 2013 (UTC)

•   Done --Jakob (talk) 13:25, 31 January 2014 (UTC)

→ Property:P1103

• Description: The number of platforms
• Datatype: Number (Integer)
• Links:
• Infobox parameter example:
• Comments: Wylve (talk)

  Support-- DangSunM (T · C) 21:16, 7 February 2013 (UTC)

  Support--Incola (talk) 19:58, 10 February 2013 (UTC)

Changed title to reflect what this actually is. Sven Manguard Wha? 05:39, 18 February 2013 (UTC)

  Support --Faux (talk) 19:25, 18 February 2013 (UTC)

  Support Danrok (talk) 16:09, 24 February 2013 (UTC)

  Comment I think we should not count the number of platforms, but the number of tracks that are next to a plaform, as there are platforms with one edge, but also platforms with two edges. Regards --Iste (D) 17:01, 1 March 2013 (UTC)

•   Done --Jakob (talk) 13:24, 31 January 2014 (UTC)

Comment. Isn't his just going to be problematic? Constantly changing on a day by day basis. Seems like a maintenance nightmare waiting to happen. I would not have thought that trying to capture rapidly dynamic information was of value. Maybe it is different when people have retired from a sport.  — billinghurst sDrewth 09:41, 29 March 2013 (UTC)

At least on enwp, there are people that do this sort of updating fairly often, though I don't follow well enough to know if they bother after every single match, or just every so often. I would wonder if it is just an enwp thing to update, or is the work getting done multiple times per player per match, in which case the proposal makes sense. Courcelles (talk) 20:01, 5 April 2013 (UTC)

  Support bearing in mind it has to be cited. If people are already doing it, and can reference it, we might as well allow it on Wikidata. Superm401 - Talk 00:57, 6 April 2013 (UTC)

  Support Emw (talk) 20:54, 20 April 2013 (UTC)

  Support for all national team (e.g. U17, U21) the player played with Xaris333 (talk) 01:15, 3 May 2013 (UTC)

  Support keeping this up-to-date for active players will be no bigger issue than any other statistic. When we get date functionality, we will have an 'as of' qualifier that can be used to indicate how recently a statistical claim was updated. Joshbaumgartner (talk) 09:54, 9 May 2013 (UTC)

•   Done --Tobias1984 (talk) 14:52, 2 February 2014 (UTC)

Discussion

•   Support --Filceolaire (talk) 20:51, 24 August 2013 (UTC)
•   SupportMcnabber091 (talk) 00:17, 25 August 2013 (UTC)
•   Support Danrok (talk) 19:57, 26 August 2013 (UTC)
•   Support Emw (talk) 03:02, 15 October 2013 (UTC)
•   Done Chrumps ► 14:58, 2 February 2014 (UTC)

Discussion

A further specification of the tournament's category (e.g. ATP, WTA, ITF), which is used in the infoboxes for many players, can be done using a qualifier.--Kompakt (talk) 03:00, 15 June 2013 (UTC)

•   Support. --Stryn (talk) 12:30, 16 June 2013 (UTC)
•   Support. -- Edoderoo (talk) 07:54, 18 June 2013 (UTC)
•   Done. --Jakob (talk) 16:00, 2 February 2014 (UTC)

Discussion

A further specification of the tournament's category (e.g. ATP, WTA, ITF), which is used in the infoboxes for many players, can be done using a qualifier.--Kompakt (talk) 03:00, 15 June 2013 (UTC)

•   Support. --Stryn (talk) 12:30, 16 June 2013 (UTC)
•   Support. -- Edoderoo (talk) 07:55, 18 June 2013 (UTC)
•   Done --Jakob (talk) 15:46, 2 February 2014 (UTC)

Discussion

As other heritage property ID. Fralambert (talk) 19:46, 19 January 2014 (UTC)

Discuss

• Agree but rename as 'Located at' and use with domain = places smaller than admin units - buildings, villages, streets. 86.6.107.229 20:40, 6 November 2013 (UTC)
• As proposer of this property, I would even think that located in the administrative territorial entity (P131) is too narrow defined: it can be easily derived if the item is a (sub)class of an adminstrative unit. Isn't it better to create 1 property for "location" that doesn't only focus on the administrative unit? Michiel1972 (talk) 12:56, 17 December 2013 (UTC)
•   Support i think located in the administrative territorial entity (P131) makes sense as it is, concentrating especially on the next higher administrative level, so pure "administrative trees" can be created. but a new property for locations which are below the lowest level of administrative units is also very useful. For example for urban quarters, smaller villages and settlements and in Germany also for Gemarkung (Q1499928) (type of cadastral division) which does not count as a real administrative unit by most definitions. Holger1959 (talk) 22:26, 3 January 2014 (UTC)
  • Holger1959, you wrote: "located in the administrative territorial entity (P131) concentrat[es] especially on the next higher administrative level". I agree with you in theory but in practice I have seen a lot of time that the property was used with several values. To force that only the next higher level should be included, one could add a single value constraint at Property_talk:P131. The cleanest "administrative tree" one can get at the moment IMO is by using contains the administrative territorial entity (P150). --Zuphilip (talk) 23:42, 3 January 2014 (UTC)
•   Support I agree with Holger1959 to have a smaller unit than located in the administrative territorial entity (P131). For e.g. Venice this would be very helpful.--Oursana (talk) 23:09, 5 January 2014 (UTC)
•   Support A good complement for located in the administrative territorial entity (P131) ans located in/on physical feature (P706) (who incule only natural feature). --Fralambert (talk) 19:42, 25 January 2014 (UTC)

  Comment If I understand, it sould be:

• Sable Island (Q1336091) --> <Located at (village/neighborhood/park)> --> Sable Island National Park Reserve (Q4133141)
• Sable Island National Park Reserve (Q4133141) --> located in/on physical feature (P706) --> Sable Island (Q1336091) (the two items have the same limits)
• And finally Sable Island (Q1336091) or Sable Island National Park Reserve (Q4133141) --> located in the administrative territorial entity (P131) --> Halifax (Q2141)

It is exact? --Fralambert (talk) 19:42, 25 January 2014 (UTC)

•   Support However, it will (especially in Germany) be difficult to define what is an administrative entity yet or still only a locality. Many cities and municipalities are dived into Stadt- or Ortsteile which do not have an administrative status but do have exact borders defined by a local law or by-law and thus stretch even into areas outside the populated area. So, even a wayside cross in the midst of the forest can be assigned to a specific (non-)administrative entity.--Leit (talk) 23:57, 30 January 2014 (UTC)

Discussion

The information instance of (P31) => nomen conservandum (Q941227) originally provided in Cactaceae (Q14560) was highly disputed at project chat. The are some more usecases (see Capparis gibbosa A.Cunn. (1841) (Q15149571) or Andrea Mez (1896) non Andreaea Hedw. (1801) (Q15298633)). Darwin Core (Q5225953) contains a vocabulary (see [2]) which we could adopt to make the information more specific. Succu (talk) 12:44, 30 January 2014 (UTC)

•   WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
•   Support - Probably should be accompanied by another qualifier with start and end date of the status. --Tobias1984 (talk) 14:25, 30 January 2014 (UTC)

•   Support - This is good. I'm wondering about the documentation, though, and whether or not it shouldn't say that it is meant to be used as a qualifier right up front in the description. Also, shouldn't the "domain" be something like "statement"? (But I guess that's a discussion for another day.) Klortho (talk) 17:01, 30 January 2014 (UTC)

• I have a lot of questions and worries. To start: this is going to be a property, not a qualifier? This would work if there were a rule of only one name per item, which would be fine by me for better than 99% of the items.

        A lot of the terms above have no nomenclatural meaning, but are taxonomic (or obsolete). Some are ambiguous (in what sense is "nomen alternativum (nom. altern.)" used here), or relative. I would indeed like "replacement name" added, and also "later homonym".

        I certainly would not use the vocabulary at the Darwin Core [brr!], but rather a more reliable source - Brya (talk) 17:41, 30 January 2014 (UTC)

This "property" should be used as a qualifier to taxon name (P225). Please understand the provided list as an example which kind of information could be expressed. Of course we can and should discuss the details. I commented out "replacement name" because we have replaced synonym (for nom. nov.) (P694). --Succu (talk) 19:59, 30 January 2014 (UTC)

Perhaps it should say so ("to be used as a qualifier"). I am not so sure about "replacement name": I would be inclined to have a link in both items "Arbor novum is a replacement name for Arbor erronis" as well as "Arbor erronis is the replaced synonym for Arbor novum". This would be good for new combinations, as well.

Some provisional notes:

• nomen abortivum (nom. abort.): does not mean anything to me; not a name
• nomen alternativum (nom. altern.) : to be defined
• nomen ambiguum (Q2533362): a taxonomic status?

--** combinatio nova (comb. nov.) -->

• nomen confusum (nom. confus.): a taxonomic status?
• nomen conservandum (Q941227): yes
• nomen conservandum propositum (nom. cons. prop.): yes
• nomen correctum (Q2372065): something dubious in zoology?
• nomen dubium (Q922448): a taxonomic status
• nomen illegitimum (Q1093954): yes
• nomen invalidum (nom. inval.): catch-all, but incompatible with taxon name (not a name)
• nomen negatum (nom.neg.): something dubious in zoology?
• replacement name (Q749462): better a separate property?
• nomen nudum (Q844326): useless distinction? = nom. inval. (not a name)
• nomen oblitum (Q901847): only in zoology and should be only used as part of a pair with nomen protectum -> thus a separate property

--** opera utique oppressa (opus utique oppr.) : needs to be rephrased, and even then not really useful = nom. inval. (not a name)

• orthographical variant (orth. var.): surely we are not going to have separate items for orthographical variants
• nomen protectum: only in zoology, and should be only used as part of a pair with nomen oblitum -> thus a separate property
• nomen provisorium (nom. provis.): useless distinction?
• nomen rejiciendum (nom. rej.): this is ambiguous. If not a "nom. utique rej. prop.", it is relative and should be only used as part of a pair -> thus a separate property
• nomen rejiciendum propositum (nom. rej. prop.): see above
• nomen utique rejiciendum (Q15149791) : yes
• nomen utique rejiciendum propositum (nom. utique rej. prop.): yes
• nomen subnudum (nom. subnud.): quite dubious (informal term), but might (occasionally) be useful?
• nomen superfluum (nom. superfl.): useless distinction? = nom. illeg.

I make that five useful terms: 1) nom. cons., 2) nom. cons. prop., 3) nom. illeg., 4) nom. utique rej., 5) nom. utique rej. prop. As well as a number of new properties to be made that could be useful. - Brya (talk) 18:12, 31 January 2014 (UTC)

Pairs that would really benefit by new properties:

• nomen oblitum - nomen protectum
• basionym - subsequent name(s)
• replaced synonym - replacement name

Also:

• "later homonym of"
• "hetertypic synonym(s)"
• "homotypic synonym(s)"

Brya (talk) 15:58, 1 February 2014 (UTC)

If I understand your comments right you principally agree with my proposal. Mind to vote? Your suggestions are welcome, but you should file a formal property proposal. l--Succu (talk) 23:23, 2 February 2014 (UTC)

I think the basic idea is a good one. At this stage I still do not really know what exactly I would be voting on. - Brya (talk) 06:29, 3 February 2014 (UTC)

•   Support. This seems like a good solution. The fact that it references a corresponding Darwin Core's corresponding 'nomenclatural status' term (http://vocabularies.gbif.org/vocabularies/nomenc_status) is a significant benefit. Videos from a 2012 workshop on semantics of biodiversity may interest users of this property: http://biocodecommons.org/workshops/sob.html. Emw (talk) 04:14, 1 February 2014 (UTC)
•   Support if this is to be used as a qualifier to taxon name (P225). I share some of Brya's concerns, but am not familiar enough with the topic to fully understand their implications for this proposed property. --Daniel Mietchen (talk) 22:10, 3 February 2014 (UTC)

  Done --Tobias1984 (talk) 12:41, 4 February 2014 (UTC)

Discussion

•   Wait - We should wait for this RfC first: Wikidata:Requests_for_comment/Image_properties:_many_properties_or_many_qualifiers. --Tobias1984 (talk) 12:12, 10 July 2013 (UTC)
•   Not done per Wikidata:Requests_for_comment/Image_properties:_many_properties_or_many_qualifiers.--GZWDer (talk) 13:25, 24 November 2013 (UTC)

  Please provide an explanation. I doubt that what was discussed there is applicable here. --Leyo 14:36, 24 November 2013 (UTC)

  • Wait for there.--GZWDer (talk) 11:09, 2 December 2013 (UTC)

  Comment If we create items for all the isotopes then this would be an easy query. What do you think? --Tobias1984 (talk) 20:04, 2 February 2014 (UTC)

+1 If we have an item for each isotope the number can be defined through the query of all isotopes of an element. Snipre (talk) 20:39, 2 February 2014 (UTC)

@Tobias1984, Snipre: If we create items for all isotopes, then yes. This of course assumes that all isotopes are notable. --Jakob (talk) 22:46, 2 February 2014 (UTC)

  Oppose all isotopes should be notable for Wikidata, and be described in Wikidata. John Vandenberg (talk) 14:50, 3 February 2014 (UTC)

  Not done Items for isotopes will be created. --Tobias1984 (talk) 14:54, 4 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 12:25, 9 December 2013 (UTC)

  Comment I am not native English: I thought you can only solve a calculation and that proving that something can be calculated is called "proving"? Is this not similar to the property for scientific discoverer? Possibly use qualifiers for that property? --Tobias1984 (talk) 14:53, 9 December 2013 (UTC)

No, you solve a problem, for example whether or not there is an answer to a question, and you prove a theorem. The question can be wheter or not there is an infinite number of prime numbers, which is a problem, the answer is yes, and the proof makes "there is an infinite numbers of prime numbers" a theorem. The question has been answered by Euclid, by proving the theorem. TomT0m (talk) 17:59, 9 December 2013 (UTC)

  Support No good reason not to crate and useful, left to long on property proposals. (in those kind of cases we should create for the proposer imo). TomT0m (talk) 22:27, 28 January 2014 (UTC)

•   Done --Tobias1984 (talk) 14:59, 4 February 2014 (UTC)

Discussion

This will enable us to generate lists of stratigraphic units, in which certain fossils are found. The reason to go "stratigraphic unit --> fossil" is that I suspect that stratigraphic units have less statements and that index fossils would get very many statements in which formation they are found. But that is open for discussion. The property might also double as a qualifier for statements about geologic time units. --Tobias1984 (talk) 19:38, 2 December 2013 (UTC)

I indeed wondered why you choose this direction. The property "t-rex" -> in stratigraphic unit -> "Holocene" seems more fitting to me, as you can easily select all units in which T-Rex bones where found so far but you cannot find all taxa which lived in the Jurrasic.  — Felix Reimann (talk)

@FelixReimann: I think for queries both would work equally fine. Having both properties would have the advantage of very good constraint violation control. The temporal range of fossils can also be checked against the temporal range of the units they were found in, giving us additional validation. By the way: Have you thought about adding support for temporal range start (P523) and temporal range end (P524) for the WikiData Taxobox? --Tobias1984 (talk) 09:28, 6 December 2013 (UTC)

@Tobias1984: not yet. But this is in principle no problem. However, I'm not sure if we should distinct fossils (which then get a palaeobox) from extant taxa (and extant extincted taxa) with instance of (P31)="fossil taxon". But I'm not sure if the definition "fossil=extincted before Holocene" is non-controversial.

@Tobias1984: first draft implemented. check it out!  — Felix Reimann (talk) 13:56, 6 December 2013 (UTC)

Regarding the proposed property: I'm not sure if you really gain something if you have both, a property A->B and a property B->A. For checking constraint violations, you can use queries (and while they are not implemented, WikiDataQuery). Having both, you just add the need to hold the data coherent, i.e. you add constraint violations without additional information.  — Felix Reimann (talk) 09:50, 6 December 2013 (UTC)

@FelixReimann: Wow, that was fast with the temporal range. Thank you very much. About the proposal: Ok lets do only one. I will try to get a few people from WikiProject Paleontology to give their opinion. There is also the question what kind of qualifiers should go with the property. For large fossils it might be interesting to know if the skeleton is complete or just some bones. From a stratigraphic point of view a qualifier for the position in the stratigraphic column would be useful. Often times fossils only occur in one horizon which might have a separate Wikipedia entry. --Tobias1984 (talk) 17:54, 7 December 2013 (UTC)

Pinging a few people that might want to comment: @Succu:, @Brya:, @Chris.urs-o:, @King jakob c 2: --Tobias1984 (talk) 14:10, 16 December 2013 (UTC)

Another example (hypothetical):

1. Nanotyrannus (Q15310631)

• found in stratigraphic unit = Hell Creek Formation (Q917642)

• parts = skull (Q13147) (Qualifier)
• coordinates = 3934 N 40843 E (Qualifier)
• in museum = Natural History Museum, Berlin (Q233098) (Qualifier)
• catalogue number = 3094349-IEI (Qualifier)
• in horizon = Bone Bed Horizon 1 (Only for notable bone-beds)
• specimen age = juvenile

The other way around it would look like this:

2. Hell Creek Formation (Q917642)

• fossils found = Nanotyrannus (Q15310631)

• parts = skull (Q13147) (Qualifier)
• coordinates = 3934 N 40843 E (Qualifier)
• in museum = Natural History Museum, Berlin (Q233098) (Qualifier)
• catalogue number = 3094349-IEI (Qualifier)
• in horizon = Bone Bed Horizon 1 (Only for notable bone-beds)
• specimen age = juvenile

Please vote on which direction seems more sensible. --Tobias1984 (talk) 14:10, 16 December 2013 (UTC)

  Comment: Tobias, Felix, couldn't the claim in example 1 be adequately captured by location of discovery (P189)? Emw (talk) 02:42, 23 December 2013 (UTC)

@Emw: I would say no, because a formation (Q736917) is not really a place but a slice of lithostratigraphy and a slice of time. There might be some ambiguity because notable fossils will have a discovery place and a formation (Q736917) in which the discovery was made. --Tobias1984 (talk) 10:29, 23 December 2013 (UTC)

I have no strong feelings here. My expectation would be that this would work great for some select cases (in either direction), but that in many other cases there would be so many data that it would be close to useless. However, this is not based on a close familiarity with the field. - Brya (talk) 17:33, 16 December 2013 (UTC)

• As outlined above, I vote for number 1.  — Felix Reimann (talk) 12:27, 17 December 2013 (UTC)
• @Emw: Do you know if there are any semantic web standards for this yet? --Tobias1984 (talk) 20:01, 22 December 2013 (UTC)

Tobias, RDF, RDFS and OWL do not support qualifiers. There are some ideas on how to represent Wikidata qualifiers in those languages, but it will likely be kind of a hack. Concretely, I think this means qualifier-centric data will be a pain to deal with in SPARQL, the W3C recommendation for querying Semantic Web data, and a likely future direction for Wikidata queries. So I think it makes sense to use qualifiers sparingly. The examples above use qualifiers rather heavily.

Furthermore, when I look at the examples, I see them describing an instance of a class -- an individual organism of a taxon. A fossil is obviously a long-since-deceased and materially diminished form of the specimen, but ultimately it represents an individual organism. I would recommend creating a new item for such things, and linking them to the taxon via instance of (P31).

This would make it straightforward to link multiple specimens to a given taxon or stratigraphic unit. The qualifier-centric approach in the examples above makes that impossible, or at least quite cumbersome. Emw (talk) 21:29, 22 December 2013 (UTC)

That sounds reasonable. For notable specimen we create items and greatly reduce the number of qualifiers. For non-notable specimens we just link to the taxon and try to use as little qualifiers as possible. --Tobias1984 (talk) 21:42, 22 December 2013 (UTC)

@Tobias1984: For the record, a discussion about rdf/owl and nary relations on the w3c website. TomT0m (talk) 23:08, 22 December 2013 (UTC)

@TomT0m: Thanks for the link. To be honest I have to read these text around 10 times until I have a grasp of what they are saying. - What do you think about this property? Are we compliant enough with semantic web and which direction should the property point to? --Tobias1984 (talk) 23:35, 22 December 2013 (UTC)

  Conditional support I'd support this, but I think the name should be changed to "fossil found in this unit" (singular instead of plural) since the object should be one fossil, and the word "lists" taken out of the description. Editors here know, in general, that a property like this can be used multiple times, right? I also agree with most of what Emw wrote above, not because I think we should eschew qualifiers in general, but because I think in the example given, some of the things that were qualifiers would be better coded as properties on the specimen. So, I'd change it to:

2. Hell Creek Formation (Q917642)

• fossils found = Nanotyrannus (Q15310631)

• coordinates = 3934 N 40843 E (Qualifier)

IMO, all of the other relations ("parts", "in museum", "catalogue number", etc.) would be better if they were statements on the specimen itself, or qualifiers on those statements. Klortho (talk) 02:05, 2 February 2014 (UTC)

@Klortho: Sounds like a good idea. Notable fossils get an item with more properties. Non-notable fossils just get a statement. Can you still give your opinion if the data should be stored with the formation or the fossil:

1. Nanotyrannus (Q15310631)

• found in stratigraphic unit = Hell Creek Formation (Q917642)

or

2. Hell Creek Formation (Q917642)

• fossil found in this unit = Nanotyrannus (Q15310631)

Pinging more frequent property reviewers @GZWDer:, @Ivan A. Krestinin:, @Paperoastro:, @Secretlondon:, @Danrok:, @Micru:, @Zolo:, @Jakec:, @Emw:. --Tobias1984 (talk) 11:21, 3 February 2014 (UTC)

Sorry, I'm not very familiar with this domain, so I won't give an opinion on which direction is more sensible. Klortho (talk) 19:37, 3 February 2014 (UTC)

•   Comment With option 2, couldn't a formation contain dozens of fossil types (thus cluttering the item) and with option 1, couldn't a fossil possibly be found in a large number of rock formations (also cluttering the item)? --Jakob (talk) 13:22, 3 February 2014 (UTC)

• @Jakec: The amount of clutter is going to be pretty equal with both choices. Fossils can be found in hundreds of formations, and some formations can contain hundreds of fossils. On Wikipedia choice number 2 is the standard. For example en:Horseshoe Canyon Formation has a table that shows which fossils are found in the unit. The fossils tend to have more detailed descriptions about their bones, evolution and other biological things. Maybe we should try to stay the most compatible with Wikipedia. --Tobias1984 (talk) 18:26, 3 February 2014 (UTC)

•   Done Not enough votes to decide which direction property should take. I am going to create it in the way that I think is more compatible to Wikipedia. --Tobias1984 (talk) 15:08, 4 February 2014 (UTC)

Discussion

  Comment This could be claimed using existing properties. By using start time (P580) as a qualifier for NRHP reference number (P649). Danrok (talk) 17:04, 8 January 2014 (UTC)

•   Not done --Tobias1984 (talk) 17:43, 4 February 2014 (UTC)

Discussion

Motivation. Пробегающий (talk) 06:21, 31 January 2014 (UTC)

•   Not done, see Wikidata:Property proposal/Pending/4.--GZWDer (talk) 16:14, 4 February 2014 (UTC)

Discussion

Additional storage elements. Example (see infobox): w:ru:Винная кислота, w:ru:Крезолы (new infobox) BattlePeasant (talk) 09:43, 22 January 2014 (UTC)

  Oppose This is solved by using instance of (P31): L-(+)-tartaric acid, D-(−)-tartaric acid are instance of tartaric acid which is considered as the racemic acid. This implies the creation of 3 items, one for the racemic and one for each isomer. If you take the CAS number or the PubChem ID for exemple each isomer has their own identifiers and often the racemic a set of specific identifiers too. Snipre (talk) 12:22, 29 January 2014 (UTC)

I agree, if is introduced SQL. BattlePeasant (talk) 19:17, 30 January 2014 (UTC)

Oppose, for the same reasons as Snipre (even if he does not use instance of correctly). --Izno (talk) 00:45, 31 January 2014 (UTC)

  Not done --Tobias1984 (talk) 17:54, 4 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 16:16, 2 December 2013 (UTC)

  Comment see About Kunstindeks Danmark and da:Skabelon:Kid navn --Steenth (talk) 16:55, 6 December 2013 (UTC)

  Support --Steenth (talk) 08:39, 9 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

  Done --Tobias1984 (talk) 17:56, 4 February 2014 (UTC)

Discussion

This is the standard number used in most Dutch libraries, and some German libraries as well. Documentation is a bit sparse (especially in English) but a description from OCLC in Dutch is available here. These PPN's are already linked in VIAF, so it might make sense to do an import from there.

  Oppose Try Nationale Thesaurus voor Auteursnamen ID (P1006)^^ BTW: The PICA system is used "in most Dutch libraries, and some German libraries as well". That is correct, but the numbers are different. In the SWB union catalog for example Theo van Doesburg (Q160422) has got PICA no. 160759439. --Kolja21 (talk) 23:31, 30 January 2014 (UTC)

Okay. Thanks for noticing that. I must say that my knowledge of all these identifiers is a little too limited, so i asked a colleague to weigh in on this subject. Husky (talk) 09:59, 31 January 2014 (UTC)

Moved this back from the archive. The Nationale Thesaurus voor Auteursnamen ID (P1006) is not the same as a PPN. The PPN is an ID that is used for multiple purposes in the GGC software that is used in many libraries. Purposes include authors, but also book titles, publishers and even keywords. NTA numbers are a subset of author PPN's. For example, the book Theatrum Orbis Terrarum (Q1368633) has PPN 054690455 (not a NTA number), the author of that book, (Abraham Ortelius (Q232916) has PPN 069075301 (is a NTA number). So, i hope that clears things up and we can add the PPN in Wikidata as well. Husky (talk) 11:19, 4 February 2014 (UTC)

Of cause P1006 is not "the PPN" in general, since it makes no sense to add numbers that are ambiguous. The PICA system is used by various libraries. As you already noticed it may be a number of a book or an authority record. You can add two or three of these numbers and never know to which library they belong. --Kolja21 (talk) 13:45, 4 February 2014 (UTC)

AFAIK PPN's are not unique to a single library. For example, here's a book with the same PPN in the catalogues of the KB and the NA. If we want to link Wikidata to the National Library of the Netherlands i can't figure out another way than PPN's. Husky (talk) 14:03, 4 February 2014 (UTC)

Discussion

We already have student (P802) but "teacher" is usually more important (a professor usually has more influence on her students than the other way around) and usable in more items (more people have had professors than students) --Zolo (talk) 18:26, 17 December 2013 (UTC)

  Support, seems useful. "Student of" might be a better label -- it's the convention for inverse properties, and avoids confusion between the several different types of "teacher" one might have (professor, teacher, etc.). Emw (talk) 21:39, 22 December 2013 (UTC)

@emw:,   Done, student of (P1066) --Zolo (talk) 08:30, 11 January 2014 (UTC)

we should use the properties student (P802) and student of (P1066) not only for a person but also in relation to the school/academy/institute. So student of (P1066): person or institute who has taught this person see Pablo Picasso (Q5593)/Royal Academy of Fine Arts of San Fernando (Q1322403)--Oursana (talk) 12:09, 31 January 2014 (UTC)

For the institutes, we already have educated at (P69). --Shlomo (talk) 23:17, 2 February 2014 (UTC)

Discussion

This is essentially the same as floors above ground (P1101) except for below ground floors. Danrok (talk) 23:26, 31 January 2014 (UTC)

  Support Useful also for mine-shafts. --Tobias1984 (talk) 23:33, 31 January 2014 (UTC)

  Support — Ivan A. Krestinin (talk) 18:21, 3 February 2014 (UTC)

  Done --Tobias1984 (talk) 18:13, 4 February 2014 (UTC)

Discussion

EHAK codes for administrative units and settlemets are used by Estonian Statistical Office and other state agencies. WikedKentaur (talk) 15:41, 2 February 2014 (UTC)

  Support --Tobias1984 (talk) 20:06, 2 February 2014 (UTC)

  Support — Ivan A. Krestinin (talk) 18:26, 3 February 2014 (UTC)

  Stöder -- Lavallen (talk) 09:15, 4 February 2014 (UTC)

  Done --Tobias1984 (talk) 18:18, 4 February 2014 (UTC)

  Support Simple link used in the specs infobox. Joshbaumgartner (talk) 07:02, 2 October 2013 (UTC)

  Comment might valvetrain configuration be a better label? --Danrok (talk) 21:02, 21 October 2013 (UTC)

  Support I agree, changed accordingly. Joshbaumgartner (talk) 00:51, 27 October 2013 (UTC)

  Support --Tobias1984 (talk) 14:15, 25 November 2013 (UTC)

Discussion

•   Support as nominator. There is currently no clear way to link something fictional to the series that it's in. We could use "part of =>" or "fictional character => of =>". But I think this usage is specialized enough that it would be very useful to have its own property with its own constraints. This would also keep the "part of" property free to say what the subject is part of in-universe. Arctic.gnome (talk) 20:59, 20 December 2013 (UTC)

  In the proposal for the similar property narrative location (P840), it was said that it could also be used for non-fictional narratives. Would the proposed property also be usable for nonfiction? --Yair rand (talk) 18:41, 24 December 2013 (UTC)

  Interesting question. I'm inclined to say no. The question of which work a fictional entity is from is a defining feature of that entity. Real-world entities, on the other hand, are notable for something else and it's only incidental to their notability that they have a book about them. Also, we would have to somehow find a way to cap the number of narratives that a real-world entity has listed; how many narratives feature Napoleon or New York City? Probably way too many to list. --Arctic.gnome (talk) 01:11, 30 December 2013 (UTC)

  @Arctic.gnome: I would think that the same would apply just as well to elf (Q174396). --Yair rand (talk) 14:09, 19 January 2014 (UTC)

  @Yair rand: True, but I would say that the defining feature of "elf" is being a mythological creature, whereas the the defining feature of "jedi" is being from Star Wars. Maybe a more accurate title for what I have in mind is "invented in the fictional work" --Arctic.gnome (talk) 17:41, 19 January 2014 (UTC)

  That substantially narrows down possible uses for the property. If the object is always going to be the "source" narrative, so to speak, then I think both the label and the description should be modified. "Invented" might not be the correct term, though. I don't think people tend to refer to characters as being "invented", in general. --Yair rand (talk) 18:04, 19 January 2014 (UTC)

  How about "from narrative" or, more specifically, "originally from narrative"? Narrowing scope is fine. I mostly just wanted a way to link pages like Narnia or Thought Police back to their source material. For items that have hundreds of books about them, like Napoleon or dragons, it might be a better idea to link from the work's page using a property like "is a work about". It might seem counter-intuitive for me to propose one property from the subject and one property from the work, but I'm trying to minimize the number of times we have to have giant lists of 100 links for one property. --Arctic.gnome (talk) 06:39, 20 January 2014 (UTC)

    Oppose In preference to storing this type of data with the work. As we are already doing to some extent with similar properties, e.g. "narrative set in". We would then be able to get a list of all works which refer to a character via a query. Danrok (talk) 15:50, 5 January 2014 (UTC)

  • What property would be used for that? Should we create a property called "contains fictional entities" that lists every character and fictional object in the story? For long stories with a large editing base, like Harry Potter, there would be a huge number of items linked. --Arctic.gnome (talk) 21:38, 6 January 2014 (UTC)

This property, character role (P453), for example. As used here: Harry Potter and the Philosopher's Stone (Q102438). Danrok (talk) 17:17, 8 January 2014 (UTC)

We already have characters (P674), actually... --Yair rand (talk) 19:11, 8 January 2014 (UTC)

  Support, could be useful to link articles like Mordor and Phrases from The Hitchhiker's Guide to the Galaxy to the corresponding work. --NaBUru38 (talk) 19:02, 12 January 2014 (UTC)

  Support --Konggaru (talk) 04:25, 19 January 2014 (UTC)

  Done Danrok (talk) 13:13, 30 January 2014 (UTC)

Discussion

I want to add information to the CPU items, but there aren't enough properties to that. MisterSanderson (talk) 14:12, 24 November 2013 (UTC)

  Support --Tobias1984 (talk) 07:51, 25 November 2013 (UTC)

  Done --Tobias1984 (talk) 18:43, 4 February 2014 (UTC)

Discussion

The largest library in Argentina and one of the most important in the Americas. --Kolja21 (talk) 15:50, 20 January 2014 (UTC)

Discussion

The existing Property:P244 appears to be for individual people; this is the equivalent control number for books. AdamBMorgan (talk) 03:05, 20 January 2014 (UTC)

  Support A good label would be "LCCN editions". Compare: IdRef ID (P269) and SUDOC editions (P1025). --Kolja21 (talk) 03:55, 20 January 2014 (UTC)

  Support Do we have a VIAF equivalent, or some other identifiers affiliated with national libraries? I will ask to the National Library of Florence. Aubrey (talk) 06:43, 20 January 2014 (UTC)

  Comment Difficult, not only because edition is ambiguous: There exist proper authority records for individual expressions (in FRBR lingo) like a italian translation LCCN no2003071617. Unfortunately these are just in the process of being installed, the authority record does not yet tell us about the translator or more general about which of (presumably) several italian translations it is about. Likewise at the moment there do not exist LC authority records for english expressions of works, be it the original language or the language of a translation. The realm of the property here for "ordinary" LC records would be manifestations, e.g. a printed version from that and that year with such and such imprint and so many pages, but not the e-book with the same text content. The item given in the example arises from the digitization and transcription of a certain copy ("University of California Southern Branch" - they probably hold several items but logically none of them is shown by the catalogue of the Library of Congress: different libraries, different copies) of the said 1911 edition which seems to be notable because of the illustrations. The introducing text in wikisource gives a short description of the publication history, unfortunately I'm not able to decide whether this 1911 "edition" should be considered a mere manifestation (identifyable by its LC number "for books") or should be considered an expression (identifyable by a LC authority record with number Library of Congress authority ID (P244) which unfortunately does not exist at the moment). Thus exactly like OCLC control number (P243) and Open Library ID (P648) the property proposed here can only serve to give proof that an "edition" with the properties (Publisher, Year of Publication, ...) asserted in the wikidata item indeed does exist. -- Gymel (talk) 07:32, 20 January 2014 (UTC)

+1. These problems are discussed by Wikidata:Books task force. --Kolja21 (talk) 15:55, 20 January 2014 (UTC)

  Comment It seems we have duplicate on Wikidata:Property_proposal/Creative_work#Library of Congress Classification. --Rezonansowy (talk) 01:04, 21 January 2014 (UTC)

No, this proposal is about the catalog no. of a single book. The classification (of the content) is something else. One of the most popular classification systems is Dewey Decimal Classification (P1036). --Kolja21 (talk) 02:25, 21 January 2014 (UTC)

Discussion

The "Also known as:" field gives not enough semantic depth to distinct between a pseudonym (alias), an abbreviation, an acronym, initials, and plurals. Therefore additional properties should be introduced to reflect this. MovGP0 (talk) 05:26, 11 January 2014 (UTC)

Agree, but I am not sure string-datatype is the best solution. -- Lavallen (talk) 19:47, 11 January 2014 (UTC)

  Oppose. Please see Wikidata:Property_proposal/Archive/7#Code, Acronym or Abbrevation. --Yair rand (talk) 10:10, 22 January 2014 (UTC)

  Not done --Tobias1984 (talk) 14:20, 10 February 2014 (UTC)

Discussion

•   Support Sounds like a good idea. Ajraddatz (Talk) 03:20, 30 January 2014 (UTC)
•   Support Helpful for organizations. For persons it's not useful, unless we want to add qualifiers like "90% left" (own view, 2001-2004), "15% left" (external view) etc. For persons please use properties like member of political party (P102). --Kolja21 (talk) 07:22, 4 February 2014 (UTC)

Discussion

•   Comment Could be the information managed by type of orbit (P522)? This property could be used as qualifier of it. --Paperoastro (talk) 00:04, 20 December 2013 (UTC)

• Problem is, that type of orbit (P522) is already mixing a few things: The altitude of the orbit (LEO, MEO), The movement relative to earth (GSYN, GSTAT), .... - We have to find a way to separate those different kinds of information. The libration points in my opinion should go together with this statement: type of orbit (P522) = heliocentric orbit (Q737809). --Tobias1984 (talk) 08:44, 20 December 2013 (UTC)

•   Support as told by Tobias1984, this property can help us to manage orbit informations. --Paperoastro (talk) 16:51, 20 December 2013 (UTC)

  Done --Tobias1984 (talk) 14:45, 10 February 2014 (UTC)

→ Property:P1114

@Macadamia1472, Yair rand, Paperoastro, TomT0m, Klortho, Emw:   Done as P:P1114 and archived. There may still be points to clarify but I think we have suffiicient consensus to create the property --Zolo (talk) 18:43, 1 February 2014 (UTC)

  Comment Could also be used as a standalone property in place of the proposed "number of instances" but I am not sure. --Zolo (talk) 07:09, 14 October 2013 (UTC)

  Support This would be useful as a qualifier Macadamia1472 (talk) 06:27, 15 October 2013 (UTC)

  Question Could you still add a couple of examples? --Tobias1984 (talk) 11:36, 25 November 2013 (UTC)

I have fixed the datatype and added a link Wikidata:Property proposal/Economics as I forgot to update that after page move. What I want is to be able to say. Country X: key production satistics: wheat: quantity: 250 000t, car: quantity: 20,000 units but actually I see in Wikidata:Requests for comment/Dimensions and units for the quantity datatype that quantity with unit datatype will be "associated with properties on creation" so this would not really work (we should rather have: wheat: mass: 250,000t, cars: number of instances: 20,000). --Zolo (talk) 08:53, 27 November 2013 (UTC)

Zolo, a couple of comments. I see what you are referring to about the units datatype, but I don't think changing the datatype of this to "number" is a viable solution. We could ask on the discussion page over there if there's any possibility of defining properties that take any generic scalar quantity as an object, with dimensions determined at statement-creation time. Otherwise, you would need a qualifier on this qualifier, to determine the units, and I don't think that's supported or reasonable. Also, I didn't see any link (which you said you added) from Wikidata:Property proposal/Economics to this discussion, so I added one here. Klortho (talk) 20:19, 12 January 2014 (UTC)

•   Oppose Until number of episodes (P1113) and quantity (P1114) are better defined (or merged) and it can be proven that this property is needed. --Tobias1984 (talk) 21:59, 3 February 2014 (UTC)
• @Zolo: Do we still need this property? --Tobias1984 (talk) 14:18, 10 February 2014 (UTC)

@Tobias1984: No I don't think so :-]

I think the formal description of number of episodes (P1113) and quantity (P1114) would be somewhat different. viz Simpsons: series length: 541: does not mean that there are 541 instances of The Simpsons (Q886) (as opposed to what "US states: number of instances: 50" means) --Zolo (talk) 15:39, 10 February 2014 (UTC)

@Zolo: - Great thanks. I'll archive this in the next run. And now I think I understand p1113 and p1114. Do you have time to vote on the proposal for mathematical constants (bottom of this page). --Tobias1984 (talk) 15:45, 10 February 2014 (UTC)

Discussion

Discussion

Main reference for athlets. --putnik 18:44, 8 January 2014 (UTC)

•   Support — Ivan A. Krestinin (talk) 19:03, 8 January 2014 (UTC)
•   Support — Danrok (talk) 18:57, 12 January 2014 (UTC)

  Done --Tobias1984 (talk) 14:46, 11 February 2014 (UTC)

   Done: neutron number (P1148) (Talk and documentation)

Description	number of neutrons of an isotope
Data type	Number (not available yet)
Template parameter	Infobox Isotope
Domain	Isotopes
Allowed values	Positive integers: ${\displaystyle \mathbb {N} =\{0,1,2,\ldots \}.}$
Example	tritium (Q54389) = 2
Format and edit filter validation	Single Value, Positive integers: ${\displaystyle \mathbb {N} =\{0,1,2,\ldots \}.}$
Source	Physics literature and databases
Proposed by	--Tobias1984 (talk) 19:57, 31 January 2014 (UTC)

Discussion

  Support Emw (talk) 01:03, 14 February 2014 (UTC)

  Comment changed proposal to include zero neutrons. I also want to set the property for isotopes that only have protons. --Tobias1984 (talk) 18:23, 16 February 2014 (UTC)

  Support TomT0m (talk) 18:27, 16 February 2014 (UTC)

  Done --Tobias1984 (talk) 21:42, 17 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 15:46, 1 December 2013 (UTC)

Was the "Item" datatype for this and the two proposals below deliberate? --Yair rand (talk) 06:02, 2 December 2013 (UTC)

Dewey Decimal Classification (P1036) is a string.--GZWDer (talk) 11:11, 2 December 2013 (UTC)

GZWDer, your examples are strings (e.g. 'H'). Do you want LCC classifications to be items or strings? John Vandenberg (talk) 11:09, 23 December 2013 (UTC)

All should be string.--GZWDer (talk) 12:52, 23 December 2013 (UTC)

•   Support. consistent with Dewey Decimal Classification (P1036) John Vandenberg (talk) 14:01, 23 December 2013 (UTC)
•   Support per above --Rezonansowy (talk) 13:18, 4 January 2014 (UTC)
•   Support. Emw (talk) 03:58, 20 January 2014 (UTC)
•   Support לערי ריינהארט (talk) 09:21, 18 February 2014 (UTC)
•   Done Danrok (talk) 20:29, 18 February 2014 (UTC)

Discussion

Pretty helpful if you visit an institute library in Germany. You'll find your literature much faster. --Kolja21 (talk) 19:26, 10 February 2014 (UTC)

•   Support לערי ריינהארט (talk) 09:25, 18 February 2014 (UTC)

Discussion

Topics and their associated Wikimedia portals are currently not explicitly linked on WD. It seems to me they should be, because it's useful information to have that is only implicit on Wikipedia and other projects. A reverse property "Wikimedia portal main topic" should probably be created too. -- Bjung (talk) 05:21, 11 January 2014 (UTC)

The names should be changed to "topic's main portal" and "portal's main topic" for consistency with "topic's main category" and "category's main topic."--Erasmo Barresi (talk) 13:30, 15 January 2014 (UTC)

•   Support A good idea. Agree with Erasmo Barresi's naming suggestion. --Jakob (talk) 23:55, 15 February 2014 (UTC)

Discussion

Generally, IPTC as a standard is widely used by GLAMS, and it is useful for cross-referencing.

Specifically, IPTC media topics are often used in meta data embedded in JPG and TIFF files we get from GLAMs. If we knew which data item the media topic corresponds to, we could automatically assign a commons category for a first, rough, categorization of the upload. Once we have commons:Wikidata for media info, this information could be used to tag images directly with Wikidata items. -- Duesentrieb (talk) 09:32, 25 September 2013 (UTC)

  Comment would this be claimed in the "instance items", e.g. an instance of a comic, or only in the "type item", e.g. comic? --Danrok (talk) 16:47, 3 October 2013 (UTC)

It would be set on the type item. We would be mapping their media topic vocabulary to Wikidata items, not usign their vocab to classify Wikidata items. -- Duesentrieb (talk) 21:23, 13 November 2013 (UTC)

Duesentrieb, I haven't found any previous work for the mapping, do you plan to do it as an automated task?--Micru (talk) 16:36, 23 November 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

Discussion

ORCID is slowly being adopted, but Scopus Author IDs are what research organisations actually typically use, for good or ill. Scopus extracts the author information on publications[6], but also has author merge processes which include human reviews by their staff. This ID is needed to query the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)

  Oppose Scopus is operated by a private company and only available by subscription. --Kolja21 (talk) 00:21, 2 December 2013 (UTC)

• The scopus author profiles (including affiliation) are publicly accessible and searchable. I have added more examples, which includes every item with ORCID iD (P496), where the ORCID record includes the Scopus Author ID and links to Scopus Author profiles.
  Is there a policy or guideline against private companies? If so, IMDb ID (P345) is also owned by a private company, Amazon (Q3884). FilmAffinity film ID (P480) is also commercial. Even ISBN-10 (P957)/ISBN-13 (P212) can be commercial; in Australia they are issued by Q15265427. John Vandenberg (talk) 01:58, 2 December 2013 (UTC)

Thanks for the link to the "Free Lookup Form" but if I want more information I have to pay: "Login Required to Access Scopus". The database of Amazon.com is completely free but I would also oppose a property for e-commerce. There are no general restrictions against private companies but against paid content. --Kolja21 (talk) 02:48, 2 December 2013 (UTC)

IMDB is not completely free. Amazon only provides the first layer of IMDB information free, and you need to pay to access IMDbPro. Find a Grave memorial ID (P535) and Emporis building ID (P455) are the same. We also have Google Books ID (P675) (which links to lots of ecommerce functionality). You say that you can access the webpage links that I provide, but call it paid content. It is freely accessible public profiles of every active researcher of the world, in nearly every discipline of research, and those freely accessible webpages contain information that you will not find in any other system, like h-index, publication counts, primary disciplines. Most of the DOIs on Wikipedia and Wikidata are going to be e-commerce. Scopus is not e-commerce. You can't buy anything on any Scopus website. Either you have access to their advanced functionality, or .. you don't and can't get it. Scopus only enter into institution licenses, like OCLC, to provide additional services for institutions and academics. John Vandenberg (talk) 04:51, 2 December 2013 (UTC)

  Support I see no compelling reason to prohibit authority control identifiers simply because they come from entities that are operated by private companies and require a subscription. Emw (talk) 04:03, 3 January 2014 (UTC)

The main problem I see here is that a given researcher may have more than one Scopus ID (e.g. due to a change in affiliation or research subject, or after marriage). I don't have access now but I once found 3 or 4 IDs for me. --Daniel Mietchen (talk) 04:23, 3 January 2014 (UTC)

Daniel Mietchen, those are only artifacts of the person publishing under different names, which all databases suffer from in this domain. Scopus has a process to have identities merged, which may be initiated by the author, the institution, or by Scopus themselves. Scopus does not want multiple identities for the same person, it is not in their commercial interest; they win bids for large bibliometrics contracts based on having high quality identity data, and in Australia at least the data is almost perfect since 2003 as each institution works closely with Scopus to fix any author identity problems during the government audit of research activity. See the many libguides about that. John Vandenberg (talk) 04:46, 3 January 2014 (UTC)

  Support GerardM (talk) 08:08, 1 February 2014 (UTC) We add value by linking to external sources.. Scopus is hardly the only resource and as its open competition does a better informative job, they will increasingly do better.

Discussion

Academics will often search Scopus for a paper to cite; lets make it easy for them to create a source item and add source clauses. Also Scopus EID are used in the data warehouse of most universities, in order to extract citation counts out of Scopus via the Scopus API. We have a proposal to add 'impact factor' (Wikidata:Property_proposal/Creative_work#impact_factor), and I expect a proposal for 'citation count' to be coming soon ;-) Adding a link to scopus allows academics in wikidata to quickly jump to Scopus to see the citation count, and view related academic papers. This ID is needed to query the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)

Following the issue raised by Kolja21 above regarding datasources that require a subscription, it may be that links to publications in Scopus do not always work without a subscription. I am not sure, as I havent seen any official statement from Scopus that publication pages are always accessible via Scopus Preview (as opposed to author profiles, which are public).
However I have tried it using a random scopus ID I saw last night ( here) without a subscription and it worked for me (in Indonesia), and the cited-by functionality also works. Kolja21, do these links not work for you? The 'Scopus Preview' pages have limited functionality, but it is the metadata that people need to view. fwiw, in Australia all universities have full access to Scopus - a country wide agreement exists. I have found this info from a third party website which says "Non-subscribers of Scopus can view all articles on the Scopus Preview page with limited functionality." John Vandenberg (talk) 02:28, 2 December 2013 (UTC)

Hi John, the links work fine but as said above a free preview is not enough. We have the same problem with the NYT and other reputable publishers: If they only provide a preview for their articles the external links in Wikipedia will be deleted. Sorry --Kolja21 (talk) 03:12, 2 December 2013 (UTC)

  Support I see no compelling reason to prohibit authority control identifiers simply because they come from entities that are operated by private companies and require a subscription. Emw (talk) 04:04, 3 January 2014 (UTC)

Discussion

Scopus has a very good database of affiliation for research articles, and for the academics, and most importantly includes hierarchical information about the structure within organisations and relationship between organisations. Public library data and DOI data is typically sourced only from the publication metadata, which includes lots of errors in affiliation (misspellings, use of non-legal entity names). This ID is useful for querying the Scopus APIs. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)

  Support. Emw (talk) 04:05, 3 January 2014 (UTC)

Discussion

Scopus has a very good database of journals, and includes publisher, issns, SNIP and SJR indexes, and subject area (fields of research, discipline) classifications. This ID is not very useful for querying the Scopus APIs regarding publications, and mandatory to use for using the Scopus API to access information about journals. John Vandenberg (talk) 03:30, 1 December 2013 (UTC)

• The data can be imported from their regularly updated spreadsheet (9MB). It also has a flag to say whether the record has been added since the last published version of the spreadsheet. The spreadsheet contains the following properties for each journal: Source ID, ISSN, E-ISSN, Title, Source Type (Journal vs Conference), Active vs Inactive, Registered in DOAJ.ORG flag, Journal merges and renames, publishers name, publisher country, and ASJC codes (All Science Journal Classification). It is this source list of 32,000 journals and the classification scheme that the majority of the sector uses, and builds bibliometrics on top of (see http://www.journalmetrics.com/documents/SNIP_SJR_complete_1999_2012_v1.xlsx 12Mb)
  I have this data in a database and am working on a bot to import it into my local copy of Wikidata. John Vandenberg (talk) 01:06, 1 January 2014 (UTC)

  Support. Emw (talk) 04:06, 3 January 2014 (UTC)

Discussion

It is a good source to have on politicians in the United States Congress. Past and present. Clarkcj12 (talk) 01:48, 11 December 2013 (UTC)

  Support Know as "Bioguide". I've added the template. --Kolja21 (talk) 02:13, 11 December 2013 (UTC)

  Support John Vandenberg (talk) 02:22, 11 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

Discussion

  SupportFilceolaire (talk) 21:44, 24 February 2014 (UTC)

Discussion

These codes are useful for scientific journals of all kinds, but are especially useful for proceedings (Q1143604), and have been most heavily used in Chemistry. Part of Wikidata:Periodicals task force. John Vandenberg (talk) 06:07, 5 December 2013 (UTC)

  Support --Kolja21 (talk) 17:38, 16 February 2014 (UTC)

Discussion

Widely used attribute of journals. Used in many citation style guides. Part of Wikidata:Periodicals task force. John Vandenberg (talk) 06:07, 5 December 2013 (UTC)

  Support We need this. --Tobias1984 (talk) 16:12, 10 December 2013 (UTC)

  Support Danrok (talk) 13:08, 30 January 2014 (UTC)

Discussion

I am less sure about the need for this, as it is mostly the same as the ISO 4. It is in many citation style guides. John Vandenberg (talk) 06:07, 5 December 2013 (UTC)

Discussion

This is the standard abbreviation used in Law citations, esp Bluebook, but also standards in other countries. John Vandenberg (talk) 06:07, 5 December 2013 (UTC)

Discussion

Motivation. Rezonansowy (talk) 19:26, 18 January 2014 (UTC)

Discussion

Motivation. TeleComNasSprVen (talk) 21:13, 31 December 2013 (UTC)

  Not done We now have number of episodes (P1113). Danrok (talk) 00:06, 13 February 2014 (UTC)

Discussion

  Not done We now have a property for this: publication date (P577). Danrok (talk) 00:09, 13 February 2014 (UTC)

Discussion

We should be able to indicate the order of any finite group. Helder 16:16, 28 November 2013 (UTC)

  Comment - I would try to find a more specific name for the property. With the current name the property might be used for other things than numbers. The question is also if a more generic number property is specific enough. --Tobias1984 (talk) 16:48, 28 November 2013 (UTC)

Alternative (but less common) names would be "Group size" or "Cardinality of the group". Helder 17:53, 28 November 2013 (UTC)

Discussion

105.236.219.79 13:38, 8 December 2013 (UTC)

  Support Pikolas (talk) 00:22, 28 December 2013 (UTC)

Discussion

Motivation. FischX (talk) 18:33, 22 October 2013 (UTC)

•   Stöder -- Lavallen (talk) 07:07, 13 February 2014 (UTC)

Discussion

•   Comment I hate them, and they are going out of fashion thankfully (see w:San Francisco Declaration on Research Assessment), but people continue to use them so it is useful. However, I am concerned about sourcing the data from Thompson data (or other bibliometrics based on Scopus), as it could be covered by a w:database copyright, as those corporations derive a lot of profit from the publication of those numbers. Wikipedia is wildly incomplete, so not a major concern, but Wikidata can easily be complete, which may cause them to seek remedies. http://uifactor.org/ is also not free data. I would prefer that we use w:Eigenfactor, as they are quite clear they hold no IP rights over the data (http://www.eigenfactor.org/faq.php # 6), but it still uses Thompson data, but it it is less risky. John Vandenberg (talk) 10:36, 30 November 2013 (UTC)

Discussion

GKZ are given on most rivers and streams in european countrys. Including them makes it easier to cross-reference entries with other sources. Ogmios (talk) 09:44, 18 December 2013 (UTC)

  Comment Moved here from Wikidata:Property proposal/References. --Kolja21 (talk) 19:20, 23 January 2014 (UTC)

  Support --Tobias1984 (talk) 08:38, 24 January 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 16:16, 2 December 2013 (UTC)

•   Comment How comprehensive is this dataset? How many records do they have? John Vandenberg (talk) 11:34, 5 December 2013 (UTC)
  • see zh:法鼓佛教學院, a Buddhist College created by Sheng-yen (Q712896) in 2007. The person ID database has 22989 records and place ID has 57968.--GZWDer (talk) 12:10, 5 December 2013 (UTC)
•   Support (thanks GZWDer) John Vandenberg (talk) 12:53, 5 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

• @GZWDer, John Vandenberg, Emw:   Done --Jakob (talk) 13:23, 25 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 16:16, 2 December 2013 (UTC)

•   Comment How comprehensive is this dataset? How many records do they have? special:search/Dharma Drum Buddhist College reveals nothing and I couldnt find the relevant record in special:search/DDBC. ;-( John Vandenberg (talk) 11:34, 5 December 2013 (UTC)
•   Support per reply from GZWDer above. John Vandenberg (talk) 12:54, 5 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

• @GZWDer, John Vandenberg, Emw:   Done --Jakob (talk) 13:29, 25 February 2014 (UTC)

Discussion

Originally SELIBR ID (P906) was proposed to link to works. But somewhere on the road, the purpose shifted to be about Authors instead. This is a remake of the original purpose! Lavallen (talk) 18:11, 16 January 2014 (UTC)

  Support I've changed the name from "libris" to "LIBRIS editions" (see Template:Book properties). I hope you don't mind. --Kolja21 (talk) 23:46, 19 January 2014 (UTC)

Discussion

Handles are used for digital objects, especially by photographs by GLAMs and research papers held in academic digital repositories. The example provided is a Wikisource transcribed digital object provided by a GLAM. I can also provide an example of a notable research paper with a handle if required, but that will take a bit more searching. John Vandenberg (talk) 18:02, 28 January 2014 (UTC)

  Support --Kolja21 (talk) 22:04, 28 January 2014 (UTC)

  Support - Husky (talk) 16:44, 30 January 2014 (UTC) - For a nice example, the Rijksmuseum has handles for all of their paintings, here's Rembrandt's Nightwatch

• Example does not work ... GerardM (talk) 08:11, 1 February 2014 (UTC)
  • It worked a few days ago. "Many ejournals and databases will be unavailable 9pm 2 February until 7am 3 February 2014 due to hardware upgrades." --Kolja21 (talk) 02:01, 2 February 2014 (UTC)
    • Seems to work again... Husky (talk) 10:09, 10 February 2014 (UTC)

This property would help capture Mendelian inheritance information about genetic disorders. Emw (talk) 02:36, 28 February 2014 (UTC)

  Support Filceolaire (talk) 22:13, 24 February 2014 (UTC)

Emw: Whats the motivation of your proposal. I see no explanation. --Succu (talk) 22:26, 25 February 2014 (UTC)

Succu, thanks for the reminder. I've added the motivation above. Emw (talk) 02:36, 28 February 2014 (UTC)

  Support --Tobias1984 (talk) 17:47, 28 February 2014 (UTC)

  Comment, Hi Emw, I added some claims to these items, but I'm wondering if they are not duplicates, for example dominance (Q6531938) is labelled in french as a transmission mode, not a dominance relationhip. Duplicate or conflict ? TomT0m (talk) 20:11, 28 February 2014 (UTC)

Conflict, TomT0m. The French article sitelinked in dominance (Q6531938) is about transmission autosomique dominante, i.e. autosomal dominant inheritance, a particular mode of inheritance. French Wikipedia also has an article on transmission autosomique récessive, i.e. autosomal recessive inheritance. Wikipedia discusses all the modes of inheritance in one article, "dominance (genetics)". The sitelinks in these inheritance articles are apparently messy. Emw (talk) 23:51, 28 February 2014 (UTC)

• @Emw, Filceolaire, Succu, TomT0m:   Done --Jakob (talk) 21:45, 1 March 2014 (UTC)

Discussion

• This is great. I'll give this two supporting votes for the price of one. --Pxos (talk) 22:43, 26 February 2014 (UTC)
• Should I give one too.--Urjanhai (talk) 22:47, 26 February 2014 (UTC)
• I support this too. --Zache (talk) 03:02, 27 February 2014 (UTC)
•   Support --Susannaanas (talk) 06:16, 27 February 2014 (UTC)
• I think datatype should be string instead of Number as it displays listing/authority control rather than Quantity. What you say? -Nizil Shah (talk) 20:29, 2 March 2014 (UTC)

Yes, string it is and not a number. --Pxos (talk) 10:02, 3 March 2014 (UTC)

My mistake. Corrected now. --Stryn (talk) 15:03, 3 March 2014 (UTC)