Allow taxonomic units to record additional information about specimens

[gaurav]

There is a clear difference between a specifier that points to a scientific name and one that points to a specimen that has been identified to a scientific name.

We would like to extend this to document all the information included about the specimen in the paper, such as scientific name, GenBank identifiers to particular genes, locality information and so on. Note that we can use an external identifier to identify a specimen when the specimen is the taxonomic unit, but in some cases, we will want to use a URI to clarify which specimens are included in a taxonomic unit circumscribed by a taxon concept or taxonomic name.

Also add support for specimens that are included solely on the basis of a genetic sequence, i.e. make sure we can include a sequence itself if necessary. This might be useful in environmental genetic surveys or bacterial phylogenies.

[gaurav]

I don't think we need this any more -- most phyloreferences use a phrasing like "the type specimen of [species name]" rather than a specimen identifier, and we haven't seen any references to GenBank IDs or locality information in a clade definition yet. Once we get to environmental genetic surveys or bacterial phylogenies, we can consider other forms of specifiers than taxa and specimens or the storing of additional information in the Curation Tool. But for now, I'm going to close this until we have a clear use-case for developing this.

[hlapp]

I'd suggest that closing an issue be kept to have relatively clear and simple semantics. Usually this means "it's done", either in the sense of work having been done that addresses the issue sufficiently well, or a conclusion having been made that it is not necessary to address it, or that it is poorly scoped (needing either to be split into, or to be combined with other issues).

I would argue that deferring work is different from that, in the sense that for work that's deferred we assume we will come back to it in the future, only when in the future hasn't been decided yet (and may not be decided for a while). I.e., deferred work is work that we continue to find worth doing. In contrast, closed issues shouldn't need to be revisited other than perhaps for the purposes of annual reporting, because they're done.

Your explanation for closing sounds to me like an argument for deferring. Perhaps I misread that, but if that's indeed what you meant, let's not close this but instead use labels (and/or possibly a pseudo-milestone) to mark deferred issues.

[gaurav]

Sounds good! I'd classify it as "deferred indefinitely" -- i.e. after thinking this through, I can't imagine that it will ever be in scope for the Curation Tool. But it definitely doesn't meet your criteria of "it's done" (and I could be wrong!), so I'll reopen it and tag it as "wontfix" instead. Will that work, or should we have a new tag specifically for "deferred indefinitely"?

[hlapp]

Well, "I can't imagine that it will ever be in scope for the Curation Tool" is in the category of "conclusion having been made that it is not necessary to address it", no?

So, if that was your intent, closing the issue seems the right action, as does labeling with wontfix.

However, your argument for closing says But for now ..., which is counter to deferring indefinitely. Perhaps you're trying to say that wasn't well worded?

[gaurav]

You're right, I worded "deferred indefinitely" poorly: I wasn't thinking about deferring the issue indefinitely, but only until we had a good use case for implementing it. Keeping it open in wontfix makes it clear that we considered this feature and determined that it was not worth pursuing, but that we could be convinced to pursue it in the future if we have a better idea about exactly where how this feature would be useful. So maybe "deferred for the foreseeable future"?

I'm also pretty hesitant to close things myself, as I might be forgetting something in our wider plan which means that something is more in-scope than I think. So I'm going to add "Should we close it?" comments when I feel like an issue should be closed. If either of you PIs agree, you can just go ahead and close it at that point!