-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
taxon-accession automatic link to accepted #456
Comments
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
<#444> and #445
<#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)
<#92 (comment)>.
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
<#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":"#456"}}} [
{ ***@***.***": "http://schema.org", ***@***.***": "EmailMessage",
"potentialAction": { ***@***.***": "ViewAction", "target":
"#456", "url":
"#456", "name": "View
Issue" }, "description": "View this Issue on GitHub", "publisher": {
***@***.***": "Organization", "name": "GitHub", "url": "https://github.com"
} }, { ***@***.***": "MessageCard", ***@***.***":
"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": ***@***.***", "facts": [ { "name": "Repository: ",
"value": "Ghini/ghini.desktop" }, { "name": "Issue #: ", "value": 456
} ] } ], "potentialAction": [ { "name": "Add a comment", ***@***.***":
"ActionCard", "inputs": [ { "isMultiLine": true, ***@***.***": "TextInput",
"id": "IssueComment", "isRequired": false } ], "actions": [ { "name":
"Comment", ***@***.***": "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",
***@***.***": "HttpPOST", "target": "https://api.github.com", "body":
"{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\":
\"Ghini/ghini.desktop\",\n\"issueId\": 456\n}" }, { "targets": [ {
"os": "default", "uri":
"#456" } ], ***@***.***":
"OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe",
***@***.***": "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 #92 (comment).
The text was updated successfully, but these errors were encountered: