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.

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.

Templates

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 are limited to specifying 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 rules determines how the role-fillers of a template instance are related.