We present the Template Instance Pattern, a content design pattern that marks an instance, which is used as a value for a property, to be a “template”. A template instance is intended to be immutable (none of its properties can be changed). If the content (i.e., any of the property values) of the template instance needs to be changed, a template flag will indicate to an ontology editor that it should create a clone of the template instance, and replace the value of the property with the desired value in the newly created clone. This pattern is especially useful for cases in which an ontology makes abundant use of reified relations (represented as instances), which are repetitive and that increase significantly the size of an ontology. We created this pattern as a result of building a large real world medical ontology that makes excessive use of reification.
Ontologies make use of reified relations to model n-ary relations or describe additional
properties of a relation (e.g., confidence level, provenance, and so on). For example,
biomedical ontologies often need to qualify facts about the domain with scientific
evidence: a definition of a disease would need to include links to scientific papers that
sourced or endorsed that definition, or relationships between different entities need to
carry a probability. Some ontologies, such as the ICD-11 [
The properties for the reified individuals, y1, y2 and y3 are all identical (the underscore represents the index for y: 1, 2, or 3):
The pattern proposes to create a template instance, y tmpl that has the common property values (right hand side of Figure 1): (y_tmpl p1 foo) (y_tmpl p2 1.0) (y_tmpl p3 z)
The template instance would be used as the value for the reified property for x1, x2 and x3: (x1 p y_tmpl) (x2 p y_tmpl) (x3 p y_tmpl)
In addition, we will also add one annotation property, isTemplate:true, on y tmpl to mark that it as a template instance. The intention is that the template instance is immutable, i.e., the property values of the template instance cannot be changed.
In the case that a user would like to change a property value of the reified instance, a clone of the template instance would be created and the change would occur on the clone. An ontology editor would use the isTemplate annotation property to check that a certain instance cannot be modified, and it should rather create a clone.
Figure 1 gives an example of this situation. Say that at a given time t0, there was an additional x4 individual that had the template instance as the value for p. At t0:
Later, at time t1, the user decides to change the value p1 from foo to bar. The ontology editor (or the user, if there is no support in the tool), will see the isTemplate annotation property on y tmpl as set on true, and it will create a clone of it, y tmpl modif, by cloning also all the object and data property axioms. Then, it will change the value of p1 on y tmpl modif. At t1: (x4 p y_tmpl_modif) (y_tmpl_modif p1 bar) (y_tmpl_modif p2 1.0) (y_tmpl_modif p3 z)
As a result of using the pattern, we can reduce the number of data and object property axioms in the ontology. This “deflation” of the ontology is especially significant, if there are many repetitive values in the ontology, with few changes, and if the number of properties of the reified instance is large. 3
As we have mentioned before, the ICD-11 ontology that describes diseases and their properties makes extensive use of reification. A class in the ICD-11 ontology represents a disease, which has several properties (e.g., title, definition, synonyms, signs and symptoms, etiology, manifestation, etc.) that are encoded as property axioms. Each disease class can participate in one or several “views” that will be extracted from the ICD-11 ontology. A view (in ICD language called “linearization”) is a portion of the ontology that is relevant for a particular sub-domain or use case (e.g. Morbidity, Mortality, Primary Care, Dermatology, etc.). Figure 2 shows an example of these views. For each disease class, the specifications of the views it participates in, are represented as reified instances (the table rows in Figure 2). Each of the view specification instances contains five additional properties (partially shown as columns in the table). Each disease class has to specify their inclusion in ten different views. Each view is represented as a reified instance. The ontology currently contains over 40.000 disease classes, each having 10 view specifications, and each of the view specifications containing additional 5 properties. Currently, we have over 400.000 reified view specifications, and over 2 million property assertion describing them. Many of these reified view specification instances are identical. We plan to use the Template Instance Pattern to reduce significantly the number of the reified instances in the ontology. For example, for the initial modeling (that contains no user modifications), we would have only 10 reified view specification instances (reduced from 400.000) and 400.000 property assertions (reduced from 2 million). This “deflation” of the ontology size is significant, would allow us to more easily maintain the view specifications, and would have a beneficial impact on the performance of the ontology tools used for editing ICD-11. 4
We presented the template instance pattern that was created from the need to address scalability and maintainability issues in the development of the ICD-11 ontology. The pattern proposes the use of template instances as values for reified properties, and their flagging using an annotation property that can be used to provide support for this pattern in ontology tools. We also described an example of the pattern and its operationalization in a generic ontology tool.