- Design considerations
- A detailed consideration of Necessary Attributes and Opaque Identifiers
- A design for storing antibody information
- A design for storing assay information
At this point I think it's worthwhile to look back and see what, if anything, is different and useful about the middle distance approach.
What struck me most as I was thinking through the examples was how similar the process was to object oriented class design. Using opaque identifiers allows moving a clump of stuff (attributes, identifiers, functionality, behavior) to another class so that the objects in the system correspond to objects in the world. They can then be analyzed as a coherent whole (aka modularization). Pragmatically, such partitioning allows developers to become intimately familiar with how the stuff within that partition operates and evolves over time, permitting them to develop a high level of fluency in the domain.
A key component of this approach proved to be the use of the criterion what could change to drive the splitting off of the chunks of stuff. As such, it is an extension to/refinement of existing design techniques rather than being a replacement for them.
So, how does middle distance thinking extend current techniques?
Extension to DB design: A focus on "objects in the world," rather than just cardinality, results in a more fine grained partition of the problem space. All things which are one-to-many or many-to-one are necessarily distinct and have different potential rates of change, but sometimes things which are one-to-one are also distinct, and should be separated to accommodate future change.
Refinement of OO design: middle distance ontologies are problem space oriented rather than software oriented. As such, it is less concerned with factoring out the appropriate superclasses than OO designs. This is because software design criteria that push such refactorings are "within the system" rather than "in the world." There is nothing in the middle distance approach that pushes common functionality up to a common implementation.
One other aspect of the middle distance approach is that it allows you to pull attributes out of the design and hide them behind the opaque identifiers. This modularization allows you to change the definition of such things as validity as your knowledge of what constitutes validity in your problem domain changes.
In summary, I think the middle distance approach is useful as a design principle, but is not a distinct design technique per se. Assessing its utility in practice must await an opportunity to apply it to a real world problem.