Shortcut: WD:PP/SCI

Wikidata:Property proposal/Natural science

From Wikidata
Jump to: navigation, search
Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sports Sister projects
Economics Transportation Natural science Property metadata

See also[edit]


This page is for the proposal of new properties.

Before proposing a property
  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.


On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2017/07.

Physics and astronomy[edit]

average yearly temperature[edit]

   Under discussion
Description temperature calculated by averaging the minimum and maximum daily temperatures over 30 years in a certain place
Data type Quantity
Domain instances of geographic region (Q82794) and instances of, recursively, its subclasses
Allowed values from -400 (minimum using degree Fahrenheit (Q42289), near to the absolute zero (Q81182)) to 350 (maximum using kelvin (Q11579), perhaps could be reached inside a volcano)
Allowed units the same as temperature (P2076), that is, degrees Celsius (Q25267), kelvin (Q11579) and degree Fahrenheit (Q42289)
Example Zaragoza (Q10305) → 15.5 °C (according to aemet.es, the Agencia Estatal de Meteorología (Q2826727))
Planned use firstly, importing data for some Spanish municipalities from the Agencia Estatal de Meteorología (Q2826727)
Robot and gadget jobs creating and regularly updating a world map (Q653848) that represents how these values are distributed across the planet
See also temperature (P2076), Köppen climate classification (P2564)
Motivation

Wikidata is lacking in climate data, and the average yearly temperature is a particularly relevant measurement. abián 15:57, 28 August 2016 (UTC)

Discussion
I think that we have a problem.
  1. If we only create a property for the average monthly temperature, we won't be able to get the average yearly temperature if we don't have well-defined data of all months. In some cases, we know the average yearly temperature but not the average monthly one.
  2. If we only create a property for the average yearly temperature, we'll never be able to know the average monthly temperature.
  3. If we create both properties, we should never use both for the same Wikidata item. This situation could be controlled using a {{Constraint:Conflicts with}}.
There isn't a perfect solution. If we usually know the average monthly temperature, I would say 1. If we usually know the average yearly temperature but hardly ever the average monthly one, I would say 2. And, if there's no a "usual" situation, I would say 3. If I would have to choose right now, without being able to talk or to find out about this, I would choose 3. --abián 20:37, 28 August 2016 (UTC)
  • Average monthly temperatures are way more informative than plain yearly average. Whether we create a specific property for this or not, we should think about how bring here monthly averages too, creating a coherent model including the later ones too.
1) Having a specific property for yearly averages and using generic temperature (P2076) 'qualified' with determination method (P459) for the monthly ones would be pretty awkward.
2) Having "average yearly temperature" and "average monthly temperature" using somehow the month as qualifier would make a little more sense. I don't know.
3) Having "average yearly temperature", "average january temperature", and "average february temperature" and... -> no.
Regardless all that, qualifiers as start time (P580) or end time (P582) should be added too. Strakhov (talk) 20:09, 28 August 2016 (UTC)
Option 2 makes much sense. :-) --abián 20:49, 28 August 2016 (UTC)
month of the year (P2922) would work as the qualifier in this scenario. Thryduulf (talk) 22:11, 28 August 2016 (UTC)
We'd need "average maximum temp." and "average minimum temp." too. Recently we approved precipitation height (P3036), but it seems pretty weird, as it represents a point in time, not an average. How about "average montly precipitation height" and "average yearly precipitation height"? Seriously, I think we need to apply here a more holistic view, not proposing one by one. Strakhov (talk) 17:09, 30 August 2016 (UTC)
  • Pictogram voting comment.svg Comment would it be possible to consider instead a property that provides a database of temperatures for the location so that whatever monthly or yearly averages are wanted can be computed from it? It might have to be a URL to a dataset...? ArthurPSmith (talk) 19:19, 30 August 2016 (UTC)
    The average yearly temperatures in a certain decade are fixed values, they won't change. However, external links will probably do, sooner or later. And, as only linking an external database wouldn't be enough to retrieve data from the Wikimedia projects, I think that it's better to directly save these data in Wikidata. --abián 09:16, 2 September 2016 (UTC)
  • Well, sometimes old values do change thanks to reanalyses - or at least in certain datasets they wouldn't be perfectly fixed. In any case, what I think would be best here would be to be able to store the full dataset, say as a CSV file, in Wikimedia Commons. However, Commons doesn't allow CSV or other dataset files at the moment. If we store monthly averages directly in wikidata, then you have 12 statements per year - for some locations there are 150 years or so of data (perhaps more in England?) so you could have 1800 temperature statements on a location item in wikidata under this approach. That doesn't seem like a good idea to me. ArthurPSmith (talk) 15:41, 21 September 2016 (UTC)
  • Per Phabricator:T120452, tabular data storage is coming to Commons at some point. I'm not familiar with what the current state of work on it is. Thryduulf (talk) 20:11, 21 September 2016 (UTC)
  • They wouldn't be 1800 temperature statements in any case. These values are average ones, usually, in a 30-years period, not in a year. --abián 18:11, 22 September 2016 (UTC)

If I'm not wrong, these are the possible Wikidata properties concerning average temperatures and their dependencies.

Deriving average temperatures.svg

These dependencies can be applied, mutatis mutandis, to any kind of average climate data (average rainfall, average relative humidity, average number of frosty days, etc.).

Having read all comments, having done some research, and knowing that these data:

  • have an absolutely different availability depending on the relevance of the place, on the country and on the antiquity;
  • should always be used with qualifiers start time (P580) and end time (P582);
  • should always have a direct reference;
  • are historical and should never change since they are added to Wikidata;

... I propose that we exceptionally assume some degree of duplication with them and that we allow to store multiple declarations using these properties even for the cases that some of them could be derived from others.

For the case of monthly data, declarations should also necessarily have the qualifier month of the year (P2922).

In conclusion, concerning this property, "average yearly temperature", I still think that creating it would be a good idea. --abián 12:25, 2 September 2016 (UTC)

  • Given that it makes sense to fill for almost any place with a location, I think having a specific property for it is warranted. Symbol support vote.svg Support ChristianKl (talk) 18:20, 25 September 2016 (UTC)
  • Pictogram voting comment.svg Comment I think it would be good to have the monthly series of min/max/avg, but I don't think current quantity type and GUI is quite ready for this.
    --- Jura 23:53, 29 September 2016 (UTC)
  • Pictogram voting comment.svg Comment Please see Phabricator:T147049.
    --- Jura 09:03, 30 September 2016 (UTC)
    • +1 Climate data is needed on Wikidata. The RedBurn (ϕ) 11:53, 15 February 2017 (UTC)
  • @Abián, Thryduulf, ChristianKl, Jura1: Commons now has tabular data; I strongly suggest that instead of this proposal we propose a "temperature dataset" property with datatype "Commons media" to allow for whatever temperature data is available to be linked to a location. ArthurPSmith (talk) 16:15, 10 January 2017 (UTC)
    • Pictogram voting comment.svg Comment Obviously, this is only marginally related to average yearly temperature, but I don't quite see the difference between gifs at Commons and Commons datasets. Neither allow us currently to do comparisons with other locations. Given that quantity datatype has gotten more efficient in terms of resources, we might try a single property for temperatures.
      --- Jura 16:42, 10 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose use tabular data on Commons. Average yearly temperature is only single quantity out of many relevant ones for climate data. Average/min/max yearly/monthly/daily temperature/precipitation are others. We should find a solution which works for all these quantities. Here it should become clear that Wikidata is not the right place for it. Climate data are tabular data and the developers decided to store tabular data on Commons and not on Wikidata, so let's use Commons. A demo is already online: en:User:Yurik/WeatherDemo using the data stored on commons:Data:Ncei.noaa.gov/weather/New York City.tab. --Pasleim (talk) 16:54, 11 January 2017 (UTC)
Pictogram voting comment.svg Comment How many dimensions data should have when we call it "tabular"? Geographic dimension represented using items.
Census data have 3 dimensions right now: location, point in time, sex.
It is possible to get 50+ dimensions from census information, we need only selection of dimensions on Wikidata, not complete 1-to-1 dumps.
Pictogram voting comment.svg Comment If we use .csv / .tabs on commons, then I would like to have a property about "tabular data available on commons"; and with qualifier about topic ("Climate data"). d1g (talk) 03:19, 14 January 2017 (UTC)
That is far too generic. It would be like having a property called "string" that we use for all strings. - Nikki (talk) 18:19, 31 January 2017 (UTC)
  • Pictogram voting comment.svg Comment this is my first time at the property proposals page, so I'm going to keep things to a comment for now. I was just editing Q21726404, and I was looking for a property for annual temperature. There are tons of bot-generated pages on the Swedish Wikipedia, for example the bot generated page for the item I just mentioned. The bot found structured data to make that page, so I feel that Wikidata could have a viable property for this. Icebob99 (talk) 14:53, 16 February 2017 (UTC)


collecting area[edit]

   Under discussion
Description The collecting area of a telescope (or any other instrument that has an area that is used to gather something)
Data type Quantity
Template parameter Area in en:Template:Infobox telescope
Domain Telescopes, but also any other instrument with a collecting area
Allowed units The same as area (P2046)
Example Hale telescope (Q2471197) → 31,000 square inch
Motivation

So far the area (P2046) parameter has been used to represent the collecting area of a telescope on enwp through en:Template:Infobox telescope. However, @Alphos has pointed out that this is not what that property is intended for - it should be used to describe the area of the telescope overall, not just the collecting area. Hence this proposal for a new property that is more specific. The existing data for areas of telescopes needs to be migrated to this new property if it is created. (Note that there is also the complication of antenna effective area (Q571946), which depends both on frequency and surface accuracy, but that's probably a problem for the future.) Thanks. Mike Peel (talk) 22:53, 20 April 2017 (UTC)

Discussion
  • Obviously full support. We can't have an area of a piece (however major) of item share a property with the area of the item itself. Alphos (talk) 23:03, 20 April 2017 (UTC)
    • I'm not sure why not? We do that frequently for other properties, for example demographic subdivisions. However, if your meaning is that "collecting area" is an area in a different sense or meaning from "geographic area" then perhaps a new property is warranted. ArthurPSmith (talk) 13:48, 24 April 2017 (UTC)
  • can't we attach the qualifier applies to part (P518) for this? ArthurPSmith (talk) 17:19, 21 April 2017 (UTC)
  • Symbol support vote.svg Support. Thryduulf (talk) 16:24, 22 April 2017 (UTC)
  • @Mike Peel: Have you checked how the same property gets modelled in other ontologies? Is there relevant prior art? ChristianKl (talk) 10:20, 24 May 2017 (UTC)
    • @ChristianKl: As far as I'm aware there is *no* prior art here - there are no other databases of telescopes that we can compare to here. Thanks. Mike Peel (talk) 00:07, 15 June 2017 (UTC)
  • Symbol oppose vote.svg Oppose use area (P2046) with qualifier applies to part (P518). Qualifiers were exactly introduced for such cases. --Pasleim (talk) 07:21, 2 June 2017 (UTC)

Biology[edit]

Please visit Wikidata:WikiProject Taxonomy for more information. To notify participants use {{Ping project|Taxonomy}}
Please visit Wikidata:WikiProject Biology for more information.

only valid for subset[edit]

   Under discussion
Description This should only be used as a qualifier. It denotes that the statement isn't true for all instances but only for a subset.
Data type Item
Example Rectus abdominis muscle (Q275150) innervated by (P3189) Sixth intercostal nerve (Q27058097) → this property → Unknown value
See also applies to part (P518), valid in period (P1264), valid in place (P3005)
Motivation

I take information about innervation from Anatomy and Human Movement Structure and Function SIXTH EDITION (Q27050364). It tells me that in sometimes Rectus abdominis muscle (Q275150) is innervated by Sixth intercostal nerve (Q27058097) while in other cases it isn't.

I want this property to be able to enter this kind of knowledge in Wikidata. I'm personally unsure whether this is the best way to model this domain. If someone has other suggestions I'm happy. ChristianKl (talk) 14:03, 24 January 2017 (UTC)

Discussion
  • Maybe use applies to part (P518)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 24 January 2017 (UTC)
    • No, I'm pretty sure that's a different meaning than ChristianKl intends, but maybe also indicates the name is confusing. I think the meaning wanted here is effectively the difference between "sometimes" and "always". How to model that in wikidata? ArthurPSmith (talk) 18:27, 24 January 2017 (UTC)
      • I also think that applies to part (P518) has a slightly different meaning. I think it's worthwhile to have properties that can make precise statements about issues like this and it's not good to overload applies to part (P518) with slightly different meanings. A human might understand what's meant when he reads the data but an automated system might not. ChristianKl (talk) 09:56, 25 January 2017 (UTC)
  • Well, you need an item for the subset anyway ? So, why not just put the statement in that item and left what is valid in every case in the upper one ? author  TomT0m / talk page 21:49, 25 January 2017 (UTC)
It might be that we have a source that says that this is true for 50% of the population. This information could be filled in. ChristianKl (talk) 09:09, 27 January 2017 (UTC)
How do you express "50% of the population" ? The set is not identified. Isn't this the notion of incidence (Q217690) View with Reasonator View with SQID or something similar you're looking for ? Or you're looking for something similar to disjoint union of (P2738) View with SQID or subclass of (P279) qualified with a numerical value representing this ? author  TomT0m / talk page 11:30, 27 January 2017 (UTC)
@TomT0m:I think it's worth having a specific property for this to allow for automated interaction with the data. If you think there's a specific way this data can already be presented I invite you to edit the example of Rectus abdominis muscle (Q275150) accordingly. ChristianKl (talk) 07:44, 2 February 2017 (UTC)
@TomT0m, ChristianKl: You can use proportion (P1107) to express this. --Swpb (talk) 17:19, 15 February 2017 (UTC)
@Swpb: If you think this property can be used here, could you edit the linked example accordingly? ChristianKl (talk) 17:52, 15 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I added a few "see also" above.
    --- Jura 11:47, 26 March 2017 (UTC)

haplogroup[edit]

   Under discussion
Description mtDNA or Y-DNA haplogroup of somebody. This is very sensitive information, only used with a reliable source.
Represents Haplogroup (Q80686)
Data type Item
Domain people
Example Benjamin Franklin (Q34969)Haplogroup V (Q1458022)
Source en:List of haplogroups of historic people
Robot and gadget jobs No
Motivation

(Add your motivation for this property here.) GZWDer (talk) 18:39, 16 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support Dhx1 (talk) 15:15, 8 February 2017 (UTC)
  • Symbol support vote.svg Support Once the information is there.--Arbnos (talk) 16:23, 20 February 2017 (UTC)


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
Pictogram voting comment.svg Notified participants of WikiProject Medicine Does this property look reasonable? ChristianKl (talk) 09:51, 3 March 2017 (UTC)

  • GA candidate.svg Initial support If we are going to implement this, we need 2 properties, "mtDNA haplogroup" and "Y-DNA haplogroup". Because these 2 concepts are about 2 different parts of genomes (mtDNA and Y-DNA), nothing related to each other and mutually independent. So one property is not enough. If splitted, I support. --Was a bee (talk) 13:22, 3 March 2017 (UTC)
  • Pictogram voting question.svg Question I am not sure. Can someone comment on whether Was a be is correct in saying that it is standard to list both of these and that the property only makes sense when both values are given? Can anyone show an example source which classifies people in this way? The source given is an English Wikipedia article. Can someone point to a place in that article where the information is presented as it should be and everything is correct? Here is the Benjamin Franklin section and here is the source backing it. Is this the kind of data presentation which is ideal, and is this the kind of sources which we will use? I am sure that if this goes live I do not want the sources to be "English Wikipedia", and instead this information should go to the original source. Blue Rasberry (talk) 15:41, 3 March 2017 (UTC)

Baltimore classification[edit]

   Under discussion
Description Virus standard classification system
Represents Baltimore classification (Q782725)
Data type Item
Template parameter |virus_group= in ca:Plantilla:Infotaula d'ésser viu
Domain virus
Allowed values dsDNA Virus (Q2901600), ssDNA viruses (Q9094469), Double-stranded RNA viruses (Q3307900), Positive-sense single-stranded RNA virus (Q9094478), Negative-sense single strand RNA virus (Q9285327), single-stranded positive-sense RNA virus (Q9094482) and DsDNA-RT virus (Q3754200)
Example Hepatitis C virus (Q708693)Positive-sense single-stranded RNA virus (Q9094478)
Source en:Baltimore classification
Planned use Add property to all virus in catalan wikipedia
See also ICTV virus ID (P1076)
Motivation

It would be very useful for virus taxoboxes. Paucabot (talk) 17:41, 27 March 2017 (UTC)

Discussion

Andrew Su
Boghog
Emw
Dan Bolser
Daniel Mietchen
Gtsulab
Andra Waagmeester
Sebotic
Elvira Mitraka
Konrad U. Förstner (talk)
Kristina Hettne
Hardwigg
i9606
Putmantime
Jasper Koehorst
Comamonas
Muhammad Elhossary
Pictogram voting comment.svg Notified participants of WikiProject Microbiology Abbe98
Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
Faendalimas
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Michael Goodyear
MPF
PhiLiP
Andy Mabbett (talk)
Prot D
pvmoutside
Rod Page
Soulkeeper (talk)
Tinm
Tommy Kronkvist (talk)
TomT0m
Pictogram voting comment.svg Notified participants of WikiProject Taxonomy

  • Can you make the description a bit more extensive? ChristianKl (talk) 11:49, 29 March 2017 (UTC)
@ChristianKl: What exactly do you need to know? Paucabot (talk) 19:01, 29 March 2017 (UTC)
@Paucabot: What's special about this virus classification scheme. How does it differ from others? I think it's possible to find a more informative 1 or 2 sentence description than "Virus standard classification system". ChristianKl (talk) 20:47, 29 March 2017 (UTC)
I'm sorry. It's my first property proposal. This virus classification scheme is one of the two most used to classify virus as you can read in en:Virus classification. The other one, has already its property: ICTV virus ID (P1076). Paucabot (talk) 05:51, 30 March 2017 (UTC)
Symbol support vote.svg Support It's the main classification criteria for viruses. It should be as a property. thnks,--Amadalvarez (talk) 10:39, 13 April 2017 (UTC)
  • Symbol support vote.svg Support, a necessary property. --Yeza (talk) 06:55, 19 April 2017 (UTC)

I dont't think this property should be termed "Baltimore classification" because the the classification is outdated and distinguishes between seven groups termed Group I ... Group VII. I think the main intentions of this proposal is to denote the genome composition. That is listed in the newer ICTV Taxonomy. The values of the property are similar to the above listed (taken from ICTV Master Species List 2016 v1 (Q29000566)):

--Succu (talk) 15:18, 19 April 2017 (UTC)

@Succu: I didn't know it was outdated. It is not noted in en:Baltimore classification nor in en:Virus classification. So, in your opinion, ICTV virus ID (P1076) does the job? Paucabot (talk) 18:31, 19 April 2017 (UTC)
No, Paucabot: ICTV virus ID (P1076) was intended to provide the external IDs of www.ictvdb.org, a database down now for some years. For details please see this discussion (in German). But I think the information you want to provide is essential. According to ICTV the genome composition is defined as „The nature (molecular and genetic composition) of the virus genome packaged into the virion”. I see two options: Rename the current proposal and notify all participating users - or - withdraw this proposal, make a new one and notify all participating users. --Succu (talk) 20:24, 19 April 2017 (UTC)
@Succu: I see. I agree with renaming. What is the name you propose? Could you help me doing it? Paucabot (talk) 20:28, 19 April 2017 (UTC)
Sure, maybe Viral genome composition is a good name for that property. The values are listed above. Most of the item mappings you'll found in your proposal. --Succu (talk) 20:43, 19 April 2017 (UTC)
@Succu: What about viral genome group, viral genome classification? Paucabot (talk) 05:16, 20 April 2017 (UTC)
Do I have to create the non-existing items? Paucabot (talk) 05:41, 20 April 2017 (UTC)
I don't know if your proposals are better suited. I'm not a specialist for this domain. I would postpone the creation of the missing items until we have to use them (e.g. one of constraint).
@Succu: Do you know someone that could enlighten us? Paucabot (talk) 05:43, 21 April 2017 (UTC)
@Paucabot, Amadalvarez, Succu, ChristianKl: Hi, I think the new property should be nucleic acid (Q123619). The Baltimore classification is correct, but it is based —and is what makes the difference among all values— on the characteristic nucleic acid of every virus. If you search for a table in a virology book, you will find that the column title is Nucleic acid. --Xavier Dengra (talk) 18:58, 22 April 2017 (UTC)
Xavier Dengra, the term used by International Committee on Taxonomy of Viruses (Q580606) is genome composition which is clearly different from your proposal --Succu (talk) 21:45, 22 April 2017 (UTC)

ICZN code properties[edit]

   Not done
Data type String
Domain taxon
Example tbd
Source ICZN compliant database, scientific articles
Planned use tbd
See also scientific name search
Motivation

There is a recurring debate on the naming of taxons on Wikipedia. Some very active people on the taxonomy project, naming Brya and Succu are engaged into a strong commitment to reflect datas about taxons following the ICZN code, which is fine. The problem is that they have a strong commitment and a tendency to reject any other stuff that can be found outside in literature as a mistake and something that should not be found in Wikidata. The opinion of the proposer of this is that it's not out job to qualify scientist work as mistake if they do not follow the ICZN rule and that it's perfectly fine to import those datas as long as they are published. The compromise that is the goal of the proposal is to make clear which datas are correct according to ICZN by making clear which properties are supposed to stricty follows the code and to let the "scientific name" be more relaxed and be able to reflect the actual datas, even if they could be considered a mistake for someone. It's a clarification and a possibility for everyone to work the way he wants and using the code he wants, to respect the possibility to cross different datas according to Wikidata - in line with Wikidata beeing a database that store tons of identifiers in all kind of fields.

This proposal is a starting point and I'll let the experts discuss the best way to model the genus and so on according to ICZN, for example use a qualifier in a statement like "ICZN genus" of a property "ICZN name", or use an item for genuses. I hope we'll end up in a result that satisfies everyone.

author  TomT0m / talk page 10:49, 28 January 2017 (UTC)

Discussion

Comment - As I pointed out on the other page. Wikdata and Wikispecies are not publications for the purposes of nomenclature as defined by the code. Therefore they cannot make nomenclatural decisions on the availability of names. To do so requires a valid nomenclatural act. All Wikidata and Wikispecies can do is follow current usage unless a valid nomenclatural act can be cited. If that current usage is confusing or even in error, a note of this can be made but current usage must be followed in the end. I agree that for taxonomic names Wikimedia should follow the various nomenclatural codes, however they must follow them completely, which includes realizing what you can and cannot do on a web publication that does not meet the requirements of the code for making nomenclatural decisions. Cheers Scott Thomson (Faendalimas) talk 11:22, 28 January 2017 (UTC)

@Faendalimas: Sorry, I don't get your point. How is this related to this proposal ? author  TomT0m / talk page 11:35, 28 January 2017 (UTC)
I am making a comment on the motivations for the proposal. You mention the wish by some to follow the code explicitly and to the exclusion of other information that may or may not agree with the code. My point is that due to its publication model Wikiedia cannot make this distinction and must include current usage for a taxon. Even if it is technically wrong. We cannot reject names that are wrong if they are in current usage. We cannot change the nomenclature of any organism to bring its nomenclature in line with the code. Cheers Scott Thomson (Faendalimas) talk 12:04, 28 January 2017 (UTC)
@Faendalimas: It seems we agree on this. My point with this proposal is to use this property only when the name is (very probably) in line with UICN rules to avoid ambiguities, not to avoid the use of other names which is indeed impossible. The idea is to retain the other used names in the existing taxon name properties. Does it seems to be a good idea ? author  TomT0m / talk page 12:25, 28 January 2017 (UTC)
A point in general: this issue does not come up exclusively with the zoological Code, the ICZN. It happens also for the Code for algae, fungi and plants, the ICNafp and for the prokaryote Code, the ICNP. These have differing definitions for homonyms and the like, but, if we don't look too closely, these are compatible.
        The problem in general is that under these three Codes there are a lot of names (formal entities) that may not be used for a taxon, no matter what taxonomic position is adopted. Wikidata has items on some of these 'inoperable' names: 1) some of these names serve a functional purpose, 2) some of these names come from careless imports, and 3) some of these names are to some degree in use.
        This is separate from the issue that, depending on taxonomic tank, circumscription and position there may be many names which can be applied to a taxon. - Brya (talk) 12:56, 28 January 2017 (UTC)
@TomT0m: I am fine with it. We just need to have a clear understanding on its usage, and in particular what we can and cannot do with respect to the code. As @Brya: points out there are multiple codes also and they have different definitions, they are independent of each other. We must at all costs refrain from being the source of a confusing nomenclature, most people who use these names have no understanding of how they are formed and governed. They do not need to. They will go to whatever source they can to get a name, including Wikimedia projects. If it is not the one in usage it can cause major issues and confusion. Cheers Scott Thomson (Faendalimas) talk 13:27, 28 January 2017 (UTC)
@Faendalimas, Brya: Then I guess we should add specific properties for the different nomenclature codes, and somehow make them "subproperties" of scientific names search. People who just don't know can then use "scientific name" and expert would refine and validate (or not) by creating a (hopefully sourced) statement with the specific property. In SPARQL it's then possible to retrieve statements and their value for scientific names by a query as simple as
select ?nameprop ?name where {
  ?nameprop wdt:P1647* wd:P225 .
  ?nameprop wikibase:directClaim ?namepropdirect .
  ?item ?namepropdirect ?name . 
} limit 100

Try it!, even excluding those who are using P225 and not a property associated with a code by changing the "*" in the query by a "+". author  TomT0m / talk page 14:37, 28 January 2017 (UTC)

@TomT0m: the information on the different Codes has long since been included, and is called up by every use of the Taxobox module. I just wanted to point out that it is not a matter of the ICZN only.
@Scott Thomson: in general terms I can agree with "We must at all costs refrain from being the source of a confusing nomenclature, most people who use these names have no understanding of how they are formed and governed." and "If it is not the one in usage it can cause major issues and confusion." However, for many taxa there are several names in use (in varying degrees). The one thing Wikidata must not be is a Checklist, a source for "right names". - Brya (talk) 16:09, 28 January 2017 (UTC)
@Brya: absolutely, we must never look like a checklist. We do not have that intent and must always appear as reviewers of the data, not creators of it. Yes there are taxa with variable names, this is unfortunate and is often these days as much ego based as being genuine mistakes. The codes are not perfect, all we can do is report what we find as best as possible. Following the code as a guideline, but realizing we are in no position to act on it is our best path. Cheers Scott Thomson (Faendalimas) talk 00:24, 29 January 2017 (UTC)

TomT0m, so you want to downgrade taxon name (P225) to a name string („A literal string of characters representing a taxon name. These may include authorships, rank indicators and other qualifiers, and concept qualifiers [...]“) as Richard L. Pyle (Q21340682) put it? --Succu (talk) 19:41, 28 January 2017 (UTC)

I want nothing. I don't really care if this is a string or something else coded with qualifiers and items, actually. author  TomT0m / talk page
To be blunt TomT0m, then shut up. --Succu (talk) 20:43, 28 January 2017 (UTC)
I would, if there were not so many stuff that felt wrong in the area of Wikidata. Including the way you answer. Don't excuse yourself to be blunt, it's your usual behavior. author  TomT0m / talk page 09:55, 29 January 2017 (UTC)
I have said it before, so I will repeat it here: I do feel we need a new property, for scientific names that cannot be used as the correct name of a taxon. But there does not seem to be much support for it. - Brya (talk) 17:42, 29 January 2017 (UTC)
I am not disagreeing with anyone here. But I am extending the issue a bit. What people often do not get is that names are really mononomial not binomial. We present them binomially and they can only be presented that way, ie Genus species. But that binomial is made up, in this case, of a genus and a species. These two names have their own references, their own synonymies. When I move a species from one genus to another I am not changing its name per se, I am changing its combination. However the names are still their own entities. So the question to ask of the database, are you going to list valid and invalid names; available and unavailable names. The valid names in the currently accepted combination is the correct binomen for a species. So how do you display these different names. How do we search for them. How does anyone know at a glance, and with no knowledge of the Code know what type of name it is. @Brya says that he sees no reason for a new property, fine I can support that. But does the current system clearly indicate the differences between the names and I would suggest highlighting the valid combination over others in some way. Is the current method effective, clear and does not have issues of confusion. If it is no problem then I agree with Brya. If it does maybe some alterations are needed. So the question needed to be answered is can we list scientific names in a way that is clear on the type of name it is under the code. Cheers Scott Thomson (Faendalimas) talk 21:19, 30 January 2017 (UTC)
Under the ICNafp (algae, fungi, and plants) and ICNP (prokaryotes) it is crystal clear that the combination is the name (Lycopersicon lycopersicum is a scientific name and Solanum lycopersicum is a scientific name). The zoological Code is a little ambiguous (some internal contradictions?), but most provisions also state that the binomen is the scientific name, for example Article 5. Anyway, unless we are going to have separate properties for names, divided per Code, we have to treat all combinations as scientific names, anyway.
        What I said on new properties, is that I do feel we need a new property, for scientific names that cannot be used as the correct name of a taxon. Under every nomenclatural Code there is a hefty percentage of names that are part of the nomenclatural universe, but that when it comes to names for taxa are deadwood. Lots of people go into databases, copy these 'dead' names and promote them to names of taxa: a "miraculous duplication of taxa". We should mark them clearly. - Brya (talk) 05:27, 31 January 2017 (UTC)
@Faendalimas: Interesting point about "monomonial" names. What I hear is that we could totally reconstruct the binomial name from a monomonial one by following the ranking statements up to the genus. So you would support a monomonial name for genus items and monomonial names for species one ? Maybe indeed that would simplify stuffs. author  TomT0m / talk page 07:25, 31 January 2017 (UTC)
Apologies @Brya, I read that the wrong way, but my argument is the same in that if it is not clear we need a new property, if it is we do not. @TomT0m, sort of. you could in theory set it up with mononomials down to subgenus, but for species you need the binomen. Reason for this is a species name you can only figure out where it belongs by its inclusion with its genus. Species names on their own do not have to be unique, ie names such as marginata can apply to dozens of species, but all in different genera. You could do this by listing the species in original combination, then linking it to its current genus and form the current binomen from that. Your last caveat would be the principal of coordination where original spelling may not be the same as current spelling due to gender conflict between names. I think that could get a little complicated. So what you need is to be able to identify which names are valid and to be used, and which are not with the option I guess of why. @Brya I was not stating any different about scientific names, I was referring to what a binomen is all these names whether they can be used or not are scientific names. I was referring largely to binomens which are the species group scientific names. I use the ICZN code as an example because I work with it all the time however the arguments can be applied to any code, just the terminology changes. Cheers Scott Thomson (Faendalimas) talk 11:06, 31 January 2017 (UTC)
@TomT0m: theoretically this is possible (there are databases that work this way, although these are much more limited in scope), but the second part of a binomen/binomial is not unique and not invariant.
@Scott Thomson: unlike Commons and Wikispecies, we do not aim to provide "right" names. We do store references and links to databases. By checking links to databases, it is possible to generate a list of taxa that are recognized by, say, NCBI. Once we have included lots of references, it should become possible, long term, to check these and to be more accurate: we can then create lists based on the literature.
        In the meantime we have names:
  1. that are in use by somebody
  2. that are not in use (although they could be used, if taxonomic insight changes), but that are here for some structural reason
  3. that may never be used, no matter what taxonomic viewpoint is adopted. A lot of these were imported by "enthousiastic" users (but a few of these serve some structural purpose).
Brya (talk) 11:58, 31 January 2017 (UTC)
@Brya: Unicity is not a problem at all, we can easily build a constraint that checks if the computed binomial is unique. Would be more intensive in computing time but nothing unsolvable. By invariant, it's no problem in Wikidata thanks to claim ranking. author  TomT0m / talk page 14:35, 31 January 2017 (UTC)
Well, extra computer time seems like a bad thing to me. FWIW, binomials need not be unique, but a binomial need not be computed, as it is not possible to store the two parts apart. I do not see how claim ranking can help with the invariance. - Brya (talk) 17:48, 31 January 2017 (UTC)
@Brya: Extra computer time is not a big problem compared to maintenance problem, Machines are made to automate things and if it can spare human volunteer work, it's what they are made for. To enter into the equation the computing time has to be extra large, which I don't seem is the case here, it will scale almost linearly with the number of taxons.
  • Apart from that, I'm confused. Need not or cannot ?
  • "I do not see how claim ranking can help with the invariance" => we can store several values and put the most recent one with the preferred rank. We can put the invaled one with the deprecated rank. It's a common problem in Wikidata, nothing specific to taxonomy.
  • It is pointless to compute a result, if one already has that result
  • Yes, but if all these values are stored, there is no longer any conceivable advantage over the current model.
Brya (talk) 18:02, 1 February 2017 (UTC)
  • It's more robust to change of classifications. If a species change its genus, you just have to change the statement and deprecate the old one, no need to change the label in every language.
  • It's in line with usual Wikidata modelling. No need to create something specific when the generic is enough, it avoids learning the specifics everywhere.
  • "If a species change its genus, you just have to change the statement and deprecate the old one, no need to change the label in every language." Nope, as it is not invariant. "It's more robust to change of classifications." Any method, if done properly will be robust. If not done properly, it will not be robust.
  • The generic is not enough.
Brya (talk) 19:00, 1 February 2017 (UTC)

TomT0m, I think it would be helpful to withdraw this proposal and to copy the discussion to another location. --Succu (talk) 18:52, 31 January 2017 (UTC)

I would second @Succu's comment here, I initially supported the concept but the ensuing comments have brought up complexities. In saying that I would like it to move forward. Whether in the end it is deemed necessary or unnecessary is not the point, I think some resolution on this issue is needed and if deemed warranted after some discussion that includes discussion of how to deal with many of the spelling, recombination and other similar issues that scientific names have. Cheers Scott Thomson (Faendalimas) talk 19:26, 31 January 2017 (UTC)
@Succu: It's a good place to discuss, and the discussion don't seem to be over. author  TomT0m / talk page 14:05, 1 February 2017 (UTC)
This is not a RfC, TomT0m, and I can't see a real property proposal. --Succu (talk) 21:56, 1 February 2017 (UTC)
OK, if this helps to close this "proposal": Symbol oppose vote.svg Oppose --Succu (talk) 19:52, 3 February 2017 (UTC)

PfaF ID[edit]

   Under discussion
Description identifier of a plant taxon, in the Plants For A Future database of uses of plants and their parts
Data type External identifier
Domain plant taxa (taxon (Q16521))
Allowed values [^\s\/]+
Example Castanea sativa (Q22699)Castanea+sativa
Source Plants for a Future (Q246234)
Formatter URL http://www.pfaf.org/user/plant.aspx?LatinName=$1

PFAF ("Plants For A Future") is a database of uses (incl edible and medical) of plants and their parts d1g (talk) 17:56, 15 March 2017 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 19 March 2017 (UTC)
  • Symbol support vote.svg Support. This looks like a useful property for describing plant uses in Wikidata.
  • Are all entries plants? If so the domain can be more narrow and the name can be "PFaF plant ID". ChristianKl (talk) 08:49, 24 March 2017 (UTC)
    I renamed to "PFaF plant ID". ChristianKl (talk) 12:47, 22 May 2017 (UTC)
  • The datatype should be changed to URL, because this one is not an ID. E.g. Castanea_sativa gives the same result as Castanea+sativa. --Succu (talk) 17:54, 23 May 2017 (UTC)
  • This seems OK. I am not too worried about the datatype. - Brya (talk) 04:23, 25 May 2017 (UTC)

uBio Namebank ID[edit]

   Under discussion
Description The uBio Taxonomic Name Server (TNS) catalogs biological names and classifications to help users find information on organisms using any of the names associated with the organizsm.
Data type External identifier
Template parameter "ubio" or "namebank" in en:Template:Taxonbar
Domain taxon (Q16521)
Allowed values distinct values constraint (Q21502410), ([1-9]\d{0,8}|)
Example Sequoiadendron (Q14707792)2663795
Formatter URL http://ubio.org/browser/details.php?namebankID=$1
Motivation

This database is supported by en:Template:Taxonbar, but it must be manually added to the template call. Adding this Wikidata property would allow this identifier to be centralized and links to this database to be automatically included in the Taxonbar. Ahecht (talk) 16:46, 23 May 2017 (UTC)

Discussion
Ahecht, please add a motivation for your proposal. --Succu (talk) 17:33, 23 May 2017 (UTC)
✓ Done --Ahecht (talk) 21:59, 23 May 2017 (UTC)
  • I suppose we can't avoid this, but I am quite uncomfortable: this is yet one more aggregator. Like all aggregators, it has its idiosynchrasies: it claims that ITIS uses "Sequoiadendron giganteum (Lindl.) Buchh." while in reality ITIS uses "Sequoiadendron giganteum (Lindl.) J. Buchholz". If I try to find the preferred form "Sequoiadendron giganteum (Lindl.) J.Buchholz" it reports "No Results for Sequoiadendron giganteum Lindl JBuchholz" (similar for "Sequoiadendron J.Buchholz"). It adds yet another structure, again at the cost of the offered content. Also, it sneaks in the infamous CoL. - Brya (talk) 03:58, 24 May 2017 (UTC)
    • Checking the somewhat notorious Paralophia, I find "Paralophia P.J. Cribb & J. Hermans" placed in beetles (supposedly according to CoL 2007) and in Lepidoptera (supposedly according to Lepindex)! It can also be found placed correctly, attributed to CoL 2008, but this seems to indicate that it uses only the 2007 and 2008 versions of CoL?- Brya (talk) 04:25, 24 May 2017 (UTC)
  • A taxon name can have multiple namebank IDs. E.g. bluefish (Q461432) has 167265, 267819, 267820, 2527517, 2576202, ... I don't think this is a useful mapping. Furthermore it looks like that the data are not updated anymore (see News). The WebServices is not working. So I would Symbol oppose vote.svg Oppose. --Succu (talk) 14:15, 24 May 2017 (UTC)
    • Web services are working. To conclude that the data are not being updated because a single "news" page is not is bogus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:42, 30 May 2017 (UTC)
  • Symbol support vote.svg Support. Used in Wikipedia. Also, our job here is to record such identifiers, not quibble about the content or quantity of the pages thay identify. 09:35, 30 May 2017 (UTC)Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

Titan ID[edit]

   Done. Titan ID (P4125) (Talk and documentation)
Description identifier for a taxon (Cerambycidae) in the Titan database
Data type External identifier
Domain taxon (Q16521)
Allowed values \d+
Example Abyarachryson signaticolle (Q14847243)3493
Source http://titan.gbif.fr/
Formatter URL http://titan.gbif.fr/sel_genann1.php?numero=$1
Robot and gadget jobs bot if we can have a complete list with taxon name
Motivation

"This database contains more than 99% of valid described species and subspecies of World Cerambycidae". Tubezlob (🙋) 19:23, 25 May 2017 (UTC)

Discussion
  • I renamed it into "Titan taxon ID". ChristianKl (talk) 20:39, 25 May 2017 (UTC)

Abbe98
Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
Faendalimas
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Michael Goodyear
MPF
PhiLiP
Andy Mabbett (talk)
Prot D
pvmoutside
Rod Page
Soulkeeper (talk)
Tinm
Tommy Kronkvist (talk)
TomT0m
Pictogram voting comment.svg Notified participants of WikiProject Taxonomy. Tubezlob (🙋) 15:46, 27 May 2017 (UTC)

  • I have used this only infrequently, and cannot really judge how good this is, but I have no objection. - Brya (talk) 17:05, 27 May 2017 (UTC)
  • Symbol support vote.svg Support Useful. Lymantria (talk) 17:10, 27 May 2017 (UTC)
  • Symbol support vote.svg Support. I haven't used it much but to my knowledge the data is always correct, including the listed citations. While not always giving a complete set of information, it certainly is a useful tool nonetheless. –Tommy Kronkvist (talk), 13:55, 28 May 2017 (UTC).
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:25, 28 May 2017 (UTC)
  • @Brya: Do you have a reason why you think "taxon" shouldn't be in the name? ChristianKl (talk) 13:44, 3 June 2017 (UTC)
It is convenient to have property names that are as short as possible. - Brya (talk) 14:06, 3 June 2017 (UTC)

WFD Chemical status[edit]

   Under discussion
Description chemical status of a Water Body in accordance with the Water Framework directive of the European Environment Agency
Data type Item
Template parameter |kemisk_status= in w:sv:Template:Insjöfakta Sverige (although this filters out mercury (Q925))
Domain water body (Q30091952)
Allowed values instance of (P31)  WFD Chemical status category (Q30893493)
Example Orlången (Q3424558)WFD Chemical status: Good status (Q30899581)
Source pp.61-62 of WFD Reporting Guidance 2016 (swEcologicalStatusOrPotentialValue) and e.g. xml for all lakes in Finland (warning 13.1 MB)
Planned use This is part of the WFD to Wikidata project aimed at making use of the WFD reporting data in Wikidata. See also motivation.
Motivation

The structure of the data and the motivation for the property are very similar to those for Wikidata:Property proposal/WFD Ecological status. As with Ecological status this information (data from 2010) is already in use for lakes on sv.wp (see e.g. infobox in w:sv:Orlången) but new official data from 2016 is now available (for all EU countries). It is therefore an excellent opportunity to ensure Wikidata gets used now that this data has to be updated anyway.

If approved the data for 2016 would be imported for all Swedish lakes. More details can be found in Wikidata:Requests_for_permissions/Bot/AndreCostaWMSE-bot_3 /André Costa (WMSE) (talk) 14:49, 27 June 2017 (UTC)

Discussion
Any other information which I can add to clarify this further? /André Costa (WMSE) (talk) 09:47, 10 July 2017 (UTC)

Biochemistry and molecular biology[edit]

Please visit Wikidata:WikiProject Molecular biology for more information. To notify participants use {{Ping project|Molecular biology}}

PROSITE ID[edit]

   Under discussion
Description identifier for a protein family, domain or functional site, in the PROSITE database
Data type External identifier
Template parameter |PROSITE= in en:Template:Pfam box
Domain protein families, domains and functional sites
Allowed values PDOC\d{5}
Example Bromodomain (Q1829843)http://www.expasy.org/cgi-bin/prosite-search-ac?PDOC00550 PDOC00550]
Source Q899676, Wikipedia
Formatter URL http://www.expasy.org/cgi-bin/prosite-search-ac?$1
Robot and gadget jobs Yes
Motivation

(Add your motivation for this property here.) GZWDer (talk) 08:09, 17 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 17 January 2017 (UTC)
  • Symbol support vote.svg Support While I support this proposal, there are two issues. The first one is a conceptual problem in its current form. What is proposed here is to create a PROSITE documentation ID, not a PROSITE ID. PROSITE, which I created, has entries for the "methods" (pattern, profile, rule) to detect a family or domain, these have accessions of the type "PS[0-9][0-9][0-9][0-9][0-9]", one or more method entries are then linked to a documentation entry (PDOC). So maybe two properties need to be created or if the PDOC property is only one which will be used in Wikidata, the property name should be changed. The second problem is the proposed URL which is not adequate, the proposal uses the "search" URL while it should use the "entry" URL. For the example in the proposal it should be: http://prosite.expasy.org/PDOC00550 Amb sib (talk) 07:27, 25 January 2017 (UTC)
  • Symbol neutral vote.svg Neutral until the issues raised by Amb sib are resolved. -Emitraka (talk) 20:05, 16 February 2017 (UTC)
  • Symbol support vote.svg Support --Egon Willighagen (talk) 09:44, 14 April 2017 (UTC)

Structural Classification of Proteins ID[edit]

   Under discussion
Description ID for protein domains in SCOP database, and also Superfamily database
Represents Structural Classification of Proteins database (Q4832556)
Data type External identifier
Template parameter SCOP at en:Template:Pfam box
Domain protein domain
Allowed values (please clarify)
Example Bromodomain (Q1829843) → 1b91
Formatter URL http://scop.mrc-lmb.cam.ac.uk/scop/search.cgi?tlev=fa;&pdb=$1 or http://supfam.org/SUPERFAMILY/cgi-bin/search.cgi?search_field=$1
Robot and gadget jobs Yes
Motivation

(Add your motivation for this property here.) GZWDer (talk) 08:19, 17 January 2017 (UTC)

Discussion

I support this proposal, however several things need to be changed. The example "1b91" is a PDB ID for a particular protein with a bromodomain, not the SCOP ID for bromodomains. It looks like the SCOP for the bromodomain superfamily is a.29.2. The formatter URL should be changed to this. Furthermore, the superfamily database has a separate ID for bromodomain SSF47370, and so should be a separate property. What will be the source for these? I'd suggest the xrefs from interpro. Gstupp (talk) 19:55, 29 January 2017 (UTC)

Agreeing with the comment about the example. Can that be resolved please? --Egon Willighagen (talk) 09:45, 14 April 2017 (UTC)

recognition sequence / cutting site of restriction enzyme / isoschizomer / neoschizomer / isocaudomer[edit]

   Under discussion
Description DNA sequence recognized by a restriction enzyme, DNA binding domain, etc.
Represents Recognition sequence (Q7302658)
Data type String
Domain restriction enzyme (Q219715), DNA-binding domain (Q13479514), etc.
Allowed values /^(5'-[ACGTRMWSYKHBDVN]+-3'|3'-[ACGTRMWSYKHBDVN]+-5')$/
Example EcoRI (Q417754) → "5'-GAATTC-3'"
Source w:List_of_restriction_enzyme_cutting_sites
   Under discussion
Description DNA cutting site of restriction enzyme
Data type String
Domain restriction enzyme (Q219715)
Allowed values /^(5'-[ACGTRMWSYKHBDVN]*(↓[ACGTRMWSYKHBDVN]*↑|↑[ACGTRMWSYKHBDVN]+↓)[ACGTRMWSYKHBDVN]*-3')$/
Example EcoRI (Q417754) → "5'-G↓AATT↑C-3'"
Source w:List_of_restriction_enzyme_cutting_sites
   Under discussion
Description isoschizomers of the restriction restriction enzyme, which have the same recognition sequence and the cutting site.
Represents Isoschizomer (Q644180)
Data type Item
Domain restriction enzyme (Q219715)
Allowed values restriction enzyme (Q219715)
Example MspI→HpaII, HpaII→MspI (both enzymes recognize and cut "5'-C↓CGG-3'").
Source w:List_of_restriction_enzyme_cutting_sites
   Under discussion
Description neoschizomers of the restriction restriction enzyme, which have the same recognition sequence but a different cutting site.
Represents Neoschizomer (Q16945915)
Data type Item
Domain restriction enzyme (Q219715)
Allowed values restriction enzyme (Q219715)
Example SmaI (Q6130415) → XmaI, XmaI → SmaI (Q6130415) (both recognize "5'-CCCGGG-3'", but the cutting site of SmaI is "5'-CCC↓GGG-3'" and that of XmaI is "5'-C↓CCGGG-3'").
   Under discussion
Description isocaudomer of the restriction restriction enzyme, which have the different recognition sequence but produces the same termini
Represents Isocaudomer (Q17000139)
Data type Item
Domain restriction enzyme (Q219715)
Allowed values restriction enzyme (Q219715)
Example MboI → BamHI, BamHI → MboI (cutting site of MboI is "5'-N↓GATCN-3'" and that of BamHI is "5'-G↓GATCC-3'", so both enzymes produce the same cohesive end "GATC".)
Motivation

There are many restriction enzymes, which have specific recognition sequences and cutting sites (see w:List_of_restriction_enzyme_cutting_sites), and some enzymes have isoschizomers, neoschizomers or isocaudomer. To introduce these data into Wikidata, new properties are needed.

Expression method for DNA sequence and cutting site is open to some debate. --Okkn (talk) 02:02, 19 February 2017 (UTC)

Andrew Su
Marc Robinson-Rechavi
Pierre Lindenbaum
Michael Kuhn
Boghog
Emw
Chandres
Dan Bolser
Pradyumna
Chinmay
Timo Willemsen
Salvatore Loguercio
Tobias1984
Daniel Mietchen
Optimale
Mcnabber091
Ben Moore
Alex Bateman
Klortho
Hypothalamus
Vojtěch Dostál
Gtsulab
Andra Waagmeester
Sebotic
Mvolz
Toniher
Elvira Mitraka
David Bikard
Dan Lawson
Francesco Sirocco
Konrad U. Förstner (talk)
Chris Mungall (talk)
Kristina Hettne
Hardwigg
i9606
Putmantime
Tinm
Karima Rafes
Finn Årup Nielsen
Jasper Koehorst
Till Sauerwein
Crowegian
Nothingserious
Okkn
AlexanderPico
Amos Bairoch
Gstupp
DePiep
Was a bee
SarahKeating
Muhammad Elhossary
Pictogram voting comment.svg Notified participants of WikiProject Molecular biology

Discussion

Pictogram voting question.svg Question That looks good. Only question I have: How many know restriction enzymes are there right now, some 500? And what would be the data source for them? Sebotic (talk) 19:12, 27 February 2017 (UTC)

@Sebotic: Thank you for making a comment. I don't know how many known restriction enzymes there are, but w:List_of_restriction_enzyme_cutting_sites contains more than 1200 enzymes. First of all, I'll introduce data from this list. And the restriction enzyme database REBASE is available. --Okkn (talk) 01:31, 1 March 2017 (UTC)
  • @Okkn, Sebotic: insufficient support and no activity for over 3 months - so marked as  Not done - if anybody wants to revive this, the discussion here was minimal so this could be reopened. Or you could start a new proposal and link to this one. ArthurPSmith (talk) 18:36, 14 June 2017 (UTC)
  • GA candidate.svg Weak support while the discussion did stall, I see no opposition to the proposal. Before the properties get created it would however be useful to review prior art, so that we don't invent our own way of expressing those relationships. ChristianKl (talk) 10:24, 16 June 2017 (UTC)

Chemistry[edit]

Please visit Wikidata:WikiProject Chemistry for more information. To notify participants use {{Ping project|Chemistry}}


standard atomic weight[edit]

   Under discussion
Description Is a relative atomic mass (Q41377) of chemical elements for terrestial samples (sources), as defined (specified) by Commission on Isotopic Abundances and Atomic Weights (Q15647945) (CIAAW)
Represents standard atomic weight (Q28912964)
Data type Number (not available yet)
Domain chemical element (Q11344) (84 out of 118)
Allowed values (\d+.\d+\(\d+\)|\[\d+.\d+, \d+.\d+\])
Example
Format and edit filter validation see allowed values
Source CIAAW, technical report 2013
Planned use
  1. add to the chemical element items.
  2. check with current mass (taken from PubChem database)
Robot and gadget jobs Present PubChem retrieved values seem outdated, incorrect
See also proposal/conventional atomic weight
Motivation

Various quantity names and values are used for the atomic weight of chemical elements. Often is used the quantity 'relative atomic mass' (Ar), which is generic. Historically, the CIAAW (an IUPAC commission) has improved the measurements and methods, and publishes a more specific, well-defined value named 'standard atomic weight'. CIAAW only uses terrestial, natural sources/samples. Their published values are useful for most materials found or created on Earth. The standard atomic weight has great authority, and is used widely. For consistency throughout, it is advisable that Wikidata and its consumers use the same, authorised mass definition, name and value. Per SI, one could write quantity symbol Ar, CIAAW or Ar, standard. The CIAAW values may be updated biannually (2017, 2019, ...). DePiep (talk) 19:40, 7 March 2017 (UTC)

Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Daniel Mietchen
Andy Mabbett
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Nothingserious
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Pictogram voting comment.svg Notified participants of WikiProject Chemistry. See also: Wikidata:Property proposal/conventional atomic weight (simultaneously). -DePiep (talk) 20:47, 7 March 2017 (UTC)

  • Added: regex value format. -DePiep (talk) 21:14, 7 March 2017 (UTC)
  • Notation: CIAAW writes: Ar(E) = value, where E is the element. The helium example would be: Ar(He) = 4.002602(2). Still, this does not specify which of their published atomic weights is mentioned (standard, conventional, abridged?). For this, and per BIPM (SI), one could write Ar, standard(He) =.... This is background information (documentational), and does not alter the proposal. -DePiep (talk) 07:48, 8 March 2017 (UTC)
  • Discussion sections reorganised. -DePiep (talk) 21:46, 9 March 2017 (UTC)
Discussion
  • Symbol support vote.svg Support Gstupp (talk) 19:55, 7 March 2017 (UTC)
  • Symbol support vote.svg Support we're in the middle of a discussion about chemical elements vs atoms; this is a property that applies to the bulk (average) not to individual atoms, so it's of interest to that discussions also... ArthurPSmith (talk) 17:11, 8 March 2017 (UTC)
  • Symbol support vote.svg Support As property on chemical element (Q11344). --Egon Willighagen (talk) 08:31, 13 March 2017 (UTC)
  • Symbol support vote.svg Support Walkerma (talk) 02:47, 9 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose It is no longer clear what is being proposed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:26, 9 March 2017 (UTC)
    • Curious. Your very first comment here started with: It's not clear what is meant ..., now you conclude "It is no longer clear ...". Does this say there was an intermediate period when it was clear to you? Of course, we are still working on the datatype detail. Anyway, I did try to clarify and there is always the link to the defining source (by the authority). -DePiep (talk) 15:28, 10 March 2017 (UTC)
      • No your intent has never been clear. You dismissed a request for clarification as "This is the clearest I can get". Since then you have "muddied the waters" further. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 10 March 2017 (UTC)
        • Are you inferring that I intentionally did not clarify enough? Why not accept that this is the best I can do, and that the issue actually is complicated by itself? -DePiep (talk) 16:36, 10 March 2017 (UTC)
          • I wouldn't pretend to understand the reason for the lack of clarity. If you as the proponent cannot clearly explain what you are proposing, who can? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:40, 10 March 2017 (UTC)
  • Pictogram voting comment.svg Comment So the only one opposer has no content argument. Well then. -DePiep (talk) 21:12, 1 April 2017 (UTC)

Datatype issues[edit]

  • It's not clear what is meant by the two examples, which use a different format. Neither is a single number, as the proposed datatype suggests. Please clarify. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:21, 7 March 2017 (UTC)
    • The Datatype only recognises 'number', not any specification. So I left it at that. The two examples show the two patterns CIAAW publishes. We'll have to accomodate those somehow. My first try for the pattern: (\d+.\d+\(\d+\)|\[\d+.\d+, \d+.\d+\]).
      3. I recon the first one is a single number, including an uncertainty as is common in physics. I don't mind the way of counting, as long as Wikidata can treat is as a number for future calculations (e.g. for molar mass & uncertainty).
      4. CIAAW gives no value for 34 unstable radioactive elements (think: 43Tc, 61Pm and ~from 84Polonium up). -DePiep (talk) 21:14, 7 March 2017 (UTC)
      • That's no clearer. A number-type property has quantitative values like "123", "6.78" or -23.89". They may have a precision, such as "2765+-2". Are you proposing a property that takes as its value strings like "4.002602(2)" and "[1.00784, 1.00811]"? If not, what exact values would it take in those cases? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:20, 7 March 2017 (UTC)
This is the clearest I can get. It is the CIAAW publishing, and they their Technical report 2013 refers to [www.bipm.org/en/publications/guides/vim BIPM VIM] for value notation. If there are limits to Wikidata possibilities - please say so. -DePiep (talk) 21:47, 7 March 2017 (UTC)
@Pigsonthewing: the (2) is standard notation for +- 2 in the last digit, it would have to be entered in wikidata as 4.002602 +- 0.000002. @DePiep: I assume the second example means there are two values given; these would have to be entered as two *separate* claims for this value, it can't be done on one line. If it is instead just a range, then it can be done with +- notation about the mid-point value. ArthurPSmith (talk) 17:11, 8 March 2017 (UTC)
The note on "(+/-2)" is correct. Then, the [d, d] notation is the range interval (is the correct word) of values (borders included), explicitly without any statistical indication.The mid-value is no more probable than an other value in the interval. I'd say writing so in WD would suggest an uncertainty, which CIAAW wants to avoid. (Background: CIAAW uses actual samples/sources from the Earth. By radioactive history those can vary for that element. A crude example by me: hydrogen in air can have developed differently (radioactively spoken) than when in minerals or oceans. So CIAAW finds different mixes of isotopes in the RL sources for hydrogen. This is presented as an interval. OTOH, the regular numbers are narrowed averages as more easily expected).
Now how to handle this? Having an actual number (with uncertainty) is great because WD users (that could be automated external 'infoboxes') can use that to calculate a molecular mass if a chemical compound, preferably handling the uncertainties right even.
I assume we can not have two properties for the same formal quantity. Is there a WD-internal option to say "use Prop-A when present (the numeric one), else Prop-B (the interval textual one)"? Cannot leave that to programmers (like Lua in enwiki).
For now, I cannot think anything better than: make it a string (regex controlled), and the reader will have to extract the number, uncertainty or border from it before any calculating (or re-formatting) can be done. Ouch. Of course, whatever WD does: any calculation will always have to make a choice on how to use the interval borders (produce two values? use the midvalue?).
A secondary solution: CIAAW also publishes a 'conventional' simple value for these interval'ed elements (12/84). (proposal too). These are single number values, a little less perfect and without uncertainty, eg for commercial and trade usage (not for pharma and sciences one would say). So, any value extracting WD-user could say: "IF Property 'conventional value' exist THEN use that one to avoid the interval, ELSE use the standard value". Would leave unsolved: those single-number values are still in this same textual property, so can not be numeric.
TL;DR; 1. CIAAW published values are sacred, including the interval form. Better not rewrite, if needed write by literal textstring... 2. Single numbers would be very useful as numbers, eg for calculations (72/84 elements). 3. Interval-value elements (12/84) should also get the single-number 'conventional atomic weight' (property), also published by CIAAW. This value can be used in less-extreme calculations. -DePiep (talk) 18:12, 8 March 2017 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────@ArthurPSmith:: in Special:ListDatatypes I see datatype "Quantity" with 'lower bound' and 'upper bound' (next to 'amount'). Q1: is this how the "number±number" is generated I see in those live item properties? Q2: are there pros and cons when we use these for an interval? Can we leave the 'amount' empty? -DePiep (talk) 15:41, 9 March 2017 (UTC)
@DePiep: I don't think you can leave "amount" empty, however that might be a matter for testing. Certainly you can't do that using the current wikidata user interface, but it might be possible via an API call. I don't know how the UI would display such a thing. But there is no need to treat the +- represented here as an "uncertainty" of any standard sort, it could represent a flat distribution for a range, just with an appropriate value for the uncertainty corresponds to (P2571) qualifier. See for example the half-life statement on caesium-117 (Q1940002) for how it's been used. Instead of "standard deviation" I would put "range" or something like that as the value. ArthurPSmith (talk) 16:47, 9 March 2017 (UTC)
* Benjaminabel (talk) 10:25, 9 March 2017 (UTC)
I don't think it's necessary to create two properties for standard atomic weigth, we could simply transpose differently range numbers and values with uncertainty like this:
  • Hydrogen: Ar(H) = [1.007 84, 1.008 11] since 2009 stored as quantity: value:1.008, lowerBound:1.00784 upperBound: 1.00811
  • Helium: Ar(He) = 4.002 602(2) since 1983 stored as quantity: value:4.002602, lowerBound:4.0026018 upperBound: 4.0026022
This first states that we can set the upper and lower values of the interval in Datatype Quantity. Secondly, it assumes we can (or must?) add the amount value, which may not be the midvalue and even may be outside of the interval (cases: conventional value for oxygen, thallium).
First requirement—a must: In every situation, we require that a value is presented as it is defined. So being a value with uncertainty or an interval: there must be two different forms available (one per element is used). By its definition, it is not acceptable that an interval is presented as a single-value-with-uncertainty. We can not compromise on the formal value published.
Second requirement—a would be nice: We could consider adding the conventional value for interval values (1.008 for hydrogen; 12 such elements). If this can be done, fine. However, this may not compromise the #1 requirement. This conventional value may not obscure the standard interval value. This asks for a different way of fetching, right?
Can the datatype Quantity serve this? (how can we test this?) -DePiep (talk) 15:57, 10 March 2017 (UTC)
@DePiep: yes the datatype supports this, although the web UI currently does not. You would need to interact with it using the API (there are python, java, etc. libraries for this). test.wikidata.org exists precisely for testing things like this. ArthurPSmith (talk) 17:17, 13 March 2017 (UTC)

Orthographic issues[edit]

How does this property relate to 'chemical element', and to 'relative atomic mass"? Part of, instance of? -DePiep (talk) 21:46, 9 March 2017 (UTC)

Overview[edit]

Developing. -DePiep (talk) 21:46, 9 March 2017 (UTC)
related: no label (Q28919928) -- note: "abridged", not "rounded" -DePiep (talk) 00:02, 10 March 2017 (UTC)

conventional atomic weight[edit]

   Under discussion
Description relative atomic mass (Q41377) of a chemical element by single number, simplified from the formal value standard atomic weight (Q28912964) when that value is an interval. Defined by CIAAW (Commission on Isotopic Abundances and Atomic Weights (Q15647945)).
Represents conventional atomic weight (Q28913027)
Data type Number (not available yet)
Domain chemical element (Q11344) (12 out of 118)
Allowed values \d+.\d+
Example
  • For hydrogen (H): Ar, conventional(H) = 1.008
(hydrogen (Q556) has formal standard atomic weight (Q28912964): Ar, standard(H) = [1.00784, 1.00811]. The value 1.008 is clearly not the midvalue, but a value that the authority published, source-weighted)
Source CIAAW, technical report 2013, Chapter 7.
Planned use Add to 12 chemical elements. Next to their standard atomic weight
See also Wikidata:Property proposal/standard atomic weight
Motivation

Proposed property standard atomic weight applies to 84 elements. Twelve of these elements have a rangeinterval value (not a single number value). That is because by source history these elements have different isotopes abundances (so it is not about uncertainty). For situations where this exactness is not needed, such as trade, CIAAW has published 'conventional' values for simplified use.

Adding this value to Wikidata by specific property id allows any user (could be automated) to use a well-sourced value for mass calculations. It should not replace the standard atomic weight, but be available next to it. The quantity symbol is Ar, which per SI for this definition could be written as Ar, conventional. DePiep (talk) 20:16, 7 March 2017 (UTC)

  • Added: regex, allowed values = \d+.\d+. Rephrased the example. The correct word is 'interval' not 'range'. -DePiep (talk) 00:26, 9 March 2017 (UTC)
  • This value is derived from proposal standard atomic weight (and relative atomic mass). So this proposal could have a wait. -DePiep (talk) 21:44, 9 April 2017 (UTC)
Discussion
  • It is not clear what is meant by the example, which is not a single number, as the proposed datatype suggests. Please clarify. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 7 March 2017 (UTC)
    • How is 1.008 not a single number? -DePiep (talk) 22:08, 7 March 2017 (UTC)
No, it was there when you first posted here. The diff you give is showing that I only rearranged the items in the example (with the introducing one always bracketed).
Given that you did not reply to the content of my reply (still valid), you have not motivated your rejection. Also, Andy, this BF attitude does not help you getting better answers. -DePiep (talk) 14:52, 9 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose I don't see that this adds anything to the information provided by the standard weight proposal. ArthurPSmith (talk) 17:14, 8 March 2017 (UTC)
    • The twelve values are published by CIAAW (!) to provide a second-grade single value for cases where the standard weight is an interval (hydrogen: 1.008 for [1.00784, 1.00811]). The value can not be calculated from the interval. In 'trade and commercial' situations this value can be useful enough, and easier to use (correctness wrt uncertainty, RL sources and good math). Also, given current Wikidata limits for the interval values, this value could help numbercrunching applications by avoiding the formal interval notation. (See the discussion at the 'standard' proposal). -DePiep (talk) 18:29, 8 March 2017 (UTC)
  • Symbol support vote.svg Support Walkerma (talk) 02:48, 9 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose Benjaminabel (talk) 10:25, 9 March 2017 (UTC) I don't think it's necessary to create two properties for standard atomic weigth, we could simply transpose differently range numbers and values with uncertainty like this:
    • Hydrogen: Ar(H) = [1.007 84, 1.008 11] since 2009 stored as quantity: value:1.008, lowerBound:1.00784 upperBound: 1.00811
    • Helium: Ar(He) = 4.002 602(2) since 1983 stored as quantity: value:4.002602, lowerBound:4.0026018 upperBound: 4.0026022
(Your reply is relevant for the standard proposal too). That could be a way to keep the datatype numeric. However, how does a WD-Reader know whether the value is an interval or is a number-with-uncertainty? The source definition is meaningfully different. And so should be the presentation (formatting, usage). I don't think we (WD) should reform the CIAAW statement.
By definition, the 'conventional' value is not the 'standard' value. This is not a "second" property for standard atomic weight. It is a different value and so different property (well defined & sourced). -DePiep (talk) 15:53, 9 March 2017 (UTC) (late)
Benjaminabel, I understand that you implicitly support creation of property standard atomic weight. Your comment (!vote) is welcome there. -DePiep (talk) 15:53, 9 March 2017 (UTC)
Again, in this tree-set of proposals: if it is 'unclear' to you as you said, why not !vote: defer? Clarity could arrive later on. -DePiep (talk) 18:27, 15 March 2017 (UTC)

relative atomic mass[edit]

   Under discussion
Description The average mass of single element atoms in a given sample or source. Made relative (dimensionless) by division by carbon-12 mass. Is not: atomic mass (not unit Da or u).
Represents relative atomic mass (Q41377)
Data type Number (not available yet)
Domain chemical element (Q11344), when standard atomic weight is not applicable
Allowed values number
Allowed units none (dimensionless value)
Example
  • Ar(B) = 10.8185(±1.5)
(My rough reading from CIAAW (2106), fig 3: boron-bearing materials, Evaporated sea water. DePiep)
Source CIAAW (2106): before going into their limiting requirements, this Report describes the general way of determining the value.
Planned use Can be added to 34 elements (118 − 84 elements that do not have a standard atomic weight assigned). Also for items that are a sample (moon rocks?). Can be used in periodic table overviews, could use an annotation.
See also
Motivation

The relative atomic mass is the general physical quantity (symbol Ar) for element's mass. Its value is dimensionless. It is written Ar(E) for element E, e.g. Ar(Tc) = 98. An uncertainty range might be added, written like "98(3)" or otherwise.

The quantity is best known in a more specified, qualified form: the standard atomic weight for elements (say Ar, standard). That specification is maintained by CIAAW (an IUPAC commission), and limits the samples to being: terrestial, natural, stable, well-handled, well-researched. Now the task is to explain: if the value is not a CIAAW authorised standard value, don't use the word 'standard' or 'CIAAW'. The separate property 'standard atomic weight' (proposed) allows for keeping these two apart.

For all situations that are not within the scope of the CIAAW standard, the general Ar should be used. For example, for the relative atomic mass of an element in -

Moon rocks (not terrestial)
Elements with instable isotopes only like polonium (not stable)
Single source research contributing to the CIAAW calculations (by itself not representative for the whole Earth)
Enriched uranium (not natural).

DePiep (talk) 16:35, 9 March 2017 (UTC)

Discussion
Then defer and wait or work to get clarification, I'd say. How is your understanding the lawmaking rule? -DePiep (talk) 06:34, 14 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose Oh I think this is clear enough, but it is not needed, if I understand the issue. First of all, to address the "moon rock" concern, simply attach a qualifier to the value indicating the origin of the mass evaluation (as well as a reference). The same can be done for specific terrestrial sources that differ from the usually asserted average. Secondly for short-lived radioactive elements, there IS no reasonable way to define a standard mass, as whatever isotopic collection we have is purely artificial and could be anything. For specific isotopes we already have mass (P2067) and the basic "A" integer value can be obtained as the sum of atomic number (P1086) and neutron number (P1148). I think the problem here is DePiep is under the impression that the "standard weight" property needs to be purely the value provided by CIAAW - yes we do something like that with our external identifier properties, but for quantitative values properties need to be generic: any authority that asserts a "standard average weight" should be allowed to provide that value for the property, with a reference (and possibly a qualifier) asserting the source or type. Properties for physical quantities should never be limited to a single source. ArthurPSmith (talk) 17:26, 13 March 2017 (UTC)
Ouch, had to correct subject item into relative atomic mass (Q41377). Will reply to ArthurPSmith here later. -DePiep (talk) 18:32, 13 March 2017 (UTC)
re ArthurPSmith (talkcontribslogs). Several issues.
1. This proposal, relative atomic mass relative atomic mass (Q41377) is a true physical quantity, symbol Ar (or r.a.m. here). Do not confuse this with standard atomic weight.
2. DePiep is under the impression that the "standard weight" property needs to be purely the value provided by CIAAW. Yes I am. And so is the IUPAC community (the CIAAW parent organisation). CIAAW/IUPAC is the one and only authority to publish standard atomic weight (Q28912964) (s.a.w. here, or Ar, standard as I can write it). Note: keyword is "standard", which is used only in this meaning & context, in this environment. Of course, when the s.a.w. itself is the topic of discussion, this limit is relaxed. More background: en:Standard atomic weight (I started recently).
3. The proposal/quest is to add s.a.w., r.a.m. or both as a property. Now, and only now, Wikidata comes in play. I want to learn why this would not be a good addition, but so far I don;t understand the reasons for rejection.
4. IIReadC, ArthurPSmith proposes to use mass (P2067) to store a mass with an element (as is done with the mass number for an specific isotope). Now P2067 is a mass. Suppose a value+source is entered correctly, how can the reader (aka infobox, or external data consumer), how can that consumer be sure to have the right mass? Must is do an interpretation of the source? How to ask for a certain mass value (while there may be an other one, or more).
Example in case: helium (Q560), today. Has "4.003±0 atomic mass unit", and "mass=4.002602±0.000002 atomic mass unit". (at the moment, I can not read the reference); (note that "standard atomic weight" value is *not* in there). So: How do I get out the value I want to know? Somehow I must be able to differentiate between available masses. -DePiep (talk) 17:56, 29 March 2017 (UTC)
For some reason I could not remove (edit) that unit "atomic mass unit", and not add Qualifier="standard atomic weight", because ... that qualifier must be a property. Circular now. -DePiep (talk) 18:17, 29 March 2017 (UTC)
Done, crudely. PubChem is not an OK source. -DePiep (talk) 18:44, 29 March 2017 (UTC)
perhaps using the source/reference relationship is not the right way to go; however, there are a huge number of properties where we do exactly this sort of thing using qualifiers, so that there are several claims for the same property with different values. For example population data is given with a "point in time" qualifier, and many geographical locations in wikidata have multiple population claims depending on the year - see for example the population section of California. Given that this and your other proposed "standard mass" properties would only apply to a very small number of items (at most the 118 elements) I really don't see a need for more than (at most) one new property, with appropriate qualifiers describing the determination method (P459). ArthurPSmith (talk) 18:07, 30 March 2017 (UTC)
How to save & retrieve a physical quantity
  • This is core physical quantity stuff.

So I have this real-life quantity (from scientific sources), and I think Wikidata (WD) should be able to receive & present that (store it, and let info-consumers read it). If I understand ArthurPSmith well, it cannot be stored as I'd expect (not some 1:1 copy), but we should store it as a mass (P2067).

I will not go into "how to save that numeric value in a property" here (see nearby).
As ArthurPSmith described, the WD-property mass with datatype Quantity can store a mass somehow. However,
A. It does not allow for the quantity name/symbol/identifier/QID. It only has "number unit" input option. One can not specify: this value is the "mass at takeoff" or mass "Ar". AFAIK, with a certain mass value (property) I can enter the source but I can not enter the appropriate quantifier:Qxxx.
B. How can an info-consumer (a wiki infobox or an external site reading & using this WD property), how can it ask specifically for item's "mass at takeoff" or item's "Ar" mass (existing, entered)? As I read ArthurPSmith here, that infobox must make an interpretation of the masses available in the item.
C. While being a "mass", it does not require the dimension of mass (e.g., also allowed is: x kg/mol). This is where the Property "mass" loses being "the physical quantity mass". Could be fine, but this shifts a bit of WD data philosophy off to the true 'mass'-reading infoboxes (...is how I feel it ;-) ).
Z So far, I get the impression that main physical quantity notation in WD (think BIPM and SI-brochure) is lacking. I'd expect that when I add a quantity value (number×unit), at least I can (should) specify its quantity definition/name/symbol/QID.

@ArthurPSmith, Pigsonthewing: -DePiep (talk) 21:55, 16 March 2017 (UTC) — -DePiep (talk) 23:22, 16 March 2017 (UTC)

Physical quantities primer[edit]

  1. quantity = value
    value = number × unit (unit has the dimension, number is a number)
  2. quantity name = number × unit name
  3. quantity symbol = number × unit symbol
  4. quantity symbolspecified = number × unit symbol
Examples:
Speed: v = 10 km/h
A more specific quantity: specify the quantity (not the unit km/hmax)
Max speed: vmax = 10 km/h

Notes:

Habit: quantity symbol is in italics: v. One rarely sees this symbol (outside tables and graphics). In written language, the name is used: "The speed is ...".
"dimension" is a product of seven independent dimensions (time, distance, ...). As in: dimension of speed = distance/time.
Note that the dimensions are not predicting a certain unit. Both mile and km are OK for a "distance" dimension.
The "×" operator symbol is usually omitted. Still: a product it is.
The formula is algebraic, on purpose. A great feature! For example, we can 'cross out' sames above and below the deviding slash (as with all math: must be done correctly...):
7 h × 10 km/h = 70 h×km/h = 70 km
Special case: dimensionless. Then the unit = 1 (not: absent; not: 0). The value is, still algebraic: number × 1
-DePiep (talk) 21:55, 16 March 2017 (UTC) — -DePiep (talk) 23:22, 16 March 2017 (UTC)
@DePiep: Now you've lost me. Have you read WD:Q? If something can't be handled using appropriate qualifiers then sure we can define new properties to handle it - and I think at least one standard atomic mass property of this sort would be helpful. As to data entry - if you define something as a string datatype you can put whatever you like into it, but that greatly limits reusability and also user expectations (that quantitative values should involve a number, not a string). Wikidata numbers are arbitrary precision, so that shouldn't be an issue. ArthurPSmith (talk) 23:39, 16 March 2017 (UTC)
re 1: No I had not read or seen WP:Q ever. That is because I am struggling for months to find plain equivalents WD pages for my familiar enwiki pages like the village pumps and documentation. Months? A year. No-where-ever did I came across a useful link, (enwiki does not have a relevant WikiProject --unless 2015 is ok-- and WD is four years old now? Compare Lua introduction), never got a useful link until some WD smarty comes along and links it, always while blaming me for not knowing it. That is WD for me. I did my very best to write this contribution, and maybe you might consider digesting it. I claim that this post about SI and physical quality deserves a better reading (see Z). You actually did not reply my core points, you just wrote a 'how to use a WD-property'.
re 2: I did not mention it in my replies, because it is a non-issue here. In this proposal any "standard atomic weight" is not relevant and it is too confusing. Ar, the quantity "relative atomic mass", is the topic. (that 'standard atomic weight' is the most well-known specific form of it, Ar, standard, but the topic is: quantity-in-WD). Please do not use 'standard atomic weight' again in this discussion this way.
re 3: You are talking 'string' datatytpe. I said: that is not the issue.
re 4: shortest: adding a mass property value to hydrogen, I could not add quantifier for that mass (value): "relative atomic mass (Q41377)"  – The preceding unsigned comment was added by DePiep (talk • contribs) at 00:39, 17 March 2017‎ (UTC).
@DePiep: when I said "you've lost me" I meant I no longer understand what you are trying to do here. I have read what you wrote, I do not follow the logic or see a clear action needed or proposal here. Given that you have been using Wikidata for longer than I have (I started in fall 2015, you apparently in fall 2013) I am also confused at your unfamiliarity with basics. "Project Chat" is the "village pump" here and you have posted there several times over the years. wikidata is not enwiki, but we do have "Help" pages of various sorts, listed on Help:Contents (which is linked via "Help" in the navigation bar on every page here). If you find them inadequate you are free to improve them or ask for help in so doing, there is also an RFC process. I find the watchlist functionality very useful. Not sure what else I can advise or help with here. ArthurPSmith (talk) 20:44, 20 March 2017 (UTC)
Sorry, that was my frustration taking over for me not getting all this. You deserve a better reply. Later on. -DePiep (talk) 11:18, 21 March 2017 (UTC)

conjugate acid[edit]

   Ready Create
Description species formed by accepting a proton (H⁺)
Represents conjugate acid (Q2014867)
Data type Item
Domain chemical compound (Q11173)
Allowed values chemical compound (Q11173)
Example azanide (Q4026895)ammonia (Q4087)
ammonia (Q4087)ammonium cation (Q190901)
phenolate (Q27122100)phenol (Q130336)

conjugate base[edit]

   Ready Create
Description species formed by losing a proton (H⁺)
Represents conjugate base (Q33113572)
Data type Item
Domain chemical compound (Q11173)
Allowed values chemical compound (Q11173)
Example ammonium cation (Q190901)ammonia (Q4087)
ammonia (Q4087)azanide (Q4026895)
phenol (Q130336)phenolate (Q27122100)
Motivation

Conjugate acid / base relation is the fundamental relation of acids and bases in Brønsted–Lowry theory. Introducing proposed properties would allow linking appropriate pairs of items and easily traversing chains of conjugate pairs, such as NH2- ⇌ NH3 ⇌ NH4+ (azanide (Q4026895)ammonia (Q4087)ammonium cation (Q190901)). Currently there is no relation between those items in the database. As a consequence, it is difficult to get the value of pKb of a base – pKa value is assigned to the conjugate acid and finding the corresponding item is difficult. Kubaello (talk) 16:36, 27 June 2017 (UTC)

Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Daniel Mietchen
Andy Mabbett
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Nothingserious
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Pictogram voting comment.svg Notified participants of WikiProject Chemistry

Discussion
  • Pictogram voting comment.svg Comment Maybe the properties should be named Brønsted–Lowry acid / Brønsted–Lowry base to avoid confusion with Lewis acids / bases. Kubaello (talk) 16:36, 27 June 2017 (UTC)
  • Pictogram voting comment.svg Comment One "represents" is wrong. --Egon Willighagen (talk) 14:08, 28 June 2017 (UTC)
    • I think that conjugate acid (Q2014867) represents the conjugate acid / base pair, or the subject in general - at least this is what labels (Korresponderende syre-basepar, Conjugate acid, Base conjugada) and contents of linked wp articles suggest. I'm not aware of separate wd items for conjugate acid and conjugate base. conjugate acid (Q2014867) seemed to be the best match. Kubaello (talk) 18:59, 28 June 2017 (UTC)
  • Symbol support vote.svg Support I think the names are fine; this seems very useful. ArthurPSmith (talk) 19:22, 28 June 2017 (UTC)
  • Are their other data bases that store the same relation? If so, how do they name it? ChristianKl (talk) 10:54, 29 June 2017 (UTC)
  • Symbol support vote.svg Support - though shouldn't the second one have "Represents - conjugate base" or did I misunderstand something? Anyway, this is a fundamental relationship in chemistry, so I support the introduction of these two. Regarding Kubaello, I think that the concept only applies to Bronsted-Lowry theory - there is no such thing as a conjugate acid in Lewis AB theory - so I don't think confusion is possible. Walkerma (talk) 23:07, 1 July 2017 (UTC)
  • Pictogram voting comment.svg Comment As above, I prefer two properties, one for conjugate acid (Q2014867) and one for conjugate base (Q33113572) (which I just made). That way the directionality can be incorporated. --99of9 (talk) 10:29, 19 July 2017 (UTC)

Medicine[edit]

Please visit Wikidata:WikiProject Medicine for more information. To notify participants use {{Ping project|Medicine}}

only valid for subset[edit]

   Under discussion
Description This should only be used as a qualifier. It denotes that the statement isn't true for all instances but only for a subset.
Data type Item
Example Rectus abdominis muscle (Q275150) innervated by (P3189) Sixth intercostal nerve (Q27058097) → this property → Unknown value
See also applies to part (P518), valid in period (P1264), valid in place (P3005)
Motivation

I take information about innervation from Anatomy and Human Movement Structure and Function SIXTH EDITION (Q27050364). It tells me that in sometimes Rectus abdominis muscle (Q275150) is innervated by Sixth intercostal nerve (Q27058097) while in other cases it isn't.

I want this property to be able to enter this kind of knowledge in Wikidata. I'm personally unsure whether this is the best way to model this domain. If someone has other suggestions I'm happy. ChristianKl (talk) 14:03, 24 January 2017 (UTC)

Discussion
  • Maybe use applies to part (P518)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 24 January 2017 (UTC)
    • No, I'm pretty sure that's a different meaning than ChristianKl intends, but maybe also indicates the name is confusing. I think the meaning wanted here is effectively the difference between "sometimes" and "always". How to model that in wikidata? ArthurPSmith (talk) 18:27, 24 January 2017 (UTC)
      • I also think that applies to part (P518) has a slightly different meaning. I think it's worthwhile to have properties that can make precise statements about issues like this and it's not good to overload applies to part (P518) with slightly different meanings. A human might understand what's meant when he reads the data but an automated system might not. ChristianKl (talk) 09:56, 25 January 2017 (UTC)
  • Well, you need an item for the subset anyway ? So, why not just put the statement in that item and left what is valid in every case in the upper one ? author  TomT0m / talk page 21:49, 25 January 2017 (UTC)
It might be that we have a source that says that this is true for 50% of the population. This information could be filled in. ChristianKl (talk) 09:09, 27 January 2017 (UTC)
How do you express "50% of the population" ? The set is not identified. Isn't this the notion of incidence (Q217690) View with Reasonator View with SQID or something similar you're looking for ? Or you're looking for something similar to disjoint union of (P2738) View with SQID or subclass of (P279) qualified with a numerical value representing this ? author  TomT0m / talk page 11:30, 27 January 2017 (UTC)
@TomT0m:I think it's worth having a specific property for this to allow for automated interaction with the data. If you think there's a specific way this data can already be presented I invite you to edit the example of Rectus abdominis muscle (Q275150) accordingly. ChristianKl (talk) 07:44, 2 February 2017 (UTC)
@TomT0m, ChristianKl: You can use proportion (P1107) to express this. --Swpb (talk) 17:19, 15 February 2017 (UTC)
@Swpb: If you think this property can be used here, could you edit the linked example accordingly? ChristianKl (talk) 17:52, 15 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I added a few "see also" above.
    --- Jura 11:47, 26 March 2017 (UTC)

may prevent[edit]

   Under discussion
Description a disease which may be prevented by a certain drug
Data type Item
Domain Medicine
Allowed values Wikidata items of instance of (P31) or subclass of (P279) disease (Q12136)
Example aspirin (Q18216)myocardial infarction (Q12152) -->
Source http://www.fda.gov/, http://ema.europa.eu/, https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/NDFRT/
Planned use several hundred preventative drug usages should be added to Wikidata
See also drug used for treatment (P2176), medical condition treated (P2175), cause of (P1542), significant drug interaction (P769)
Motivation

As listed above, Wikdata has several properties to describe drug-disease interactions (drug used for treatment (P2176), medical condition treated (P2175)), drug side effects (cause of (P1542)) and drug-drug interactions (significant drug interaction (P769)). What is still missing is a way to describe that a certain medication can prevent a disease from even occuring. This property proposal should cover these cases. Sebotic (talk) 19:00, 8 February 2017 (UTC)


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
Pictogram voting comment.svg Notified participants of WikiProject Medicine

Discussion
  • What exactly is meant by "may"? I think the property should likely to be worded to be more clear about the meaning. ChristianKl (talk) 22:09, 8 February 2017 (UTC)
I followed the wording of NDF-RT and it makes sense, because medications in many cases do not have a 100% success rate. But certainly, I can rename it to 'used for prevention of', if you prefer that. Sebotic (talk) 09:54, 9 February 2017 (UTC)
Many substances that are labeled with drug used for treatment (P2176) aren't better than placebo's. They are used by doctors to treat but there's no evidence that they are effective for that purpose. When it comes to this property it's important to be clear about whether this property indicates that there's evidence that supports this claim. I don't think it has to be made clear in the property name so "may prevent" is okay. But it should be made clear in the property description. We don't want people to make bad decisions because they think the property indicates proof for the capability of preventing a disease when it doesn't. ChristianKl (talk) 14:50, 10 February 2017 (UTC)
  • support the creation of this property and feel it is needed, but prefer the 'used for prevention of' label to be consistent with the way the treatment property is written. Gtsulab (talk) 18:01, 1 June 2017 (UTC)

Cytogenetic location[edit]

   Under discussion
Description Cytogenetic location of the gene or region.
Data type String
Domain gene (Q7187)
Example
Source


See also chromosome (P1057), genomic start (P644), genomic end (P645)
Motivation

en:Locus (genetics). These symbols are used to show the locations of the genes in genetics. I noticed that this property had not yet created. So I propose.Was a bee (talk) 07:33, 4 May 2017 (UTC)


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
Pictogram voting comment.svg Notified participants of WikiProject Medicine New property proposed. Was a bee (talk) 07:27, 2 July 2017 (UTC)

Andrew Su
Marc Robinson-Rechavi
Pierre Lindenbaum
Michael Kuhn
Boghog
Emw
Chandres
Dan Bolser
Pradyumna
Chinmay
Timo Willemsen
Salvatore Loguercio
Tobias1984
Daniel Mietchen
Optimale
Mcnabber091
Ben Moore
Alex Bateman
Klortho
Hypothalamus
Vojtěch Dostál
Gtsulab
Andra Waagmeester
Sebotic
Mvolz
Toniher
Elvira Mitraka
David Bikard
Dan Lawson
Francesco Sirocco
Konrad U. Förstner (talk)
Chris Mungall (talk)
Kristina Hettne
Hardwigg
i9606
Putmantime
Tinm
Karima Rafes
Finn Årup Nielsen
Jasper Koehorst
Till Sauerwein
Crowegian
Nothingserious
Okkn
AlexanderPico
Amos Bairoch
Gstupp
DePiep
Was a bee
SarahKeating
Muhammad Elhossary
Pictogram voting comment.svg Notified participants of WikiProject Molecular biology New property proposed. Was a bee (talk) 07:27, 2 July 2017 (UTC)

Discussion
  • Pictogram voting comment.svg Comment I first read "citogenesis location". :)
    --- Jura 11:24, 12 May 2017 (UTC)
  • Pictogram voting comment.svg Comment I think your pings didn't work as you didn't include a signature [6].
    --- Jura 18:11, 29 June 2017 (UTC)
  • Pictogram voting comment.svg Comment Oh, signature needed!? I try again. Thanks! --Was a bee (talk) 07:25, 2 July 2017 (UTC)

Symbol support vote.svg Support Gstupp (talk) 17:22, 5 July 2017 (UTC)

exists between[edit]

   Under discussion
Description subject item exists between object item(s) physically
Data type Item
Example Shoulder joint (Q1758798)values as qualifiers (Q23766486) (of (P642): scapula (Q16336) & humerus (Q162595))
oval window (Q2301793)values as qualifiers (Q23766486) (of (P642): middle ear (Q501553) & scala vestibuli (Q617973))
synaptic cleft (Q15320191)values as qualifiers (Q23766486) (of (P642): presynaptic membrane (Q14864381) & postsynaptic membrane (Q14864257))
palate (Q172605)values as qualifiers (Q23766486) (of (P642): cavity of mouth (Q27042858) & nasal cavity (Q156104))
Core–mantle boundary (Q1330051)values as qualifiers (Q23766486) (of (P642): Planetary core (Q742129) & mantle (Q101949))
equator (Q23538)values as qualifiers (Q23766486) (of (P642): Northern Hemisphere (Q39061) & Southern Hemisphere (Q41228))
Motivation

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 06:32, 23 May 2017 (UTC)

Discussion
  • Why do you think this property will be better than using connects with (P2789)? ChristianKl (talk) 08:47, 23 May 2017 (UTC)
  • I do not know I want to say yes because it is easy to find examples where this is the best way to describe the relationship between things. I want to say no because this is so vague that it would be hard to describe when to use this and when the relationship is trivial to note. Perhaps if the name could be made more specific then using it would be more meaningful. Like for example, should every street be tagged like Seventh Avenue (Q109926) -> exists between Sixth Avenue (Q109873) and Eighth Avenue (Q109951)? This seems like an inefficient way to sort maps, even if the relationship might work for body parts. Blue Rasberry (talk) 14:02, 23 May 2017 (UTC)
@ChristianKl, Bluerasberry: In case both connects with (P2789) and «exists between» can be used, connects with (P2789) should be used. (ex. NOT “stomach «exists between» esophagus and small intestine” but “stomach «connects with» esophagus and small intestine”)
However, some relations such as the above examples is a little different from connects with (P2789) because the subject item and object items are heterogeneous. In my opinion, boundary surface doesn't connect with its surrounding object. This is the same with bone vs joint or cavity vs wall relationships. In addition, if X «exists between» A and B, X usually can't be exist without the existence of A and B.
I feel certain that this property is required. --Okkn (talk) 14:56, 23 May 2017 (UTC)
@Okkn: Okay, that seems reasonable. I am not sure what more I should ask. Would it be fair for me to ask that you write some documentation which says, "If both this and property X can be used, then use only property X, which is more specific"? I do not know how properties get documented here, but it seems like there would be standard text for saying how users should apply the most specific property which could be applied when both a specific one and a vague one are available. Blue Rasberry (talk) 15:05, 23 May 2017 (UTC)
@Bluerasberry: I agree with you. Maybe description field or Wikidata usage instructions (P2559) statement is the place for that use.
And I think that constraints like {{Constraint:Conflicts with|list={{P|2789}} }} or those for other specific properies can be used. --Okkn (talk) 16:11, 23 May 2017 (UTC)
There's another issue, our properties takes one value and not two. When it takes more than one value we usually use qualifiers. ChristianKl (talk) 15:40, 23 May 2017 (UTC)
@ChristianKl: If there is only just one pair of two values, can't it be dealed with in the same manner as connects with (P2789)?--Okkn (talk) 16:11, 23 May 2017 (UTC)
@Okkn: The semantics of our properties are structured in a form that they work even if there's more than one pair of values. ChristianKl (talk) 17:11, 23 May 2017 (UTC)
@ChristianKl: I think this property should have only just one pair of values. Is that still no good? --Okkn (talk) 17:35, 23 May 2017 (UTC)
Unfortunately, no. The semantics of the property shouldn't change when another pair of values gets added. There's also no natural way to determine which is the one-and-only correct value that's between A and B and our usual way to deal with a case where there isn't an absolute truth is to allow different people to make different statements. ChristianKl (talk) 10:26, 24 May 2017 (UTC)
@ChristianKl: OK. Then, whould it be a problem if we use values as qualifiers (Q23766486) and of (P642) to take a pair of values? (I fixed the above examples.) --Okkn (talk) 15:30, 24 May 2017 (UTC)
I'm okay with those semantics. ChristianKl (talk) 15:41, 24 May 2017 (UTC)

surrounds or encloses/surrounded or enclosed by[edit]

   Under discussion
Description something that is physically surrounded by the subject item
Data type Item
Example Endomysium (Q3395843)muscle fiber (Q18891564) = myocyte (Q428914)
Perimysium (Q3543470)Muscle fascicle (Q6321987)
fascia (Q936531)skeletal striated muscle (Q1048687)
bony labyrinth (Q262489)membranous labyrinth (Q6593307)
Myelin (Q187388)axon (Q178999)
Amnion (Q473749)embryo (Q33196) and amniotic fluid (Q901674)
atmosphere of Earth (Q3230)Earth (Q2)
mantle (Q101949)Planetary core (Q742129)
   Under discussion
Description something that surrounds the subject item
Data type Item
Example muscle fiber (Q18891564) = myocyte (Q428914)Endomysium (Q3395843)
Muscle fascicle (Q6321987)Perimysium (Q3543470)
skeletal striated muscle (Q1048687)fascia (Q936531)
membranous labyrinth (Q6593307)bony labyrinth (Q262489)
axon (Q178999)Myelin (Q187388)
embryo (Q33196)Amnion (Q473749) and amniotic fluid (Q901674)
Earth (Q2)atmosphere of Earth (Q3230)
Planetary core (Q742129)mantle (Q101949)
Motivation

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 07:15, 23 May 2017 (UTC)

Discussion
  • I do not know I think it would be excessive to have this apply to maps. Like for example, many statues are "surrounded" by parks. Would all monuments in all parks use this? What limits should be on this property? Blue Rasberry (talk) 15:01, 23 May 2017 (UTC)
  • I don't feel strongly about the issue of marks and monuments. ChristianKl (talk) 11:50, 24 May 2017 (UTC)

Mineralogy[edit]

Please visit Wikidata:WikiProject Mineralogy for more information. To notify participants use {{Ping project|Mineralogy}}

Informatics[edit]

Please visit Wikidata:WikiProject Informatics for more information. To notify participants use {{Ping project|Informatics}}

File format magic numbers[edit]

   Under discussion
Description magic numbers used to incorporate file format metadata in form of a string coded hexadecimal number (usual encoding, "0" = 0 and "F" = 15, space ignored). Qualifiers can specify an offset and a padding value for this number.
Data type String
Template parameter Template:Infobox file format (Q10986167) magic number parameter
Domain file format (Q235557)
Example Graphics Interchange Format (Q2192) -> 47 49 46 38 39 61
Source Gary Kessler's File Signatures Table
Planned use I plan to add magic numbers to Wikidata items for the corresponding file formats.
Motivation

Magic numbers are constant numerical or text values used to identify file formats. Having this data in Wikidata will help make file format information more complete. Magic numbers are part of how we verify file signatures and are used in forensic computing. This is also a parameter of the Infobox:File format. It will be possible to transfer all of the magic numbers stored in infoboxes to Wikidata if we create this property. There is also this list [List of file signatures] that we could transfer to Wikidata. YULdigitalpreservation (talk) 15:43, 17 October 2016 (UTC)

Qualifier[edit]

(Additions to the proposal by TomT0m)

Offset[edit]
   Under discussion
Description qualifier of "magic number" for the number of bytes before the magic number to be searched in a file
Data type Number (not available yet)
Example Modelling the format "RVT" "
[512 (0x200) byte offset]
00 00 00 00 00 00 00 00 	  	[512 (0x200) byte offset]
........
RVT 	  	Revit Project File subheader
gives
< RVF > magic number search < 00 00 00 00 00 00 00 00 >
offset search <  512 >
.
Source Gary Kessler's File Signatures Table
Planned use qualifier for the property above

Talk[edit]

  • Symbol support vote.svg Support Symbol wait.svg Wait. author  TomT0m / talk page 17:31, 17 October 2016 (UTC)
  • Symbol support vote.svg Support but there are several other kinds of "magic numbers" so I think the name needs to be more descriptive - maybe "file format magic numbers"? Also, with string value isn't there some room for ambiguity in how the numbers are to be represented here? ArthurPSmith (talk) 18:18, 17 October 2016 (UTC)
    • Good point. If the numbers are string coded hexadecimal, this should be made explicit. The spaces seems also totally irrelevant and adds burden to parse. I can also see in the files that spec also specifies offsets : [11 byte offset] and [512 (0x200) byte offset]. This could be handled better than with an unspecified string format in a structured data projects. Also see if the string can't encode the non-hex version such as directly the string, for example in
    46 41 58 43 4F 56 45 52 FAXCOVER
    2D 56 45 52 	        -VER
    
    it should be possible to store more efficiently directly "FAXCOVER-VER", maybe an offset with a qualifier, and maybe a "padding value" also with a qualifier, something like
    < format > magic string search < FAXCOVER-VER >
    offset search < 0 byte >
    padding search < 0 >
    . author  TomT0m / talk page 18:32, 17 October 2016 (UTC)
    • Pictogram voting comment.svg Comment Thanks for this feedback. I revised the label for the property proposal. It looks like we will need a hexadecimal option as well as an ascii option. I welcome suggestions of how to further refine the proposal. YULdigitalpreservation (talk) 13:45, 18 October 2016 (UTC)
  • Symbol support vote.svg Support It will be very useful for data regarding file type identification. CC0 (talk) 11:45, 28 October 2016 (UTC)
  • Pictogram voting comment.svg Comment Could this property be specified to contain values which are Perl Compatible Regular Expressions (PCRE), allowing for more advanced signatures to be specified if desired? For example, "\x89PNG\x0D\x0A\x1A\x0A" for the PNG family, "\x00\x01\x00\x00Standard Jet DB" for Microsoft Access MDB, "GIF8[79]a" for the GIF family, etc. The advantages are: for ASCII-only-signatures (GIF), it's human-readable. For signatures containing binary/non-ASCII data (PNG), it's in a readily usable format (C/C++ strings for example) and for optionally complex signatures, it's in a format ready to use with a PCRE compliant parser. Pixeldomain (talk) 02:44, 17 November 2016 (UTC)
    Pictogram voting comment.svg Comment The offset could be identified in the PCRE expression, as an example: "(?s)^\x00\x01\x02.{38}ANSWERTOEVERYTHING" would look from the start of the file for \x00\x01\x02 then skip 38 bytes to offset 42 in the file where it would look for "ANSWERTOEVERYTHING". More advanced expressions could look at bytes from the end of the file (ZIP archives have a central directory tacked on the end of the file), perform negative look-aheads, etc. Whilst there is extra complexity with PCRE, it does not have to be used, and the fall-back is a simple C/C++ string representing binary data. Pixeldomain (talk) 03:09, 17 November 2016 (UTC)
  • Pictogram voting comment.svg Comment Also worth taking a look at is how the magic file of the "file" command stores file type signatures: https://github.com/file/file/tree/master/magic/Magdir Pixeldomain (talk) 03:32, 17 November 2016 (UTC)
    Pictogram voting comment.svg Comment Also take a look at the FIDO PRONOM database at https://raw.githubusercontent.com/openpreserve/fido/af3fc47791855ad7b955eb4272411113bfcff54d/fido/conf/formats-v88.xml which uses PCRE to define signatures for each file type. Pixeldomain (talk) 04:04, 17 November 2016 (UTC)
  • @Pixeldmain, cc0, YULdigitalpreservation, TomT0m, ArthurPSmith: what is the status of this proposal? Thryduulf (talk) 16:32, 22 April 2017 (UTC)
    • @Pixeldomain, CC0: (fixing pings) - obviously there was some debate here about the string format for this property. Of the proposals for format, I think the PCRE idea has a lot of merit. But I'd be ok with the original space-separated hexadecimal pairs too. No strong preference. ArthurPSmith (talk) 13:24, 24 April 2017 (UTC)
      • Pictogram voting comment.svg Comment @ArthurPSmith: My current view is that magic numbers or patterns are not a good property for a file format. See use of described at URL (P973) on Graphics Interchange Format (Q2192) for an example of an alternative approach I prefer for the identification and description of file formats. Pixeldomain (talk) 01:31, 26 April 2017 (UTC)
        • that means relying on a third party to provide the actual details of the format, but in some cases that may be all we have, so it's at least a good option to use. I still think a wikidata property specifically for something like this is useful though. ArthurPSmith (talk) 13:37, 26 April 2017 (UTC)
        • An alternative I have also considered is detailing the structure of file formats on Wikidata by creating items for each data structure and field within each format. This moves the data from external sources into Wikidata, whilst allowing external references and sources (typically international standards, RFCs, etc) be used to describe each new item. Do you have any thoughts on this possible approach? Pixeldomain (talk) 00:58, 27 April 2017 (UTC)
          • I'd probably want to see an example? Would there be several additional properties needed to do that, or can you make do with existing properties? ArthurPSmith (talk) 19:25, 27 April 2017 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Azertus
Pintoch
Jsamwrites
Fractaler
Pictogram voting comment.svg Notified participants of WikiProject Informatics Are there additional opinions about whether we should implement this property? ChristianKl (talk) 20:32, 24 May 2017 (UTC)

  • Symbol support vote.svg Support This property is really needed for file formats. Looking aback to the discussion, the best approach seems to be using PCRE. One last aspect may be adding a qualifier to add a weight or a probability on the proposed PCRE. This is a common practice in implementing format identification from magic numbers. Toto256 (talk) 20:51, 24 May 2017 (UTC)

data storage device[edit]

   Under discussion
Description data storage device supported by a machine (e.g. camera or mobile phone)
Represents data storage device (Q193395)
Data type Item
Template parameter |storage= at en:Template:Infobox camera
Domain machine
Allowed values data storage device
Example Canon EOS 300D (Q64039)CompactFlash (Q678615)
Source Freebase
Robot and gadget jobs Probably
Motivation

Note: First proposed at Wikidata:Property_proposal/Archive/38#storage medium. GZWDer (talk) 13:03, 18 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support The has part (P527) solution doesn't allow easy integration into Wikipedia templates. ChristianKl (talk) 09:44, 27 January 2017 (UTC)
  • Would this be slightly generalisable to "uses data storage type" to take values for internal and external storage? Thryduulf (talk) 22:08, 14 April 2017 (UTC)

Coded character set identifier[edit]

   Under discussion
Description identifier of a coded character set
Represents Coded Character Set Identifier (Q5009716)
Data type External identifier
Domain coded character set (Q29149990)
Allowed values \d+
Example UTF-8 (Q193537)1209
Source Coded character set identifiers
Planned use apply this property to coded character sets within Wikidata
Formatter URL https://www-01.ibm.com/software/globalization/ccsid/ccsid$1.html
Motivation

The Coded Character Set Identifier (CCSID) is issued by IBM and uniquely identifies many coded character sets used in the past and present within computer and telecommunications systems. Pixeldomain (talk) 04:57, 4 April 2017 (UTC)

Discussion

Code page identifier[edit]

   Under discussion
Description identifier of a code page
Represents code page (Q184766)
Data type External identifier
Domain code page (Q184766)
Allowed values regex: \d+{5}
Example EBCDIC 1047 (Q5322566)01047
Source Code page identifiers
Planned use apply this property to code pages within Wikidata
Formatter URL https://www-01.ibm.com/software/globalization/cp/cp$1.html
Motivation

The Code page identifier (CPGID) is issued by IBM and uniquely identifies many code pages used in the past and present within computer and telecommunications systems. Pixeldomain (talk) 05:08, 4 April 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment this seems very IBM-specific but the name is too generic. Can you think of a better name for this? Unicode also uses the term "code page". Also it's not clear to me how this specific property would be useful - do we really have many "code page" items in wikidata this would apply to? ArthurPSmith (talk) 19:45, 4 April 2017 (UTC)
Pictogram voting comment.svg Comment @ArthurPSmith: The only way I can think of making this property name more specific would be to add "IBM" in front of it as the issuer of these identifiers. Code pages are widely referred to in the field of computing (mostly historical now that Unicode has taken off) and IBM has long been a default "standards body" for code pages/character sets in early computing (pre Unicode) along with ISO to formalise standards. Unicode uses slightly different terminology, i.e. Unicode coded character set > Unicode plane (Q10853148) > Unicode block (Q3512806) > code point (Q1105784). I would argue that Unicode block (Q3512806) and code page (Q184766) are the same thing (IBM treats it as such with their CPGID and CPUID pair of identifiers), but there are separate Wikipedia articles at the moment. Is there an issue with creating properties with only a small (let's say 100) set of items that use the property? Pixeldomain (talk) 00:46, 5 April 2017 (UTC)
"Unicode blocks" and "code pages" are different concepts. A code page might contain characters from multiple Unicode blocks. Conversely, the vast majority of Unicode blocks don't have code page IDs assigned. Question about putting "IBM" in front – I'm not convinced that is right, because I know both Microsoft and IBM have the concept of "code pages" (which Microsoft picked up from IBM in the DOS and OS/2 days and still exists in contemporary Windows). And from my own brief research, it appears that Microsoft defines code pages which can't be found on IBM's list. SJK (talk) 14:34, 15 June 2017 (UTC)

Graphic character global identifier[edit]

   Under discussion
Description identifier of a character/grapheme
Represents graphic character global identifier (Q29146986)
Data type External identifier
Domain grapheme (Q2545446)
Allowed values regex: [A-Z]{2}\d+{6}
Example exclamation mark (Q166764) → SP020000
Source Graphic character identifiers
Planned use apply this property to characters/graphemes in Wikidata
Motivation

The Graphic Character Global Identifier (GCGID) is issued by IBM and uniquely identifies many characters/graphemes used in the past and present within computer and telecommunications systems. Pixeldomain (talk) 06:42, 4 April 2017 (UTC)

Discussion
  • @Pixeldomain: I think it would be good if the description goes into more detail and gives the user more information about the property. ChristianKl (talk) 16:04, 23 May 2017 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Azertus
Pintoch
Jsamwrites
Fractaler
Pictogram voting comment.svg Notified participants of WikiProject Informatics ChristianKl (talk) 16:04, 23 May 2017 (UTC)

Graphic character set global identifier[edit]

   Under discussion
Description identifier of a character set
Represents graphic character set global identifier (Q29147300)
Data type External identifier
Domain character set (Q29149925)
Allowed values regex: \d+{5}
Example GB 2312 (Q1421973)01081
Source Character set identifiers
Planned use apply this property to character sets within Wikidata
Formatter URL https://www-01.ibm.com/software/globalization/cs/cs$1.html
Motivation

The Graphic Character Set Global Identifier (GCSGID) is issued by IBM and uniquely identifies many character sets used in the past and present within computer and telecommunications systems. Pixeldomain (talk) 06:57, 4 April 2017 (UTC)

Discussion

Symbol support vote.svg Support. This looks like a useful identifier to include in Wikidata. I can imagine wanting to refer to these sets. YULdigitalpreservation (talk) 13:59, 18 April 2017 (UTC)

uniform resource identifier scheme[edit]

   Under discussion
Description identifier of a uniform resource identifier scheme as assigned by IANA
Represents class (Q5127848)
Data type External identifier
Domain set (Q36161) (any class which contains items which may be referenced by a URI scheme)
Allowed values regex: [a-z][a-z0-9+\-.]*
Example website (Q35127) → https, email address (Q1273217) → mailto
Source Uniform Resource Identifier (URI) Schemes
Motivation

Whilst there aren't many URI schemes currently registered, there are numerous other scheme identifiers used unofficially by software and common practice. URIs are extensively used (think http://, https://, mailto://, ssh:// and others) and it is therefore useful to record the formal structure of such schemes in Wikidata. Pixeldomain (talk) 01:29, 5 April 2017 (UTC)

Discussion
In principle this sounds like a good idea. In practice I'm not sure what most of the wikidata items would be for those schemes other than the most heavily used ones - for example for Andrew File System (Q504669), we have 'afs', but does a file system really define a protocol? And some of the others seem even less clear (what item would you link to "mailto"?). On the other hand, would it be helpful to apply the same property to URN namespaces, rather than add yet another property to cover those also? See this list (the identifier would then be urn:issn, for example for the issn namespace). ArthurPSmith (talk) 19:09, 5 April 2017 (UTC)
Pictogram voting comment.svg Comment @ArthurPSmith: My intention was that this property would be applied to classes of items which a URI is intended to reference, so for the "mailto" URI, property/value pair would be applied to email address (Q1273217) as this is the class of item intended to be referenced by a "mailto" URI. I see the confusion with my original proposal, as I had a bad example for the "http" scheme. This is now fixed. I can see how a "URI" property proposal (not "URI scheme") could also be created, with existing properties official website (P856) and e-mail (P968) (amongst others) becoming children of the new "URI" property. This "URI" property could be applied to any item in Wikidata for which a URI exists that references it. An existing example of a related property which already uses this approach is ITU/ISO/IEC object identifier (P3743). Pixeldomain (talk) 02:34, 12 April 2017 (UTC)
Well, ok, that makes sense for mailto and http/https. But then what about ssh, what are you representing there? Remote shell operations? ftp? afs as I mentioned - files? ipp - representing a printer? ldap representing a directory?? I think it would be helpful to work out the mapping you are thinking of here for a dozen or so examples to be sure this makes sense. ArthurPSmith (talk) 12:30, 12 April 2017 (UTC)

AUR package[edit]

   Under discussion
Description Indicates the official name of the package on the Arch's User Repository
Data type External identifier
Example dislines (Q29566755) → dislines
Source https://aur.archlinux.org/
Planned use Que esté asignada a los paquetes de software que apliquen
Formatter URL https://aur.archlinux.org/packages/$1/
Robot and gadget jobs
See also Arch package (P3454)
Motivation

There is a property for the Arch's official packages. But exists a second repository where the users can upload their own packages: the AUR. Giovanni Alfredo Garciliano Diaz (talk) 01:58, 26 April 2017 (UTC)

Discussion

CPUID code[edit]

   Under discussion
Description CPUID identification code
Data type String
Template parameter "cpuid" in en:template:Infobox CPU
Allowed values hexadecimal string
Example Core i7-6700 (Q28739510) → 506E3 (see http://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=57560)
Motivation

CPUID code to identify a specific CPU microarchitecture. List of these codes can be found here : http://www.cpu-world.com/cgi-bin/CPUID.pl. Maybe other codes can be created too for family, model and stepping (in decimal) Mikayé (talk) 14:46, 10 February 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment - no formatter URL to link directly to these values? ArthurPSmith (talk) 16:46, 10 February 2017 (UTC)
  • Symbol support vote.svg Support. I took the liberty of adding the formatter URL. --Swpb (talk) 16:37, 15 February 2017 (UTC)
    • @Swpb, Mikayé: That formatter URL does NOT work with the supplied example of 506E3 - it gives an invalid CPU ID error. ArthurPSmith (talk) 20:02, 16 February 2017 (UTC)
    • The formatter is not good. The value should be the value returned by the cpuid instruction, not the id on cpu-world website. I gave the website as an example of source to obtain the value for a specific CPU. I think Swpb made a confusion between the two cpuid. Maybe the cpu-world id can be another property but that's another story... I removed the formatter. Mikayé (talk) 10:27, 17 February 2017 (UTC)
  • Symbol support vote.svg Support. This looks very useful to me. YULdigitalpreservation (talk) 14:50, 16 February 2017 (UTC)
  • I would like the description to contain more information about what the item is about, so that people who don't already know the abbrivation have an ID of what it's about by reading it. @Mikayé: ChristianKl (talk) 10:45, 20 February 2017 (UTC)
  • BA candidate.svg Weak oppose Intel documentation for how this code should be formatted for Intel processors is provided in figure 3-6 on page 3-204 of Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 2A. AMD documentation is provided at the top of page 11 of AMD CPUID Specification. This proposal concerns me a little bit because it is actually an accumulation of multiple identifiers. I assume this accumulation is meant to be a mixture of Base Family (4 bits), Base Model (4 bits), Extended Family (8 bits), Extended Model (8 bits), but this proposal does not make it clear how these identifiers are to be arranged together. I propose an alternative approach which is to create 4 distinct properties for CPUID Base Family, CPUID Base Model, CPUID Extended Family and CPUID Extended Model. You may also want to investigate whether a CPUID Stepping (4 bits) property could be useful as well to capture revisions/manufacturing variants of each CPU. Dhx1 (talk) 14:06, 22 March 2017 (UTC)
  • Pictogram voting comment.svg Comment We need to be clear that the "CPUID code" being talked about here is part of the x86 / x86-64 CPU architecture, and so doesn't exist on CPUs of other architectures such as ARM, SPARC, POWER, MIPS, etc. (Those other CPU architectures may in some cases have similar facilities, but they probably won't be called "CPUID" and will likely have a different format.) So, I think the property proposal should be amended to clarify that this property is only for x86/x86-64 CPUs. Maybe change the label to "x86 CPUID code" or something like that to make it clear. SJK (talk) 22:20, 1 April 2017 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Azertus
Pintoch
Jsamwrites
Fractaler
Pictogram voting comment.svg Notified participants of WikiProject Informatics ChristianKl (talk) 13:09, 24 May 2017 (UTC)

Geology[edit]

Please visit Wikidata:WikiProject Geology for more information.

Geography[edit]

Irish Grid Reference[edit]

Description grid location reference from the Irish Grid reference system used in Ireland
Represents Irish grid reference system (Q1672843)
Data type External identifier
Template parameter Irish Grid Reference
Domain Places on the island of Ireland
Allowed values [A-Z]{0,1}[0-9]{4,10}
Example Kilbeggan (Q68364)N330357
Source Ordnance Survey Ireland maps are the original sources
Formatter URL https://tools.wmflabs.org/os/coor_g/?params=$1_region%3AIE_scale%3A25000
See also OS grid reference (P613)
Motivation

This property is similar to OS grid reference (P613) except for covering the island of Ireland rather than the UK. Teester (talk) 23:25, 23 March 2017 (UTC)

Discussion
  • Wikidata descriptions are plain text and thus don't support links like the one in this description. ChristianKl (talk) 07:56, 26 March 2017 (UTC)
  • I have adjusted the description to remove the link. Teester (talk) 10:14, 26 March 2017 (UTC)

Maths[edit]

Please visit Wikidata:WikiProject Mathematics for more information. To notify participants use {{Ping project|Mathematics}}

nLab ID[edit]

   Under discussion
Description name of a page in nLab
Represents NLab (Q6954693)
Data type External identifier
Template parameter w:Template:Nlab
Domain topic in maths
Allowed values [a-zA-Z0-9\+]+ (case sensitive)
Example category of sets (Q2518298)Set
External links Use in sister projects: [de][en][es][fr][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][Wd][Ws].
Formatter URL https://ncatlab.org/nlab/show/$1
Robot and gadget jobs Yes
Motivation

See usage GZWDer (talk) 16:29, 25 June 2017 (UTC)

Discussion

All sciences[edit]

WIGOS station ID[edit]

   Under discussion
Description identifier of a meteorological station, in the WIGOS database
Represents WIGOS identifier (Q28686426)
Data type External identifier
Domain weather station (Q190107)
Allowed values int\.wmo\.wigos-([0-9]|1[0-4])-(([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-4])-){2}-[0-9A-Z]{1,16}(-[0-9A-Z]+)?
(refer to Manual on the WMO Integrated Global Observing System (Q28686657) page 106 for further information)
Example Blue Hill Meteorological Observatory (Q1803017) → int.wmo.wigos-0-20000-0-74492
Source
Planned use Insert weather station items into Wikidata to allow external climate databases to be queried for climate data, adding further information to a Wikidata query. This can be useful for automatically generating climate data for a city by finding the nearest weather station, then fetching external climate data for that closest weather station.
Robot and gadget jobs Almost all weather stations from Legacy format station report (in use until 2018) can likely be imported automatically in bulk, as there are currently ~50 weather station items listed in Wikidata.
Motivation

The WIGOS identifier is used by the WMO and other meteorological organisations to uniquely identify weather stations around the world. By creating a new Wikidata item for each weather station around the world, it becomes possible to query Wikidata for the weather station(s) closest to a particular city, obtain the WIGOS identifier(s) and then query external climate information databases to obtain real time, near real time and/or historical climate data recorded by the particular station. Dhx1 (talk) 14:19, 6 February 2017 (UTC)

Discussion
  • Symbol support vote.svg Support This sounds useful. The idea is to have an item for every weather station in the world? Do we have some of these in wikidata now? ArthurPSmith (talk) 17:00, 6 February 2017 (UTC)
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:15, 6 February 2017 (UTC)
  • Is there a reason not to name this property "WIGOS weather station ID"? ChristianKl (talk) 08:50, 9 March 2017 (UTC)
  • Symbol support vote.svg Support. This looks like a useful external id to me.YULdigitalpreservation (talk) 16:09, 10 March 2017 (UTC)
  • Pictogram voting comment.svg Comment @ChristianKl: Changed to "WIGOS ID" as suggested. I overlooked your comment when previously marking as ready, sorry. Dhx1 (talk) 22:00, 27 March 2017 (UTC)
    • @Dhx1: Actually my suggestion was also to reference the domain in the name, is there a reason not to do so? ChristianKl (talk) 07:43, 28 March 2017 (UTC)
    • I renamed the property to WIGOS station ID. If you are happy with that, set it to ready. ChristianKl (talk) 11:19, 25 May 2017 (UTC)

Jamanetwork ID[edit]

   Under discussion
Description The ID of an scientific article on jamanetwork
Data type External identifier
Domain scientific articles
Example Experimental specific memory reaction to cornea, lens, and retina antigens. (Q30111633) -> 631770
Planned use Identifier, source
Formatter URL http://jamanetwork.com/journals/jamaophthalmology/article-abstract/$1
Robot and gadget jobs Bots can import from website if item name in English matches name on Jamanetwork, or if doi matches.
Motivation

I did a google search on an article and found this website. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 19:03, 3 June 2017 (UTC)

Discussion
@PokestarFan: Can you tell us a bit more about what jamanetwork happens to be? ChristianKl (talk) 18:38, 4 June 2017 (UTC)
See en:List of American Medical Association journals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 4 June 2017 (UTC)
So not Jamanetwork ID but Jamanetwork-JAMA Ophthalmology ID. Strakhov (talk) 22:22, 4 June 2017 (UTC)
Part of the problem is that JAMA Ophthalmology (Q4787301) has incorrectly conflated JAMA Ophthalmology with the earlier Archives of Ophthalmology which it continued. See [7]. Not sure how to deconflate them now. LeadSongDog (talk) 19:20, 7 June 2017 (UTC)