OntoTip: Lift/Borrow/Steal Software Engineering Principles

This is one post in a series of tips on ontology development, see the parent post for more details.

The main premise of this piece is that ontology developers can learn from the experience of software engineers. Ontologists are fond of deriving principles based on abstract concepts or philosophical traditions, whereas more engineering-oriented principles such as those found in software engineering have been neglected, which is to our detriment.

Figure: An appreciation of engineering practice and in particular software development principles is often overlooked by ontologists.

 

In its decades-long history, software development has matured, encompassing practices such as modular design, version control, design patterns, unit testing, continuous integration, and a variety of methodologies , from waterfall top-down design through to extreme and agile development.  Many of these are relevant to ontology development, more than you might think. Even if a particular practice is not directly applicable, knowledge of it can help; thinking like a software engineer can be useful. For example, most good software engineers have internalized the DRY principle (Don’t Repeat Yourself), and will internally curse themselves if they end up duplicating chunks of code or logic as expedient hacks. They know that they are accumulating technical debt (for example, necessitating parallel updates in multiple places). The DRY principle and the DRY way of thinking should also permeate ontology development. Similarly, software developers cultivate a sense of ‘code smell’,  and will tell you if a piece of code has a ‘bad smell’ (naturally, this is always code written by someone else).

Don’t worry if you don’t have any experience programming, as the equivalent ontology engineering practices and intuitions can be learned through training, experience, the use of appropriate tools, and sharing experience with others. Unfortunately, tools are not yet as mature for ontology engineering as they are for software, but we are trying to address this with the Ontology Development Kit, an ongoing project to provide a framework for ordinary ontology developers to apply standard engineering principles and practice.

Computer scientists and software engineers are also fortunate in having a large body of literature covering their discipline in a holistic fashion; this includes classics such as The Mythical Man Month, The “Gang of Four” Design Patterns book, Martin Fowler’s blog and his book Refactoring. While there are good textbooks on ontologies these tend to be less engineering-focused, at best analogs of the (excellent, but sometimes theoretical) Structure and Interpretation of Computer Programs. Exceptions include the excellent, practical engineering-oriented ontogenesis blog.

An incomplete list of transferrable software concept, principles, and practice includes:

• Version control: use GitHub or equivalent (why? see the top answer here, just replace “code” with “ontology”)
• Use continuous integration (see here), social coding, non-private issue trackers
• Commit early, commit often
• Read about design patterns, and anti-patterns. Recognize and act on bad smells
• Avoid spaghetti logic
• Separate source from compiled product (see ROBOT workflows).
• Be use case and requirements driven. Usability of the ontology is key. Your goal is not to make a perfect ontology to be marveled at by ontologists, but to build something that is usable by people in your domain.
• At the same time, build for extensibility. Understand the concept of  technical debt.
• Test, test, test
• Learn debugging tools [see future blog post]
• Provide documentation for users
• Provide documentation for ontology developers (and your future self, you will thank your past self); especially your design patterns and design decisions. Inline documentation is your friend
• Think modular; reuse components from other ontologies, or from modules within your own ontology
• DRY: Don’t Repeat Yourself
• While good engineering is essential, the so-called soft skills are actually harder. Learn to acquire these.
• Ask for help early and often. And work to support inclusivity and a culture where people feel safe to ask questions.

 

I hold that all of the above are either directly transferrable or have strong analogies with ontology development. I hope to expand on many of these on this blog and other forums, and encourage others to do so.

Also, I can’t emphasize strongly enough that I’m not saying that engineering principles are more important than other attributes such as an understanding of a domain. Obviously an ontology constructed with either insufficient knowledge of the domain or inattention to users of the ontology will be rubbish. My point is just that a little time spent honing the skills and sensibilities described here can potentially go a very long way to improving sustainability and maintenance of ontologies.

Advertisement