A Semantic Framework for Virtual Reconstructions: A Formalised Ontology for Documenting 3D Modelling Processes Through HBIM and Knowledge Graphs Systems

1. Introduction

1.1. Documentation Frameworks for Virtual Reconstructions

The theoretical foundations of transparency in virtual reconstruction were laid by two milestone documents. The London Charter [1] established that computer-based visualisation of cultural heritage must be grounded in documented research sources and that the relationship between sources, implicit knowledge, and visual outcomes should be made explicit through paradata. The Seville Principles [2] translated these general requirements into the specific domain of virtual archaeology, introducing, among others, the principles of scientific transparency and authenticity, and recommending that the degree of historical–archaeological evidence supporting each reconstructed element be communicated to the public. The notion of paradata itself, the documentation of the interpretative processes underlying visualisation, was systematised in the volume by Bentkowska-Kafel, Denard and Baker [3], which remains the conceptual reference for the field.

A first family of operational responses to these principles concerns the visual communication of reliability. Numerous scales of certainty or evidence have been proposed, typically mapping levels of documentary support onto colour gradients or transparency values applied to the finished model [4,5,6,7]. More recent work has moved from qualitative scales towards the quantification of uncertainty, proposing user-independent metrics and multi-feature analyses at the scale of the single element [8] and of the whole urban scene [9]. While increasingly rigorous, these approaches generally operate a posteriori and at the level of the rendered surface: the assessment is communicated, but the reasoning that produced it, and in particular the documentary basis of each individual dimension, is not always recorded in a structured, machine-readable form that descends below the architectural element to the individual source or measurement.

A second family addresses the formalisation of the reconstructive reasoning itself. The Extended Matrix [10,11,12] adapts the stratigraphic logic of the Harris Matrix to virtual reconstruction, introducing dedicated units that allow the source-based inference process to be diagrammed, connected to sources, and published alongside the model; its associated open-source toolset supports the entire pipeline from documentation to publication, and has been progressively aligned with CIDOC CRM, CRMarchaeo [13,14,15] and implemented within the HBIM framework [16,17].

Regarding infrastructure development, comparable efforts include the structured documentation schemes developed within the DFG network on digital 3D reconstruction [18], the CoVHer project [19], WissKI repository [20,21] and infrastructures for the documentation of virtual reconstructions such as IDOVIR [22,23]. These approaches share the conviction that validation requires the process, not only the product, to be published. However, their granularity generally stops at the level of the interpretative unit or hypothesis: the geometric operations through which evidence becomes shape, the construction logic of profiles, paths, and primitives, are not part of the documented record.

1.2. Heritage Ontologies and Semantic Documentation

The CIDOC Conceptual Reference Model (CIDOC CRM, ISO 21127) [24] provides the de facto ontological standard for cultural heritage information, modelling the domain through event-centric patterns in which things, actors, places, and time are connected by documented events. Its extension family is directly relevant to reconstruction documentation: CRMdig models the provenance of digital objects and digitisation processes [25]; CRMsci formalises scientific observation, measurement, and inference making [26]; CRMinf provides a fine-grained model of argumentation, beliefs, and premises; CRMba addresses the documentation of standing buildings and their stratigraphy [27]; CRMarchaeo covers excavation processes; and CRMgeo provides the spatiotemporal grounding [28]. Together, these modules make it possible, in principle, to express how a statement about a past state of a building derives from observations and inferences on evidence, which is precisely the chain that scientific validation requires.

Several projects have built reconstruction-specific ontologies on this foundation. Of relevance to the present work is the notion of Virtual Reconstruction Information Management (VRIM methodology) [29], which proposed a scientific method and a data structure for documenting and visualising virtual reconstruction processes rather than only their outputs [30,31].

Within the German-speaking tradition of digital reconstruction, the OntSciDoc3D initiative and related ontologies [32] model the scientific documentation of hypothetical 3D reconstructions, connecting sources, actors, and variants.

In the archaeological domain, European infrastructure projects such as ARIADNEplus have consolidated CRM-based catalogues of archaeological datasets, including 3D content [33,34,35]. These experiences demonstrate the maturity of CRM-based documentation [36], but they also reveal a recurrent limitation for the architectural case: the modelling act itself is often treated as a black box, a digitisation or creation event with inputs and outputs, while the internal geometric reasoning, the dimensional data extracted from sources, and their differentiated reliability remain outside the formalised record.

As regards publication environments, ResearchSpace (RS) [37] an open-source platform on top of a CRM-based knowledge graph, enables the creation of semantic narratives, annotation, and structured search over heritage data. Its native support for CIDOC CRM and its extensible visualisation components make it a natural candidate for publishing reconstruction records in which documentation and 3D content can remain visually connected. Beyond its origin at the British Museum, where it was developed with funding from the Andrew W. Mellon Foundation, RS has been adopted by a growing community of cultural-heritage institutions and research institutions [38]. Among them are national bodies such as the National Gallery Collection in London, which uses it to record conservation practice together with provenance and historical context [39].

1.3. BIM, Semantic Web, and their Integration for Heritage

Historic Building Information Modelling (HBIM) has become an established methodology for the documentation and management of built heritage since the seminal work of Murphy et al. [40] and comprehensive reviews chart its evolution towards semantic enrichment and interoperability [41]. The Industry Foundation Classes (IFC, ISO 16739) constitute the openBIM exchange standard [42], describing buildings as hierarchies of semantically classified components; however, the IFC schema was conceived for contemporary construction, and its native classifications only partially cover the descriptive needs of historical architecture, prompting research on extension and enrichment strategies for heritage [43,44]. Attempts to bridge BIM data and heritage ontologies have multiplied in recent years [45], including mappings from IFC to CIDOC CRM for archaeological and architectural documentation [46], hybrid HBIM–knowledge graph workflows for conservation [47], and semantic web publication of HBIM models [48]. These works confirm both the feasibility and the value of the integration, but they typically address the descriptive state of the building [49], what exists and its properties, rather than the reconstructive process: the documentation of how a hypothetical or restored state was derived from sources, with its uncertainties and dimensional interpretations, has not yet been the object of a dedicated, openly published ontological framework connected to the IFC model at publication time.

The convergence between BIM and the semantic web has followed two main routes. The first is the direct translation of the IFC schema into OWL: the ifcOWL ontology [50,51] provides a complete Resource Description Framework (RDF) representation of IFC data, at the cost of inheriting its complexity [52]. The second is the modular approach of the W3C Linked Building Data community, which proposes lightweight ontologies such as the Building Topology Ontology (BOT) [53,54] to describe buildings in a web-native way, linked to domain ontologies as needed. The distance between IFC and the CRM family, however, suggests the limits of any schema-level translation for the reconstructive case. A comparison conducted between IFC 4.3.2 (876 entities and about 13,900 descriptive attributes) and CIDOC CRM v7.1.3 with its built-heritage extension CRMba shows an asymmetric overlap: the topological and compositional relations that structure an IFC model find direct counterparts on the CRM side, whereas the historical–stratigraphic and evidential dimensions, construction phases, reuse of material, and, more generally, the temporal depth of the built object, have no systematic counterpart in IFC, which describes a single, synchronic state of the building. A full translation of one schema into the other is therefore either lossy or artificial; a more sustainable strategy is to let each standard operate in its own domain and to establish the connection at the terminological level, through shared classification.

IFC natively supports this strategy: through the IfcClassification / IfcRelAssociatesClassification mechanism, any element of the model can be associated with references to an external classification system. The buildingSMART Data Dictionary (bSDD) [55] complements this mechanism as a publication service for machine-readable dictionaries, classification systems, properties, and allowed values identified by persistent URIs that can be attached to IFC models to guarantee terminological consistency across tools and domains [56,57]. On the heritage side, the Getty Art & Architecture Thesaurus (AAT) [58] is the reference-controlled vocabulary for art and architecture, published as Linked Open Data and widely adopted for the semantic annotation of heritage datasets; its hierarchies cover, among much else, the components and canonical systems of architectural elements.

A classification of architectural elements published on bSDD and terminologically grounded in AAT can therefore act as a bridge that is at once operational in the BIM environment and citable in the knowledge graph, a possibility that, to the best of our knowledge, has not yet been systematically explored for virtual reconstruction.

1.4. Positioning of the Present Work

The review above outlines a converging but still incomplete landscape. Against this background, the paper addresses a single research question: how can the process of virtually reconstructing architectural heritage, its geometry, its sources, and the reliability of each choice be documented so that it remains transparent, machine-actionable, and jointly explorable with the 3D model? The novelty of the answer is the connective tissue that the landscape still lacks: an ontology that documents the reconstruction down to its geometric and dimensional reasoning, terminologically classified through bSDD and the Getty AAT, and reused and validated inside an open platform where the knowledge graph and the IFC model remain linked. Concretely, the paper makes three contributions:

(i) it releases and formally implements CRMvr, a CIDOC CRM-aligned ontology for the virtual reconstruction process, tested against real data rather than only specified; (ii) it defines a classification-based method that connects HBIM/IFC modelling and CRM documentation through a shared bSDD/Getty AAT vocabulary of architectural elements;(iii) it demonstrates, on the aedicula of the Porta Aurea in Ravenna case study, a reconstruction record in which geometry, sources, and reliability remain connected in RS.

2. An Ontology for Virtual Reconstructions (CRMvr)

2.1. Design Principles and Alignment

CRMvr (CRM extension for Virtual Reconstructions) is an application ontology designed to document, in a machine-readable and interoperable form, the process by which a virtual reconstruction of architectural heritage is derived from evidence [29]. It is aligned to CIDOC CRM and extends two of its modules: CRMdig, for the provenance of digital objects and digitisation processes, and CRMsci, for scientific observation and inference making. In its current release (version 1.0.0) CRMvr comprises 25 classes (V1-V25) and 113 object properties (VP1-VP62 with their inverses), and it is serialised in TriG as a named graph, ready for ingestion in a CRM-based triplestore (Figure 1).

The ontology [59] follows the application-ontology paradigm: rather than replicating CIDOC CRM, it introduces purpose-built classes for the entities and events that are specific to reconstruction, each declared as a subclass of an existing CRM (or CRMdig/CRMsci) class to preserve interoperability. Throughout this paper, entities are referred to using the encoding conventions established by the CIDOC CRM family of specifications: CRM classes are prefixed with E and properties with P; CRMdig classes with D and properties with L; and CRMsci classes with S and properties with O. CRMvr's own classes and properties, introduced below, follow the same logic with the prefixes V and VP.

Four design commitments shape the model. First, the heritage object is treated as a decomposable whole, so that reconstruction can be documented at the level of individual components. Second, geometry is treated as knowledge: the way a component is modelled its profiles, its paths, its ordered primitives is documented explicitly, opening the black box of the modelling act. Third, reconstruction is treated as inherently plural: alternative hypotheses about the same object are represented as distinct, authored versions. Fourth, every reconstructive statement is treated as an inference from sources whose uncertainty, accuracy, and dimensional provenance can be evaluated and recorded.

2.2. Decomposition of the Heritage Object

The upper level of CRMvr defines the object of reconstruction and its context. V1 Domain (subclass of E77 Persistent Item) delimits the area of interest of which the reconstructed object is part, comprising all entities attributable to a given cultural-heritage context. Within it, the model distinguishes V2 Immaterial Heritage (subclass of E89 Propositional Object), for heritage documented by sources but without a certain physical existence, from V3 Cultural Heritage (subclass of E24 Physical Human-Made Thing), for heritage that had a documented physical existence.

V4 Find (subclass of V3) comprises the surviving physical evidence of the heritage object, which can itself be acquired, for instance, through Structure-from-Motion and represented digitally as a V6 3D Find (subclass of D1 Digital Object).

The reconstruction proper is articulated through V5 Component Element (subclass of E89 Propositional Object), the functional units into which the object is analysed according to the declared domain and its controlled vocabulary. Component elements are recursive: a V5 may itself contain further V5 sub-components, and the depth of this part-decomposition is declared by V7 Hierarchy Identifier (subclass of E42 Identifier).

This recursive, classification-driven decomposition is the natural meeting point with the IFC spatial and compositional hierarchy, and it is the level at which the bSDD classification is attached. The digital counterpart of a component is the V8 3D Object (subclass of D1 Digital Object), the solid model typically built through constructive solid geometry that defines the volume of the element it represents (Figure 2).

2.3. Geometry as Documented Knowledge

The distinctive core of CRMvr is the explicit representation of how a component is modelled (Figure 3). V11 Geometrical Representation (subclass of E73 Information Object) captures the visual knowledge about the geometry of a V5 Component Element and is specialised into V14 Profile, the geometry in the vertical plane containing both endpoints of a profile, i.e. a vertical section of the representation and V15 Path, the geometry in the horizontal plane containing both endpoints of a path. Both are built from V12 Primitive Entity (subclass of E89 Propositional Object), the geometrical primitives necessary to construct a profile or a path, whose position in the construction sequence is declared by V13 Order of Sequence Identifier (subclass of E42 Identifier). A complementary V16 Morphological Representation (subclass of E73 Information Object) records knowledge about the morphology of a component that is not reducible to its constructive geometry: the qualitative character of its profile (an ovolo rather than a cavetto, a cyma rather than a cyma reversa) that allows the element to be recognised and named, as distinct from the metric, dimensional information that fixes its size. This distinction between geometric (dimensional) and morphological (recognitional) information recurs in the case study.

By decomposing the modelling act into ordered primitives, profiles, and paths, CRMvr records the parametric logic by which documentary evidence is translated into a shape at a level of documentation that remains outside most existing frameworks, and that is decisive for reproducibility: two modellers may produce visually similar volumes through entirely different, and differently reliable, construction logics.

2.4. Versioning and Authorship

Because reconstructions are hypothesis-driven and contingent on fragmentary evidence, several plausible reconstructions of the same object may coexist (Figure 4). CRMvr represents this plurality through V9 Version Identifier (subclass of E42 Identifier), which labels each 3D-modelled version of the same V8 3D Object produced on the basis of different evidence or references, and through V10 Author (subclass of E21 Person), which attributes each version and each evaluation associated with it to a responsible agent. Versioning and authorship together make the palimpsest effect explicit and traceable: alternative hypotheses are not silently overwritten but preserved, compared, and attributed.

2.5. Sources, Inference, and the Evaluation of Reliability

Every reconstructive statement in CRMvr is anchored to evidence through V17 Source (subclass of E73 Information Object), which comprises the sources and documents used as references for modelling. The reasoning that connects sources to geometry is modelled as an event: V18 Transparency Inference Making (subclass of S5 Inference Making, from CRMsci) comprises the act of making propositions about the geometrical or morphological representation of a Find, its digital representations, and the sources behind them, with the explicit aim of bridging the gap between documentation and 3D model. Grounding this class in CRMsci's inference-making machinery is what allows CRMvr to treat modelling as a documented scientific inference rather than an undocumented craft act.

Three specialised inference events refine this assessment. V19 Uncertainty Evaluation makes propositions on data observable from a source by evaluating its V21 Uncertainty Grade (subclass of E55 Type), while V20 Accuracy Evaluation does the same with respect to a V22 Accuracy Grade (subclass of E55 Type). Both grades are typed vocabularies that can be assigned to a V17 Source, so that uncertainty and accuracy are recorded as retrievable assessments attached to the evidence itself, rather than as colours applied to the finished surface.

Finally, CRMvr addresses a dimension of reliability that is rarely formalised: the provenance of the measurements used in modelling. V25 Evaluation of Dimension Provenance (subclass of V18) makes propositions that connect a dimension and its values to the source used for reconstruction. It relies on V24 Type of Dimension Provenance (subclass of E55 Type), which is restricted to three enumerated types indicated: when a measurement is explicitly given by a source; when it is inferred from the source; and when it is supplied by the modeller.

Because modelling software rarely uses the same units and values as the source, V23 Dimension Equivalent (subclass of E54 Dimension) records the equivalent value adopted in the modelling environment, preserving the link between the figure declared in the source and the figure realised in the model as shown in Figure 4. This three-fold provenance is, to our knowledge, the most granular expression of dimensional reliability currently available in a reconstruction ontology, and it is central to the scientific-validation aim of this special issue.

2.6. CRMvr and CRMba: Architectural Elements versus Building Sections

Because CRMvr and CRMba both decompose the built object and both align to CIDOC CRM, their comparison deserves explicit discussion. CRMba was conceived from a building-archaeology perspective, and this origin is inscribed in its core constructs [60].

Entities are named here according to encoding conventions: CRMba classes start with B and properties with BP, while CRMarchaeo classes start with A and properties with AP. CRMba pivotal notion is function, which extends from the whole building to its parts: a B1 Built Work is composed of B2 Morphological Building Sections functional parts of the monument such as wall, storey, roof, foundation, or room linked by the property BP1 has section, and each section is in turn analysed as a play between matter and space, through B3 Filled and B4 Empty Morphological Building Section, while B5 Stratigraphic Building Unit captures the stratigraphic reading of the standing fabric (Figure 5).

CRMba interprets buildings similarly to archaeology: as layered deposits of matter and void, segmented into functional parts that mirror its physical remains. Conversely, CRMvr's method arises from a different discipline, resulting in three essential semantic differences.

The first is the change in the unit of analysis: in architecture, the building is divided into elements. The most traditional example, serving as the foundation for architectural representation's analytical categories, is the classical order. An order isn’t merely a collection of parts but a system: pedestal, column, and entablature form a hierarchy, with the column further divided into base, shaft, and capital; the entablature divided into architrave, frieze, and cornice, each with distinct mouldings and profiles. This hierarchical arrangement, codified and passed down through treatises from Vitruvius to Vignola, Palladio, and Scamozzi, provides a clear terminology and relationships between parts: each element has a recognised name, a position within the system, and size relations governed by the module. This typological and generative outlook sees the building as defined by its systematic placement rather than solely by its physical fabric.

CRMvr formalises this reading through V5 Component Element and V7 Hierarchy Identifier, typed by the bSDD/AAT vocabulary. CRMba's B2 Morphological Building Section, by contrast, is a functional partition of the fabric, while for CRMvr a capital is an architectural element with a typological identity, not a morphological section of matter.

The second is that the term 'section' carries different meanings in the two fields, causing confusion when mixed. In building archaeology, a "section" (CRMba B2) refers to an analysis of existing fabric. In architecture, a section is a vertical cut or drawing of a structure. CRMvr deliberately separates these meanings: the vertical section of a component is modelled as V14 Profile, a geometric representation, not a decomposition unit. Conversely, CRMba's 'section' is a component element, while in architecture it is a profile. Making these distinctions clear helps ensure that CRMvr's type-based, element decomposition doesn't conflict with its geometric representations using profiles and paths.

Third, the two ontologies highlight different but complementary sources of evidence. CRMba focuses on the building's physical remains, including functional sections, materiality, voids, and stratigraphy, essentially treating the building as its own document. Its insights come mainly from observable fabric. In contrast, CRMvr documents the reconstruction process, relying on sources like archival records, treatises, surveys, measured drawings, and photographs (recorded as V17 Source), and evaluating them through various events (V19, V20, V25). It is most useful when the building must be inferred from indirect evidence. While CRMba asks what the building reveals physically, CRMvr investigates what the documents indicate, their reliability, and how their data translates into geometric models. This explains why the experiments occurred in an HBIM environment: HBIM naturally organises components hierarchically, fitting CRMvr’s decomposition, and constructs geometry coherently using architectural profiles along paths.

Therefore, the two ontologies are not rivals but complementary: in a monument with reconstructed sections, CRMvr's V4 Find aligns with the remaining parts described by CRMba in terms of stratigraphy (Table 1).

2.7. CRMvr and OntPreHer3D: Documenting the Model versus Documenting the Modelling

A second, closer comparison is required with OntPreHer3D [61], the recently published ontology that shares with CRMvr the goal of documenting virtual reconstruction within the CIDOC CRM family, and that explicitly evaluated the conceptual reference model of CRMvr. The two ontologies start from the same diagnosis but diverge in what they consider the object of documentation, and this divergence is instructive. OntPreHer3D classes start with M and properties with R.

The shared premise is that a 3D model alone cannot fully explain a reconstruction. A completed mesh or solid shows the result but hides the reasoning, sources, and decisions behind it. When published in a web viewer, it can be mistaken for an authoritative fact, though it’s one of many possible interpretations.

OntPreHer3D's Speyer Synagogue experiment provides strong evidence for this: four modellers, provided with the same source package and segmentation into architectural elements, created notably different reconstructions of the same round window. These differences stem not from the evidence but from their choices in simplifying and constructing the geometry. This serves as empirical proof that the model itself lacks justification and that documentation should focus on the process, not just the artefact. CRMvr fully agrees with this idea; the debate is about how best to document the process.

The two ontologies present different perspectives, and as with the term "section" above, a shared vocabulary conceals a difference in meaning. OntPreHer3D treats modelling as a simulation: its core event, M19 Simulation, is a subclass of software-execution events that record parameters like fidelity, simplification, style, and tools used to digitally recreate a physical attribute (Figure 6). The interpretive step from source to shape is handled by the CRMinf argumentation model and weighted by a numeric uncertainty value. The geometry itself is kept a black box deliberately so as to remain applicable to organic and free-form shapes. Conversely, CRMvr views modelling as a geometric construction: it exposes that black box and logs the constructive logic, ordered primitives, profile, and path that generate the solid. Reliability is based on the provenance of each dimension (indicated, deduced, or interpreted) and on source evaluations of uncertainty and accuracy.

The concept of "inference" also varies: OntPreHer3D's is CRMinf's argumentation-based inference (Inference to the Best Explanation), while CRMvr's V18 Transparency Inference Making is closer to CRMsci's scientific S5 Inference Making, which aligns more with observation and measurement. This difference was partly circumstantial when CRMvr was developed; CRMinf was not yet stable, but it aligns well with the domain, where deriving a measurement or morphological feature from a drawing is more common than belief formation. Both approaches are compatible, and the alignment of V18 with CRMinf is the direction taken by the successor discussed in Section 5.

Ultimately, OntPreHer3D documents the model and the confidence in it, whereas CRMvr documents the modelling process and the reasoning behind it; a comprehensive record could include both. The idea is that breaking down into profiles and paths is a specialised approach different from typical practice: in architecture, creating profiles and paths is the natural way the geometry is built. However, this depends on having a level of description available, not on reaching it by necessity. The profile-and-path level assumes sources that contain the necessary data, such as measured drawings, sections, or profile studies, and CRMvr supports recording at that detailed level when sources exist (like the V11 Geometrical Representation or V5 Component Element with or without internal construction) or stopping at a coarser level (V16 Morphological Representation) when they do not. The ontology sets the maximum resolution at which the process remains transparent, rather than requiring a minimum for every element.

The main conclusion, summarised in Table 2, is that neither ontology replaces the other; instead, they serve complementary roles. While OntPreHer3D investigates confidence in the simulated shape, CRMvr asks how the shape was constructed, based on which measurements, and under whose authority.

3. Implementation in ResearchSpace (RS)

The implementation demonstrates the life-cycle view set out in Section 1.4: the ontology is not only defined but reused and tested inside an operational platform. Before following the process, it is worth making explicit what is shared between the two environments, because this is the condition that lets them be aligned at all.

The alignment rests on three semantic layers, common to both the knowledge-graph framework (RS) and HBIM: at the ontology layer, CRMvr aligned with CIDOC CRM and its extensions; at the taxonomy layer, the Getty AAT vocabulary of architectural elements; and at the knowledge-representation layer, the shared apparatus through which the reconstruction is finally made explorable: knowledge maps and data retrieval on the RS side, the classified model and the IFC web viewer on the HBIM side.

Each layer is realised on both sides at once, so that the two environments speak the same language at every level rather than being reconciled after the fact.

The distinctive feature of the workflow is that these three layers do not operate in sequence but in parallel across the two environments: the semantic analysis of the sources and the geometric modelling of the object advance together and inform each other and are finally joined through the shared bSDD/Getty AAT classification (Table 3).

3.1. ResearchSpace (RS) as a Research Environment and Ontology Ingestion

RS is a free, open-source semantic-web platform that unites structured data with flexible knowledge-graph representations on a CIDOC CRM foundation [37,62,63]. It stores data as RDF triples in a triplestore, supports SPARQL querying, and can ingest ontologies in OWL or RDFS, automatically generating and tagging the knowledge patterns associated with an uploaded ontology and removing them when the ontology is withdrawn, a mechanism that supports maintainable, provenance-driven curation. CRMvr, serialised as a named graph aligned to CIDOC CRM, CRMdig, and CRMsci, is uploaded into this environment, where its classes and properties become available as configurable resources for search, templating, annotation, and visualisation. Beyond hosting the ontology, RS is used here as a genuine research environment: the place in which the documentary and iconographic sources of the reconstruction are gathered, semantically annotated, and analysed before and while the model is built.

3.2. Parallel Source Analysis and HBIM Modelling

The workflow begins in RS with the analysis of the sources. Each documentary or iconographic source, archival document, treatise, measured survey drawing, photograph, comparative example is described in the graph and semantically annotated, so that the pieces of information it carries about the object (a dimension, a profile, a morphological detail) become explicit, addressable statements rather than tacit knowledge held by the modeller. Crucially, these annotations are classified with the Getty AAT vocabulary, the same controlled vocabulary that will later type the architectural elements of the model, so that the source analysis and the model are, from the outset, expressed in a shared nomenclature.

This source analysis proceeds in parallel with the geometric modelling in the HBIM environment. The annotations produced in RS feed the modelling directly: the dimensional and morphological information extracted from each source is what the modeller uses to construct the corresponding component, and, in the reverse direction, the act of modelling reveals which information is missing, ambiguous, or in need of interpretation, sending the analysis back to the sources. Because the model is built in HBIM, the information about the resources used can be attached to the components in the BIM environment itself: each modelled element can record the level of reference (LoRef), the type of iconographic or documentary resource on which its reconstruction is based [64], so that the evidential basis of the geometry travels with the geometry. The level of reference is one of the five assessment levels through which CRMvr structures the reliability of a reconstruction: level of elements, level of measures, level of reference, level of uncertainty, and level of accuracy [65], and it corresponds, in the ontology, to the V17 Source attached to each component and to the evaluations built upon it. The use of RS thus provides a parallel process of semantic modelling of the knowledge and of the data drawn from the sources, coupled to, rather than separated from, the geometric modelling in HBIM.

3.3. Enriching the Model with the bSDD/AAT Classification and Exporting to IFC

Once the object has been modelled and populated with the information derived from the documentary and iconographic sources, the HBIM model is enriched with the semantic structure obtained through the bSDD data dictionary. This step makes the classification of the elements unambiguous: each component is defined semantically through a persistent bSDD entry, itself anchored to a Getty AAT concept. Because the source annotations in RS had already been classified with the same Getty vocabulary, model and documentation now share a single nomenclature and classification, and the two data environments become terminologically aligned by construction rather than by post-hoc reconciliation. Once the HBIM model carries the bSDD (Getty AAT) classification, it is exported to the openBIM exchange format, IFC.

3.4. Visualising the IFC Model inside ResearchSpace (RS)

For online visualisation, an open-source web-based IFC viewer was adopted. The viewer was modified so that it can display the attributes of the individual architectural elements, and not merely the geometry: selecting an element in the 3D view exposes the properties it carries, including its classification and the level-of-reference information assigned during modelling. The viewer was then linked within RS as an external page, thereby becoming an information carrier of the system. In this way, it becomes possible to display the model, interact with it, and link it to the corresponding knowledge map (KM) in RS. A KM is a visual, navigable representation of a portion of the knowledge graph: a diagrammatic canvas on which the entities of the graph, objects, sources, actors, events, concepts and the relationships between them are laid out as nodes and links that the user can explore, expand, and annotate. It is the interface through which the semantic network built around the reconstruction is read and interrogated, turning the underlying RDF triples into an explorable map of the reasoning. Once the HBIM model had been produced, all the images of the architectural elements into which the model was decomposed were inserted into this knowledge map, so that each element in the map is associated with the visual sources that document it. The source annotations and the linked IFC viewer together form a single connected environment.

The published artefact is therefore not a rendering with an accompanying report, but a reconstruction record: a single semantic environment in which the geometry, the sources, and the reasoning that links them remain connected and jointly interrogable, and in which the reliability of every modelled element can be traced back to the resources on which it rests. This directly answers the third shortcoming identified in the Introduction: the loss, at publication time, of the link between model and documentation.

4. Case Study: the aedicula of Porta Aurea in Ravenna

The workflow is demonstrated on the aedicula of the Porta Aurea of Ravenna, a monument that no longer exists and therefore can be reconstructed using both documentary and iconographic sources (Figure 7). This approach reflects the conditions under which CRMvr is intended to function. The Porta Aurea served as the grand entrance of Roman Ravenna, constructed in the first century AD during Emperor Claudius's reign. It featured a double archway, surrounded by two cylindrical towers, and was embellished with marble. For a long time, it was considered the city's most significant monument. Already partly buried and deteriorated, it was demolished in 1582; today, only the bases of the two cylindrical towers remain. The Porta Aurea is a particularly illustrative case because several sixteenth-century architects admired and depicted its architecture before its destruction, so the monument mainly survives through Renaissance survey drawings [66,67].

The reconstruction presented here draws on this heterogeneous body of evidence. These drawings differ appreciably in their proportions and details, and it is precisely this divergence between sources of unequal reliability that the CRMvr constructs for source evaluation and dimensional provenance are designed to make explicit.

Starting from the analysis of drawings (Table 4), it is possible to notice the heterogeneity of information that can be retrieved from them. In terms of virtual reconstructions, it is important to identify the accuracy and uncertainty of the sources [68] regarding morphological and geometrical representations.

4.1. The Knowledge Graph Framework

After the ontology becomes operational in RS, it can be used to create conceptual knowledge maps illustrating the breakdown of the architectural elements that constitute the aedicula. This graph environment, based on Ontodia [69], allows for the direct construction of a knowledge map (KM) of the architectural artefact as a visual network of typed entities.

As shown in Figure 8, the decomposition reaches down to the third level of elements: the geometric atoms forming profiles and paths, along with the V12 Primitive Entities and their sequence. These detailed aspects are intentionally deferred to later stages, so that the graph currently emphasises the organisation of the aedicula into its main components and sub-components (V5 Component Element and V7 Hierarchy Identifier), rather than their internal details. Once the architectural parts are identified, the corresponding images documenting them are uploaded into the system.

Using RS as a research environment offers immediacy because semantic annotations can be directly applied to images and linked to specific knowledge maps. Image annotations in RS follow the International Image Interoperability Framework (IIIF), which defines universal standards for describing and delivering images over the web. Notably, knowledge maps are created as an integral part of the process, not afterwards. They generate semantically structured knowledge that aligns with the CIDOC CRM standard, featuring graphical elements that represent ontological classes. This method enables the map to serve as a visual database, removing the need for separate tables or relational databases. The process of drawing the map and recording data as structured, standard-compliant information occurs simultaneously.

The two drawings used to reconstruct the Porta Aurea aedicula are labelled Hdz 1245r and Hdz 1246v. They complement each other rather than simply duplicate and understanding each is crucial for the documentation process. Hdz 1245r (Figure 9 and Figure 10) presents an elevation of the aedicula, showing the entire structure with detailed measurements. Its annotations in RS are categorised at higher hierarchical levels such as aedicula, column, entablature, pedestal, and recess and mainly provide dimensional data.

In contrast, Hdz 1246v (Figure 11 and Figure 12) offers a graphical view of moulding details. It contains less general measurement information but illustrates the geometric structure of individual components. Its annotations are at a lower level: architrave, cornice, and frieze, and specify profiles like cyma, cyma reversa, cavetto, and ovolo.

A further condition governs the reading of both sheets: the compositional order of the architectural elements. The members of the aedicula must be read in sequence, from the bottom upward: pedestal, then column with its base, shaft, and capital, then entablature with its architrave, frieze, and cornice and, within each member, the mouldings in their own order.

This is not a mere convention: the same nomenclature recurs at different points of the composition, a cyma in the cornice and again in the pedestal, a cavetto in more than one member and only the position within the compositional hierarchy distinguishes one occurrence from another. Recording that position is the role of V7 Hierarchy Identifier for the elements and of V13 Order of Sequence Identifier for the primitives; without them, two mouldings sharing a name would collapse into a single ambiguous entity. This is why the knowledge maps label recurring elements by their position (the paired left/right members and their sub-elements), so that identically named mouldings remain distinct nodes anchored to distinct source annotations.

Following the drawing analysis, an initial ‘Abacus of hypothetical virtual reconstructions’ for the aedicula was created to advance the HBIM modelling stage, illustrating how dimensions, either specified or inferred from the drawings, can inform HBIM models.

4.2. HBIM Modelling and Semantic Alignment

The model is not built from a single source but composed according to the combinations proposed by the level-of-reference abacus (Figure 13): for each member of the aedicula, entablature, pedestal, column, the abacus sets out which portion of the element is documented by which drawing, so that a component may take its overall profile from one survey and the detail of a given moulding from another. Modelling by these documented combinations makes the evidential basis of every element explicit from the outset: the level of reference, and the type of documentary or iconographic source underlying each modelled part, are recorded as the element is built and therefore travel with the geometry rather than being reconstructed afterwards.

The taxonomy used to name the elements consists of a vocabulary of the architectural orders discussed and was implemented as a buildingSMART Data Dictionary (bSDD). The dictionary can describe the architectural elements and their component elements. Its terminology is grounded in the Getty Art & Architecture Thesaurus (AAT): each dictionary entry references the corresponding AAT concept (Figure 14), so the vocabulary is not an ad hoc list but anchored to an authoritative, Linked-Open-Data controlled vocabulary widely used across the heritage sector [70].

Through the bSDD plug-in for Revit 2024, this terminological classification was assigned directly to the modelled elements, so that each component carries the same controlled term that types its counterpart in the knowledge graph (Figure 15). Once assigned through the plug-in, the classification appears in the model as a shared parameter and can therefore be displayed through a label or tag. This step is not immediate, however: the plug-in creates the parameter but does not register it in the active shared-parameter file, so the parameter must first be exported to that file before it can be scheduled or tagged. Once exported, the bSDD classification behaves as any other shared parameter, and each element can be labelled with its controlled term, making the classification visible and retrievable within the BIM environment itself.

The result is a series of component-based HBIM models (Figure 16) in which every element carries, at once, its geometry, the controlled term that classifies it, and the level of reference that records the evidential basis of its reconstruction: the three things that the export to IFC then makes available, through the shared classification, to the knowledge graph. Once the model is exported to the open exchange format, it can be opened in other, independent viewers, and the same names and sources reappear intact: selecting the architrave in one viewer, and then the same element in a completely different one, returns the same classification and the same reference to its source (Figure 17).

4.3. The ResearchSpace (RS) Framework for Virtual Reconstructions

The knowledge map of the aedicula (Figure 18) shows how CRMvr was used to organise the data of the virtual reconstruction as an instantiated graph. The complete 3D model is connected to the graph through the 3D Model resource attached to the "Aedicula" element by its subject of: this resource carries a Digital Object whose value is a direct link to the online viewer, so that from the knowledge map a reader can open the full reconstruction in the browser and inspect it in three dimensions. The graph thus documents the reconstruction and, at the same time, provides the route to the model it describes.

At present the link between the graph and the geometry passes through an external online viewer, reached from the resource; a natural next step is to embed a 3D viewer directly within ResearchSpace, so that the model can be rotated and inspected inside the platform, and selecting an element in the 3D view would resolve directly to its node in the knowledge map, and vice versa, closing the loop between geometry and documentation within a single environment.

5. Conclusions and Future Directions

Besides the case study, this approach has diverse uses. In research and education, it formalises the process of working with 3D model sources, decisions, and techniques into a structured, reusable format ideal for scholarly articles and teaching, aligning with higher-education efforts to document digital reconstructions. In heritage conservation, separating geometry from materiality and recording modelling choices helps inform virtual restoration decisions and supports semantic data provision in web-visualisation. For public engagement, linking semantically enriched 3D models to a knowledge graph allows virtual tours and self-guided experiences where individual objects are accessible entities connected to their documentation. Across all these areas, the core property, ensuring traceability from each element to its sources and the decisions behind it, makes the record both reusable and trustworthy.

5.1. Limitations and Challenges

Several limitations qualify the present work. First, the geometric decomposition of CRMvr through profiles, paths, and ordered primitives is well suited to elements generated by extrusion and revolution; the majority of architectural heritage is governed by geometrical rules, but complex organic or free-form geometries are only partially reducible to this logic; documenting them can be provided using V16 Morphological Representation. As discussed in Section 2.7, that coarser granularity is admissible by design, since the profile-and-path level depends on the availability of measured drawings and profile studies from which the constructive logic can be decoded; the practical consequence, however, is that the depth of the record varies across a single project, and comparing the transparency of differently documented elements requires care. Second, the mapping from the HBIM model to CRMvr, although anchored by the shared bSDD/AAT classification, still requires that the modelling be organised in a component-wise, classification-driven way from the outset; retrofitting the workflow onto models built without this discipline is labour-intensive. Third, the reliability of the whole depends on the completeness and consistency of the IFC export: missing or inconsistently defined relationships, a known issue in real-world IFC files, can weaken the correspondence between model and graph, and the granularity of manual 3D-modelling documentation remains a general concern for CRM-based approaches. Fourth, there is currently no shared benchmark for evaluating reconstruction-documentation ontologies, which makes comparative, reproducible assessment across implementations difficult; establishing such benchmarks, with curated models and ground-truth documentation, is an open task for the community. Finally, sustaining the bSDD dictionary and its alignment to the Getty AAT over time requires governance and maintenance commitments that go beyond a single project.

5.2. From CRMvr to CRMvrp: An Ongoing Development

The ontology presented in this paper is the formalisation of CRMvr in its original conception: the Conceptual Reference Model for Virtual Reconstruction as it was defined within the doctoral research that introduced it, published as a specification but never, until now, encoded, released, and tested in an operational environment. Making that state explicit is a deliberate choice. A methodological foundation that has been cited, evaluated, and criticised by others deserves to exist in a citable, machine-readable form before it is superseded, both so that the evaluations already made of it can be verified against an actual artefact, and so that what follows can be understood as an evolution from a declared starting point rather than as a substitution of one undocumented proposal with another.

Work is indeed already underway on a successor, provisionally named CRMvrp (Conceptual Reference Model for Virtual Reconstruction Processes). Its guiding principle is the shift signalled by its name: from a model centred on the reconstruction as an object to be described, to one centred on the reconstruction processes as they are declared, argued, and defended. The main direction of this development concerns the treatment of inference. As discussed in Section 2.7, CRMvr grounds its inference-making classes in CRMsci, a choice that reflected both the measurement-centred nature of architectural reconstruction and the fact that a stable version of the CRMinf argumentation model was not available when the original specification was drafted. CRMvrp will therefore express reconstruction processes as declared arguments in CRMinf terms, retaining the constructive-geometry and dimensional-provenance constructs that distinguish CRMvr while embedding them in a fuller account of how a hypothesis is asserted and justified.

Further work concerns aligning the qualitative uncertainty and accuracy grades with the quantitative metrics recently proposed for hypothetical reconstruction and extending the evaluation apparatus to cases in which several sources conflict.

CRMvrp will supersede CRMvr as the recommended model for new documentation projects. CRMvr, however, is not thereby rendered obsolete as a methodological reference: it establishes the analytical premises on which the successor rests the architectural element rather than the building section as the unit of discourse, the geometric construction logic as documentable knowledge, and the provenance of each dimension as the finest grain of reliability and it remains the model against which the added value of the successor can be measured. Declaring that foundation and demonstrating that it can be operationalised rather than only theorised is the specific contribution of the present paper.

Beyond the ontology itself, this work is offered as a position statement for the field of architectural drawing and representation. Ontologies are still frequently regarded, within this disciplinary domain, as an abstract concern of information science, remote from the practice of survey, modelling, and graphic analysis. The argument advanced here is the opposite: that the questions ontologies answer what an architectural element is, how its geometry encodes an interpretation, which source authorises which dimension, and how a representation can be held accountable to its evidence are precisely the questions of the discipline of representation, and that answering them formally makes the discipline's own reasoning transparent, verifiable, and reusable. Demonstrating this operationally, inside a working platform and against a real IFC model, rather than conceptually alone, is what the workflow presented here is intended to show.