Skip to content
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

Open
hlapp opened this issue Dec 13, 2018 · 3 comments
Open

Semantics of class hierarchy is inconsistent #14

hlapp opened this issue Dec 13, 2018 · 3 comments

Comments

@hlapp
Copy link
Contributor

hlapp commented Dec 13, 2018

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) of NOMEN_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.

@mjy
Copy link
Member

mjy commented Dec 13, 2018

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?

@hlapp
Copy link
Contributor Author

hlapp commented Dec 13, 2018

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., name from ICZN Official List of Works Approved as Available subclassOf (ICZN name and part_of some Official List of Works Approved as Available); ICZN name subclassOf (biological name and governed_by value ICZN).)

@mjy
Copy link
Member

mjy commented Dec 13, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants