The Reasonable Ontology Templates Framework

The OTTR language and its features will be introduced in an incremental and example-driven approach that builds on the example established in the introduction. The complete specification of the OTTR language is found in Section 3.

A template library is a collection of templates developed and curated for a particular purpose, such as representing patterns for a given vocabulary, domain, or project. The ability to share and reuse templates for common modelling patterns is central to the OTTR framework and will be further elaborated in Section 5. By following best practices and principles similar to linked open data [19] and ontology publication, templates and template libraries are expected to be published and interconnected in a distributed and decentralized manner, promoting their reuse and community-driven curation. Our intention is that template libraries should be developed alongside the development of vocabularies and ontologies which are intended for reuse, in order to promote and simplify correct and consistent typical use of the vocabulary or ontology. Given that a template’s signature is clearly documented and understood, there is no need to understand how the template is implemented in order to correctly instantiate the template. Templates at different abstraction levels, and templates and their instances, target different users and use cases, and can hence be created and managed separately and by different users.

Efficient instantiation of templates is also central to the OTTR framework. For this task, it is natural to consider a template as a mapping from its signature input format to the pattern of its expansion. The OTTR framework provides two specifications, bOTTR and tabOTTR, for selecting and translating data from structured sources into template instances, which in turn can be expanded into a knowledge graph or ontology according to the corresponding template definitions. These are presented in Section 6. The bOTTR specification defines an RDF vocabulary with which mappings from database query results to templates may be specified. The tabOTTR specification describes a simple “markup” language for defining mappings to templates directly in tabular datafiles, such as CSV, TSV or Excel files. These specifications permit the OTTR framework to become a part of a complete data transformation pipeline, where external tools may be used to cleanse and prepare data for template instantiation, and the OTTR framework’s mapping specification may be used to collect and integrate data from multiple sources to build knowledge graphs and ontologies at scale.

An early predecessor and inspiration to OTTR templates dates back to 2008 [26]. Here, a template mechanism was developed for “lifting” compact data representations, typically tabular data, to rich semantic format according to a complex upper level ontology. A prototype of the template mechanism was implemented using OWL and SWRL rules [18].

The practical and theoretical aspects of OTTR templates were first introduced in 2017, where OTTR templates were defined parameterized knowledge bases using a dedicated OWL ontology [48], and as description logic macros [10].⁵⁵5 The name “Reasonable Ontology Templates” comes partly from the fact that in the first version of OTTR, templates were parameterized OWL ontologies that could be directly reasoned over. Also, “reasonable” has a suitable double meaning of “being reasonable” and “being subject to reasoning”. The acronym OTTR is inspired by OWL.

The formulation of the OTTR language later matured into a dedicated representation of templates and template instances [50, 51]. The OTTR language has since then evolved into a framework and reached the state of stable resource, far beyond a research prototype – with multiple users from different communities and industries, multiple independent implementations initiated, and several publicly available template libraries.

All publicly available resources managed by the OTTR team are available from the project web page: https://ottr.xyz. The formal specifications and software are hosted in the Git repository at: https://gitlab.com/ottr/. Stable releases are also published at Zenodo: https://zenodo.org/communities/ottr/.

OTTR is a language for expressing statements, in particular for ontologies and knowledge graphs represented using OWL and RDF. The basic building blocks for such statements are terms. As different terms may play different roles within these statements, and denote, e.g., relationships, entities, or data values, OTTR introduces a type system over the terms to ensure that terms are used correctly. The type system assigns a type to each term and uses subtype and compatibility relationships between types to check correct and consistent use of terms across ontologies and knowledge graphs. Below we introduce these terms and type systems.

Note that list terms can be nested arbitrarily, so if $e_1,e_2,e_3$ are terms, then, e.g., $⟨e_1,⟨e_2,e_3⟩,\mathrm{𝑛𝑖𝑙}⟩$ is also a term. The special constant $\mathrm{𝑛𝑜𝑛𝑒}$ denotes a missing value, similar to how NULL or null is used in SQL and many programming languages. This constant is not intended to be used in the final statements that become part of constructed the knowledge graph, but only within the OTTR framework’s definitions.

We call types of the form $\mathrm{𝐿𝑖𝑠𝑡}⟨t⟩$ and $\mathrm{𝑁𝐸𝐿𝑖𝑠𝑡}⟨t⟩$ (non-empty list) for list types. These types have terms that are lists, i.e., ordered collections of terms. Note that we distinguish, at the type level, between empty and non-empty lists. Types of the form $\mathrm{𝐿𝑈𝐵}⟨t⟩$ are called LUB-types where LUB is short for least upper bound. The motivation for the latter type constructor builds on the following definition.

The intuition behind the compatibility relation between types is to permit the use of terms in places that are compatible with their type. We use the notion of compatible types to check correct use of terms and consistent use of terms. Correct use means that a term may only be used in places where its type is compatible with the expected type. Consistent use, which is only relevant for $\mathrm{𝐿𝑈𝐵}$-typed terms, means that a term is not used in multiple places that are incompatible.

$\mathrm{𝐿𝑈𝐵}$-types are required when the lexical form of terms is alone not sufficient to determine its type, which is typically when there are more types than different lexical forms. In these cases, one needs to examine the expected types of where the terms are used to establish if the term is used consistently. For the semantic web languages RDF and OWL, this is relevant as the IRIs and blank nodes of RDF may be used to designate different types of entities in OWL that are necessary to keep apart to ensure their correct and consistent use. For instance in OWL, object properties and datatype properties are disjoint types, yet, it is not possible to determine based on the lexical representation alone if an IRI represents an object property or a datatype property. For these terms, we only give an upper bound ($\mathrm{𝐿𝑈𝐵}$) of what types they can have. A term to which we assign the type $\mathrm{𝐿𝑈𝐵}⟨t⟩$ may have a type that is a subtype of $t$, and may therefore be used any place where any subtype $t^{\prime }$ of $t$ is expected. However, terms must also be used consistently, so the same term cannot then be used in a place where a type not compatible with $t^{\prime }$ is expected.

Note how we exploit $\mathrm{𝐿𝑈𝐵}$-types when we assign non-empty list terms the type $\mathrm{𝐿𝑖𝑠𝑡}⟨\mathrm{𝐿𝑈𝐵}⟨\top ⟩⟩$. Since all list elements are type-checked, it is unnecessary to give a more specific type to the list itself. Any type violation of a non-empty list is either due to the list itself is given to an argument expecting a non-list, or that a term “inside” the list is of an incompatible type. The type assigned to the list term itself need only account for the first of these two cases. However, to type-check the terms inside lists we need to know how deeply nested a term is inside a list, and how deeply nested a given type is inside a list type. This is captured in the following definitions.

As an example, in the type $\mathrm{𝑁𝐸𝐿𝑖𝑠𝑡}⟨\mathrm{𝐿𝑖𝑠𝑡}⟨t⟩⟩$, $t$ occurs at depth 2.

The definition is used to relate depths of terms in lists to the type at corresponding depths in nested list types. However, note that for $\mathrm{𝐿𝑈𝐵}⟨t⟩$, $t$ must be a basic type and, e.g., not a list type. It is therefore no $n$ such that $t$ occurs at depth $n$ in $\mathrm{𝐿𝑈𝐵}⟨t⟩$, but, e.g., $\mathrm{𝐿𝑈𝐵}⟨t⟩$ occurs at depth $1$ in $\mathrm{𝑁𝐸𝐿𝑖𝑠𝑡}⟨\mathrm{𝐿𝑈𝐵}⟨P⟩⟩$.

We now introduce the implementation of terms and types to be used for creating knowledge graphs and ontologies in RDF and OWL.

The following illustrates an interesting feature of OTTR’s type system. Some types of the OWL ontology language are defined to be disjoint, such as OWL object properties and datatype properties, and should raise an error in the case that an IRI is assigned multiple such types. Other cases of assigning multiple types to the same IRI can result in what is called punning, e.g., stating that Eagle is both a owl:NamedIndividual and a owl:Class, which is permissible in OWL, but may not always be desirable. The type hierarchy presented in Table 1 above does not permit punning, as there is no subtype of, e.g., owl:NamedIndividual and owl:Class that is different from $\perp$. However, it is easy to extend the type hierarchy with types to allow for punning. Table 2 lists the necessary extensions of types to allow for punning according to the OWL standard. This example is further developed in Section 3.5 on page 3.5.

Statements in OTTR are expressed by template instances. Before we can introduce these, we need a couple of utility definitions specific to the use of lists in statements. OTTR has special support for lists in the form of list expanders, which are functions that allow a single statement to expand to multiple statements by replacing a list of terms with the elements of the list, in different ways.

The list expanders defined above will be used in the definition of instance expansion, Section 3.4. With this, we are ready to define the notion of template instance.

A template instance can be viewed as a call to a template. A template is a definition of a pattern of statements, and a template instance denotes one instance of the template’s pattern.

A template is a parameterized set of statements – which themselves are template instances. Thus, templates are a recursive structure where a template is defined in terms of other templates. Base templates are the exception, and are used to represent basic statements in a different data representation language.

Before we can define our notion of templates, we need to establish some preliminary definitions.

The $\mathrm{𝑜𝑝𝑡𝑖𝑜𝑛𝑎𝑙}$ modifier is used to control how the $\mathrm{𝑛𝑜𝑛𝑒}$ term behaves during expansion. This is defined in Section 3.4. However, the intuition is that we specify a parameter as $\mathrm{𝑜𝑝𝑡𝑖𝑜𝑛𝑎𝑙}$ if $\mathrm{𝑛𝑜𝑛𝑒}$ is a meaningful argument, and omit $\mathrm{𝑜𝑝𝑡𝑖𝑜𝑛𝑎𝑙}$ when it is not. All statements with a $\mathrm{𝑛𝑜𝑛𝑒}$ as arguments to a non-$\mathrm{𝑜𝑝𝑡𝑖𝑜𝑛𝑎𝑙}$ are discarded. This allows templates to contain subpatterns that are only used when specific values are present (i.e., not $\mathrm{𝑛𝑜𝑛𝑒}$).

Recall that our implemented terms contain blank nodes, and that blank nodes are, according to the RDF specification [27], not permitted as predicates in RDF triples. Blank nodes can also be undesirable in certain other settings, for example, if concrete values are required to be meaningful for their intended use. The $\mathrm{𝑛𝑜𝑛𝐵𝑙𝑎𝑛𝑘}$ modifier is introduced to control where blank nodes are permitted and not. That is, a blank node is not allowed as an argument to a parameter marked with $\mathrm{𝑛𝑜𝑛𝐵𝑙𝑎𝑛𝑘}$.

In the above definition, we use $\mathrm{𝑛𝑜𝑛𝑒}$ to denote that a parameter does not have a default value, and say that a parameter does not have a default value if the parameter’s default value is $\mathrm{𝑛𝑜𝑛𝑒}$.

As we shall see, a signature is part of the definition of a template. However, a signature is also meaningful on its own, as documentation of how to use a template, similar to function and method signatures in programming languages.

A signature may contain a set of ground instances called annotations. These are meant to be used for documenting the signature (similar to Javadoc in Java or Docstrings in Python), such as who created the template, the version of the template, and a description of the template pattern.

A base template denotes a parameterized basic statement that cannot be broken down into a set of smaller (parameterized) statements. Base template instances can either be used directly in an OTTR serialization, or, more commonly, be transformed into statements in a different language and serialization format.

One can imagine implementations supporting other base templates: Base templates for RDF quadruples, OWL expressions, rows in tabular files, or SQL INSERT statements.

We are now ready to define the central concept of a template.

A template is the core construct in OTTR, and is the primary means of abstraction. Using templates, we can create complex parameterized statements that are easy to reuse. A template can either be defined in terms of base templates directly, or by instantiating other templates (or a combination). Taking a bottom-up approach, this supports layers of abstractions, each layer creating more complex statements that are closer to the terminology of that of a concrete domain to be modelled. To use a template, all one needs to know is its signature. The signature states the arguments a user must provide, and may also contain annotations that further describe the intended use of the template.

We have now defined the core constructs in the OTTR framework, and will proceed to define the process of instance expansion, which is to iteratively transform instances into ultimately instances of base templates only.

We treat list expansion separately first, as this is technically the most complex part of the expansion process. List expansion is specified using two functions, where the first selects the lists to expand from the instance and expands them using the given list expander function, while the second creates one instance per element in the result of this function application. The full list expansion is the composition of these two functions.

The function $ϵ$ takes an instance and produces a set of instances by first selecting the argument lists that are to be expanded and applies the list expander function (with ${ϵ}_1$), and then creates new instances based on the expanded lists by combining elements of the expansion with the original non-expanded values of the argument instance (with ${ϵ}_2$).

In the above definition, the first case is performing the list expansion defined in the previous definition. The second case handles $\mathrm{𝑛𝑜𝑛𝑒}$ values, where $\mathrm{𝑛𝑜𝑛𝑒}$ values given to non-optional parameters (without default value) result in an empty expansion, i.e., the instance is discarded, and $\mathrm{𝑛𝑜𝑛𝑒}$ values given to parameters with a default value are replaced with that default value. The third case states that the expansion of a base template (or a signature, i.e., the case where we do not have the full definition of a template object) is just the base template itself (however, note that step comes after the former two, so these steps apply first). The final case is the replacement of an instance to a template with the pattern the template denotes, where parameter values are substituted with argument values.

This denotes a single step in the expansion, the full expansion of an instance is simply the fix-point of this process.

Section 3.4 gives an example of the expansion process of the previously exemplified instances and templates.

Finally, we define the process of annotation expansion.

In this section, we will define what it means for a set of template objects and instances to be correct, e.g., with respect to the type system and template signature specifications. We start by defining the notions of template library and dataset.

The inferred type of a term is the type the term is used as. A term may therefore have many inferred types, one for each time the term occurs in any instance.

In other words, a term is consistently typed if there is a type one can assign it that is a subtype of all of its inferred types and that is compatible with the actual type of the term. Note that this definition covers both the consistent use of terms and correct typing as discussed above. For example, if a term $v$ is used both as an xsd:int and as a xsd:string, this is a case of inconsistent use of the term $v$, as there is no subtype for these inferred types (unequal to $\perp$), which violates the first point. If the term $v$ has type xsd:int but is used as a xsd:string, then it is a case of incorrect typing and a violation of the second point of the definition.

Note that the definition above ensures that the $\mathrm{𝑛𝑜𝑛𝐵𝑙𝑎𝑛𝑘}$ modifier is propagated upwards in the dependency graph of templates so that any variable used as an argument to a $\mathrm{𝑛𝑜𝑛𝐵𝑙𝑎𝑛𝑘}$-parameter must be marked as $\mathrm{𝑛𝑜𝑛𝐵𝑙𝑎𝑛𝑘}$.

This covers the correct use of terms.

We now define correctness of the interplay between template objects and between templates and instances by way of several properties that combined form the notion of correctness.

Acyclicity ensures that instance expansion terminates and is finite. Note that this also disallows recursively defined templates. However, we have no means of manipulating or producing new terms apart from through list expansion. Under the current type system, we are unable to define a template that can apply a list expander to an instance of itself, as this would not be consistently typed. Thus, a recursive call within a template’s pattern can only reuse the same arguments it was originally given or have constants as arguments, thus creating an infinite loop in the expansion.

Referential integrity ensures that all instances refer to a unique template object, and that the number of arguments equals the number of parameters in the corresponding signature.

Well-foundedness is a property that ensures that all templates are properly defined, that is, there are no templates that depend on a template object that is a signature only. It characterizes the fact that instances can be expanded all the way to instances of base templates only. Note that well-foundedness is not the same as acyclicity. A template that depends on a template object which is a signature is non-well-founded but acyclic, while a template that directly depends on a base template and itself (recursively) is well-founded and cyclic.

The difference between a semi-valid and a valid library is whether all template objects are properly defined or not.

The stOTTR serialization format is designed to be a terse and easy to read and write syntax for representing OTTR templates and instances following the abstract model and syntax as defined in Section 3. The stOTTR grammar takes the Turtle RDF grammar [2] as starting point and expands this to support expressing templates and instances. Formally, stOTTR is specified in Antlr⁶⁶6https://www.antlr.org/ Extended Backus-Naur form (EBNF) that extends relevant parts of the formal Turtle grammar which is used for the representation of terms, i.e., IRIs, blank nodes and literals. The stOTTR grammar specification is developed in GitLab,⁷⁷7https://gitlab.com/ottr/spec/stOTTR and published at ottr.xyz⁸⁸8https://spec.ottr.xyz/stOTTR/0.1.4/ and Zenodo.⁹⁹9https://zenodo.org/records/12568905 Figure 5 on page 5 demonstrates the stOTTR format on the o-p:NamedPizza template.

wOTTR is an RDF vocabulary for expressing OTTR templates and instances in an RDF format. The motivation for an RDF-based serialization format for OTTR is to support a development and management environment for OTTR based only on semantic web standards, using, e.g., triple stores, SPARQL, OWL, and rule languages to manipulate and manage templates and their instances. The vocabulary is designed to result in a compact and readable representation of templates and instances in Turtle format exploiting in particular Turtle’s compact RDF list representation for expressing parameter lists, argument lists and complex type specifications. The entities defined in the wOTTR vocabulary lie close to the formal vocabulary established in Section 3; the classes, properties and named individuals of the vocabulary are listed in Table 3, Table 4, and Table 5, respectively. The wOTTR vocabulary is developed in GitLab,¹⁰¹⁰10https://gitlab.com/ottr/spec/wOTTR and published at ottr.xyz¹¹¹¹11https://spec.ottr.xyz/wOTTR/0.4.5/ and Zenodo.¹²¹²12https://zenodo.org/records/12581215