Computer Aided Design (CAD) software primarily focused on creating two-dimensional digital drawings. The only meaningful concept in these software packages was to organise the drawn lines by so-called layers that could be turned visible or not. While the field of prospective architectural 3D models experienced a continuous development to meaningful parametric model parts (Fig. 1) – starting with Graphisoft’s ”Virtual Building“ concept for the first version of the ArchiCAD software in 1987 and leading to present-day Building Information Modelling (BIM) systems –, the field of descriptive 3D models for visualisation tasks mostly practised for reconstructions remained rather “meaningless” until today (Fig. 2) (Cf. BLÜMEL 2013 for distinguishing between prospective (for planning tasks) and descriptive architectural 3D models). There are actual ambitions on developing BIM-like features for the 3D modelling software products Rhino and FormZ. There are no reports on such attempts for more common modelling and visualisation products like Maya, 3D StudioMAX, Cinema 4d or the open source software Blender. Stephen Wittkopf differentiated between “geometric modelling” and “semantic modelling” meaning BIM concepts (WITTKOPF 2001, pp. 77). For reasons of disambiguation with the same term used for data modelling in information technology, we prefer to call the object-oriented meaningful approach in 3D modelling Semantic 3D Modelling (HAUCK 2014).
Fig. 1: A wall with attributes in ArchiCAD 17 (screenshot).
The object-oriented approach of contemporary BIM models only allows the input of geometric objects when meaningful attributes are added. Eg. the walls forming a room can only be created adding attributes about the wall surface material. When the software creates a book of finishings room by room, the wall’s surface information is collected for each room – all automatically. This simple example shows the large benefit of semantic modelling for planning purposes.
Linking 3D model parts representing real building parts or other items of interest (so-called objects) with the sources for their 3D reconstruction also requires a meaningful approach: If the sources describe for example a wall with a fireplace, it is necessary to attach the information to the 3D objects in the 3D model representing these terms. Defining an object in the model is not a question of technical visualisation requirements any more, but it is a question of scientific topics with a special focus on the reconstruction’s sources.
We model what we are talking and thinking about. Thus we define the 3D objects in the model by the architectural technical terms used in the descriptions (sources) and during the discussions of the 3D reconstruction process. This is also the reason why actual BIM software products can’t be used for reconstruction purposes: as contemporary BIM models describe contemporary architecture with the technical terms of our times, it is very difficult to describe premodern architectural building parts with their corresponding terms and also terms from other disciplines than architecture with the products on the market.
Fig. 2: A cuboid in Maya without any meaning representing the same wall geometry as the example in Fig. 1 (screenshot).
Another reason for not using BIM software for digital 3D reconstruction is the reconstruction’s focus on visual communication: even if it comes to the visualisation of BIM models using state-of-the-art rendering software, the data set is trimmed to containing only information about the geometry and the visual appearance of the surfaces to be rendered. All other information behind the rendered pixels gets lost. This is one important reason why this information is generally not documented in 3D reconstructions solely published by imagery: all efforts of documentation are worthless if there is no means of publishing. Thus the call for scientific documentation of digital 3D reconstructions is in fact the call for virtual research environments (VRE) that bring the research the reconstruction is based on together with semantic 3D models telling the story of their own creation. Cultural Heritage Markup Language (CHML) is designed to describe the processes of 3D reconstructions and builds the foundation for a VRE in this field – this WissKI application.
The semantic core of CHML – and though of this WissKI application – is a simple attribute called type. The type gives everything a meaning. It is a required attribute for every object, source, activity and actor. It consists of a four letter code for example CEIL for ceiling. The type is a non-ambiguous categorisation that can be linked to authority files, controlled vocabularies, thesauri and wikipedia (or DBpedia). The type system can be used for creating project’s glossaries and for the translation of technical terms. The type system can be seen as the basis for a controlled vocabulary and even a thesaurus for 3D reconstructions. Every type has hierarchical relations with other types: a “window”, for example is a narrower term than “opening”, “tracery window” is a narrower term than “window”. But there are also other, more complex relations expressed by certain rules: an architectural survey as a type for activities for example creates always primary sources for the reconstruction. A window or a niche is always part of a wall. In addition to that, types can be correlated with certain traditional architectural scales or levels of detail.
see also: Semantic Level of Detail
please read carefully: VA 2015 paper
— Read on www.patrimonium.net/node/14095