Wikidata talk:WikiProject Chemistry

From Wikidata
Jump to: navigation, search
Icône de rangement Old discussions are archived in Archive 2013, Archive 2014, Archive 2015, Archive 2016, Archive 2017.

crystal violet (Q420705)[edit]

After several bot changes, this item (cation) does not correspond anymore to its sitelinks (chloride). I would prefer to keep the sitelinks in this items, i.e. to correct identifiers etc. --Leyo 15:39, 12 June 2017 (UTC)

Hi - I looked over changes for the past more than 1 year and I don't see an edit that changed the chemical formula, can you point to one that was a problem? Or you could chat with User:Egon Willighagen who has edited this item recently and is not a bot, get his advice... ArthurPSmith (talk) 18:09, 12 June 2017 (UTC)
The first edits that started causing this issue were done more than a year ago (e.g. Special:Diff/240694269). --Leyo 21:47, 12 June 2017 (UTC)
ah, that's almost 2 years ago. It might be better to create a new item for the chloride and move the sitelinks you think belong there. ArthurPSmith (talk) 15:37, 13 June 2017 (UTC)
Yes, this likely needs to be resolved... splitting the cation from the salt seems wise. I have to check what "gentian violet" formally refers to, but EN-Wikipedia suggests the salt indeed. I also second the observation that the change to a cation was made almost two years ago. My more recent edits are based on InChIKey matches, and points to the cation. One question I have here, what is more important, the sitelinks or the data here? Not sure how to check when the sitelinks are made, and what to do when local Wikipedia versions contradict (that happens). So, I am not sure at this moment if the proper action is to make a new entry for the ion or the chloride salt... ---Egon Willighagen (talk) 17:08, 13 June 2017 (UTC)
@Egon Willighagen, ArthurPSmith: I corrected it so the whole item reflects the chloride salt only. The kation version should be represented as separate item, as it has its own UNII, ChEBI, ChEMBL, etc. The items should be linked via part of (P361) and has part (P527). This issue did not go unnoticed as you can seem from the fact that it is included in my issue list. Please curate! Sebotic (talk) 18:11, 13 June 2017 (UTC)
@Egon Willighagen, ArthurPSmith, Leyo: Better move sitelinks that changing WD data: WP articles are not reliable as often data about several compounds are mixed in the same article. The only best way in my opinion is to used the InChI as key parameter to define what is the real compound or entity represented by the item. Snipre (talk) 14:36, 22 June 2017 (UTC)
@Sebotic: Can you update Group C list ? I wanted to continue the curation of that list and each time I opened an item I saw that a value was added since the date the list was issued ? Thanks Snipre (talk) 14:36, 22 June 2017 (UTC)
@Snipre: I updated lists C and D, rest will follow. Sebotic (talk) 00:17, 2 August 2017 (UTC)

Soliciting suggestions of new data sources[edit]

Dear all, we on the Gene Wiki / ProteinBoxBot team are doing some planning and prioritization of future biomedical data sets to load, and we'd like to solicit suggestions from the broader Wikidata community. Historically, the scope of our bot loading effort has revolved around genes, proteins, drugs, diseases, and microbes. And more recently we've also helped related groups load data on genetic variants and pathways. We would welcome suggestions of either other related entity types that should be systematically loaded, or data sources that describe relationships between these entity types. Obviously, availability of a high-quality, CC0-licensed data source is essential. Please let us know if you have any suggestions. (Cross posting to WD:MB, WD:MED, and Wikidata:WikiProject_Chemistry.) Best, Andrew Su (talk) 20:04, 23 June 2017 (UTC)

There's a growing conversation about molecules and their adverse effect of human health. I'm talking food additives, cosmetic molecules, pesticides… There are some maximum daily doses prescribed by institutions like the EFSA (European Food Safety Agency). Also a trove of related studies, commercial or not about each of those substances. And potential relationships with diseases (lung cancer, breast cancer…). Is that something that could fall within the scope of ProteinBoxBot ? --Teolemon (talk) 11:58, 24 June 2017 (UTC)
@Teolemon: In general EFSA data sounds very interesting, but unfortunately this description of the data access rules does not sound promising in terms of loading to Wikidata. Best, Andrew Su (talk) 17:18, 26 June 2017 (UTC) is the PoC. They do open data. --Teolemon (talk) 12:22, 27 June 2017 (UTC)
Thanks for the lead. I will follow up! Best, Andrew Su (talk) 16:50, 27 June 2017 (UTC)
@Teolemon: Unfortunately I don't think we will be able to load data from EFSA anytime in the short term... Best, Andrew Su (talk) 20:02, 10 July 2017 (UTC)

Problem of concept definition for some ions[edit]

There is a regular mistake for items about ions: People mix the concept of ion and those of compounds family containing the ion. I don't know if the second concept is really necessary so I prefer to have feedback of other users before doing a merge.

Snipre (talk) 11:29, 29 June 2017 (UTC) @Infovarius: Snipre (talk) 14:21, 30 June 2017 (UTC)

I've noticed your changes in some elements about ions/compound classes and I'm not sure if adding ion/anion is correct. It is true that two concepts are usually mixed in one element and it should be fixed, but most articles in Wikipedias are about compound classes (and these articles are linked to WD elements) not about anions (info about anions are in most cases included in the article about compound class). So we cannot link de:Sulfate to WD element about an anion (Sulfate sind Salze oder Ester der Schwefelsäure so it's not about an anion), we cannot add commons:Category:Sulfates to such element, and we cannot even add instance of (P31)/subclass of (P279) = sulfate (anion) to e.g. sodium sulfate anhydrous (Q211737). The element about anion could be used only with has part (P527). There should be different elements for anions and for compound classes (and the latter should be linked to Wikipedia articles in most cases). Wostr (talk) 11:14, 30 June 2017 (UTC)
@Wostr: Thanks for your comment. I never dared about the WP articles because they are not reliable to define the concept of an item: currently most items linked to WP articles focused on compounds family have data concerning only the ion. So we have to clean the items and I can do that job. I will let the Wikipedians decide which item is corresponding the best to their article. The only critical thing to define now is: do we want to keep some items for compounds family or can we merge those mentioned items ? Snipre (talk) 11:30, 30 June 2017 (UTC)
I will one step further because I already had some feedback from other contributors:
if we agree to have two different classes of items, one class for the ions and one for the compounds family, all items for compounds family have to have subclass of (P279): chemical compound (Q11173) orsubclass of (P279): salt (Q12370) ? Snipre (talk) 14:34, 30 June 2017 (UTC)
I thought we decided above just a few days ago (discussion with Kubaello) to split element and substance items - so it seems even more clear we should do the same in this case, for ions and compounds based on those ions. Definitely don't merge the ones that are already separated. Since salt (Q12370) is a subclass of chemical compound (Q11173) I would go with the most specific superclass that's accurate. ArthurPSmith (talk) 14:38, 30 June 2017 (UTC)
Is salt (Q12370) correct in this case? As e.g. sulfate can be a salt or an ester. Both are derivatives of the same acid, but if we decide to have elements like sulfate (salt) and sulfate (anion), we should also create sulfate (ester)... I'm not sure that spliting sulfate into 3 diffrent elements is the best option. Maybe sulfate (not anion) should be described as derivative of xxx acid without classifying it as a salt/ester and only by chemical compound (Q11173)? Wostr (talk) 21:35, 30 June 2017 (UTC)
@Wostr: The different items already exist for sulfate category. Sulfate ion and sulfate group are not the same: just think about all funcitonal groups composing organic molecules. Mixing salts and organic molecules is just creating a messas inorganic and organic chemistry follow different rules especially for nomenclature. Snipre (talk) 01:35, 1 July 2017 (UTC)

@Snipre:: Yes, but sulfate as a class of compounds is defined in the first place as salt or ester and that's true for many similar classes (exluding those that don't exists as an esters and a salt form is only possible). I think the correct hierarchy is:
  • sulfuric acid derivative
    • sulfate (salt or ester)
      • sulfate (salt)
        • containing sulfate anion
      • sulfate (ester)
        • containing sulfate group
    • hydrogen sulfate (salt or ester)
      • hydrogen sulfate (salt)
        • containing hydrogen sulfate anion
      • hydrogen sulfate (ester)
        • containing hydrogen sulfate group
(of course there could be a division into organic [ester or salt]/inorganic [salt] in the first place but IMHO concept of organic/inorganic compounds is not a good choice in classification of compounds in terms of their structure etc.)
That's why I'm asking which sulfate is the one which we plan to create here: sulfate anion vs sulfate salt or maybe sulfate anion vs sulfate salt or ester? In the latter salt (Q12370) would be incorrect. Wostr (talk) 08:36, 1 July 2017 (UTC) PS Beacause maybe sulfate salt and sulfate ester could be eliminated and have only sulfate salt or ester. Wostr (talk) 08:38, 1 July 2017 (UTC)
@Wostr:: "sulfate as a class of compounds is defined in the first place as salt or ester". Who say that ? This is classification so we are free to follow some existing classifications or not. For example ChEBI classification doesn't follow your classification (see sulfuric acid derivative where the class is splitted into sulfuric ester, sulfates and organic sulfate. The best is to compare existing classifications and to identify what are the rules defined for each classification and choose the one which corresponds to our needs. Snipre (talk) 17:58, 4 July 2017 (UTC)
@Snipre:, I know ChEBI classification and you should check how these three classes are linked to each other and their definitions:
  • sulfuric acid derivatives : organic sulfate , sulfates , sulfuric ester
    • sulfates : sulfate salt , organic sulfate (?)
    • sulfuric ester and organic sulfate are not linked in any way but both classes are esters of sulfuric acid.
I don't see any reason, why would anyone follow this classification, it's unlogical and IMHO incorrect. Wostr (talk) 21:59, 4 July 2017 (UTC) PS And the organic sulfate is ambiguous – sulfate salt with organic cation is not an organic sulfate? That's why classification based on organic/inorganic concept is not a good option. Wostr (talk) 22:12, 4 July 2017 (UTC)
@Wostr: I didn't say we have to follow ChEBI classification, I just mentioned there are other types of classifications. I want to start a discussion about what are the elements of a good classification. If I take the examples you gave about sulfuric acid derivative I don't understand the need of the intermediate levels sulfate (salt or ester) and hydrogen sulfate (salt or ester) ? Why can we have a more horizontal classification without unnecessary levels ? We can have
  • sulfuric acid derivative
    • sulfate (salt)
    • sulfate (ester)
    • hydrogen sulfate (salt)
    • hydrogen sulfate (ester)
The only way to be able to choose is to define criteria first and then to start the classification. Snipre (talk) 08:15, 20 July 2017 (UTC)
Yes, the salt and ester level may be redundant – my proposition was bases on category tree and the intermediate level is useful there (but it may not be here). Wostr (talk) 09:30, 20 July 2017 (UTC)

bromoaniline (Q4973722)[edit]

no label (Q27120791) has repeatedly been merged into bromoaniline (Q4973722) by a user. However, I do strongly believe that this is against Wikidata principles. de:Bromaniline is an article on a group of chemical substances, whereas en:Bromoaniline is a disambiguation page. Any other views? --Leyo 13:15, 17 July 2017 (UTC)

Hmm, the enwiki page is only disambiguating the different articles about specific chemicals in that group, so they really are about the same thing. I think the best solution here might be to change the enwiki article so it's not a disambiguation page but more about the group of chemicals (with links to the specific articles retained of course), perhaps some of the text from the dewiki article can be translated and imported? Yes in general disambiguation pages and regular article pages should not be mixed up like this. ArthurPSmith (talk) 14:45, 17 July 2017 (UTC)
I had a similar problem with Metasilicate and after a small discussion on WP:en, I deleted all references to disambiguation page to create a real article about the Metasilicate family. Snipre (talk) 16:15, 17 July 2017 (UTC)
I wouldn't call en:Metasilicate an article, but rather an unsourced stub. ;-) But anyway, this is surely a possibility if someone is going to convert en:Bromoaniline into an article. If not, we need another solution. --Leyo 21:14, 17 July 2017 (UTC)
@Leyo: Don't mix page type and evaluation: an unsourced stub is an article at a stub level. But this is an article compared to a disambiguation page or a category. What is important is not the content, because the content is under WP responsibility, but how we have to classify it in WD. Did you do a difference in WD between a A-class article and a stub article ? Snipre (talk) 10:18, 18 July 2017 (UTC)
Yes, sure, en:Metasilicate an article in Wikidata terms.
The case of no label (Q27120791), however, remains open. --Leyo 10:51, 18 July 2017 (UTC)
My proposition:
* Delete the mention of disambiguation page in WP:en (transform it in an article)
* Delete all descriptions in no label (Q27120791)
* Delete instance of disambiguation page
The definition in the WP:en article is not correct: Bromoaniline can't refer to 2-bromoaniline or 4-bromoaniline. This is against the chemical nomenclature. Bromoaniline can refer to only 1 thing: the family of Bromoaniline compounds.
Better to keep an unique system where general terms are used for compounds family only and to avoid the use of disambiguation page for chemicals. There is a chemical nomenclature which is able to identify each chemical, so if a name is not sufficient to distinguish two chemicals, it is wrong. Simplification in chemical naming is just a bad habit which is support by no authorities in chemistry. Snipre (talk) 12:09, 18 July 2017 (UTC)
By family of bromoaniline compounds you mean three bromoaniline isomers or bromoanilines and any derivative of them (having bromoaniline in the structure)? Wostr (talk) 20:15, 19 July 2017 (UTC)
I prefer to keep bromoaniline for the group of the three isomers and to use another name like bromoaniline derivatives for the rest. I have a rigid idea of the naming for chemicals but I am facing so many cases where names don't help to identify compounds that I prefer to use strong principles. That's my opinion. Snipre (talk) 21:11, 19 July 2017 (UTC)
I agree. I asked because in some wikis we have different approaches and names like bromoanilines etc. refer to group of isomers or derivatives (and sometimes to both: article describes group of isomers and category collects derivatives). Wostr (talk) 09:22, 20 July 2017 (UTC)
Done. By the way en:Chloroaniline is not a disambiguation on WP:en, but a list. There is a huge structure problem in WP:en preventing to have a good idea of the classification scheme. Snipre (talk) 08:03, 20 July 2017 (UTC)

Iron phosphate (Q1211305) and contains administrative territorial entity (P150)[edit]

I found that Iron phosphate (Q1211305) has contains administrative territorial entity (P150) with ferrous phosphate (Q2618789) and ferric phosphate (Q1311179) (these two phosphates have located in the administrative territorial entity (P131)). At first, I wanted to delete located in the administrative territorial entity (P131) and contains administrative territorial entity (P150), but maybe we have some properties that would be better in that case? Wostr (talk) 17:12, 6 August 2017 (UTC)

perhaps has part (P527) and part of (P361) respectively? ArthurPSmith (talk) 19:53, 7 August 2017 (UTC)

HMDB identifiers[edit]

Hi all, 10 days ago the Human Metabolome Database (Q5937262) seems to have updated a new identifier scheme, one with more zeros, I guess anticipating a major data load. The regular expression of the HMDB ID (P2057) is still fine, but they decided to give all compounds new identifiers, with extra zero's. For example, D-fructose was HMDB00660 and is now HMDB0000660, with the original identifier now a secondary identifier. How should we update the Wikidata entries? Keep the original identifier as well as the new identifier, maybe even with a new property (personally, I rather not)? Use ranks to indicate what is the primary identifier (I'm aware of an ongoing related discussion about secondary identifiers). Only the new identifier? That will break compatibility with a lot of database. --Egon Willighagen (talk) 13:35, 26 August 2017 (UTC)

@Egon Willighagen: Correct all existing values of HMDB ID (P2057) and perhaps it is good to think if the current display of that kind of identifiers is the best: if we use only the relevant part of the identifier i.e. the number without the zeros (HMDB0000660 -> 660), we would not have this problem. WE can always add the letters and the zeros when we create the links. Snipre (talk) 22:44, 31 August 2017 (UTC)
@Snipre: I'm personally not fond of these shortened identifiers, as *all* tools need to start adding such prefixes... but since this seems to be a Wikidata habit, I'm fine. I can easily add the new values (SPARQL query followed by QuickStatements), but not sure how to automate removing the old values... work for a bot? @Andrawaag:, or can you help me bootstrap a modern bot? --Egon Willighagen (talk) 07:47, 2 September 2017 (UTC)
@Egon Willighagen: The main problem is that an identifier shouldn't be modified so if the different databases are not respecting this rule, we have to find a way preventing us to modifiy all values each time the identifier pattern is changed. The question is simple: are we sure that HMDB won't change again their identifier structure in the future ? As they already did it once, we can't exclude that probability so we have to find a solution for us which limits the risk of having to update the whole set of values. And this can be done by storing in WD the only part of the identifier which is stable. So unless you can provide the garantee that HMDB won't change any more their identifier pattern, the best is to switch to a more secured datat format. Snipre (talk) 04:22, 3 September 2017 (UTC)
@Snipre: Sorry, you lost me here... I think I already said I would not object to your suggestion... are you now suggestion yet another approach? Other than that, I am not member of the HMDB developer community... I am not the person to ask if they will change in the future... I did ask about the next practical steps, and your opinion on that is not clear to me: how shall we update the Wikidata content... do you have a bot to make your suggested changes? --Egon Willighagen (talk) 07:16, 3 September 2017 (UTC)
@Egon Willighagen: My comment was not personal, it was just an answer to your remark "this seems to be a Wikidata habit": this is not a habit, but a real strategy to use only the core part of identifier. And my reflexion about HMDB is just a possible way to join your position: if you have some connections with HMDB and you can get the garantee that they took enough margin with their new identifier pattern, then we can consider to keep the new pattern like it is. Snipre (talk) 19:12, 3 September 2017 (UTC)

Monolingual text IUPAC names?[edit]

Four years ago the IUPAC name was proposed as property and put on hold to await establishment of multilingual text (see Wikidata:Property_proposal/Pending). This does not seem to happen soon. I asked today on the #wikidata IRC channel where it was suggested that reproposing the property may be a good idea. But before I do so, I like to hear the ideas of the current people involved and others who commented last time, like @Andrew_Su:, @Tobias1984:, @Emw:, @Graeme Bartlett:, and @Beetstra:. --Egon Willighagen (talk) 17:56, 2 September 2017 (UTC)

Jasper Deng
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
Devon Fyson
Pictogram voting comment.svg Notified participants of WikiProject Chemistry

Before doing anything we need the creation of the multilingual datatype. I don't think we need to reopen the proposal: we need to ask the creation of the good datatype. Snipre (talk) 18:15, 2 September 2017 (UTC)
Can you explain why this needs to be multilingual, and not monolingual? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:43, 2 September 2017 (UTC)
Snipre (talkcontribslogs), I sort of have the same question as Pigsonthewing (talkcontribslogs)... the entry in Wikidata:Property_proposal/Pending does not give a lot of context, and browsing the Phabricator, it seems that multilingual is for single 'texts' that have more than one language... but IUPAC names are always just in one language: it's an English IUPAC name, a Dutch IUPAC name, etc. If not mistaken, you participated in the original discussion... do you know where that discussion was held 4 years ago, or let me know more of the context of back then? --Egon Willighagen (talk) 21:59, 2 September 2017 (UTC)
@Pigsonthewing, Egon Willighagen: The difference is in the definition of the datatype: a monolingual datatype means you store one value with one language per statement. If you have several languages, then you create several statements. A monolingual datatype means you have some values in small set of languages. In the case of multilingual datatype, you have a value for all the languages the system can support. From contributor point of view, this doesn't help a lot, but for machine or programming point of view, this is different: for a monolingual datatype, I am not sure to find a value for a defined language so I have to start first to check if a value exists for the language I want and then if the value exists, I can extract if. With a multinlingual datatype I don't need to first check if a value exists for one specific language: the value exists anyway but the value can be empty.
From database point of view, the multilingual datatype save space as it already include the structure to save a value for all languages. Perhaps I should use a better picture: the monolingual datatype is like a flat in one bedroom: you can have one guest. The multilingual datatype is like a flat with several bedrooms. What is the difference ? The flat with several bedrooms shares a unique batchroom and an unique kitchen. I want to have several guests with flat composed of only one bedroom I need several flats with all having a bathroom and a kitchen.
How this impact WD ? Just try to open an item with several hundred of statements (like Germany (Q183)): this is a nightmare for data amount because for each value you have, you have to deal with a corresponding statement structure to download. Another picture: the monolingual datatype is like a bookshelf designed for only one book. If you want several books, you need several bookshelves. The multilingual datatype is like a bookshelf designed for several books so you save space and time to look for a book.
And if my last explanation is not sufficent, try to see once how the data are stored in the servers in JSON language, it is something like:
blablabla(value = XXX, language = YYY)blablabla
So storing 5 monlingual datatype statements gives that
blablabla(value = XXX1, language = YYY1)blablabla
blablabla(value = XXX2, language = YYY2)blablabla
blablabla(value = XXX3, language = YYY3)blablabla
blablabla(value = XXX4, language = YYY4)blablabla
blablabla(value = XXX5, language = YYY5)blablabla
With a mutilingual datatype, this would be:
blablabla(value = XXX1, language = YYY1; value = XXX2, language = YYY2; value = XXX3, language = YYY3; value = XXX4, language = YYY4; value = XXX5, language = YYY5; value = XXX5, language = YYY5;)blablabla
Just do the same exercise with 200 or 300 languages. Do you see a difference ?
So the multinlingual datatype is different from the monolingual datatype because:
* multinlingual datatype assume the existence of one value (which can be empty) for all languages of the system. This helps data extraction because you don't need to check first the existence of a value in a specific language
* from memory space and access time point of view, the multilingual is optimized to store dataset contrary to monolingual datatype.
This two features deal mainly with system features and not with contributor features but Wikidata is not only used by humans and this is good to design systems which can be easily used by machines too. Snipre (talk) 03:51, 3 September 2017 (UTC)
Perhaps I have to add info about drawbacks of multinlingual datatype: this datatype assume one and only one value per language. For IUPAC name, this not always the case, as we can have several names we will have to create different IUPAC name properties like the "preferred IUPAC name". Snipre (talk) 04:12, 3 September 2017 (UTC)
So, no IUPAC names in the foreseeable future? --Egon Willighagen (talk) 07:18, 3 September 2017 (UTC)
Two steps process:
* ask the development team if they plan to create the multilingual datatype in a near future (✓ Done, see here)
* if no, then we can go back to the first discussion: do we want to use the monolingual datatype for IUPAC name or do we prefer to wait for a hypothetical multilingual datattype creation first ?
This is my opinion but I am not the majority. Snipre (talk) 22:54, 3 September 2017 (UTC)
Among the already present properties I can only see an advantage of multilingual datatype in one case: media legend (P2096). We are in this case only interested in having one line of text for each language. The Dutch, French or Danish text do not have to say the same thing, but you still only need max one value per language. But on second thought, I am not so sure any longer. If there would be a "new caption property" with multilingual datatype, it would still only be useful if it had a translation to the language I am interested in. In an infobox at Wikipedia et all, I am not interested in a fallback to English or any other language. The only thing I am interested in, is to find the caption who have "language=sv". One single claim instead of 17 saves space, but that is only true until somebody add a second claim with the same property. Then a Multilanguage datatype would probably take more space, since I guess a multilang-datatype needs more metadata. Another drawback could be that a source for the en-value in the multilang datatype maybe isn't the same as the source for the "de-value"? -- Innocent bystander (talk) 05:50, 4 September 2017 (UTC)
Could we just use official name (P1448) for this (sourced to IUPAC)? ArthurPSmith (talk) 14:47, 4 September 2017 (UTC)
ArthurPSmith: As explained there are several IUPAC names, for example take en:Acetic acid which has a Systematic IUPAC name (Ethanoic acid) and a Preferred IUPAC name (Acetic acid). Then more complex molecules have different names depending on the nomenclature used. So we will have several properties for IUPAC names or other systematic names, all having a specific translation in the different languages. Snipre (talk) 18:47, 4 September 2017 (UTC)
Retained names, preselected names etc. just in organic IUPAC nomenclature. For inorganic nomeclature there are at least 4 different methods (and eg. there may be several names created using just one method; see table IX in IUPAC Red Book 2005) and there will be PINs for inorganic compounds in the future as well [1]. I think the whole system of properties (multilingual as I don't see how it would be possible to maintain all of these names using monolingual properties; there is already World Health Organisation International Nonproprietary Name (P2275) and having several such properties with dozens of names...) should be discussed in great detail before any atempts to add IUPAC systematic names to WD (and to ensure that these properties will be filled with correct IUPAC systematic names, as the Internet and sources (and Wikipedia too) are full of non-systematic, semi-systematic, almost-systematic, old-systematic, CAS-systematic, ACS-systematic etc. names). Also there is a problem that not every language has its own translation of IUPAC nomenclature (and even if there is one, sometimes it's a translation of an old recommendations – so we have to decide whether we should accept names in languages that don't have its own translation or reject these names). And how to deal with names that was systematic in old recommendations? I don't think it is reasonable to propose any property about IUPAC systematic name without months of discussion. Wostr (talk) 23:42, 4 September 2017 (UTC)