Version 6 (modified by jowik, 16 years ago)


TracNav menu

The elements of a template definition

The purpose of this page is to give an overview of the elements that go into defining an ISO 15926 template in its generic form, by which is meant the definition of what it expresses, without consideration of practical implementation. A template is primarily defined in an implementation-agnostic form, using first-order logic. Implementations will attempt to capture such definitions.

The explanations given here are informal on purpose, and directed toward the practical use of templates. Formal-logical definitions to match will be provided in due course.

Go to MmtSig for background.

Template roles

Roles are unary predicates. A role is used to specify constraints on single things. Note that "thing" is used here in the generic sense of ISO 15926-2 Thing, and may have intended interpretation as variously a physical object, a class, a metaclass, a number, and so forth.

A template role will typically lay down constraints of the following kinds, about an argument x:

  • The ISO 15926 entity type(s) of x
  • Data type, if x is a piece of data
  • Classifiers: What class (classes) does x belong to?
  • Superclasses: Of what class (classes) is x a variant?

For example, a role can be used to specify that an argument x is a person, that it is some kind of activity, that it is a category of equipment. In the first case, it will state that x belongs to the class of persons (classification); in the second, that x has an Activity entity type; in the third, that x is an artefact class.

In implementations, role definitions that go beyond mere assignment of entity types will need to refer to one or several ontologies (Reference Data Libraries, RDLs) for the definitions of classes.


A template is a predicate with an arbitrary number of argument places.

A template instance is a sentence made by filling the argument places with (identifiers for) things. The things that instantiate the arguments of a template are called role-fillers.

Templates should ideally be named using a system of human-friendly mnemonics. Every template should be accompanied by an informal explanation of what statement is expressed by an instance.

For example, a minimal account of a template may be given as, "the template IDt(x, y) may be used to express that y is a name (a textual identifier, hence the t in IDt) of the thing x".

(Proposal: A shortcut template is adequately defined as long as its name and number of arguments are specified. It is then understood that the arguments are all Thing's in the ISO 15926-2 sense.)

Template signatures

A template signature is a conditional that assigns roles to the arguments of a template predicate. The signature lays down minimal requirements on what counts as a candidate fact made using the template predicate.

For example, given a ternary template T and roles R1, R2, and R3, a signature for T can have the form

T( x1, x2, x3 ) --> R1( x1 ) and R2( x2 ) and R3( x3 ).

(Proposal: A light template is adequately defined given that it has a signature. In the degenerate case that all roles require nothing beyond the minimum, that each argument should have the Thing entity type, a light template is equivalent to a shortcut template.)

Template rules

A template rule serves to capture the relationship(s) between the arguments that enter into a template. In other words, a template rule determines how the role-fillers of a template instance are related.

A template rule should provide an unambiguous account of what fact is expressed by an instance of a template.

For example, a rule can have the following form. Note that the conditional of the template signature is replaced by a biconditional; we assume T1 and T2 are binary predicates.

T( x1, x2, x3 ) <-->

R1( x1 ) and R2( x2 ) and R3( x3 ) (the signature) and T1( x1, x2 ) and T2( x2, x3 )

A proper template rule for a template T serves to relate any statement made using T to a set of simpler statements. For complex templates, this means specifying a set of statements using other, less complex templates that say the same as the statement using just T.

Reduction: Evaluating a rule in the left--right direction yields a set of statements with a lower complexity. Eventually, any complex statement expressed using templates should reduce, by the application of rules, to statements that employ no vocabulary beyond ISO 15926-2, simple classes and relations from a Reference Data Library, and individual identifiers. This reduction to a canonical format is intended to serve the purpose of a common data format for storage and exchange.

Construction: A proper template rule is bidirectional. Given a set of ISO 15926 data, what facts it implies, as expressed using templates, should be unambiguously given. The facts can be discovered by evaluating definition rules in the right--left direction.

About PCA
Reference Data Services