SpeciesFileGroup / nomen

A nomenclatural ontology for names (not concepts).
The Unlicense
11 stars 1 forks source link

rank ordering #17

Closed mdoering closed 4 years ago

mdoering commented 4 years ago

There might not be a full agreement on how to order all ranks, but providing a standard ordering would be very useful

mjy commented 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?

mdoering commented 4 years ago

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.

mjy commented 4 years ago

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.

proceps commented 4 years ago

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?

proceps commented 4 years ago

It looks like I can add a second SubClass Of property for each rank. Is it reasonable?

mjy commented 4 years ago

I don't think you should add another subclass, that implies always. It will likely be another annotation property, I have to ask.

proceps commented 4 years ago

Added a 'rank parent' annotation.