TYPE | The Labelling System


Types in CHML and in WissKI (patrimonium.net) are used for disambiguation of items around the digital 3D reconstructions of physical objects in the cultural heritage.

Thus there are types for objects, sources, events/activities, natural parsons, corporate bodies, places, digital source types, materials. 

Types are also linked to existing controlled vocabularies and thesauri such as Getty AAT and GND.

Types are not a thesaurus by their own, but our project’s gate to the semantic web.

In general this implies that the aim is not to have a complete thesaurus or vocabulary for 3D reconstructions, but rather to represent exactly the terms used in the project with their translation into the four project’s languages: German, Polish, Russian and English. The focus is on the 3D objects to be modeled. Everything else is to be seen as auxiliary and of minor interest.

Types can be changed throughout the workflow. They are not fixed to an item once and forever.

If there are doubts about what is the right type for something, a broader term should be applied. If it is not sure whether a tree was a lime tree or an oak, the term "tree" should be used. The broadest term for objects for example is "object" – this is called the "fallback type" (in this case for objects).

For the management of the terms we designd the TYPE Editor within WissKI, see figure below.


TYPE Editor



Compared to existing thesauri and controlled vocabularies, the patrimonium.net type system has a very flat hierarchy.

There are the following categories at present (this can be changed if necessary):

TYPE Activity This is the category for any kind of "research activity" around the objects to be modeled, e.g. surveys, laser scan, photographic documentation, historic research, source evaluation, 3D modeling, etc.

TYPE Animal Category for animals.

TYPE Digital-Source-Type Digital source types according to IPTC. Do not add any other terms to this category!

TYPE Event Every action and historic event that does not fall within the definition of an activity (vide supra) is an event.

TYPE Exterior Everything belonging to open space that is neither part of façades (facade), infrastructure, light source, organizational, plant nor structural.

TYPE Facade Category for façade elements not being structural.

TYPE Furnishing None-fixed interior furnishing.

TYPE Infrastructure Category for objects like canals, streets, etc.

TYPE Institution Category for corporate bodies (actors).

TYPE Interior Category for objects of interior design not defined as furnishing (vide supra).

TYPE Light-Source Category for light sources

TYPE Material Category for materials as used in the 3D model.

TYPE Measurement Category for measuring units.

TYPE Media Category for source concepts, not for sources seen as objects.

TYPE Organisational Category for objects that include many structural and other kinds of objects but are not necessarily built themselves. Eg.: rooms, wings, floors, etc.

TYPE Personal_Relation N.A.

TYPE Personal Category for natural persons (actors).

TYPE Personal_Role N.A.

TYPE Place Category for locations outside the 3D models.

TYPE Plant Category for plants.

TYPE Structural Category for supporting building and major architectural components parts like walls, piers, columns etc.


Every type must have at least one entry in the field "broader term" referring to one of these categories to make it appear in the right pulldown menu in the main "entry masks" for the themes: Objects, Sources, Events, Actors (CorporateBodies & NaturalPersons) and Places.

The most appropriate term has to be chosen. Some types may have more than one entry: WIND:window for example can be "interior" or "façade". But there should never be a mixture between types for different masks: if a term has a broader entry for objects (e.g. painting: furnishing) it can’t have a broader entry for sources( e.g. painting: media). There should be two different painting types instead.

The following chart shows the hierarchy of the type system for the main "entry masks":

Hierarchy of the type system 



The input fields „broader term“ and „narrower term“ are used according to ISO 25964. This means that the relation shows that the narrower term is more specific than the broader term.

All corinthian capitals can be seen as capitals, but not all capitals are corinthian capitals. Therefore „capital“ is a broader term for „corinthian capital“ and „corinthian capital“ is a narrower term for „capital“.



This field is specific for object types. It allows to add common part-of relations to objects.

A capital "can be part of" a column. A wall „can have part“ opening. It is defined as "can" not as "is" because there exist walls without openings and capitals have been often re-used as spoils for bases (a famous example is the so-called basilica cistern in Istanbul).



This section of the type input mask is for linking the term to the semantic web. Either "identifier"/"source" can be used or "URL" for direct linking.

In general there are four sources at present that can be used for automatic linking: Getty AAT, Getty TGN, Getty ULAN and German National Library’s GND.

In these cases the only thing needed for input is the appropriate ID and mentioning one the forementioned four sources in the "source field".

All other thesauri, controlled vocabularies or wikipedia should be entered with complete URL in the URL field. The use of all three fields is deprecated.

The following illustration shows an excerpt of object types with their relations:

Object types with their relations



Only few patrimonium.net users are allowed to conduct the type system. Thus there are two important questions for using patrimonial.net concerning types.

1. What should I do if the appropriate type for my entry is missing?

For this case, there are so-called "fallback types" for each kind of mask as shown in the table below.

Fallback types


2. Which type should I choose if I am not sure about using the right type or if the type is still topic of an open discussion?

In this case, the closest "broader term" should be applied. If for example it is not clear whether a capital is a "corinthian capital" (KCAP) or a "composite capital" (CCAP), the broader term "capital" (CAPI) should be applied.

In case of greater doubts ("Is it a capital at all?"), also the "fallback type" (OBJE:object) can be used.

3. What should we do, if there is no English term (no fitting translation) for a specific object? 

In this case we can (and we should) use the term in the specific language (e.g. German, Polish or Russian). For instance the term "Patronatskirche" for the church under the patronage of a lord situated near the manor is not common in English. In this case we use the vernacular term in quotation marks as preferred title (the English title), see figure below. In the description the meaning (in english) should be provided.




Types are the semantic core of the project and thus should be introduced carefully and discussed in the project team.

The input should be semantically correct and make sense.

If there are any doubts about the translation of a term, please don’t use the translation. No content is preferred against wrong content!


Compare also: ISO 25964 Information and documentation - Thesauri and interoperability with other vocabularies (Link)

Part 1: Thesauri for information retrieval     [published August 2011]

Part 2: Interoperability with other vocabularies     [published March 2013]



Hierarchy of the type system.png315.72 KB
Fallback types.png178.79 KB
Object types with their relations.png288.07 KB
TYPE_Patronatskirche.png56.78 KB
TYPE_Editor.png109.99 KB