pOTTR: Incrementally building a template library
Table of Contents
Incrementally building a template library
A top-down modelling approach for building template libraries.
- Authors
- Daniel Lupp
- Issues
- https://gitlab.com/ottr/language/pOTTR/issues
1 Introduction
In this chapter we will see how OTTR can be employed to incrementally build a template library for a given domain. We recommend the reader to familiarize themselves with the basics of OTTR before proceeding, as the use case will make use of all many of its features.
The example domain we will be considering in the following is that of mobile phones. Specifically, we wish to represent the design of various phones and the parts of which they consist. To that end, we differentiate between a phone model, which designates a specific type or make of phone, and phone instance, which refers to a specific, physical mobile phone (referred to via some identifier).
We wish to build a template library that will aid us in building a
knowledge base for this domain. To do this, we will follow a top-down
design methodology, i.e., we will begin by defining high-level templates that
closely reflect intuitive conceptualizations within the domain of
interest. In Section 2 we begin by defining templates that cover key
terms in the domain, ex:Phone and ex:ConsistsOf. In Section 3
we work our way conceptually downwards, and define necessary
templates that generate a usable ontology.
1.1 Prefixes
The following prefixes are used throughout the document, and may be used in the text input areas of the interactive examples without declaration.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dbp: <http://dbpedia.org/ontology/> . @prefix ex: <http://example.com/ns#> . @prefix ottr: <http://ns.ottr.xyz/0.4/> . @prefix ax: <http://tpl.ottr.xyz/owl/axiom/0.1/> . @prefix rstr: <http://tpl.ottr.xyz/owl/restriction/0.1/> .
2 Defining core patterns
As is common in modeoling, one must first determine what important
concepts one wishes to model. In our domain, the central notion is
that of a phone. In order to capture this notion, we introduce a new
template called ex:PhoneTemplate.
2.1 Exercise: Creating a signature
In the following we see some example inputs given by end-users. We see that our template takes three arguments: the class of phones being created, the parts list, as well as a label. In the form below, add a suitable signature such that, when expanding, the output equals the input.
Note the use of base templates here: this is a very useful tool when constructing a template library. It allows us to check, amongst other things, whether our signatures are correct. Throughout this example, we will see how base templates can be used to check whether our top-down modeling approach is yielding the intended results.
2.2 Exercise: Extending the signature to a template
The next step in our example is to define what it means for something to be a phone. For the purposes of our use case, we wish to model that
- the parameter
?nameis a subclass ofex:Phone, - the second parameter
?componentsis a list comprising the parts?nameconsists of, and - the third parameter
?labelis a label of?name.
Here we once more make use of base templates as a design tool. We
introduce a new base template ex:ConsistsOf. The intention is that, once
we have defined the body of ex:ConsistsOf, this template expands
to an ontology that models that ?device consists of precisely
the parts in the paramter ?components. We postpone this modeling
problem to later and thus regard it as a base template for the time being.
In the fields below, use ex:ConsistsOf as well as other templates
defined at tpl.ottr.xyz in order to create the body of the
ex:PhoneTemplate.
3 Refining incrementally
Having defined the top-level templates in the previous
section, our task is now to conceptually work our way down and add
more granularity to our model. We begin by more precisely defining the
ex:ConsistsOf template.
3.1 Exercise: Add ConsistsOf
As we have done before, we will once more make use of base templates
as an aid in modeling. Previously, we described the intended
expansion of ex:ConsistsOf as modeling that ?device consists
precisely of the components in ?components. In the context of
our domain, ?phone "consists of" the elements in ?components if two
conditions are satisfied:
?phonehas some component of each of the classes in?components,?phonehas only components from the classes in?components.
Use the base templates ex:HasComponents and ex:OnlyComponents templates below
to define the ex:ConsistsOf template. We will define
ex:HasComponents and ex:OnlyComponents in the next exercise.
3.2 Exercise: Add HasComponents and OnlyComponents
Our next step is to define the ex:HasComponents and
ex:OnlyComponents templates. For convenience, we have already
defined the ex:HasComponent template below with respect to
existing OWL templates. In description logic notation,
ex:HasComponent(A, B) will expand to the axiom
\[
A \sqsubseteq \exists \text{ex:hasComponent}.B,
\]
i.e., that all elements of \(A\) are related to some \(B\) via the
property ex:hasComponent.
Use ex:HasComponent below as well as existing OWL and RDFS
templates in tpl.ottr.xyz to define ex:HasComponents and
ex:OnlyComponents.
Hint: Recall the use of expansion modes as well as blank nodes from the OTTR basics, and take a look at rstr:ObjectUnionOf and ax:SubObjectAllValuesFrom).
4 Instantiation
4.1 Exercise: Add PhoneInstance
As we said in the introduction, we wish to model both phone models
as well as phone instances. The templates we have constructed so
far have only been concerned with creating the classes of phones
and not with populating them with specific phone instances. The
template ex:PhoneInstance that we define in this section aims to
remedy this.
Thankfully, modeling phone instance in our scenario is not too complex. Using the paramter names from the signature given below, our template should model:
?phoneInstanceis of type?phoneand?phoneInstanceisex:hasComponentrelated to each of the individuals in?components.
Define the template ex:PhoneInstance below. Recall the use of
expansion modes from basics of OTTR and that you can use
pre-defined templates, such as ottr:Triple or those found at
tpl.ottr.xyz.
4.2 Exercise: Instantiation
We have now constructed our template library and can populate the model with relevant classes and indivudals. Create one or more new phone models and populate them with phone instances.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dbp: <http://dbpedia.org/ontology/> . @prefix ex: <http://example.com/ns#> . @prefix ottr: <http://ns.ottr.xyz/0.4/> . @prefix ax: <http://tpl.ottr.xyz/owl/axiom/0.1/> . @prefix rstr: <http://tpl.ottr.xyz/owl/restriction/0.1/> . ex:PhoneTemplate(ex:Nokia3310, (ex:Screen, ex:HardCase, ex:CPU), "indestructible"^^xsd:string). ex:PhoneTemplate(ex:SamsungS9, (ex:CurvedScreen, ex:FastCPU), none). ex:PhoneTemplate(ex:iPhone8, (ex:RetinaScreen, ex:OtherFastCPU, ex:FPReader), "iphone"^^xsd:string).
5 Appendix
5.1 WebLutra
The web application that drives the interactive examples in this primer, called WebLutra, uses Lutra, the reference application for OTTR. Both applications are open source and available at http://gitlab.com/ottr/lutra/lutra. If you experience errors or have suggestions for improvements, please take a look at existing issues or file a new issue: http://gitlab.com/ottr/lutra/lutra/issues