\section{Introduction}
\label{sec:introduction}
The basic building block for constructing modelling tool architectures is the relationship between a type and its instances~\cite{ConceptsForComparing,DMLA}.
It is only through this relation, that a distinction can be made between a model and its associated metamodel.
Effectively, a metamodelling hierarchy consists of a set of models, between which the type/instance relation holds.
The type/instance relation is bidirectional: going from the metamodel to the model, there is instantiation, and going from the model to the metamodel, there is conformance.
There is no doubt that this is a special kind of relation, which is of critical importance to the tool.
For example, strict metamodelling~\cite{StrictProfilesWhyAndHow} does not allow relations between a model and its metamodel, \emph{with the exception of the typing relation}.

But due to the special attention given to these relations, it is often shifted to the implementation level.
This is done for a multitude of reasons, the most obvious ones being conceptual clarity (the whole tool depends on it) and performance (it is a frequent operation).
Most (meta-)modelling tools store the typing somewhere internally in a datastructure, without exposing it to the user.
Similarly, instantiation and conformance checking semantics are hidden from the user.
While this is a working solution, such important aspects are hidden inside of the (hardcoded) implementation, with only (possibly non-existent) documentation to guide users.
For example, what is the semantics of the typing relation?
When can one consider a model to be typed by another (meta)model?
And how is it possible, in a uniform way, to change or read out the type of elements?

It has been shown that many alternative conceptual frameworks and implementations have been proposed~\cite{ConceptsForComparing}, each with their distinct advantages and disadvantages.
Since current tools fix their used framework and type/instance relationship, they become unusable in different domains.
This kind of inflexibility was previously identified as one of the major shortcomings of current tools~\cite{Papyrus}.

In this paper, we touch upon these, and other, problems, which we believe are raised by the implicit, hardcoded type/instance relation.
We propose to explicitly model the type/instance relation, by pulling it out of the coded implementation, and making it user-accessible.
This includes the type mapping, but also the instantiation and conformance checking semantics.
To prevent the extension of the tool interface, and further increase the applicability of the features of our tool, both the type mapping and the semantics will be models in their own right.
As they are models, they can become subject to all features offered for ordinary models, such as model versioning, model transformations, and model management operations in general.
We discuss both advantages and disadvantages of our approach, followed by an example application.

The remainder of this paper is structured as follows.
Section~\ref{sec:conformance} elaborates on the type/instance relation, and the limitations of the common approaches in use nowadays.
Section~\ref{sec:explicit_conformance} presents our solution to these problems: the explicit modelling of both instantiation and conformance checking semantics, combined with an explicit type mapping model.
An example application is given in Section~\ref{sec:example}, where different kinds of subtyping are implemented in our tool.
Related work is presented in Section~\ref{sec:related_work}.
Section~\ref{sec:conclusions} concludes the paper and presents future work.