Open mfrasca opened 5 years ago
Op 18-10-18 om 00:38 schreef Mario Frasca:
This is an idea based on a comment from @Ejgouda https://github.com/Ejgouda (»The record need to stay in the database, not to loose any information, but to the outer world it does not exist«), and definitely related to the two issues see #444 https://github.com/Ghini/ghini.desktop/issues/444 and #445 https://github.com/Ghini/ghini.desktop/issues/445 from @RoDuth https://github.com/RoDuth.
When you have Accessions linked to a Taxon, and the Taxon gets status of Synonym, with an accepted Taxon elsewhere, what's the point of having to perform any changes in the database when your goal is to guarantee that your reports (e.g.: labels) contain only accepted taxa? We have software, and we're rightfully lazy: isn't it much easier to use a global setting similar to the existing 'include synonyms'?
My taxon records can point to the correct taxon when synonym, which is probably not the nicest, but the easiest solution.
Maybe an nicer solution would be to have taxon records, with attached name records, so you get a pool of names pointing to one taxon record and one of them is flagged the correct name. When you flag an other name the correct one, all others in the pool will be un-flagged. Identification records just point to name records, not taxon records and indirect all point to the same taxon record. A taxon record can have a name field too, which will make the queries easier.
The problem of this later solution is that you have an extra table, which does not make it easier and you have to split taxon records when synonym name becomes current again. Probably accession records will point to the taxon records and need to be sorted out too.
I can not use this specific solution (with the extra intermediary table), because the Taxasoft MySQL interface is not a specific Taxonomic interface and can be used for all kinds of relational databases. All Taxonomic functionality is added in a modular way. The interface it self, does not know anything about the database it is working with. This functionality is not included in the source, which has it restrictions, but makes it incredible flexible.
Expected behaviour
the software helps you link directly with the accepted taxon, unless you really want the one used originally. something like the |redirect| feature in wikipedia, like for the Ghini https://en.wikipedia.org/w/index.php?title=Ghini&redirect=no page.
for example, /Parasieranthes toona/ synonym of /Falcataria toona/. what already happens if you you look for |Par too|, you get both the matching taxon and its accepted form in the results list.
The idea would be that all your accessions mentioning either of the two be reported as accessions of the accepted F. toona, regardless to which of the two they are linked.
My accessions have one or more identification records and is linked to the correct taxon record automatically, based on most current identification. In herbarium specimen, you must choose the accepted identification, which is different. In this case accessions always point to the right name and visa versa.
From the opposite end, both taxa would show the complete list of accessions.
Advantage? in case your taxonomists decide that the accepted taxon is the other and not the one, you only reverse the link and your reports will show P. toona with no further intervention on the database.
particularly useful for authonyms #92 (comment) https://github.com/Ghini/ghini.desktop/issues/92#issuecomment-429524184.
In my solution an autonym will be synonymized when all other sister infraspecific taxa are synonymized and thus, accessions will automatically point to the right taxon again. This solves a lot of problems, for example when a new sister infraspecific taxa is crated, all identifications are still in tact and the attached accessions will automatically point to the autonym taxon again.
Just some thoughts:-)
Eric
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ghini/ghini.desktop/issues/456, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdSyjcia2zHoRTCWE7vvV8kXQwZOAaCks5ul7FegaJpZM4XqXkY.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/Ghini/ghini.desktop","title":"Ghini/ghini.desktop","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/Ghini/ghini.desktop"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"automatic link to accepted (#456)"}],"action":{"name":"View Issue","url":"https://github.com/Ghini/ghini.desktop/issues/456"}}} [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/Ghini/ghini.desktop/issues/456", "url": "https://github.com/Ghini/ghini.desktop/issues/456", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } }, { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB", "title": "automatic link to accepted (#456)", "sections": [ { "text": "", "activityTitle": "Mario Frasca", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@mfrasca", "facts": [ { "name": "Repository: ", "value": "Ghini/ghini.desktop" }, { "name": "Issue #: ", "value": 456 } ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"Ghini/ghini.desktop\",\n\"issueId\": 456,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close issue", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"Ghini/ghini.desktop\",\n\"issueId\": 456\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/Ghini/ghini.desktop/issues/456" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 396982552\n}" } ], "themeColor": "26292E" } ]
I like the idea of the "taxon table" (to paraphrase). Makes me think of the approach in Darwin Core, e.g. taxonID and scientificNameID also this issue from a while back Bauble/bauble.classic#234 about storing the LSID for a taxon which aligns with Darwin Core's scientificNameID I believe.
It's always worth a look at any of the TDWG standards, particularly DwC and ABCD (and of course ITF2 - which is now largely a part of ABCD and DwC).
This is an idea based on a comment from @Ejgouda (»The record need to stay in the database, not to loose any information, but to the outer world it does not exist«), and definitely related to the two issues see #444 and #445 from @RoDuth.
When you have Accessions linked to a Taxon, and the Taxon gets status of Synonym, with an accepted Taxon elsewhere, what's the point of having to perform any changes in the database when your goal is to guarantee that your reports (e.g.: labels) contain only accepted taxa? We have software, and we're rightfully lazy: isn't it much easier to use a global setting similar to the existing 'include synonyms'?
Expected behaviour
the software helps you link directly with the accepted taxon, unless you really want the one used originally. something like the
redirect
feature in wikipedia, like for the Ghini page.for example, Parasieranthes toona synonym of Falcataria toona. what already happens if you you look for
Par too
, you get both the matching taxon and its accepted form in the results list.The idea would be that all your accessions mentioning either of the two be reported as accessions of the accepted F. toona, regardless to which of the two they are linked.
From the opposite end, both taxa would show the complete list of accessions.
Advantage? in case your taxonomists decide that the accepted taxon is the other and not the one, you only reverse the link and your reports will show P. toona with no further intervention on the database.
particularly useful for authonyms https://github.com/Ghini/ghini.desktop/issues/92#issuecomment-429524184.