The BORO method is a simple, repeatable process for developing formal ontologies. The method takes an extensional approach to ontology development. The advantage of BORO over other methods is that its grounding in physical reality means that, if followed to the letter, the method will always produce the same ontology given the same inputs. This makes it particularly powerful for comparing multiple data-sources for semantic matches/mismatches and for re-engineering multiple legacy systems into a coherent whole (either as a new monolithic system, or as a method for designing federation of existing systems).

Although BORO produces an ontology (information science) in the very strictest sense of the term, it does not produce the type of ontology (information science) that computer scientists would use for reasoning and inference. Instead, BORO's purpose is to improve the quality of information and information models, to integrate multiple information sources and extract hidden semantics. The purpose of the method is to re-engineer disparate data sources into a common model. It is particularly good at semantic analysis – establishing whether two concepts are the same, if they overlap, or if they are unrelated.

Traditional methods of data analysis tend to be linguistic; comparison of concepts is based on the names these concepts have. More modern methods have introduced a more semantic approach, where the analyst will tend to analyse the meaning behind a word. Although these methods tend to produce more accurate comparisons, a lot of it depends on the analyst’s domain knowledge and linguistic interpretation. BORO is different to many other data analysis techniques in that treats the names of things as a secondary concern. With BORO, the analyst is forced to identify individual concepts by their extent. In the case of physical objects, this is their spatial/temporal extent. For types of things, the extent is set of things that are of that type.

BORO is an approach to developing ontological or semantic models for large complex operational applications that consists of a top ontology and a process for constructing the ontology. It was originally developed as a method for mining ontologies from multiple legacy systems – as the first stage in an architectural transformation [1] or software modernization. It has also been used to enable semantic interoperability between legacy systems

As an example, take “Waterloo Bridge” as a concept. The first thing we ask is “does it have spatial and temporal extent ?”. It has spatial extent; it spans the River Thames. However, when we examine the temporal extent we realise there have been two bridges at that site. The first, built in 1817 (two years after the battle of Waterloo) was demolished in 1920. The bridge that stands there now was built in 1942. This analysis has immediately highlighted a problem with a name-based approach – there are two bridges of that name, which one are we referring to ? At this point, the analyst can add one or both of the bridges to the ontology, then apply the appropriate names to each. The process also works for types of things. Take “bridges” as a concept. It doesn’t have spatiotemporal extent, so we go to the next question “does it have members ?”. It does – the members are all the bridges in the world. We then identify some exemplar members – e.g. Waterloo Bridge. At this stage, it is advisable to identify exemplars that are “on the edge” of the set – e.g. things that may or may not be bridges – e.g. pontoons, bridging vehicles, etc. so as to accurately identify the extent of the type. The final concept covered by the process is the tuple. A tuple is a relationship between things. If the concept under analysis is neither a type nor an individual, then it must be a tuple. We identify the things at the end of the tuple then add it to the ontology.