Practical ontology in the style of Barry Smith has learned from computer science and many other sciences, especially efforts in medical and biological ontology. They work with formal ontologies using RDF and automatic reasoning. It’s fascinating to read about.
Thanks for making that connection. I have a PhD in philosophy and now my career is working with the biological and biomedical ontologies you’re talking about: http://obofoundry.org. Happy to answer any questions.
It has certainly been my experience that philosophy and programming have a lot to teach each other.
Very cool! I’ve only sporadically read some books and articles about BFO. Before that, my interest in conceptual modelling was stimulated by Christopher Alexander (community-driven pattern languages for architecture) and Eric Evans (domain-driven design for software).
I’d be super curious to hear just what kind of problem you’re working on at the moment, or some recent success (small or large) in ontological modelling or problem-solving that made you feel excited about being in the field. :)
My graduate work was in philosophy of science. Along the way I learned to program, and like the author of the article I still really enjoy the challenge of breaking a problem domain into clean, orthogonal pieces, then writing code to make the solution actually work. Now I’ve found a niche where I can combine technical and conceptual skills to help scientists do better science.
I’m deeply involved in the Open Biological and Biomedical Ontologies community, which brings together a large number of open source, scientific ontologies under a set of shared best practises. I contribute to several ontologies, including the Ontology for Biomedical Investigations. My main client is the Immune Epitope Database, where I help with data integration and validation. I’m most excited about building tools to help scientists develop and work with ontologies and linked data. Two examples of that are ROBOT and Knotation (work in progress).
It’s not my work, but one of the most impressive examples in this area is the Monarch Initiative. They’ve been able to integrate genotype and phenotype data across multiple model organisms to help understand rare diseases in humans. Much harder than it might sound!
Knotation looks really good. It reminds me a bit of Inform 7, which by the way also has a pretty interesting basic ontology.
It seems somehow obvious that “IT systems” would benefit from having clear ontological structures that can be expressed in readable ways. For example, I would love to be able to study the ontology of Photoshop as a way to learn how to think about using that program. It would be a bit like looking at the type hierarchy of the program, or its storage schema—but those are usually somehow convoluted compared to how you would really describe the ontology to a user.
It’s really fascinating to browse around in the Monarch site! It feels somehow comforting in this purported age of “post-truth” to see these obviously high quality arrangements of scientific knowledge.
Thanks for reminding me about Inform 7 – I’ll take another look at it.
I agree that the set of types (and their relations) for a program can sometimes be close the ontology its domain. That’s also part of the promise of Object Oriented software, and Domain-Driven Design that you mentioned. In practise, both the types and the objects are often more about the implementation than the domain. Good technical documentation should break a software system down into a set of clear concepts, allowing the user to form an effective mental model. The worry is that any such abstraction will be “leaky”. Having some sort of implementation, in a program or formalism, forces you to confront those leaks and edge cases.
The ontologies I work with often support more detail about the domain than anybody actually wants to implement in their database or system. Programmers are likely to think that this makes them over-architected. But that detail lets us do data integration between systems that are talking about the same domain using different abstractions suited to their different use cases.
Practical ontology in the style of Barry Smith has learned from computer science and many other sciences, especially efforts in medical and biological ontology. They work with formal ontologies using RDF and automatic reasoning. It’s fascinating to read about.
Thanks for making that connection. I have a PhD in philosophy and now my career is working with the biological and biomedical ontologies you’re talking about: http://obofoundry.org. Happy to answer any questions.
It has certainly been my experience that philosophy and programming have a lot to teach each other.
Very cool! I’ve only sporadically read some books and articles about BFO. Before that, my interest in conceptual modelling was stimulated by Christopher Alexander (community-driven pattern languages for architecture) and Eric Evans (domain-driven design for software).
I’d be super curious to hear just what kind of problem you’re working on at the moment, or some recent success (small or large) in ontological modelling or problem-solving that made you feel excited about being in the field. :)
My graduate work was in philosophy of science. Along the way I learned to program, and like the author of the article I still really enjoy the challenge of breaking a problem domain into clean, orthogonal pieces, then writing code to make the solution actually work. Now I’ve found a niche where I can combine technical and conceptual skills to help scientists do better science.
I’m deeply involved in the Open Biological and Biomedical Ontologies community, which brings together a large number of open source, scientific ontologies under a set of shared best practises. I contribute to several ontologies, including the Ontology for Biomedical Investigations. My main client is the Immune Epitope Database, where I help with data integration and validation. I’m most excited about building tools to help scientists develop and work with ontologies and linked data. Two examples of that are ROBOT and Knotation (work in progress).
It’s not my work, but one of the most impressive examples in this area is the Monarch Initiative. They’ve been able to integrate genotype and phenotype data across multiple model organisms to help understand rare diseases in humans. Much harder than it might sound!
Knotation looks really good. It reminds me a bit of Inform 7, which by the way also has a pretty interesting basic ontology.
It seems somehow obvious that “IT systems” would benefit from having clear ontological structures that can be expressed in readable ways. For example, I would love to be able to study the ontology of Photoshop as a way to learn how to think about using that program. It would be a bit like looking at the type hierarchy of the program, or its storage schema—but those are usually somehow convoluted compared to how you would really describe the ontology to a user.
It’s really fascinating to browse around in the Monarch site! It feels somehow comforting in this purported age of “post-truth” to see these obviously high quality arrangements of scientific knowledge.
Thanks for reminding me about Inform 7 – I’ll take another look at it.
I agree that the set of types (and their relations) for a program can sometimes be close the ontology its domain. That’s also part of the promise of Object Oriented software, and Domain-Driven Design that you mentioned. In practise, both the types and the objects are often more about the implementation than the domain. Good technical documentation should break a software system down into a set of clear concepts, allowing the user to form an effective mental model. The worry is that any such abstraction will be “leaky”. Having some sort of implementation, in a program or formalism, forces you to confront those leaks and edge cases.
The ontologies I work with often support more detail about the domain than anybody actually wants to implement in their database or system. Programmers are likely to think that this makes them over-architected. But that detail lets us do data integration between systems that are talking about the same domain using different abstractions suited to their different use cases.