-
Notifications
You must be signed in to change notification settings - Fork 1
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
Semantics of class hierarchy is inconsistent #14
Comments
At first glance I think this is a label issue and the semantics are OK in this specific case. When I classify my data with this status, then we can inferr the thing I am classifying is a ICZN name. Our curators want so see the label "ICZN Official List of Works Approved as Available" as a specific option/choice for assigning that class (there is very specific meaning related to the Official List bit). There may be other official list related status in other codes (there are in fact), we need to differentiate reference to those codes. Does this make any sense? |
I'm not a nomenclator 😄 I think a certain kind of name of a certain nomenclator being inferred as a name from that nomenclator makes perfect sense. That a list of works is a name does not. I.e., is it true that "ICZN Official List of Works Approved as Available" is_a "biological name". If yes, then maybe work on the label such that the word "name" is in there and has primacy (e.g. "name from ICZN Official List of Works Approved as Available", even if that's a mouthful). If no, then separate the semantics of different types of names from the nomenclatural status that these names have, the kinds of nomenclators that use that type of name, and the kind of lists of works in which these types of names are included. Almost everything in biology can be classified along multiple semantic axes. It's very instructive how, for example, the GO deals with this kind of problem (and also UBERON). In short, the asserted subclass hierarchy is along whatever is chosen as the main axis, and property restrictions assert hierarchies along the others. (E.g., |
You are exactly right in interpretation. Our intent is not to assert that the name is in a list, it is to assert that there is a status that comes to be because a name is placed in a very particular type of list. We do not want to find the set of things in the list, we want to infer the consequences of some status related to being in the list. We'll try and clarify this issue by 1) improving this label ("Name in ...", and 2) adding a defintion that reflects this discussion. |
There are several places in the class hierarchy for names and for ranks where lists of things are interspersed inconsistently in a hierarchy of things. The issue here may be more on finding a proper label and definition that resolves the inconsistency than actually rearranging the structure. That said, using class hierarchy to record membership in a subset of the ontology is poor practice if that's what this is for; OBO ontologies use subset definitions ("slims") for that.
Examples are
NOMEN_0000025
("ICZN Official List of Works Approved as Available") being a subclass (transitively) ofNOMEN_0000107
("ICZN name"), which asserts that an official list of works is_a "ICZN name", and (by transitivity) a "biological name". Perhaps from a nomenclator's point of view this isn't even necessarily untrue, but it certainly is very weird semantics otherwise. Similarly for the "subdivisions" that are under the rank class.The text was updated successfully, but these errors were encountered: