search

CatalogueOfLife / checklistbank

UI for checklistbank.org
https://www.checklistbank.org/
6 stars 2 forks source link

Merge name and taxon details page #85

Open mdoering opened 5 years ago

mdoering commented 5 years ago

The taxon page mostly shows associated data like vernacular names now. Names information incl publication reference and name relations are not shown. Also other taxon properties seem to be missing:

thomasstjerne commented 5 years ago

Are they in the /dataset//taxon/ endpoint all of them, or where do I find them? (the status is I know) If you have a nice example, please post it here

thomasstjerne commented 5 years ago

All name details from /name route should be on taxon

mdoering commented 5 years ago

show key name properties for each synonym too, ideally in a single line, not a table:

Consider to show all other name properties on demand (+) or in a dedicated page: name relations, verbatim data, homotypic group, code, origin, issues, name type, remarks

thomasstjerne commented 5 years ago

@mdoering can you point me to a name in the api that has some relations?

mdoering commented 5 years ago

The ColDP Example dataset 1600 should have some

mdoering commented 5 years ago

Haha, this is the only one I can spot: http://api.col.plus/dataset/1600/name/1006/relations

mdoering commented 5 years ago

Its findable both directions even though relations are directional: http://api.col.plus/dataset/1600/name/1006-s3/relations

thomasstjerne commented 5 years ago

I cant see the name status in the response https://api-dev.col.plus/dataset/1010/name/Fis-147647 even though it is present in the verbatim data. However, since the synonyms endpoint is grouped into homo - and heterotypic and misapplied, the status is more or less obvious when listed in those categories?

mdoering commented 5 years ago

There is no name status in the verbatim, the terminology is misleading. Sp2000NameStatus is the taxonomic status and the 5 allowed values are indeed represented by taxon.provisional and synonym.status

The name status has different values and is dealing with nomenclature only: http://api.col.plus/vocab/nomstatus

It's null in most cases currently

mdoering commented 5 years ago

What about Taxon.origin? https://www.col.plus/dataset/2044/taxon/.Bk3M https://api.col.plus/dataset/2044/taxon/.Bk3M

And how should we get to verbatim data and issues? Should issues not already show on the details page?

https://www.col.plus/dataset/2044/taxon/Lamprostiba_pu!chra https://api.col.plus/dataset/2044/taxon/Lamprostiba_pu!chra https://api.col.plus/dataset/2044/verbatim/5452939

mdoering commented 5 years ago

How about rendering AccordingTo and AccordingToDate in one row just as AccordingTo NAME, DATE?

mdoering commented 5 years ago

Please see also https://github.com/Sp2000/colplus-backend/issues/253

thomasstjerne commented 5 years ago

Most of it is on the name page now, you get to it by clicking the button on top of the taxon page: https://www.col.plus/dataset/2044/name/Lamprostiba_pu!chra

mdoering commented 5 years ago

The taxon details still misses out some key data like the rank, publishedIn, name status and more which you can only find in the names page.

There is not much benefit from showing redundant information or pure ids like the atomised name fields, homotypic and name index ids. But why not show all interesting name information already on the taxon page, maybe in a dedicated "nomenclatural" section?

Maybe we should even avoid having a name details page at all but instead go with the NameUsage idea we use for searching and render these. There we have 3 classes of name usages, a Taxon, a Synonym or a BareName being just a name record.

mdoering commented 4 years ago

reopening to show all name details on the taxon page. having an extra name details page is rather annoying, we should show all details maybe similar to the verbatim data in a collapsable section.

Can we still have a name page to show details for Bare Names and share the UI component somehow?

mdoering commented 4 years ago

There is also an issue to show decisions and type material infos on a taxon page.

mdoering commented 3 years ago

Maybe we should even avoid having a name details page at all but instead go with the NameUsage idea we use for searching and render these. There we have 3 classes of name usages, a Taxon, a Synonym or a BareName being just a name record.

@thomasstjerne do you see any reason not to have a single /nameusage route that can show a taxon or synonym? There is a unique nameusage id and it is the kind of object you also get from the searches. It also allows to show verbatim data for synonyms which currently is very unaccessible. And does away with the rather simple name page. I am not entirey sure about the route name. The API calls it /nameusage, but it is rather long. Personally I mostly just call it /usage, but that might be misleading? In GBIF we settled on /species which isn't great either. TDWG now calls these things TaxonomicNameUsage.

BareName links from the search might pose a problem as they are not really name usages, but just names without a usage and therefore do not have a usageID but just a nameID. Probably we should keep a route for just a name, but I would not mind to ignore BareNames for now and simply not link them in the name search for now. They are very rare and rather special.

thomasstjerne commented 3 years ago

@thomasstjerne do you see any reason not to have a single /nameusage route that can show a taxon or synonym? There is a unique nameusage id and it is the kind of object you also get from the searches. It also allows to show verbatim data for synonyms which currently is very unaccessible. And does away with the rather simple name page. I am not entirey sure about the route name. The API calls it /nameusage, but it is rather long. Personally I mostly just call it /usage, but that might be misleading? In GBIF we settled on /species which isn't great either. TDWG now calls these things TaxonomicNameUsage.

BareName links from the search might pose a problem as they are not really name usages, but just names without a usage and therefore do not have a usageID but just a nameID. Probably we should keep a route for just a name, but I would not mind to ignore BareNames for now and simply not link them in the name search for now. They are very rare and rather special.

I must admit I have some reluctancy about merging taxon and name pages. Using my "software dev / database admin" lens it would be more or less OK, and maybe also for hard core taxonomists who fully get the relations between names and taxa. But I think many biologists, citizen scientists, decision makers etc really would expect to see a taxon page, with a list of synonyms.

I have never been very happy about GBIF having separate pages for synonym usages which produces distribution maps for a nameusage - not a taxon. Except if you happen to hit the usage page for the accepted taxon, then you see a distribution map for the taxon. In the Checklistbank / clearinghouse a synonyms name page is currently only one click away from the taxon page. In the name search Synonyms used to point to the name page rather than the taxon page, we could do that again and display the usage (link to accepted) more prominently.

Likewise, we could also show other usages than the accepted on the name page, like misapplications (treatments, etc).

mdoering commented 3 years ago

I think there is a misunderstanding. We definitely need taxon pages like we currently have that show the synonymy, vernaculars etc. My proposal is to:

Synonyms and taxa both share the same identifier namespace, names do not and could potentially clash. A synonym page should never show all the information we have for taxa. Vernacular names, distributions, media etc is only available for taxa. You cannot access such infos in the API as it clearly separates taxa from synonyms.

dhobern commented 3 years ago

Regarding this proposal, I have a personal opinion and one that may be more political.

My personal opinion is that 99% of the time we claim to be referring to taxa, we are really just talking about an accepted name and a set of names we treat as aliases for that name. The ludicrously simple (and easily understood) old COL model where everything is a name with a second set of fields that represent the currently accepted name and classification for the relevant species, and where we don't have separate taxa, has a lot to offer. The downsides I can see are:

  1. There is no standard way to express different perspectives on synonymy and classification. It would however not be hard to have an optional table with rather few elements for offering alternative classifications for some or all of the tree. The main name table would show the preferred and default view.
  2. Names in each group (species-group, genus-group) can be reused with an altered rank (varieties can become subspecies or species, subfamilies can become tribes, etc.). We would need to treat each different ranked usage as a separate name (but that's pretty much what we do now anyway).
  3. Not sure there's anything else major.

The political consideration is that much of our community UNDERSTANDS that names are not taxa and wants to shift to a taxon-concept model. If we seem to be treating names as the only unit of taxonomic currency, some significant pundits will reject what COL is doing.

The redundancy in having separate Name and Taxon tables (or else the opaque nature of the Taxon table) is a challenge and I would be quite happy to see a general collapse into a single table. For me, however, the only real benefit would be that I could treat Distribution, SpeciesInteraction, etc. records as associated with a name, allowing them to remain correctly attached if the synonymy changes. Right now, if a Taxon comes to be considered a Synonym, any Taxon-linked data elements have to be migrated to link to the accepted Taxon. If the Taxon is subsequently split back, it will be a real pain to determine which of this information needs to revert to the original Taxon. In practice, most such information is really tied to a name, not a taxon.

mdoering commented 3 years ago

thanks @dhobern. I was not proposing to change the API and data model we have in place. That would have really large knockon-effects. Tying associated information to a synonym would be such an API change (although on the database level it is actually already possible).

The issue here is targeting just presentation and available human links.

Personally I would actually prefer to refactor the API and deal with flexible NameUsage instances that can be a synonym or a taxon and have embedded name information. Just as we did in ChecklistBank before, that worked very well. And it is supported by ColDP and not alien to the TDWG TNC group either.

dhobern commented 3 years ago

Sorry - my mistake. Do you therefore have in mind that changing a taxon to a synonym or vice versa could be a simple matter of changing some of the elements in a record? This would address the need I indicated for somewhere safe to anchor taxon-related information. It would also mean that every synonym/taxon would have a unique ID in the same namespace.

One question is what cardinality is support for the relationship between Names and NameUsages.

If we want to be able to represent multiple alternative classifications via alternative NameUsage records, we presumably need to design a new element that allows each NameUsage to be associated with one of these classifications. Constructing a classification would then be a matter of filtering the NameUsages to one classification.

On the other hand, if we don't wish to support multiple classifications, I assume that each Name should be associated with at most one NameUsage record that represents a taxon. However, pro-parte synonyms mean that we still have to allow for a Name to be associted with multiple NameUsage records where these represent synonyms. I'm not sure whether this inconsistency is workable.

In other words, our current perhaps over-painful model is unambiguous for our core use cases. We would need to consider what patterns of usage we want to support if we go down the NameUsage path.

mdoering commented 3 years ago

Agree. In GBIF CLB the pro parte name usages kept a pointer to an artificial "primary pro parte usage" that was grouping them so clients understood they share the same name. A nameID property would work to group them.

Supporting alternative classifications is another elephant in the room. Having a multi dataset model you can obviuously have as many alternative classifications in different datasets. Having alternative classifications in COL would mean either additional taxa sharing the same name. Sharing associated informations like vernaculars is a problem then as these are tied to taxa. If we separate out just the classification, essentially just the parentID, I am not sure what these would link to and where to attach distribution to for example. I am worried you cannot untangle that cleanly.

@thomasstjerne just spotted a pain with name relations pointing to names, not usages: https://github.com/CatalogueOfLife/backend/issues/872 When you have to deal with both name and usage ids you often need to go back and forth between them. In your Alucita xanthozona example it links to a basionym. Would you not want to show a link to that basionym that gives more information on its publication, its taxonomic and nomenclatural status and list e.g. all subsequent combinations? Is it then not better to resolve this name relation to a name usage instead of having a names page that in turn link to all usages for that name?

Moving between Name and NameUsage ids is inconvenient and difficult to sell to a user

mdoering commented 1 week ago

A simple improvement for now would be to replace the tabs on the usage detail page with a menu like in import metrics and offer:

this also allows to link to individual menu items which you cant do with the current deprecated tabs. The verbatim page needs to show both taxon and name records just as we do already on the right hand side.