I know there is a lot of debates on going (especially for the last one), so having it there might be important. (going through all archives is not so optimal) – The preceding unsigned comment was added byAdrianoRutz (talk • contribs) at 28 December 2020 (UTC).
@ AdrianoRutz: I can't speak for the others but I think fundamentally it's a matter of resources. To add a database such as Open Tree of Life someone has to propose the property needed to add the identifier, get hat approved, then someone needs to get access to the data, figure out how to map it to existing taxa (and what to do if there isn't already a corresponding taxon in Wikidata), then run some scripts to add all the data (and deal with any errors in that process). In the case of the Leipzig Catalogue of Vascular Plants this is problematic because they don't, as far as I can tell, have any resolvable identifiers for taxa, they simply list names and say whether they are accepted or not. Without an identifier (ideally resolvable on the web) then they can't be added. Catalogue of Life has gone through several iterations so that their identifiers have changed, so anyone working on that dataset will want reassurance that the current identifiers are stable. Ultimately, I suspect people who see value in these databases will do the work to add them if they can, and if people don't see the value, they won't be added. Personally for me at the moment, none of these three databases is a priority. Others may feel differently. --Rdmpage (talk) 12:21, 3 February 2021 (UTC)
Project Grants Proposal: Wiki Loves Butterfly Phase-V
Hi Wikimedians,
Greetings from Wiki Loves Butterfly team. As you might know, for the last 4 years, we have been documenting butterfly taxon endemic to eastern and north-eastern part of India through the Wiki Loves Butterfly project. Our aim is to increase the amount of free license materials along with enrichment of related content on different Wikimedia sites. Our project has been previously supported by 4 Rapid Grants. Since the beginning of the project in 2016, we have gained considerable amount of expertise, maturity and confidence to successfully plan and execute field-documentations and expanded our area of activity in remote deep forests of North East India. But the range of activities in all of our previous endeavors were much restricted due to budget constraints, which has now encouraged us to apply for the Project Grants Program for the coming phase, for vaster and more extensive qualitative documentation related to the topic. The WLB team is requesting all interested Wikimedians to visit our Project Grants proposal and provide valuable feedback and suggestions here. If you feel this project proposal is eligible to get the grant, then you can endorse the proposal here.Thank you--Atudu (talk) 06:56, 3 February 2021 (UTC)
Neutral point of view
Hi, if we want to be neutral, as all our external sources have their own statements (parent, status, rank, ect...), we should retrieve all their statements without filters or judging them. See below a possibility on how to retrieve four different taxonomic "point of views" about the same name (the two first, ITIS and WoRMS faithfully reproducing, without filter or judgment, the information given by them, and the two last being inventions provided as examples):
In this model, taxon synonym (P1420), parent taxon (P171) and taxon rank (P105) are lowered as qualifiers, and additional qualifiers such as "Status" and "Accepted name" are needed, as well as an additional property "Other taxonomic source...". Advantage: all the "point of views" are perfectly retrieved, and finally there is not a single way to remain more neutral than that. Disadvantage: the Wikimedia projects infoboxes has to follow one and only one taxonomic tree (though I guess it should be possible to define what concept(s) to follow in priority). Christian Ferrer (talk) 07:47, 27 January 2021 (UTC)
@Christian Ferrer: I think "status" and "synonym" are redundant, if you view "synonym" as unidirectional (i.e., "is synonym of"). In other words, if a name is accepted, it is not the synonym of another name. If it is a synonym, then by definition it isn't accepted. This is essentially the model adopted by databases such as ITIS, GBIF, etc. Obviously in Wikidata any statement of synonymy needs a qualifier "according to". --Rdmpage (talk) 11:47, 27 January 2021 (UTC)
@Christian Ferrer: OK, let's try that again. I suggest that a way to model status is to have a property "accepted taxon" that has as its value the item for accepted taxon, and which needs a qualifier for what database/publication makes that claim. If, say, ITIS says name A is a synonym of name B, then name A has "accepted taxon" point to name B with a qualifier "ITIS". Names that don't have an "accepted taxon" property are by default, accepted. My concern is to avoid the redundancy of having both a property for taxonomic status and a property saying what the accepted taxon is. The more general point is that I think a lot of what people are looking for in Wikidata with respect to taxonomy is difficult to express as properties about an item, rather they are more properly thought of as the results of queries (e.g., all the synonyms of a species). --Rdmpage (talk) 12:14, 27 January 2021 (UTC)
Same thing without the status value (the third exemple being removed as became unuseful):
Let me show that the redundancy is not where you think, in the example above you have 15 values stored, if you want to retrieve exactly the same data as above with our current system you have only this possibility:
@Rdmpage: I let you see that our system currently need 22 values to do the exact same thing that I did with 15, furthermore my model is visually understandable by a child while our system is clearly not... Christian Ferrer (talk) 17:03, 27 January 2021 (UTC)
@Christian Ferrer: I'm sorry I guess I don't see that one is "visually understandable by a child" while the other is not (although I haven't done the experiment). But surely all the information in your preferred 15 row example is already modelled by Wikidata, it's just a different view of that data? This seems to conflate two separate questions: (a) what is the best way to model taxa, and (b) what is the best way to display that information. --Rdmpage (talk) 18:26, 27 January 2021 (UTC)
Regarding the first point I agree that I often have unfortunate way to express what I think, likely an English language gap to fully express my feelings, sorry for that. That being said I see my model as more simple and understandable than the other. And yes that is IMO likely (a) a better way to model taxa which leads to (b) a best way to display that information and (c) maybe also a best way to retrieve the data. I don't have much to add, and I will continue with the current system because I have not the slightest beginning of illusion that it can change. And this is well here its weak point. Take care. Christian Ferrer (talk) 18:44, 27 January 2021 (UTC) (note that with a difference of 7 values to retrieve the exact same data for only 3 sources and only one name, imagine with e.g. 30 sources, and for all the taxa....)
I corrected my example above because I actually forgot one value, it is in fact not 22 values that are needed but 23, this accentuates my example a little more. Christian Ferrer (talk) 08:04, 28 January 2021 (UTC)
Given the relationship between the (scientific) name and it's external id is fixed there is no guarantee the underling taxonomy has not changed over the time. The parent taxon could be more specific. Eg. tribe instead of family or subgenus instead of genus. Or vice versa. taxon synonym (P1420) could be changed too (widened/narrowed). In rare cases this is true for taxon rank (P105). Hence you have to add retrieved (P813) or an equivalent like software version identifier (P348). But in noteable databases (eg. IUCN, NCBI, NSR, NZOR, Dyntaxa, FishBase, ...) the external id refers a taxon concept labeled with the valid/accepted scientific name. So how would you handle this problem with your model, Christian? At the moment I can simply move the property value to another item (if exsists). --Succu (talk) 19:02, 28 January 2021 (UTC)
As I work often in Echinodermata topics, and especially within the class Ophiuroidea, as our current taxon tree is in most part built after ITIS, and as some major taxa groups within ITIS have not been reworked since the 1990's, I am perhaps the one who suffers the most in Wikidata that the taxonomy can change while our taxon tree not unless we do it manually. Trust me I'm fully aware. I understand your question but I can't really answer. Indeed, how my model is less modifiable than the current one? and why should'nt we able to move the property value to another item with my model as you can do? The issue of a potential update is exactly the same, and note that if we add retrieved (P813) (I'm not against that) at each stored value in the tables above my demonstration concerning the number of values is even more reinforced. In all case my model don't seems to be neither better nor worse regarding the update topic/issue.
That make me thinks to GBIF, takes exactly the exemple above: Ophiacanthidae, GBIF has one "main" record [1] within what they call the "GBIF Backbone Taxonomy", just below the map in that page the datasets are listed. Looks at the left list: the "Checklist datasets". If you make an analogy with our system:
and surprise, if on those pages you click on the link "classification" at bottom right, you will see that the parents are not the same, and that a little sentence is available at top "You are browsing: Integrated Taxonomic Information System".
The update topic apart, the two big differences with my model are:
1/if you count "GBIF Backbone Taxonomy" + ITIS + WORMS you have 3 pages (or 3 items for the analogy), while in my model ITIS and WORMS are statements with the data stored within qualifiers
2/that leads them to the second difference, they arbitrary chose one specific parent taxon for the main record within their "GBIF Backbone Taxonomy" (luckily they followed WoRMS). But the result is that "GBIF Backbone Taxonomy" is not realy neutral point of view. Hence the potential utility to lower the properties "parent" and "rank" as qualifiers for one specific source, specially if we store all the data about a name within only one item.
Regardind the update topic, I have no specific solutions for us, I have discussed only a very few time with GBIF staff, and I think to have understood that each dataset can be updated by their respective owners, and those changes are made available inside GBIF when they run a synchronization which I do not know the frequency but it's pretty regular because the last time I asked for an error to be corrected I only waited a few days if I remember correctly.
Ok, let's wait a bit, I'm going to built a full exemple that includes all identifiers excepted the ones you listed above. Waiting at my exemple, just looks a flagrant weak point of our system: [2], there is a taxon author as qualifier of the taxon name and a reference to ITIS, if you read the data as it is here (without going to ITIS to verify) you think "ITIS said that the taxon name is Ophiacanthidae and the author is Axel Ljungman", however this is wrong as ITIS give another author. The weak point is not that ITIS is right or wrong, the weak point is that it is very hard with our system to know what taxonomic source said what about what, especially when they are several values. I think that the use of "stated in" has its limits within the taxonomy topic. Because with several possible values for e.g. 4 statements, if you have 10 taxonomic sources which you want to store the data, the only way to know who said what is to have a "stated in" for each values of each statement and for each sources = a minimum of 4*10= 40 "stated in". And the qualifiers complicate the task a little more with the current system if we want to know where the data come from. Otherwise despite the fact that we have potentially a lot of identifiers for each names, it's hypothetical to know who said what about a specific name. E.g. for Ophiacanthidae you have 14 identifier (-2 if we remove the 2 that you listed above), it is currently impossible, by only reading Wikidata, to know who said what about what unless you follow the identifiers and that you go see yourself. And although it is not impossible, I am not sure that it is realistic to put a "stated in" each time, hence my model that takes the opposite way: the properties identifiers, though they are not used in the same way, have the role of "stated in" and all other properties having become qualifiers of those properties, you automatically know who said what, and furthermore with less values ("stated in" having become unuseful), and if needed we can of course use a "retrieved" to know the point of time. Christian Ferrer (talk) 06:07, 29 January 2021 (UTC)
@Christian Ferrer: I guess I'm confused because I think the existing system can do want you want without breaking the model, and without adding a whole host of qualifiers to identifiers. Why not use references to link assertions to sources? In other words, the parent taxon (P171) of Ophiacanthidae (Q3458700) is currently set to Ophiacanthina (Q51823418) with a reference to World Register of Marine Species (Q604063). If you want to include alternative classifications, just add more values for parent taxon (P171) linked to the appropriate sources. Then you can retrieve, say, the classification for Echinoderms based on World Register of Marine Species (Q604063) by including only parent taxon (P171) relationships from that database. To me it seems to be asking for trouble to bury information in qualifiers to identifiers (if identifiers have qualifiers, surely they should be about the identifier itself, not what it identifies?). To my mind, the display you want can be achieved by a query on the existing data. Hence I'd be in favour of keeping the model as it is, but adding sources for statements such as parent child links. This also means we can add additional evidence for those links in the normal way, for example if a paper comes out asserting a new parent child relationship, that can be added and linked to the source as a reference. Under your model we can't do that unless we add a new property for each publication(!). I think I've said this elsewhere, but I think one of the biggest challenges is to distinguish modelling data from querying it. Sometimes the solution is not to change the model, but have queries that display the data in they way you want. To me your preferred model is simply one way to view the data, one which can probably be generated by query on the existing data model. --Rdmpage (talk) 13:48, 29 January 2021 (UTC)
Of course I will go to the end, and I will do the same thing in another sandbox for our system of "stated in", and then likely Rdmpage will understand what I wanted to mean with "more understandable even by a child". Christian Ferrer (talk) 10:35, 29 January 2021 (UTC)
(WoRMS is also quite incomplete and seems wrong on the fact that Ophiacanthinae Paterson, 1985 have been raised to family rank, as the family already existed) There are two taxonomic different concepts, Ophiacanthinae Ljungman 1867 have never intended to be a child of Ophiacanthidae as it is currently stated in our item so if we push our "current model" in order to retrieve that concept we should add Amphiuridae (Q3276417) as parent taxon of Ophiacanthinae.
Ophiacanthinae Ljungman 1867 → is a child of → Amphiuridae Ljungman, 1867
Ophiacanthinae Ljungman 1867 → was raised to → Ophiacanthidae Ljungman 1867
Ophiacanthinae Paterson, 1985 → is a child of → Ophiacanthidae Ljungman 1867
Hence I thinks it is more easy to separate the infos of each sources. It is a kind of homonymy and both are currently unaccepted. Ophiacanthinae Ljungman 1867 having been raised to family rank maybe that makes the name "Ophiacanthinae" still available and this is why Paterson used it. Christian Ferrer (talk) 07:29, 31 January 2021 (UTC)
In a certain way the taxonomic concept Ophiacanthinae Paterson, 1985 is a child of the taxonomic concept Ophiacanthinae Ljungman 1867.... :) Christian Ferrer (talk) 07:53, 31 January 2021 (UTC)
Also a bit of explanation for the authorship of Ophiacanthidae Ljungman 1867 vs Ophiacanthidae Perrier 1891/93 (shown in my model):
Perrier was indeed the first who used literally the name "Ophiacanthidae" (as far I know there) and he did not give the authorship to Ljungman neither he refers to Ljungman, but it is well the concept Ophiacanthinae Ljungman 1867 that have been followed by the authors within the years, and is still followed regarding the characteristics of Ophiacanthidae (characteristics which may correspond to those put forward by Perrier, but it was Ljungman who did it first). In summary we can say "Perrier raised Ophiacanthinae Ljungman 1867 to Ophiacanthidae Ljungman 1867" though he did not do it explicitly (?nor was it really his goal as he don't refers to him?). Historically the authorship of the name have almost always be given to the original author of the concept: Ljungman 1867. Christian Ferrer (talk) 09:00, 31 January 2021 (UTC) (en:Ophiacanthidae is also wrong, Paterson did not raise the subfamily to the family rank)
Article 50.3 (ICZN): Authorship unaffected by changes in rank or combination. So the authorship for a scientific name within the family group (family, subfamily, tribe, ...) is allways „Ljungman 1867“. This is independent of the taxon concept described in a certain publication (sensu, sec.). So it's Ophiacanthidae Ljungman, 1867 sec. Perrier, 1891 and Ophiacanthinae Ljungman, 1867 sec. Paterson, 1985. In our current model we can handle this with a reference to the publication. The latest taxon concept of Ophiuroidea (Q59256) I'm aware of is Ophiuroidea sec. O’Hara et al., 2018.
Yes, thanks you Succu, I already noticed User:Succu/Ophiuroidea sec. O’Hara et al., 2018 a few days ago, good works! I also added User:Succu/taxobox.js to my common.js a few times ago, that is interesting ("instance of recombination" take all its meaning). Yes World Ophiuroidea Database is mostly maintened by 3 of the 5 authors of the article, they regularly add new taxa and quickly correct errors when they are reported. When your BOT will have ended I wonder if it will be possible to modelize that taxon concept with a querry. Christian Ferrer (talk) 22:31, 5 February 2021 (UTC)
Verrill's publication(s)
Hi, this is about the following publication:
Verrill, A.E. (1868-70) Notes on Radiata in the Museum of Yale College, with descriptions of new genera and species. No. 6. Review of the Corals and Polyps of the west coast of America. Transactions of the Connecticut Academy of Arts and Sciences. 1(2): 377-558 BHL
It appears that this publication have been made within 3 years (1868-69-70), and that affects the author citations for the taxa concerned. You can see the reference for such a claim in the templates I made in Wikispecies Verrill, 1868, Verrill, 1869 and Verrill, 1870. My question is: is it better to create one item or 3 items. Me I would tend to create 3 items such as "Notes on Radiata in the Museum of Yale College, with descriptions of new genera and species. No. 6. Review of the Corals and Polyps of the west coast of America [1868: p.377-422]", ect.... Ideas? Christian Ferrer (talk) 13:44, 23 February 2021 (UTC)
@Succu: you don't understood, you're right that "Notes on Radiata in the Museum of Yale College..." is divided into 9 parts, and yes of course each should have an item. The problem being that the part number 6 (maybe others too, but me I talk about the 6) have been published in 3 parts, therefore the date of publication of the taxa published within the part number 6 have 3 different years according the pagination. My question is: should the part number 6 have 3 items or one? But maybe you understood my question but your answer is "no just do one item", but in that case, how to retrive the 3 different years of publication within one item? Christian Ferrer (talk) 20:00, 23 February 2021 (UTC)
In fact this shema is already followed by the major sources as ITIS and WoRMS though it is not explained as well as I tried to do it within the templates in Wikispecies. A few years ago I found that page where that article number 6 is divided into 3 parts, and I asked clarifications to WoRMS editors about the dates for the taxa within this publication, sadly I did not keep the mail and I don't remember exactly what was said, but that was after that discussion that I created the 3 templates aboves. I remember that it was Stephen D. Cairns (Q18238018), who is editor for that taxa group both in ITIS and WoRMS, who gave me Bayer (1977) as additional reference, explaining to me that Bayer was a respected and respectable authority. Sadly Bayer passed away and I've no idea to how he got the infos, but concretly this shema is already followed by almost all editors of that taxa group. E.g. Rhizopsammia pulchra from page 510 is dated from 1870 for both ITIS and WORMS, Muricea fruticosa from page 428 is dated from 1869 for both ITIS and WORMS, ect...
Excepted for a very few taxa this is that is already applied in the reality by our sources, the thing that I want is to retrieve that in Wikidata and in a way that a reader can understand it quite easily if possible. Christian Ferrer (talk) 21:11, 23 February 2021 (UTC)
Maybe with something like that and giving as reference (Bayer, 1977) and (Breedy & Guzman, 2002) for each claim:
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Some major taxonomic databases aren't actually supported and it feels unclear if there is a specific reason to it or if it simply never was discussed.
Adding a list of already evaluated databases and reasons why they were rejected/included would be great.
My question is more specifically about:
i) Open Tree of Life (OTL: https://tree.opentreeoflife.org)
ii) Leipzig Catalogue of Vascular Plants (LCVP: https://idata.idiv.de/ddm/Data/ShowData/1806)
iii) Catalogue of Life (CoL: https://www.catalogueoflife.org)
Question can retrieved (P813) help for potential update made by BOTs? and sorry for my long answer. Christian Ferrer (talk) 20:42, 28 January 2021 (UTC)
Done I'm done, well maybe I'll add some changes, but it would be marginal. Good reading! Christian Ferrer (talk) 20:07, 29 January 2021 (UTC)
