Wikidata:Property proposal/is a synonym of taxon name
is a synonym of taxon name
[edit]Originally proposed at Wikidata:Property proposal/Natural science
Description | more or less the inverse of taxon synonym, P1420 |
---|---|
Represents | synonym (Q1040689) (including homotypic synonym (Q42310380), heterotypic synonym (Q59511375)) |
Data type | Item |
Domain | taxa (Q16521), plus items for scientific names |
Allowed units | taxon (Q16521) |
Example 1 | Enneapogon brachystachyus (Q50828916) -> Enneapogon desvauxii (Q5379150) |
Example 2 | Asteriscus maritimus (Q50828075) -> Pallenis maritima (Q1780814) |
Example 3 | Aristolochia littoralis auct. (Q61949225) -> Aristolochia elegans (Q1891719) |
Example 4 | Sedum nuttallianum Raf. (1832) (Q50869677) -> Sedum nuttallii (Q15488076) |
Expected completeness | partial (thousands already present in Wikidata, but the literature holds hundreds of thousands of synonyms, if not millions, mostly very obscure. It is to be hoped that most of these will never be imported into Wikidata, but it appears difficult to stop this entirely) |
Robot and gadget jobs | maybe |
Motivation
[edit]Intended to replace "instance of: synonym" with qualifier "of [target name]" (used in several thousand items). It is noticeable that some users misunderstand taxon synonym (P1420) and use this when they want to express the reverse, namely "is a synonym of taxon name". The latter can be done at the moment by using "instance of: synonym" with qualifier "of: [target name]", but to some users this appears counter-intuitive. Since this is an important relationship, it seems wise to remove this apparent ambiguity.
This proposed property is intended to be not quite the inverse of taxon synonym (P1420), since P1420 is intended to produce a list of synonyms of a particular taxon name. This is useful for well-known synonyms, occurring frequently in the literature, as this eliminates unnecessary confusion. On the other hand, this proposed property will often be used for very obscure names that nobody ever heard of, but that somehow got introduced into Wikidata anyway. For these obscure names it is very useful to be able to establish a relationship to a taxon name, so that it is placed in perspective. Inclusion of such obscure names in a list of synonyms would not be a good idea, as this would give them more prominence, and likely would cause further confusion.
This proposed property is not intended for isonyms, orthographical variants, and misspellings (incorrect subsequent spellings and incorrect original spellings). These are not synonyms (other names), but erroneous manifestations of the same name. However, it is intended to include misidentications. - Brya (talk) 10:51, 3 March 2019 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Discussion
[edit]- Support David (talk) 06:57, 4 March 2019 (UTC)
- Support It's kinda frustrating that this property didn't exist already. Circeus (talk) 16:46, 4 March 2019 (UTC)
- Support I was looking for it! TED 19:33, 4 March 2019 (UTC)
- Oppose Redundant inverse. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 5 March 2019 (UTC)
- I think it is really useful to have pointers going both ways in a case like this, and that is a normal practice. Otherwise, when looking at one item there is no indication of the relationship to the other item. Strobilomyces (talk) 15:06, 10 May 2019 (UTC)
- Agreed, and that is so true that we should have a warning, in the kind if the one that you have when you put "category main topic" somewhere and that you forgot to do the opposite with "topic main category". Christian Ferrer (talk) 16:45, 10 May 2019 (UTC)
- If the two properties which are each other's inverse are themselves connected by the property inverse property (P1696), you get a warning if the connection is only set in one direction.Wiljes (talk) 12:51, 29 July 2019 (UTC)
- Agreed, and that is so true that we should have a warning, in the kind if the one that you have when you put "category main topic" somewhere and that you forgot to do the opposite with "topic main category". Christian Ferrer (talk) 16:45, 10 May 2019 (UTC)
- I think it is really useful to have pointers going both ways in a case like this, and that is a normal practice. Otherwise, when looking at one item there is no indication of the relationship to the other item. Strobilomyces (talk) 15:06, 10 May 2019 (UTC)
- Oppose per Pigsonthewing. --Giovanni Alfredo Garciliano Díaz ★ diskutujo 06:05, 6 March 2019 (UTC)
- Comment I do not understand why we should have items just for the synonym of a taxon. --GPSLeo (talk) 16:44, 7 March 2019 (UTC)
- Oh, lots of reasons.
- To start with, there are a lot of Wikipedia pages for names that can be nothing but synonyms (no matter what taxonomy is followed). Wikidata is obliged to have items to accommodate these sitelinks.
- There are also lots of pages for what is regarded as valid / correct in that Wikipedia, but that is regarded in other Wikipedia's (using a different taxonomy) as being a synonym. Wikidata is obliged to have items to accommodate these sitelinks.
- Then there is the consideration that Wikidata aims to record data. Lots of data that is found in the literature is connected to names that may or may not be regarded as synonyms (depending on the taxonomy used). To manage this data it needs to be connected to the name used in the literature. This goes easiest if each name has its own item.
- We do have items for synonyms, and lots of them. The question is how to manage these. - Brya (talk) 17:39, 8 March 2019* (UTC)
- But there is a huge problem with labes, descriptions and aliases then. I think in most cases the label of a taxon is the most common common name in the language. And every scientific and former scientific name will be an alias. This will only create much confusion, because people will add the synonym as an alias to the main taxon and the main name as an alias to the synonym. And both items will get many common names. --GPSLeo (talk) 19:46, 8 March 2019 (UTC)
- Oh, lots of reasons.
- There is indeed an ongoing problem with labels and aliases (hopefully not descriptions). It is slowly being cleared up with labels migrating to the scientific name, and scientific names in aliases being migrated to corresponding items.
- The only way to avoid items for synonyms would be to have a Central Authority that sets a single (Original Research) WMF-Taxonomy and prescribes that for all Wikipedia's, forbidding any page that does not conform. Given that many Wikipedia's have a No Original Research policy and given the independence of Wikipedia's, this is extremely unlikely to happen.
- There is indeed a risk of confusion, and this proposal is intended to combat this confusion. - Brya (talk) 07:17, 9 March 2019 (UTC)
- I don't think it is necessary to have a central authority or do original reseach in order to associated together all the names referring to one organism. It is just necessary to choose one name, without claiming that it is the real current name. But it seems to me that this property proposal falls into the same sort of criticism because I think it is using the word "synonym" in a sense which excludes the current name. For instance if A is the taxon and B and C are synonyms, A would not be a synonym. But I think it is better terminology to say that A, B anc C are synonyms and at present A is the current name. Doesn't this proposal require original research because it is necessary to identify which of a number of homotypic names is the real current one? Strobilomyces (talk) 15:06, 10 May 2019 (UTC)
- Any indication of whether a name is current / correct (according to a particular point of view) depends upon a taxonomic reference, which documents an actual decision by an actual taxonomist. So, normal practice by Wikidata does not involve Original Research but rather VER. However, a decision to appoint a Real Current Name (as in the One and Only True Name) may well violate NOR. But this is not normally done in Wikidata. - Brya (talk) 17:19, 10 May 2019 (UTC)
- Support I have long been looking for this property too. --LamBoet (talk) 20:55, 13 March 2019 (UTC)
- @Circeus, TED and LamBoet Any idea why this could not reconciled from sourced statements of P1420 ? --Succu (talk) 21:38, 13 March 2019 (UTC)
- @Succu:: I don't understand the question. TED 07:08, 14 March 2019 (UTC)
- @*Pigsonthewing and Giovanni Alfredo Garciliano Díaz why do you think ist an inverse constraint (Q21510855) --Succu (talk) 22:21, 13 March 2019 (UTC)
- Support Panek (talk) 09:24, 2 May 2019 (UTC)
- @Brya: Do we get rid of the instance of (P31)=synonym (Q1040689) statements? Should we mark special names (has basionym (P566) or original combination (P1403)) somehow? --Succu (talk) 20:02, 3 May 2019 (UTC)
- The intent is to replace the instance of (P31)=synonym (Q1040689) statements, over time. However, it is probably wise not to rush into this, and to see first how things develop.
- As to has basionym (P566) or original combination (P1403), this is unrelated. Both basionym (P566) and original combination (P1403) indicate nomenclatural relationships, while this proposed property deals with a taxonomic relationship. It is quite possible that a name that is the basionym of another name is not now regarded as a synonym by anybody (that there was once at least one taxonomist who based another name on it may not be all that relevant). - Brya (talk) 03:31, 4 May 2019 (UTC)
- I'm not really convinced that this a good solution, but it's much better than the P31 solution. Hence
Support. --Succu (talk) 18:07, 4 May 2019 (UTC) Changed my mind. --Succu (talk) 19:46, 9 October 2019 (UTC)
- I'm not really convinced that this a good solution, but it's much better than the P31 solution. Hence
- Oppose. Unnecessary, redundant inverse. --Yair rand (talk) 20:04, 5 May 2019 (UTC)
- As explained above, in some cases it is an inverse, in other cases it definitely is not. And even when it is an inverse it serves a useful function: it is not redundant. - Brya (talk) 10:37, 6 May 2019 (UTC)
- Comment I don't think this proposal should be considered until there has been substantial further analysis of the meaning of the concept "synonym" and how it should be represented in Wikidata. Some relevant issues are:
- The relationship "is a synonym of" can only apply to entities which are names. However, Wikidata applies them to items that are instances of taxon (Q16521). If Q16521 really represents a "taxon" – a group of organisms – then it's simply wrong to apply any kind of "synonym relationship" to such items. A taxon cannot be a synonym of another taxon; only a taxon name can be a synonym of another taxon name.
- "Synonym" is not used with exactly the same meaning in the different nomenclature codes. For example, moving a species from one genus to another, creating a new combination, creates a new synonym in botanical nomenclature, but not in zoological nomenclature. The differences between the codes are not represented in Wikidata.
- There is a significant distinction between "objective synonyms/homotypic synonyms/nomenclatural synonyms" and "subjective synonyms/heterotypic synonyms/taxonomic synonyms", again not represented in Wikidata.
- As Brya notes, some cases of "X is a synonym of Y" imply that "Y is a synonym of X" and some do not, but this is complicated by Wikidata not distinguishing clearly what kind of synonym is involved, and by this being in some cases a subjective issue dependent on taxonomic opinion. For a botanist who chooses to place a species originally described as P q into a different genus R, as R q, the name R q is a homotypic synonym of P q. Databases such as the World Checklist of Selected Plant Families then list each name as a synonym of the other, treating the relationship as symmetric. (See e.g. the entries for Hyacinthus candicans, Galtonia candicans and Ornithogalum candicans in the WCSP.) If these were zoological names, strictly speaking they wouldn't be what the ICZN calls "synonyms" at all.
- When one plant genus is sunk into another, e.g. Galtonia into Ornithogalum, those who choose the wider name, like WCSP, treat each genus name as a (heterotypic) synonym of the other, so that the relationship between the names is symmetric, although in this case the relationship between the taxa represented by the names is clearly not symmetric – Ornithogalum in its wider sense includes Galtonia but not vice versa. This is a particular problem in Wikidata if "synonym relationships", however expressed, are regarded as being between taxa rather than names. Also for those who maintain the two genera, Ornithogalum in its original narrower sense is not a synonym of Galtonia nor vice versa. So whether or not the two taxon names are synonyms of one another depends on the taxonomic view. Since Wikidata should be neutral on taxonomic views, we should be able to say both that they are synonyms (with a source) and that they are not (with a source). Um...
- Peter coxhead (talk) 08:44, 8 May 2019 (UTC)
- You're (somewhat indirectly touching) onto the heart of an issue I have with how Wikidata treats taxon and names: the property system surrounding name-related properties presumes that names are items, but nothing else in the data structure does. It's literally impossible to create a taxon name as a properly documented item without violating a whole bunch of constraint! Circeus (talk) 17:21, 8 May 2019 (UTC)
- @Circeus: in practice, if not in theory, taxon (Q16521) actually represents both a taxon name (because it has relationships/properties only valid for names, like synonym or basionym), and a taxon (because it has relationships/properties only valid for taxa, like parent taxon or images). Peter coxhead (talk) 20:44, 10 May 2019 (UTC)
- Peter coxhead states: Databases such as the World Checklist of Selected Plant Families then list each name as a synonym of the other, treating the relationship as symmetric. (See e.g. the entries for Hyacinthus candicans, Galtonia candicans and Ornithogalum candicans in the WCSP.) . I don't recognize this at all: the WCSPF does what most everybody does. For Ornithogalum candicans it states "This name is accepted" and provides a list of names under the heading "Synonyms". For Hyacinthus candicans and Galtonia candicans it states "This name is a synonym" and refers to Ornithogalum candicans as the accepted name. There is no trace of a symmetric relationship: Hyacinthus candicans and Galtonia candicans are synonyms of Ornithogalum candicans. And this last has two synonyms: Hyacinthus candicans and Galtonia candicans. I don't see how it could be clearer. - Brya (talk) 02:00, 10 May 2019 (UTC)
- @Brya: the usage of "synonym" you give above works if, and only if, (1) there is an accepted name, so that "synonyms" are always alternatives to the one accepted name (which as you have said before cannot be adopted here) and (2) there are different representations for "synonym" in the sense you used it (which implies a representation for the "accepted name"), "homotypic name" and "heterotypic name". With an accepted name and these three relationships, "synonym" is not symmetric, the other two are. What I see is Wikidata's "synonym" used for all kinds of "alternative scientific names", including "homotypic name". Do you really want to restrict "synonym of" to "accepted name"?
- I note you didn't address the points about the confusion between "taxon" and "taxon name". Peter coxhead (talk) 20:37, 10 May 2019 (UTC)
- Yes, "synonym" as used for taxonomy presupposes that there is an "accepted name" / "correct name": it is "the synonym of ...". A taxonomic paper will not call an unaccepted name that is unresolved a "synonym", but will have a separate heading for it ("unresolved names", "nomina inquirenda", etc) away from the accepted names.
- "Homotypic" and "heterotypic" apply primarily to nomenclature. "This name is homotypic with" is a symmetric relationship, and Wikidata probably could use a property "this name is homotypic with". Whether "this name is heterotypic to" is symmetric or not is more complicated: most of the millions existing names are heterotypic to most other names, and this could count as symmetric. However, in practice nobody would say anything like this. It is only relevant to comment on a name being heterotypic if there is a taxonomic relationship, and in that case the relationship will not be symmetric.
- And obviously you are right that "A taxon cannot be a synonym of another taxon;" although not about "only a taxon name can be a synonym of another taxon name": this would be "only a name can be a synonym of a taxon name". But we covered this elsewhere. - Brya (talk) 03:38, 11 May 2019 (UTC)
- You're (somewhat indirectly touching) onto the heart of an issue I have with how Wikidata treats taxon and names: the property system surrounding name-related properties presumes that names are items, but nothing else in the data structure does. It's literally impossible to create a taxon name as a properly documented item without violating a whole bunch of constraint! Circeus (talk) 17:21, 8 May 2019 (UTC)
SupportRedundant inverse is not true, specially for quarries in the kind ("filter not exists {?item wdt:P31 wd:Q1040689.}") to exclude the taxa that are synonyms. I very often use "instance of " "synonym" "of", example Asterias echinophora (Q63607694). Therefore a such new property will be a little more easy and quick to use for me. The same principle could be applied to "subject has role" "protonym" "of" with a new property "protonym of" (same example with Asterias echinophora (Q63607694)). A property that can works to have the same result without the obligation to use qualifiers is of course much better for the future potential querries (and likely from the ontological point of view too), and should be preferrer IMO. Christian Ferrer (talk) 19:02, 9 May 2019 (UTC)
- I change to Neutral, for now Christian Ferrer (talk) 12:41, 28 November 2019 (UTC)
- Comment I think this property would be a good thing if it could be used to distinguish and conceal "very obscure names", especially old basionyms (which all need to have items in order to record the author information, following the taxonomy project tutorial). Please can I ask whether it will be restricted to items having "instance of" = "taxon"? If not, I think it could be part of a big improvement to the data model, eliminating garbage from "instance of" = "taxon". In that case it would be necessary to define what other "instance of" values are allowed. Strobilomyces (talk) 18:42, 10 May 2019 (UTC)
- The proposal is to use it in items for (non-taxon) scientific names as well as in items of taxa / names of taxa. - Brya (talk) 03:05, 11 May 2019 (UTC)
- Although the debate has stalled I think it would be good to have a bit more support votes to confirm that the property is useful before going ahead with creating this, so I will remove the ready flag for now. − Pintoch (talk) 21:34, 23 July 2019 (UTC)
- Not done no consensus for now, no prejudice regarding proposing again in the future --DannyS712 (talk) 00:20, 16 January 2020 (UTC)