Building an ontology using BFO was a bit tricky. It takes some time to get one’s head around the way BFO models the world For example, the distinct difference between information and its representation (as in, the same information could be contained in a both a word processing document and a slide presentation). Some of this is made a little easier by using BFO as an upper-level ontology and using a mid-level ontology such as the Common Core Ontologies being developed for use by the US Army. (See this paper for a discussion of their application.)
But getting my head wrapped around how BFO represents information wasn’t the half of it.
Once I had what I believed was a good ontology in place, meaning that it passed the consistency checks of at least one reasoner (such as Fact++ or Pellet), I needed to add data to it. That’s where the real fun began. I have several tens of thousands of records representing ships and position information reports that need to be converted from the existing concept-based ontology into the BFO-based version (perhaps hundreds of thousands, I haven’t really counted).
To do the conversion, I’m using the Manchester OWL API. It’s robust and pretty straightforward, and I’ve used if for other projects, so it was a natural choice for me. (For anyone who objects that a Java application is awfully heavy for doing what is essentially text conversion, you’re probably right. But I’m not a real programmer; I only impersonate one from time to time when it’s necessary for a given task. And I’ve got deadlines to meet for the work project that I’m doing this for, so I went with what I know.)
Actually adding the data revealed several inconsistencies in my ontology, all centered around that very explicit distinction between information and its representation. Thankfully, a colleague who is doing much of the development work on the Common Core Ontologies was able to help me out.
I’ve managed to update all of the data about individual ships to the new ontology; now I need to update the position information.