Closed mdoering closed 4 years ago
You hit the nail on the head, we left out order specifically because we saw so many conflicting representations came in from legacy datasets, and because it's not governed, contrary to what many people may think. You can think of it as "we only manage rules that are rules" in NOMEN.
Rank ordering is for the most part a presentation layer problem. We do have these rules in TW that we could use as the basis. I'm relatively sure that we don't want that layer in formal NOMEN, but it could go into something like /community
here or elsewhere?
It is called rank because it is ordered. So the ordering is really a core property of ranks - even though some of them are disputed or differ between codes. There is a lot to reason when knowing the expected order. But this is more a taxonomic exercise, not so much nomenclature, so I understand if you do not want to include it.
Points taken, somewhat of a label/concept issue going on :). As you note in as much as order is dictated by Rules then we should capture that formalism in NOMEN.
I'm not saying we shouldn't capture more, but you definiteyl get the drift. Every new "axis" we add so to speak means more to curate, debate and discuss. I, personally (being very biased), have zero desire to argue whether nanorder is higher or lower than parvorder or nonorder, or what they mean. The ICZN didn't care, and not just didn't care, in their wisdom realized they couldn't or shouldn't control such things. They didn't just come to some conclusion I suspect, but rather there was a lot of discussion as to what/not to do. Seems like a historical lesson there.
One other bit about ranks in NOMEN. They exist here primarily to ensure that rules that must be applied when an assertion that some name is at some rank can be organized logically. Since 'nanorder' vs 'parvorder' include no difference in the rules that must be applied as stated by the code, then, as we noted, only a presentation issue remains.
What is the preferred property to record the parent rank? Description::SubClass Of::Instances ??? Is this the right place to put a preferred parent rank?
It looks like I can add a second SubClass Of property for each rank. Is it reasonable?
I don't think you should add another subclass, that implies always. It will likely be another annotation property, I have to ask.
Added a 'rank parent' annotation.
There might not be a full agreement on how to order all ranks, but providing a standard ordering would be very useful