`Shortcut: WD:PP/SCI`

# Wikidata:Property proposal/Natural science

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties. Check if the property was previously proposed or is on the pending list. 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. Select the right datatype for the property. Start writing the documentation based on the preload form below and add it in the appropriate section. Creating the property Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. Creation can be done 1 week after the proposal, by a property creator or an administrator. 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 2018/11.

## Physics/astronomy

### proper name of astronomical object

Under discussion
Description The astronomical object has a proper name Category:Exoplanets with proper names (Q26206374) list of proper names of stars (Q1433418) Monolingual text astronomical body (Q6999) 55 Cancri b (Q50665) → Galileo (en) 42 Draconis b (Q849267) → Orbitar (en) Mintaka (Q680341) → Mintaka (en) eventually complete (Q21873974) for the near future

#### Motivation

Stars and Exoplanets usually have only catalog code (P528). But some also have proper names. Right now, there is no way to query for those. so why don't we add the proper name as a separate property? Shisma (talk) 21:07, 18 November 2018 (UTC)

## Biology

### CETAF specimen ID

Under discussion
Description persistent identifier URL for a taxonomic specimen, compliant with the Consortium of European Taxonomic Facilities Stable Identifier Initiative URL taxon type specimens (+other notable specimens, if any) item for the type specimen of Cinnamomum bejolghota (Q2972821) → http://herbarium.bgbm.org/object/B100277113 item for the type specimen of Harpagoxenus sublaevis (Q309349) → http://id.luomus.fi/GL.749 item for the type specimen of Carabus lusitanicus brevis (Q5037464) → https://science.mnhn.fr/institution/mnhn/collection/ec/item/ec32 Consortium of European Taxonomic Facilities (Q5163385) many thousands, eventually millions eventually complete

#### Motivation

the Consortium of European Taxonomic Facilities has created a system of persistent identifiers for type specimens (https://cetaf.org/cetaf-stable-identifiers). The intension is that the URI to the specimen will remain stable indefinitely, so we can link to type specimens without fear that the link will break.

The CETAF initiative creates "a joint Linked Open Data (LOD) compliant identifier system". The particpating institutions include the Royal Botanic Garden of Edinburgh, the Museum für Naturkunde, Berlin, The Natural History Museum, London, the Royal Botanic Gardens, Kew and the Royal Museum for Central Africa. Additional information can be found at the CETAF Stable Identifier Initiative Wiki.

AIUI, the intention is that data about type specimens should be stored on an item about the specimen, not the item about the taxon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 24 June 2018 (UTC)

Notified participants of WikiProject Biology -- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 24 June 2018 (UTC)

#### Discussion

SupportTom.Reding (talk) 13:55, 24 June 2018 (UTC)

•  Oppose - better to use links to the actual specimen in the holding museum, not a third party. Most holding museums are major organisations with stable websites. This is adding an extra step for mistakes. Cheers Scott Thomson (Faendalimas) talk 17:46, 24 June 2018 (UTC)
• CETAF IDs are in fact exactly what you advocate i.e. links to the specimens in the holding museum not a third party. CETAF is acting more as a standardisation body to get the museums to produce URLs with similar behaviours - basically Linked Data URIs with some agreed metadata attached. RogerHyam (talk) 15:12, 25 June 2018 (UTC)
• No they are not, they are an unreviewed third party and this is problematic in nomenclature which requires serious review and checking prior to publication, ie peer review. Cheers Scott Thomson (Faendalimas) talk 15:33, 26 June 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

@Faendalimas: The three examples given above are:

For each of those three cases, please tell us which "third party" is being linked to? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:47, 26 June 2018 (UTC)

I did not say linked to, I said obtained from, and that it is a non reviewed assessment hence unchecked by scientific rigor. In anycase the first one has a second url on the page which is the museum whether its the correct specimen I do not know, the second is possibly linking to the correct specimen without evidence to show its correct, the third is a dead link for me so I cannot tell what its supposed to do. Cheers Scott Thomson (Faendalimas) talk 03:07, 27 June 2018 (UTC)
@Faendalimas: What you said was "better to use links to the actual specimen in the holding museum, not a third party". Furthermore, when told "CETAF IDs are in fact exactly what you advocate i.e. links to the specimens in the holding museum... CETAF is acting more as a standardisation body to get the museums to produce URLs with similar behaviours - basically Linked Data URIs with some agreed metadata attached.", you replied "No they are not". [I've fixed the third link, in my comment; it was always correct in the proposal template.] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:26, 27 June 2018 (UTC)
I do not have an issue with the links. Its the authority of the information. I meant not "from" a third party. (If you copy and pasted my previous statement, I did not look, I must have left that word out, apologies for that). As in not obtaining the information from a third party. Rather than from the source. What I am getting at is that the information needs to be peer reviewed which online resources are not. I did figure there was a mistake in the url above I assumed you would fix it. Cheers Scott Thomson (Faendalimas) talk 15:16, 27 June 2018 (UTC)

Comment I think this proposal needs some thorough investigations. According to CETAF Stable Identifiers the following 15 CETAF institutions implemented this kind

So how could we restrict this URI to this institutions. Most of the URIs will not represent a type specimen (Q51255340). How to use this URIs here? Next week I will try to have a closer look to the 5,5 million URIs provided by the Muséum national d'histoire naturelle. --Succu (talk) 17:59, 24 June 2018 (UTC)

In the current MNHN dataset of ca. 5.5 million specimens 107,867 have a "typeStatus": type (Q3707858) = 27,277; syntype (Q719822) = 18,148; holotype (Q1061403) = 14,454; isosyntype (Q55195195) = 2,798; lectotype (Q2439719) = 2,521. --Succu (talk) 16:30, 25 June 2018 (UTC)
Some problems with the current MNHN dataset I observed:
The dataset contains holotypes for family names
The dataset has multiple holotypes for a taxon, e.g. Cyathea rouhaniana (Q17037631) = P00411818 to P00411823
The dataset uses "decimalLatitude" and "decimalLongitude" without "coordinatePrecision". "verbatimCoordinates" or "verbatimLatitude" and "verbatimLongitude" are not given. --Succu (talk) 08:08, 26 June 2018 (UTC)
--Succu (talk) 18:05, 25 June 2018 (UTC)

Support Excited by this. Would be willing to help with automated populating property. --RogerHyam (talk) 15:22, 25 June 2018 (UTC)

Hi Roger, nice to see you here. If I understand the proposal right, it involves the creation of items to get taxonomic type (P427) working. So we need to define how to map the metadata values to our properties. I created P01069419 (Q55196248), P01069417 (Q55197790) and holotype of Ouratea sipaliwiniensis (Q55200035) as a base for discussions. --Succu (talk) 18:53, 25 June 2018 (UTC)
I'd rather not get into recreating nomenclature. It is a intellectual exercise akin to the jigsaw puzzle in Laura & Hardy "Me and My Pal" (YouTube) - We will be at each others throats and the biodiversity of the world destroyed before we finish the task. Really a type relationship has to include literature and a lot of complexity that is of use to a small specialist audience and just confuses everyone else. If someone wants to know the type of a taxon they can read the literature in the Taxon Name (Property:P225).
It appears Wikidata is building a single consensus taxonomy. If we had a single property that was "has Voucher Specimen" or similar then we could add properties to taxa based on the identifications by experts in museums. e.g. Q557928 "has Voucher Specimen" http://data.rbge.org.uk/herb/E00590786 would be possible. Perhaps I should be proposing a different property but I'm new to the wikidata thing. RogerHyam (talk) 10:18, 26 June 2018 (UTC)
Wikidata is not building a single consensus taxonomy. The contrary is true. A lot of users have difficulties to accept this. ;) --Succu (talk) 17:48, 26 June 2018 (UTC)
Hi Succu. Could you give an examples of multiple taxa (taxon concepts) with the same full scientific name in Wikidata. I'm a bit ignorant on this and need to understand how it is being represented. RogerHyam (talk) 08:15, 27 June 2018 (UTC)
E.g. we implemented APG I to IV. See the references for parent taxon (P171) at Cactaceae (Q14560): Maybe this is not exactly what you expected. Please note note this discussion too. --Succu (talk) 17:43, 27 June 2018 (UTC)

Comment I'm not sure that the name of the property is good. It may be better to have it as "Museum Specimen ID" or "Voucher Specimen ID" and then have a recommendation that these are CETAF compliant URIs. This way we can have stable links to many specimens that have been determined to belong to a taxon by experts and, if people are good with their data markup, most of these will be expandable into images and geolocations etc. RogerHyam (talk) 15:21, 25 June 2018 (UTC)

•  Support David (talk) 15:25, 25 June 2018 (UTC)

Comment that this is already so confused shows why this is not a good idea in concept. You cannot call the type specimen a voucher specimen or a museum specimen per se. Yes a type is both of those but so are many other specimens. The type is a special case of a voucher or museum specimen as it is the only specimen that the available name of a taxon is attached to. No other specimen has this. It is the specimen upon which the name is established. It has major import. I agree it is only of major interest to a specialist minority, ie taxonomists mostly, but you cannot undervalue it, nor have it proposed in a way that any museum specimen or voucher could be called this. Only the original description or a peer reviewed taxonomic review should be used as the reference of the type specimen. As such they should be listed with reference to these articles and only this way. Then there is a clear reference. Online resources are not reviewed as such and are not reliable when it comes to types. This will introduce potential error in this area of nomenclature that is extremely exacting. Cheers Scott Thomson (Faendalimas) talk 15:18, 26 June 2018 (UTC)

I agree. I created P01069419 (Q55196248) from the details given in Novitates neocaledonicae V: Eugenia plurinervia N. Snow, Munzinger & Callm. (Myrtaceae), a new threatened species with distinct leaves (Q55196032) ("Typus: New Caledonia. Prov. Nord: Ouazangou-Taom, Onajiele, 165 m, 20°46’43’’S 164°27’59’’E, 20.III.2016, Munzinger (leg. Scopetra) 7530 (holo- : P [P01069419]! ; iso- : G [G00341659]!, MO!, MPU [MPU310532]!, NOU [NOU054468]!, NSW!, P [P01069420]!)"). The applied changes by Mr. Mabbett now give the impression the data are taken form the MNHN record. --Succu (talk) 17:41, 26 June 2018 (UTC)
If you don't give references when you make claims, don't complain when someone else adds a valid citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:40, 26 June 2018 (UTC)
The item was created to discuss mappings (= data model). If you had checked your reference you should have noticed some differences. --Succu (talk) 18:45, 26 June 2018 (UTC)
The item was created without citations. I added them. If you think I acted improperly, you know where the admin noticeboard is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:48, 26 June 2018 (UTC)
I corrected my omission. --Succu (talk) 20:03, 26 June 2018 (UTC)
But it was reverted with the comment o restore coordinates, as previsouly?! --Succu (talk) 20:15, 26 June 2018 (UTC)
No; it was reverted with the comment "to restore coordinates, as previously"; and that was because, as well as your declared reason for editing, you also - yet again - re-added coordinates saying that the object is in New Caledonia, on the opposite side of the planet to its actual current location. Hence Wikidata:Project_chat#Coordinates_of_objects_in_museums. None of which, of course, has anything to do with the proposal at hand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:51, 26 June 2018 (UTC)
You proposed this change. Im OK with this. --Succu (talk) 21:34, 26 June 2018 (UTC)

You are moving a bit fast for me to keep up, so please forgive my request for clarifications. Also, please forgive my lack is wiki etiquet if this is the wrong place for these comments.

It would be fantastic to load up all our typification information from the Meise Botanic Garden to Wikidata, but can you point me to a place that describes how?
In this property proposal there are no authority names. This is essential due to homonyms, but where possible they should be linked to people somewhere. However, does this cause problems when linking these data to other Latin names in Wikis that don't use authorities?
I’m sure there are errors in the data, such as there being two holotypes, fixing these is a motivation to expose the data. Does this work for you?
There also needs to be a field that tells you what sort of type it is holo-, lecto, iso, para, neo, etc. Do you want a full list?
The National Botanic Garden of Belgium changed its name a while ago, can I just edited this wikidata entry?

Qgroom (talk) 04:45, 27 June 2018 (UTC)

I wish there was an easy answer to this. I would love to see a proposal that actually did types the way they should be, with all the appropriate metadata included, utilising the correct terminology as accepted in the science and discipline of taxonomy and nomenclature. Alas we do not get this we get rather hit and miss efforts. If someone wants to try and create a property with all the needed attributes, obtaining data from reliable resources I would be happy to help. The same types of properties I create already in museum databases as a museum curator. The same ones I already use as highly published taxonomist and a nomenclatural specialist. You want us to use this material at Wikispecies Andy?? then do it right. I would support this if it was done correctly Andy. Cheers Scott Thomson (Faendalimas) talk 04:56, 27 June 2018 (UTC)
I think there are a few people in the CETAF community who could help get this right. Though personally I find it difficult to discuss these things in a chat page and I'm not sure how decisions are made here. Nevertheless, I'd really like to make this happen. Qgroom (talk) 06:11, 27 June 2018 (UTC)
"I would love to see a proposal that actually did types the way they should be, with all the appropriate metadata included" Then you are in the wrong place. This is a proposal to create a property to hold one type of identifier-URL. The only arguments you have presented about it are either easily refuted (see "third party links" discussion, above. or are merely vague hand -waving and appeals to authority, with no substance. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:34, 27 June 2018 (UTC)
My comment here was a generalized one only brought up in reference to the above comment. Its not a direct reference to the proposal here at hand. So yes I know this is not the right place. I think the whole structure of how types are presented is inadequate. My point was that unfortunately many proposals are attempts to gather information from online resources for ease of mass import with no respect to the exacting nature of taxonomic data and metadata permitting potential mistakes. These online resources are not authorities on the taxonomy of species. What is the point of data if there is no evidence inherit that demonstrates it has been tested for accuracy. For taxonomic data I want to see us produce useful information not page upon page of unreliable rubbish. Your difficulty Andy is you do not use this information. You are presenting it, but not using it. Much of the informatics being presented, not necessarily by you I am generalizing now, has no guarantee, therefore it has no use in taxonomy. So what is it then except page upon page of what exactly? Cheers Scott Thomson (Faendalimas) talk 15:30, 27 June 2018 (UTC)
@Qgroom: for "a field that tells you what sort of type it is", please see P01069419 (Q55196248); but note also the issues with that data model, which I have raised here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:34, 27 June 2018 (UTC)
I think I get it. So in your example P01069419 (Q55196248) you would replace the URL (P2699) with this proposed CETAF specimen ID property.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 15:29, 27 June 2018‎ (UTC).
@Qgroom: Precisely. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 27 June 2018 (UTC)
Could you please explain why this substitution is useful? What we (=Wikidata) gain from this change? --Succu (talk) 20:45, 27 June 2018 (UTC)
I suppose the question is why we need a subcategory of URL that is specific to CETAF specimen ID. Well from my point of view, which is quite ignorant of the workings of Wikidata, having the distinction is useful because the CETAF specimen ID points to a great level of stability and functionality than a standard URL. I'm not certain this is entirely necessary, however, it is particularly useful to have one URI that uniquely represents the digital representation of the physical specimen. People could link to many different image files or website all representing that specimen. These might be labelled in all sorts of ways and be derived from all sorts of places. Yet it is much better that there is only one standard way to refer to the physical specimen. Qgroom (talk) 13:51, 29 June 2018 (UTC)

Oppose per Scott. --Succu (talk) 21:56, 12 October 2018 (UTC)

### Properties for nomenclatural types

#### Name-bearing type

Under discussion
Description The name/identifier for this species' type type (Q3707858) String taxa Solanum ivohibe (Q2298270) → Reserves Naturelles 3516 (P00349043) Solanum africanum (Q17400483) → (1) Dillenius, Hort. Eltham. 2:365, t. 273, f. 352. 1732 → (2) s.c. s.n. (Dill-HE 273-352) always incomplete (Q21873886) taxonomic type (P427)

#### Nature of type

Under discussion
Description Identify which subcategory of type this species has, only as subproperty type (Q3707858) Item item holotype (Q1061403), lectotype (Q2439719), neotype (Q19353453), epitype (Q55195035) (i believe a few extra terms are in use in zoology, but I am not familiar with them) Solanum africanum (Q17400483) → Dillenius, Hort. Eltham. 2:365, t. 273, f. 352. 1732 → lectotype (Q2439719), s.c. s.n. (Dill-HE 273-352) → epitype (Q55195035) always incomplete (Q21873886)

#### Motivation

These two properties allow for the entry of data about type specimens for species and infraspecific taxa (subspecies, varieties etc.), which is actually more crucial to defining taxa than any other data we currently have. All other elements that "Name-bearing type" would need can be handled in a straightforward manner with existing properties:

Also note that the proposed CETAF id above could make use of Nature of type for describing what the specimen is (the proposal currently doesn't include an actual way to do that).

Circeus (talk) 20:43, 7 October 2018 (UTC)

#### Discussion

• I think it would be helpful if the labels indicated that these properties are for species. Yair rand (talk) 19:01, 9 October 2018 (UTC)
• Actually types apply to all ranks (at least in 'botany'), not just species.  – The preceding unsigned comment was added by Brya (talk • contribs) at 10:51, 13 October 2018‎ (UTC).
•  Oppose We have taxonomic type (P427). --Succu (talk) 21:38, 12 October 2018 (UTC) PS: An new qualifier designated by (LT) is probably more valuable. --Succu (talk) 22:13, 12 October 2018 (UTC)
• Taxonomic type is explicitly intended for type species/genus and are of a different data type. You literally cannot assign a type with taxonomic type (P427) without creating an item for the individual specimen first. That is hardly a practical approach. If you want to expand a property, expand taxon author (P405) to handle all types of nomenclatural acts, as I explicitly suggested above. Circeus (talk) 00:26, 13 October 2018 (UTC)
• So what? This project tries to provide structure data, not plain strings. Structured authorship and references to nomenclatural acts (ICZN) are working well, but are needing a lot more of knowledgeble contributers. --Succu (talk) 22:02, 13 October 2018 (UTC)
•  Comment These are two separate proposed properties, and it would be better to have two separate discussions.
1. the first touches on the perennial question if it is handy to have two separate properties (one with datatype string, and one with datatype item) for the same feature. This would also be handy for synonyms (not all synonyms are notable). I guess a string property for nomenclatural types may work, but it could also cause problems, depending on how it is used. Separate items are safer, but a lot more work. I guess I could be talked into either approach (and in the long run either approach may prove to be wrong). - Brya (talk) 10:50, 13 October 2018 (UTC)
2. the second would probably be useful, but if Wikidata has separate items for types, this had best be a statement, and if Wikidata allows strings for types, it needs to be a qualifier.
3. a property for "designated by" (LT, NT, EP) may be useful also. - Brya (talk) 10:56, 13 October 2018 (UTC)

### Virtual Guide to the Flora of Mongolia ID

Description identifier for a species on the Virtual Guide to the Flora of Mongolia website Virtual Guide to the Flora of Mongolia (Q58430446) External identifier taxon (Q16521) [1-9]\d* Amaranthus retroflexus (Q157663) → 1560 Primula algida (Q10954984) → 503 Sibbaldianthe adpressa (Q17235150) → 552 https://floragreif.uni-greifswald.de/taxon/?flora_search=Taxon&action=species Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 1994 Template:Taxonbar (Q22741012) 303 https://floragreif.uni-greifswald.de/taxon/?taxon_id=\$1 Mongolia (Q711)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of botany (Q441). Thierry Caro (talk) 15:54, 10 November 2018 (UTC)

Discussion

Notified participants of WikiProject Taxonomy. Thierry Caro (talk) 15:54, 10 November 2018 (UTC)

@ديفيد عادل وهبة خليل 2, MargaretRDonald, Thierry Caro, Pigsonthewing:  Done: Virtual Guide to the Flora of Mongolia ID (P6139). − Pintoch (talk) 09:30, 17 November 2018 (UTC)

### Verspreidingsatlas.nl ID

Description identifier for a species on the verspreidingsatlas.nl website Netherlands species distributions (Q58466085) External identifier `|1=` in nl:Sjabloon:Link verspreidingsatlas.nl (no label (Q58466591)) taxon (Q16521) [A-Z]?\[0-9]?\d+ Riccia cavernosa (Q17263620) → 3464 muskrat (Q26283) → 8496181 Auriculinella bidentata (Q3237092) → S62900 Hemipholiota heteroclita (Q52382897) → 0109270 https://www.verspreidingsatlas.nl/ Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 19882 https://www.verspreidingsatlas.nl/\$1 Netherlands (Q55)

#### Motivation

Verspreidingsatlas.nl is a website presenting distribution maps and some more data on species. Data are from the database Netherlands Flora and Flora National databank (Q2507556). Used at nlwiki, especially at items on plants. Lymantria (talk) 21:26, 11 November 2018 (UTC)

#### Discussion

Notified participants of WikiProject Biology.

Notified participants of WikiProject Taxonomy.

### Atlas of Florida Plants ID

Under discussion
Description identifier for a species on the Atlas of Florida Plants website no label (Q58759647) External identifier taxon (Q16521) [1-9]\d* Euphorbia dentata (Q978763) → 354 Rhynchospora marliniana (Q58759343) → 4378 Zoysia japonica (Q15227563) → 234 http://florida.plantatlas.usf.edu/Search.aspx Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 2001 Template:Taxonbar (Q22741012) 4803 http://florida.plantatlas.usf.edu/Plant.aspx?id=\$1 United States of America (Q30) Calflora ID (P3420), CNPS ID (P4194), Michigan Flora ID (P6103)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of the Flora of the United States (Q5460447). Thierry Caro (talk) 05:09, 16 November 2018 (UTC)

Discussion

Notified participants of WikiProject Taxonomy.

Notified participants of WikiProject United States. Thierry Caro (talk) 05:09, 16 November 2018 (UTC)

### NAS ID

Under discussion
Description identifier for a species in the Nonindigenous Aquatic Species database, on the U.S. Geological Survey website Nonindigenous Aquatic Species (Q58786227) External identifier taxon (Q16521) [1-9]\d* Santeetlah Dusky Salamander (Q1594865) → 155 Japanese rice fish (Q1142975) → 302 Sternotherus odoratus (Q674891) → 1269 https://nas.er.usgs.gov/queries/FactSheetList.aspx Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 2011 Template:Taxonbar (Q22741012) 1335 https://nas.er.usgs.gov/queries/FactSheet.aspx?speciesID=\$1 United States of America (Q30) GT IBMA ID (P6054)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of the Environment of the United States (Q3055453). Thierry Caro (talk) 12:48, 16 November 2018 (UTC)

Discussion

Notified participants of WikiProject Invasive Species. Thierry Caro (talk) 13:04, 16 November 2018 (UTC)

Notified participants of WikiProject United States. Thierry Caro (talk) 12:48, 16 November 2018 (UTC)

### Invasive Plant Atlas of the United States ID

Under discussion
Description identifier for a species on the Invasive Plant Atlas of the United States website Invasive Plant Atlas of the United States (Q58786944) External identifier taxon (Q16521) [1-9]\d* Cabomba caroliniana (Q786072) → 5223 Robinia hispida (Q894236) → 11577 Rorippa austriaca (Q305979) → 6323 https://www.invasiveplantatlas.org/distribution.html Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 2006 Template:Taxonbar (Q22741012) 1540 https://www.invasiveplantatlas.org/subject.html?sub=\$1 United States of America (Q30)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of the Flora of the United States (Q5460447). Thierry Caro (talk) 13:02, 16 November 2018 (UTC)

Discussion

Notified participants of WikiProject United States. Thierry Caro (talk) 13:02, 16 November 2018 (UTC)

•  Support David (talk) 07:45, 17 November 2018 (UTC)

### EUNIS ID

Under discussion
Description identifier for a species on the European Nature Information System website European Nature Information System (Q374924) External identifier taxon (Q16521) [1-9]\d* Long-legged Buzzard (Q233684) → 928 Salix alba (Q156918) → 182638 Ursus arctos (Q36341) → 1568 https://eunis.eea.europa.eu/species.jsp Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. Template:Taxonbar (Q22741012) 278000 https://eunis.eea.europa.eu/species/\$1 Fauna Europaea ID (P1895), Common Database on Designated Areas ID (P4762)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of biodiversity in Europe (Q16532801). Thierry Caro (talk) 13:14, 17 November 2018 (UTC)

Discussion

Notified participants of WikiProject Taxonomy. Thierry Caro (talk) 13:14, 17 November 2018 (UTC)

Support. My bot can add the ids. --Succu (talk) 13:46, 17 November 2018 (UTC)

### Cal-IPC ID

Under discussion
Description identifier for a species on the California Invasive Plant Council website California Invasive Plant Council (Q58819364) External identifier taxon (Q16521) [1-9]\d* Ammophila arenaria (Q161568) → ammophila-arenaria Geranium dissectum (Q158413) → geranium-dissectum Leucanthemum vulgare (Q27164) → leucanthemum-vulgare https://www.cal-ipc.org/plants/profiles/ Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. 2007 Template:Taxonbar (Q22741012) 308 https://www.cal-ipc.org/plants/profile/\$1-profile/ United States of America (Q30)
Motivation

This new Wikidata property to identify taxa (Q42396390) would improve our coverage of the entries on the list of invasive plant species in California (Q17032347). Thierry Caro (talk) 14:35, 17 November 2018 (UTC)

Discussion

Notified participants of WikiProject Invasive Species. Thierry Caro (talk) 14:35, 17 November 2018 (UTC)

Notified participants of WikiProject United States. Thierry Caro (talk) 14:35, 17 November 2018 (UTC)

•  Support David (talk) 07:55, 18 November 2018 (UTC)

## Chemistry

### tautomer of

Under discussion
Description target item is a tautomer of this one tautomer (Q334640) Item chemical compound (Q11173) 1H-tetrazole (Q58826308) → 2H-tetrazole (Q58826418) 2H-tetrazole (Q58826418) → 1H-tetrazole (Q58826308) MISSING symmetric constraint (Q21510862) E.g. relation 'tautomer of' in ChEBI (Q902623) stereoisomer of (P3364)

#### Motivation

'Tautomer of' property would be used to link different tautomers like those given in the example above, but also zwitterions with its neutral forms, keto-enol tautomers, ring-chain tautomers (e.g. for sugars, we already have a few items about different forms of sugars depending on the chain/ring structure) etc. There were questions earlier in WikiProject whether we need/want items about tautomeric forms that are minor (less predominant), but this is IMO unavoidable as in various databases there are entries for different tautomers, not only one entry mixing both tautomeric forms into one (like in PubChem).
This property would be the next property for linking between compounds based on quite clear definition (we already have stereoisomer of (P3364), is a hydrated form of (P4770), monomer of (P4599), polymer of (P4600), conjugate acid (P4147), conjugate base (P4149)). Wostr (talk) 23:55, 17 November 2018 (UTC)

#### Discussion

•  Support David (talk) 07:43, 18 November 2018 (UTC)

## Computer science

### software version of

Under discussion
Description the subject item is a version of the object item software (Q7397) Item item software (Q7397) Firefox 4 (Q1950119) → Mozilla Firefox (Q698) software version identifier (P348)

#### Motivation

Inverse of software version identifier (P348). There are items that are software versions of other items. Currently, there isn't a property that links from the former to the latterMalore (talk) 14:57, 18 May 2018 (UTC)

#### Discussion

•  Support David (talk) 16:38, 18 May 2018 (UTC)
•  Support actually it's not an inverse of software version identifier (P348) since that is a string-valued property and can't have an inverse in wikidata. I think this is the better direction to have this anyway, so definitely I support this. ArthurPSmith (talk) 17:29, 18 May 2018 (UTC)

Notified participants of WikiProject InformaticsChristianKl❫ 15:09, 24 May 2018 (UTC)

We should be creating and using generic properties wherever possible, so as to avoid creating many 1000s of very specific properties. The concept of version is not limited to software, and we do already have based on (P144) and subclass of (P279) which can be used in many situations. Danrok (talk) 01:28, 29 May 2018 (UTC)
@Danrok: You could say the same about edition or translation of (P629), or a bunch of other properties that could be substituted by instance of (P31) and subclass of (P279).--Malore (talk) 16:57, 30 May 2018 (UTC)
• After thinking about it for long time, I  Oppose, since I see two problems here:
• It's to specific. "software version of" makes it usable to only software. If at all it should be "version of" since there are other things that are versioned too (Licenses, 3D-Models, technical Specifications, etc.) and there is a fluid transition. But I would like to have even more abstract properties and share them with other areas where different versions/editions/iterations of things exist, including editions of books. The reason is that the more specialized properties your have for each area the harder it's getting to write queries that (also) work in the border-areas and/or in the bigger picture. An example in this case would be technical specifications and standards which are in between of software and books, but are none of both. Should one then use "software version of" or has edition (P747) or yet another to be created property? When writing queries and would need to know and think of all these special cases, which doesn't work…
• It's semantically not fully correct in most cases – including the reference example: Firefox 4 (Q1950119)Mozilla Firefox (Q698). Firefox 4 is not one version of Firefox. It's a version series. Firefox 4.0.0, 4.0.1, etc. are versions of Firefox. This would be the issue basically always since we so far basically only have items about version-series not single versions. One could bypass this by renaming it, but that would make it uglier and lead to problems if/when we have items about singe versions. And in the end this increases the need for having a more general property.
I see the need to improve the ontology of software versions, but I'm against this property. Sorry! I'm thinking about writing down all the open questions & issues about software versioning (there are a lot!) and make a working group or a big RFC, but I sadly don't have the time right now. -- MichaelSchoenitzer (talk) 11:49, 8 June 2018 (UTC)
• In order to simplify the queries, we could make "software version of" and edition or translation of (P629) (and eventually other properties such as "specification version of") subproperties of "edition or version of".
"software version of" and edition or translation of (P629) should be separate properties because they have different qualifiers and the model that describes books - the FRBR model - is different from the software version one (in fact, there isn't a universal versioning model, but every software can adopt its own).
• Firefox 4 is a major version of Firefox, while as far as I know Firefox 4.0.0 and Firefox 4.0.1 are called releases. They are different type of versions, but they are both versions.
However, even if "software version of" wasn't the best solution, it's better than the current management of software version and I think it doesn't create problems if we want to change the model in future.--Malore (talk) 16:08, 8 June 2018 (UTC)
•  Oppose Use generic properties whenever possible. Many types of things are versions of something, this concept is not limited to software. Danrok (talk) 01:32, 29 May 2018 (UTC)
•  Oppose I think we would be better off expanding the scope of edition or translation of (P629) to include "or version". Is there a reason this wouldn't work? --99of9 (talk) 01:24, 1 June 2018 (UTC)
• @99of9: edition or translation of (P629) would no longer be the inverse of has edition (P747) - unless we change it into "edition or version" - and it would no longer be an instance of version, edition, or translation (Q3331189) - unless we change it into "version, edition, translation or version". Probably other things should be modified because these properties are thought for books, not for software. I think we can use similar structures in order to describe software and books, but not the same one--Malore (talk) 04:02, 1 June 2018 (UTC)
Ok, I've struck my opposition. --99of9 (talk) 12:26, 14 July 2018 (UTC)

## Geology

### areas affected

Under discussion
Description areas affected by a natural disaster Item "affected" in en:template:infobox earthquake geographic location (Q2221906) 1906 San Francisco earthquake (Q211386) → North Coast (Q2671326), Central Coast (Q2413435), San Francisco Bay Area (Q213205)

#### Motivation

Filling a template need. NMaia (talk) 12:47, 15 April 2018 (UTC)

#### Discussion

•  Oppose for now, per my concern above. --99of9 (talk) 06:55, 17 July 2018 (UTC)

## Mathematics

### Alexander–Briggs notation

Under discussion
Description common notation of abstract knots Alexander-Briggs notation (Q55960283) String knot (Q1188853) /[0-9]+[0-9]+<\/sub>/ unknot (Q1188344) → 01 trefoil knot (Q168620) → 31 three-twist knot (Q7797291) → 52 en:List of prime knots or http://katlas.math.toronto.edu/wiki/The_Rolfsen_Knot_Table

#### Motivation

It is a standard notation of abstract knots, see enwiki. It consists of a number and a subscript: maybe, there is a better way to fill it than with <sub>subscript</sub>? Wikisaurus (talk) 14:35, 4 August 2018 (UTC)

#### Discussion

•  Oppose It's not currently possible to store super/subscript markup in values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:45, 4 August 2018 (UTC)
• User:Pigsonthewing, as I understand, you oppose using <sub>-tag, not storing subscripts altogether. Is there a standard Wikidata way to store subscripts? If not, we can use underscore, like 5_1 instead of 51, as it is sometimes used in Alexander-Briggs notation. I would like to ask you to be more communitative and not just vote oppose without giving exact explanation, as it makes atmosphere on this site worse. Wikisaurus (talk) 10:38, 5 August 2018 (UTC)
• No, I do not "oppose using <sub>-tag"; I oppose this proposal because it is not possible to do so. That is why I wrote "It's not currently possible to store super/subscript markup in values", which is both "communitative" and an "exact explanation". Personally, I find that a false accusation "makes atmosphere on this site worse". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:49, 5 August 2018 (UTC)
• I think there is a miscommunication here. One question (a) is if it's currently possible to store subscripts in wikidata, the other question is (b) if the suggested property is significant. I think one could and should discuss these questions separately. --Physikerwelt (talk) 09:08, 6 August 2018 (UTC)
• Thank you for sharing your opinion. The former is not a "question", since we already know that it is not possible to store subscripts in Wikidata. Given that, it is perfectly reasonable to oppose a proposal which explicitly requires us to do so, without initiating a "separate discussion". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:04, 6 August 2018 (UTC)
• Dear @Pigsonthewing:, could you kindly explain me, what your mean by not possible. Technically - well, you can store sub-tag, you can use space or underscore as separator, you can use mathematical format. Semantically - well, in most cases formatted data is not stored semantically, just satisfying some regexp. By the rules - link, please. Accenting language error in the comments of other people not only is rude, but probably violates en:WP:CIV or how is it called here on Wikidata. Wikisaurus (talk) 11:09, 8 August 2018 (UTC)
•  Comment @Wikisaurus: You could just use characters from Superscripts and Subscripts (Q3513021) for the subscript values. Mahir256 (talk) 21:57, 4 August 2018 (UTC)
• User:Mahir256, I rather dislike these special characters, this UNICODE mechanism should be deprecated. For example, they exist only for numbers, not for letters. Moreover, they are indistinguishable from usual numbers on some devices, which makes 111 and 111 look the same. Wikisaurus (talk) 10:38, 5 August 2018 (UTC)
• If you switched the datatype to mathematical expression one could write (\d+)_((\d)|\{\d+\}) which would be rendered as ${\displaystyle 10_{3}}$ unfortunately mw:Extension:Math does not support knot rendering as on http://newweb.cecm.sfu.ca/cgi-bin/KnotPlot/KnotServer/kserver?ncomp=1&ncross=10&id=3 yet..--Physikerwelt (talk) 08:53, 6 August 2018 (UTC)
• @Wikisaurus: Yes, as Physikerwelt points out, we have a variant of the string datatype that DOES support TeX notation - see for example defining formula (P2534). ArthurPSmith (talk) 17:47, 6 August 2018 (UTC)
• If we store the values, I would want to store them in unicode and leave out any tags. 5₂ works better than 52. I  Support the property with unicode and  Oppose it otherwise. ChristianKl❫ 11:25, 25 August 2018 (UTC)

### Logically implies (necessary condition)

Under discussion
Description Necessary condition, i.e. logical consequence of a mathematical statement Logical consequence (Q374182), requirement (Q774228) Mathematical expression Maxwell's equations (Q51501) Mathematical theorems (or other mathematical laws e.g. from theoretical physics) Maxwell's equations (Q51501) =>(P?) Coulomb's law (Q83152) https://en.wikipedia.org/wiki/Logical_consequence connect physics theorems / axioms by logical relation to annotate constraints / necessary conditions should be allowed

#### Motivation

My vision is to enable creating a logically structured semantic network of mathematical theorems (starting with theoretical physics). This would allow researchers to quickly grasp the constraints of the formulae (Wikidata items) they are working on, the framework they are working in. A theorem / formula (Wikidata item) is falsified already if one of its necessary conditions turns out to be falsified. Thus it is vital to know them, in order to prevent mathematical researchers from wasting their time working on something that may be invalid.  – The preceding unsigned comment was added by PhilMINT (talk • contribs) at February 19, 2018‎ (UTC).

#### Discussion

•  Support @PhilMINT: This is an interesting proposal - unfortunate that it seems to have gotten lost. I believe the datatype should be item, not "formula" (your example follows that pattern). I don't particularly like the parenthetical label - you can add that as an alias. Perhaps to be clearer the main English label should be "logically implies"? ArthurPSmith (talk) 20:30, 13 September 2018 (UTC)
• Conditional  Support. I agree that the datatype should be item. I think this property could be useful, although I don't know how many interesting theorems imply other interesting theorems outright, rather than imply in the context of plausible background assumptions. The "source" will be different secondary and textbook sources depending on the relation claimed. "Domain" is another field that seems to be filled in incorrectly: the domain of this property should be something like mathematical object (Q246672) or proposition (Q108163): we need a clear decision on what the domain will be. MartinPoulter (talk) 10:10, 19 September 2018 (UTC)
•  Comment(s) I also included this in Wikidata:Property proposal/Natural science in the maths section. Interesting proposal. I’d propose to add qualifiers to add the necessary axiom and logic in which the implication is valid (eg. some implications are true under ZFC but fot in ZF, or true in first order logic but not in a substructural one). But this needs more development : Banach–Tarski paradox (Q737851) is a logical consequence of ZFC, ie. it is a theorem of ZFC. Specifically, commenting your example, if we consider Maxwell equation an axiomatic system, does not this simply state that Coulomb’s law are a theorem of the Maxwell theory in first order logic ? This is what a logician would tell. In that spirit, I’d complete the proposal with the following properties and/or qualifier that might be needed in a context of mathematical logic like the refinement around the different logics and axiom-set. Please feel free to discuss the best models for the different combinations. For example it might be better to create a « theorem of » property with a theory range « Coulomb's law theorem of Maxwell equation (in first order logic) » considering maxwell equation as a logical theory. author talk page 14:40, 3 October 2018 (UTC)

#### logic and axiom system

Under discussion
Description Necessary condition, i.e. logical consequence of a mathematical statement logical system (Q17488292)   -- or specifically the set of rule of inference (Q1068763) (resp. rule of inference (Q1068763) - the set of axiom or logical theory) Item qualifier of « implies » statement (the previous proposal), maybe useful elsewhere logical system (Q17488292)   (resp rule of inference (Q1068763) - the set of axiom or logical theory) theorem of search < ZFC set theory >logic search < Q4055684 > Something with a higher order logic theorem : Courcelle's theorem (Q5178114). What is the best way to model ? Something with a weaker logic : Markov's principle (Q3922074) that is true in a weaker logic than classical logic but is not obvious. What is the best way to model ? This article discusses the different axioms we can choose in an intuitionistic logic : http://math.fau.edu/lubarsky/Separating%20LLPO.pdf should be allowed
##### discussion

These properties or qualifiers are useful to model en:Deductive_system used to derive the theorems, but there may be terminology issues and different way to model this, so this is only a proposition starting point that needs to be discussed and amended. Taking into account the axiom and inference rules leads to the difficulty that complete logical systems includes the two and that items topic often implies the inference rules used. We already have some properties for logic like admissible in search to link inference rules to logic, for example, but it’s not enough obviously) author talk page 14:40, 3 October 2018 (UTC)

@MartinPoulter, ArthurPSmith, PhilMINT: Notified participants of WikiProject Mathematics author talk page 14:44, 3 October 2018 (UTC)

•  Comment I don't have any strong opinion on this. How many different logic/axiom systems are there? And aren't those two different things anyway? Maybe we already have a qualifier that can capture this appropriately? ArthurPSmith (talk) 18:51, 5 October 2018 (UTC)

## Base material

### heat treating

Under discussion
Description Industrial and metalworking processes used to alter the physical, and sometimes chemical, properties of a material. heat treating (Q1458918) Item This proprety request is part of the project of creating an infobox for materials. base material (Q214609) Items that are subclass of Heat treating. Like tempering (Q685487), annealing (Q187360), quenching (Q871335), Precipitation hardening (Q779974), Differential heat treatment (Q5275351), case hardening (Q1205902), Cryogenic treatment (Q5190530) and specific items like "T6" (normalized). Maybe long description items like "Quenching in water at 1080°C" that could be reused /or/ we need to add many more properties like "Quenching temperature". N690Co (Q3334175) : hardness (P5483) → 285 HB with Heat Treating → annealing (Q187360) [1] N690Co (Q3334175) : hardness (P5483) → 60 to 62 HRC with Heat Treating → quenching (Q871335) [2] N690Co (Q3334175) : hardness (P5483) → 58 to 60 HRC with Heat Treating → quenching (Q871335) and tempering (Q685487) [3] w:Heat treating Creating an infobox for materials

#### Motivation

This proprety request is part of the project of creating an infobox for materials. The work hardening is a necessary qualifier for mechanical propreties of materials : most of metals, some ceramics...

Important qualifier : most alloys items needs the heat trating to be specified for most properties. This is currently blocking the creation of several steels items.

-- Thibdx (talk) 16:02, 19 August 2018 (UTC)

#### Discussion

•  Support David (talk) 11:50, 22 July 2018 (UTC)

#### Discussion on heat treatments's qualifiers

The discussion on qualifiers is an important topic since most of alloys mechanical properties depends on the exact heat treatment used. Following the above discussion, a dedicated thread has been created on the qualifiers' materials project talk page.

Or did I misunderstand something? Wostr (talk) 00:13, 23 July 2018 (UTC)
It is like you said, and I realize it will not be the best...
The main difficulty is that these qualifier apply to the qualifier and not the initial proprety :
As far as I know Wikidata does not allow to add qualifiers on qualifiers. So that in my opinion we need new qualifiers ;
• Quenching temperature
• Tempering temperature
• Tempering duration
• ...
-- Thibdx (talk) 11:25, 23 July 2018 (UTC)
Yes, there is no such thing as qualifiers for qualifiers (it would be helpful in some situations though), but not necessarily we need new qualifiers. I think it will be quite clear with generic qualifiers (temperature (P2076)/duration (P2047)) if Wikidata usage instructions (P2559) and Wikidata property example (P1855) are present in 'Heat treating' property and proper uses of temperature (P2076)/duration (P2047) are described there (provided there won't be two temperature (P2076) added to one value). However, I'm not sure about fabrication method (P2079) – look at the constraints in this property, especially value type constraint (Q21510865) – you can't put water (Q283) there. Maybe uses (P2283), only that's also not ideal qualifier for that — but: you wrote «quenching (Q871335) or Water quenching (Qxxxx)», so maybe this information can be included by using proper items for 'Heat treating' property, i.e. not generic ones like quenching (Q871335) but only more specific like water/oil quenching etc.? Wostr (talk) 16:51, 23 July 2018 (UTC)
Since quite half or mechanical properties of metals depends on heat treatment you raise a very important point. I added a dedicated discussion about this topic on the project's qualifiers talk page -- Thibdx (talk) 21:27, 23 July 2018 (UTC)

### surface roughness

Under discussion
Description component of surface texture quantified by the deviations in the direction of the normal vector of a real surface from its ideal form surface roughness (Q114817) Quantity This proprety request is part of the project of creating an infobox for materials Mechanical property of all solid Materials Any number. Qualifiers : relative to (P2210) (mandatory) + others depending on the use Roughness N12 ISO Grade Number (Qxxx) : surface roughness (Pxxx) → 50 µm relative to (P2210) → Ra (Q55776776) Roughness N12 ISO Grade Number (Qxxx) : surface roughness (Pxxx) → 200 µm relative to (P2210) → Rt (Q55776788) Coefficient of friction : 0,3 with surface roughness (Pxxx) → 3,2 µm and relative to (P2210) → Ra (Q55776776) w:Surface roughness Creating an infobox for materials

#### Motivation

This proprety request is part of the project of creating an infobox for materials. To be used as a qualifier for properties such as coefficient of friction, fatigue limit or corrosion resistance. It could also be used as a standalone property for parts, measuring methods, standards or manufacturing processes such as Abrasive blasting (Q917273) with qualifier like the granularity of sand, the velocity and the material. It could also be a geologic property referring to soil surface roughness.

#### Discussion

•  Support David (talk) 07:36, 28 July 2018 (UTC)

### environment

Under discussion
Description describe the surroundings of an item. surface roughness (Q114817) Item This proprety request is part of the project of creating an infobox for materials Physics, Biology... Any item Corrosion resistance (Pxxx) → 500H with ISO standard (P503) → 9227, environment (Pxxx) → sodium chloride (Q2314), ... Corrosion resistance (Pxxx) → 500H with ISO standard (P503) → 9227, environment (Pxxx) → nitric acid (Q83320), ... Coefficient of friction : 0,3 with ISO standard (P503) → 15113, environment (Pxxx) → Dry (Qxxx) and Clean (Qxxx), ... w:Environment and w:Biophysical environment Creating an infobox for materials

#### Motivation

This proprety request is part of the project of creating an infobox for materials. To be used as a qualifier for properties such as coefficient of friction or corrosion resistance. In the material scope we are interested in the w:Biophysical environment. However since environnement has a variety of uses it could be more interesting to create one global property that can accept any item as a value. --Thibdx (talk) 21:46, 27 July 2018 (UTC)

#### Discussion

•  Comment this label seems a little too generic and could be confusing ("enviroment" has a variety of meanings). Is there another term commonly used for this? ArthurPSmith (talk) 13:02, 30 July 2018 (UTC)
It could be medium to narrow a little bit. It is possible to use more specific terms specifying the type of medium : reaction medium, lubrication medium... --Thibdx (talk) 13:17, 30 July 2018 (UTC)
•  Support, this should be useful, even with very broad name 'environment' (in this case we would have to add proper descriptions and instructions that this qualifier is only for chemical environment of measurement/reaction/etc, place some constraints here like value type constraint (Q21510865) = chemical substance (Q79529) etc. and keep an eye on the constraint violations pages). Wostr (talk) 18:55, 10 August 2018 (UTC)
•  Comment My original goal was to propose a very open property to avoid the creation of several specialized ones in the futur. However I feel like you prefer to have something with a precise meaning. In this case I would better use a title that says precisely what the property is intended for in order to avoid violations. I would then propose reaction medium and lubrication medium that are the most immediate needs for materials. What do you think about it ? --Thibdx (talk) 21:19, 10 August 2018 (UTC)
• IMHO such qualifiers are too specific and won't be needed if there's 'environment' qualifier. The only thing is that the constraints have to be applied correctly to this qualifier and someone have to watch for any attempts to use this qualifier in a non-intended way. Wostr (talk) 13:23, 11 August 2018 (UTC)
• I'm OK with that too. It is just a matter of deciding. If we use environnement with constraints it could be precised by some other items like climates and items specifying that there is no chemicals like dry. However we may not have to list evrything now. This could be improved later. --Thibdx (talk) 19:43, 11 August 2018 (UTC)
The good point of having a wide qualifier could be on some cases where you specify a résistance to special environments. Most rescue knives are made to resist in corrosion in rivers. Wich is not the same as resting to corrosion in sea. Also deep sea is not the same as surface sea since there is not the same amount of oxygen. This is very specific but some steels, like hyper duplex, have been developed for very specific uses. Hyper Duplex is the only steel that resist when searching for deep oil. -- Thibdx (talk) 20:17, 12 August 2018 (UTC)

### chemical resistance

Under discussion
Description predictive measurement of a material resistance to a chemical chemical resistance (Q1069398) Item This proprety request is part of the project of creating an infobox for materials. Chemical property of stainless steel (Q172587). ISO 4628 set criterias: Blistering N2-S2, Discoloration I1... Most datasheets (and en Wikipedia's infoboxes) use Poor/Fair/Good wich can be a first approach. together with (P1706), temperature (P2076) are mandatory qualifiers. neoprene (Q143937) → poor together with (P1706) → acetone (Q49546), acetaldehyde (Q61457), acetophenone (Q375112), ... [4] neoprene (Q143937) → fair together with (P1706) → acetamide (Q421721), acetylene (Q133145), benzene (Q2270), ... neoprene (Q143937) → good together with (P1706) → adipic acid (Q357415), aluminum acetate (Q419150), arsenic acid (Q413334), ... w:chemical resistance Creating an infobox for materials

#### Motivation

Most datasheets only give poor / fair / good. From a purely scientifical point of view I always find this citeria a bit weak. However this is incredibly usefull as a first criteria to choose the gloves you will use to manipulate a chemical, to choose a lubricant for a material, to know if you can use this material in such environnement... --Thibdx (talk) 07:58, 10 August 2018 (UTC)

#### Discussion

• Maybe the 'environment' qualifier discussed above would be better here? Wostr (talk) 10:53, 10 August 2018 (UTC)
Probably. I was thinking about this too. I still don't know if the above request will end in creating a qualifier "environnement" or something more precise like "chemical medium". --Thibdx (talk) 11:34, 10 August 2018 (UTC)
Another argument for creating this qualifier ;) Wostr (talk) 18:48, 10 August 2018 (UTC)

### shrinkage

Under discussion
Description Reduction in the size of something, or the process of becoming smaller, typically when a material return to room temperature after heating. Shrinkage (Q1170964) Quantity This proprety request is part of the project of creating an infobox for materials. base material (Q214609) Any number. direction (P560) maybe used for material with an anisotropic shrinkage. determination method (P459) or fabrication method (P2079) shall be specified. Two temperature (P2076) values are needed except if the process already define it. percentage (Q11229) nylon 6-6 (Q7071155) → 0,1 % with direction (P560) → parallelism (Q53875) and fabrication method (P2079) → injection molding (Q260606) nylon 6-6 (Q7071155) → 0,9 % with direction (P560) → normal (Q273176) and fabrication method (P2079) → injection molding (Q260606) Grivory GM-4H (Q57051271) → 0,8 % with fabrication method (P2079) → injection molding (Q260606) w:Shrinkage Creating an infobox for materials

#### Motivation

Shrinkage is one of the most important information considering the processing of a material. It is needed to define the exact dimensions of the mold. --Thibdx (talk) 21:06, 7 October 2018 (UTC)

#### Discussion

•  Comment from the samples/description, it seems that the proposal needs datatype quantity, not item. I updated that above. --- Jura 11:20, 9 October 2018 (UTC)
• Right. Thanks for the update. --Thibdx (talk) 20:11, 9 October 2018 (UTC)

## All sciences

### funding scheme

Under discussion
Description is supported under the funding scheme Item research project (Q1298668), film (Q11424) instances of funding scheme (Q58684939) The Guilty (Q30126665) → New Danish Screen (Q58684995) High-Definition Tomography (Q55089213) → European Research Council Advanced Grant project (Q55089188) Measuring with no tape (Q54826536) → European Research Council Starting Grant project (Q55083655) National Health Protection Scheme (Q58852228) → Ayushman Bharat (Q47999649)

#### Begrundelse

Research projects and sometimes films may receive support from agencies under specific funding schemes. For European Research Council (Q1377836) they are currently called "Advanced grant", "Starting grant", etc. For supporting movies funding schemes could be New Danish Screen (Q58684995) and (AFAIU) Digital Shorts (Q5275986)Finn Årup Nielsen (fnielsen) (talk) 13:57, 15 November 2018 (UTC)