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

Critical conceptual error #26

Open
Archilegt opened this issue Sep 15, 2022 · 1 comment
Open

Critical conceptual error #26

Archilegt opened this issue Sep 15, 2022 · 1 comment

Comments

@Archilegt
Copy link

Archilegt commented Sep 15, 2022

The following example is conceptually incorrect, at least in the sense of the ICZN:

Example 2: 'Aus bus is a synonym of Bus cus' Start by answering the initial question, one, or two names? Your assertion is the name 'bus' is a synonym of 'cus'. Note the assertion is not "Aus bus" is a synonym of "Bus cus". The relationship between "Aus" and "bus" is itself another assertion. While there are finer levels of granularity using the expression bus http://purl.obolibrary.org/obo/NOMEN_0000307 (ICZN Synonym) cus will work. When making an assertion of "synonymy" (in some general sense) the "incorrect" (for lack of a better cross-nomenclature label) name is on the left (i.e. the subject), and the "correct" name is on the right (i.e. the object). NOMEN includes domain and range assertions in its object properties. In this case the instance in the domain (left side of the expression) is classified as http://purl.obolibrary.org/obo/NOMEN_0000226 (ICZN Invalid).

Incorrect use of terminology, conducing to an incorrect example:
Your assertion is the name 'bus' is a synonym of 'cus'. This is against the Code, because 'bus' and 'cus' are not names, they are specific epithets. One of the most important principles in the Code is the Principle of Binomial Nomenclature. You can model genus and specificEpithet separately if needed, but if you want NOMEN and the examples to be Code compliant (at least with the ICZN) and to not generate confusion, then the example should refer to the relation between actual names, not specific epithets: "The binomen Aus bus is a synonym of Bus cus."

Incorrect direction of synonymy:
The assertion 'Aus bus is a synonym of Bus cus' is direction-neutral and does not reflect which name is incorrect. In natural language, the assertion "Scolopendra cubensis is a synonym of Scolopendra alternans" is true, while the reverse is also true. It is the nature of the priority (another important principle, the Principle of Priority) of each synonym what gives information on "correctedness". In natural language, "Scolopendra alternans is the senior synonym of Scolopendra cubensis". In that sentence, the name on the right (i.e., the object) is invalid (= incorrect) in the sense of the ICZN, while the name on the left is valid (= correct), as opposed to your example.

@mjy
Copy link
Member

mjy commented Sep 15, 2022

Thanks for drawing attention to this @Archilegt. We'll refactor the terminology here so that it better reflects the difference between a) the rules of nomenclature and b) how to encode data that represents nomenclature using NOMEN. Many different ways of encoding the data are possible, NOMEN provides one way. Since the ICZN was not designed as a data-representation model (for example these fields can be used to represent this name) interpretations of how to store data vary greatly. I.e. encoding the information is different from how it is "rendered" to the user or how the result in interpreted under the ICZN. Here, as you note, we blur the language between these two concepts.

Your assertion is the name 'bus' is a synonym of 'cus'.

We are using the word "synonym" in a global sense here, much like what you would see for CoL, where all forms of synonym must be "merged" into a single operational representation.

This is against the Code, because 'bus' and 'cus' are not names, they are specific epithets.

We should perhaps better describe this as "monomials", because NOMEN uses monomials as a way to encode data that are interpreted as the rules.

Incorrect direction of synonymy:

You're right, we are introducing junior and senior concepts here with our use of directionality, again I feel that this is our poor use of language to distinguish between encoding, and interpreting. It is much simpler to explain to the average user (and to code) knowing that the encoding asserts that the invalid name is on the left, and the valid on the right- at that moment in time. Each statement is historical, not necessarily current. We must accumulate all assertions, then figure out what the true "senior" is at the present moment in time.

Will keep reflecting on this and look at updating the text, thanks again.

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