We have yet to properly specify and formally evaluate a tool-supported methodology for the development and maintenance of knowledge bases using OTTR templates. However, we believe the abstraction mechanism that OTTR templates provide can work in a similar manner as application programming interfaces (APIs) work for programming and software engineering. We anticipate the following roles for such a methodology:
Template library designer
This is the designer and maintainer of the basic and core template libraries. The job of the library designer is to construct well-designed interfaces, i.e., capture modelling patterns using OTTR templates, for basic RDF and OWL vocabularies, such as the RDF and OWL vocabularies themselves, but also other vocabularies like SKOS, Dublin Core, BFO, and possibly also special purpose vocabularies like Galen where ontological expertise is required to correctly understand the vocabulary. Hence, this role requires good insight into the underlying logical languages, i.e., RDF and OWL, and the OTTR language. There is currently no special-purpose editor for this role; we recommend that you use your favourite text-editor to create templates “by hand” in stOTTR syntax, and use Lutra to check the correctness of your templates.
Template programmer
The job of the template programmer is to bridge the abstractions over the logical vocabulary created by the template library designer with the conceptualisation of domain experts. The is achieved by creating user-facing templates that combine and restrict already existing templates available in template libraries, to create new templates that capture specific modelling patterns for given tasks. The programmer must have a firm grasp on the users’ needs and task, but need “only” to understand the templates in the library and to lesser extent understand the formal logic that underlies these templates. This requires that the templates in the library are well-documented. The user-facing templates form the interface for data input (and possibly output) that is presented to the domain expert. There is currently no tool support for this role, other than what is available to the library designer. We have ideas for a standalone tool to support the template programmer.
Domain expert
The domain expert is equipped by the template programmer with a well-designed set of user-facing templates. However, for the domain expert these templates present themselves only in the form of structurally simple spreadsheet formats, i.e., tabular forms with column headers and explanations. We assume that it is possible to create such formats that lie close to the domain experts existing conceptualisation of the domain. This would make them easy to understand and use. “Using” means here 1) creating template instances by filling in data row in the tabular format, or 2) using the format as a query, in which the results of the query will be presented as data rows in the same format. The tabOTTR specification and Lutra provide support for this user role.
An input format prepared by the template programmer and filled with data by the domain expert can, using the template expansion mechanism, be consistently translated into a knowledge base using the vocabulary prescribed by the templates. The separation of responsibility between the roles allows a single template library designer to serve multiple template programmers, which in turn can serve multiple domain experts. This fits the skill and tools sets that information modelling projects typically have available, e.g., domain experts are used to working with spreadsheets and rarely have the competence required for working with ontology editors, while there are usually fewer people that have the required logical background and competence for building and maintaining semantic knowledge bases.
