Meronomic Model
2. The Challenge of Representing Kinds
A key semantic challenge is the need to instances of abstract kinds of things and processes, not just individuals. In current ontologies, a category such as Device is instantiated in the real world by real devices, such as ultrasound machines, heart monitors and so on. Each such physical device is an instance of the category Device (or some more specific category, if it exists). However, we also have objects (manuals, online descriptions, DB catalogue representations) in the real world that describe a category or model of device, for example a particular kind of ultrasound machine manufactured by Philips, possibly with usage and maintenance instructions.
The common characteristics of any collection of identical devices, some of which will be pertinent to their use, such as resolution, 4-dimensional imaging capability and so on, would either have to be recorded in the record of every device, or else in a common record representing the device type or model. Doing the latter clearly makes it much easier for the update of device characteristics from a manufacturer.
We can think about this problem in terms of information found within typical databases. Consider the relationship among four entities:
-
realist ontologies, as governed computable knowledge artifacts, intended to describe reality;
-
individuals in the real world, as described by the ontologies (actual machines etc);
-
information models (also governed entities) and,
-
data instances of 3.
The same logic applies to any manufactured object, since 'manufacturing' is the business of creating replicated units based on a common plan. It thus applies to cars, measuring devices, and any industrial machine. Indeed, there is no limit to the depth of hierarchy of device descriptions.
This relationship is not a simple instance-to-model relationship. There are model families, and common core technologies, so there is generally a hierarchy of progressively more general artifact types, each potentially described by a real world informational artifact, sitting above any actual machine in the real world. The diagram below shows two levels of this.
| There is a confusing English term that is problematic here: 'instance of'. In common parlance, we use that to mean 'Davey Jones' instance-of human (ontic entity → ontology entity), and also data record 1425 (representing Davey Jones in the hospital admin system) instance-of class Person in some DB schema or UML model (data instance → information model class). The diagram uses 'instance-of' to mean what it means in BFO, and 'data-instance-of' to indicate data being an instance of its formal type. |
Machines and models are only one instance of the 'kind' problems. Medicines are described in terms of their kind, e.g. 30mg oral Aspirin. Part of such descriptions may include the chemical formula for active ingredients, plus allergenic information, contraindications and so on. However, in use, medicines and vaccines are purchased in finite amounts, and manufacturing lots may differ. Sometimes an error in manufacturing causes a recall of a particular vaccine lot. In this case, we are tracking purchased inventory, with each package being documented by both its individual characteristics (lot number, delivery date, manufacture date, place of manufacture etc), and its kind (DtP vaccine, 0.5mL dose, intramuscular route, …).
We can now see that the 'individual' characteristics of drugs are applicable to whole purchase packages, rather than each individual tablet or vaccine ampoule.
Currently, medicine and vaccine types are represented in pharmaceutical databases and registries, e.g. the US NLM RxNorm drug database, while individual / purchase level information is carried in an inventory database within the using organisation.
The SPLASH solution to representing 'Kind' level information is based firstly on understanding that 'kinds' are not things, but descriptions information, and therefore belong in the Info Entity hierarchy.