To modularize or not to modularize…

Here’s a topic I’ve found that could generate lively discussion at the start of the ontology development process, and can still generate lively discussion long after the first ontology has been made and delivered. Do we modularize or not modularize the ontologies? And if we take the time to modularize, are we going to take advantage of those modules? 

There are research papers on the benefits of modular ontologies, and I won’t go into that kind of discussion in this short article. The second question of taking advantage of those modules will also not be addressed. In this brief article, I’ll just mention a few practical steps for consideration when deciding to modularize or not modularize.

My short stint in training and curriculum development gave me an acronym that I found ‘catchy’ and so have never forgotten. It is ADDIE. It stands for Analyze-Design-Development-Implement-Evaluate. After spending many years working on information science and IT projects, I’ve really found that development cycles for just about anything are done using some variation of ADDIE. At its basic level, these ADDIE steps also need to be taken too when going through the practical steps of deciding on modularization. Because this article is about a decision to modularize or not to modularize, the article will focus on Analyze and include some Design considerations. 

Analyze … Is there a business need to manage processes of updating an ontology separate from the updating of another ontology, while still allowing querying across the ontologies? Will any of the ontologies grow to a size that might warrant it to be placed on a separate server? Will there be a need for any portion of the ontology to be distributed separately from the others? I think most people would agree that anything monolithic would bring less flexibility. Thinking through all the possible business, hardware and software needs for the ontology will help drive a decision for modularization or not. But after an analysis of the needs, the development of the requirements, and making the decision to move forward using a principle of modularization, the challenge will then be to determine the separation principles to be used. 

I mentioned in a previous article that I work as a part of a team that developed the Mayo Clinic – Consumer Health Vocabulary (CHV). I believe that is indeed our ‘flagship product’. But that is actually 1 of over 120+ ontologies that we manage, many of which are interconnected. We have modularized, and as new needs arise, the need for any new ontologies are evaluated against the existing set of ontologies to determine the necessary step to take, i.e. to combine the new ontology with an existing ontology, or to create a new module.

Design … But as you might suspect, getting to that current state of 120+ ontologies, with many interconnected, was not simple. Even with the determination to separate modules by (1) knowledge base of a specific domain of information, such as conditions, drugs, etc., and (2) ontologies developed purely for a particular function, such as supporting special groupings of other ontologies for queries, just determining when there should be new completely separate ontologies in each of those two areas is at times a challenge.

As modularization is considered and designed, it is also essential to create a plan for the URI pattern to be used when modules are created. Decisions on URI patterns should be made before any work begins. And the one thing I would say that I have learned is that any URI decisions that are made initially should be reviewed periodically and the URI plan updated as needed. As the area grows, the needs might change and affect the URI decisions made earlier on.

Go for it ... Once your analysis and design to address the decision of modularization are completed have fun in your continued work on the ontology! With modularization, you will find ‘owl:import’ to be your friend as you connect the necessary modules to help ease querying. Start small, and test against your business requirements to make sure the modules can meet the need. I heard someone say at a conference once (but I can’t recall who or where!) that… “An ontology is basically a lazy artifact. It doesn’t do anything on its own; you have to do something with it.” That resonated with me as I have worked most of my career in positions where things are built to meet a need. So, this too should be evaluated to make sure it is built to meet the need.

This brief article only begins to mention some practical considerations when modularizing ontologies. As you might suspect, the ‘devil will be in the details’. The challenge I think will be to find the best point at which a level of granularity can be reached, and not surpassed, that will meet the business need … because navigating through grains of sand will probably be more difficult that navigating through small stones.