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.

II. THE TYPE SYSTEM IN WissKI

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 ActivityThis 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 Media Category for source concepts, not for sources seen as objects.

TYPEOrganisational 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 PersonalCategory for natural persons (actors).

TYPEPersonal_RoleN.A.

TYPE Place Category for locations outside the 3D models.

TYPE PlantCategory 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":

III. BROADER and NARROWER TERM

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“.

IV. CAN BE PART OF and CAN HAVE PART

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).

V. IDENTIFIER

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:

VI. WORKFLOW

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.

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.

VII. CONCLUSION

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!