The development of a HIS that answers the identified needs in Section 2
is filled with interesting design choices. It is based on a user-centred design described in Section 4.1
, that delivers a robust conceptual data model presented in Section 4.2
, on which we base the information system architecture described in Section 4.3
. The final HIS-PC is thus interesting for its architecture relatively simple that permit semantic, temporal and geometric queries based on a core point cloud. In the context of this research, we consider the “semantic” as any attribute information related to model objects that are not spatial, temporal and identity aspects [42
4.1. HIS-PC User-Centred Design
There exist various methodologies to design an Information System (IS), mainly proposed by the computer science community. To handle the complex nature—uncertainties, missing data, lack of formalism, and multi-modal roles—of heritage information, we propose to use and adapt an existing IS design methodology based on a user-centred approach. Several authors used a similar approach in the field of heritage information management [51
]. In this sub-section, we present the main guidelines of the method. We describe the four design steps and some of the most crucial outputs to facilitate the development and implementation of a HIS. It is interesting to note that such a complexity of information can be found in several other areas—heritage data, however, has the particularity of requiring multiple interpretations [41
The design process is iterative and follows the human-centred design for interactive systems ISO 9241-210:2019. For an information system to be pertinent, it must meet the requirements of the organisation or the targeted users. The methodological steps illustrated in Figure 6
are the following:
The analysis of users’ requirements (step 1) which ended up with a list of needs and formalised specifications, both for the IS and data acquisition.
The conceptual design (step 2) where conceptual data models, system’s interfaces and data acquisition procedures are set up based on the specifications of the first step.
The design and prototyping (step 3) which consists of an IS prototype development, data acquisition and data integration in the IS prototype.
The usability evaluation (step 4) which is performed by the designers and the users. Depending on the result of the evaluation, either a new prototyping loop starts or the prototype reaches a further step of implementation and maintenance.
The quality criteria that the system must meet can be taken from existing standards. We propose to draw inspiration from the ISO 9126 standard established for software development. Whenever possible, we encourage the use of database management systems (SQL and/or NoSQL) that are adapted to the heterogeneous data sets that characterises cultural heritage applications. Without excluding spatial representations of vector or mesh types, we encourage the use of point clouds as a geometric core data modality. Connections between the different databases must be ensured, and all the system functionalities required by the users must be accessible through ergonomic interfaces that facilitate the handling and use of the system.
4.2. Data Model
The data model was developed during the conceptual design step (see Figure 6
—2.A). During this phase, several iterative processes between the users and developers end up with some conceptual deliverables: a conceptual data model (see Figure 6
—2.A), a mock-up of the information system architecture and interfaces (see Figure 6
—2.B) and a data acquisition methodology (see Figure 6
Heritage information is complex. It is by nature, incomplete and uncertain, usually associated with one or multiple spatial and temporal representations [54
]. When creating a conceptual data model for archaeological information, two antagonists’ aspects should be handled: specificity and interoperability. Indeed, the model must fit with the specific needs of the users while the developed system is rooted in a particular organisation. However, the model should also be open to other models and standards: it must be evolutive and mappable to other models or ontologies. Several initiatives exist to offer a conceptual modelling environment for uninitiated individuals lacking knowledge in information modelling (e.g., [55
]). We have chosen to start from a very generic metamodel that defines key concepts. Therefore, the methodology imposes to start the iterative process with a metamodel gathering core concepts (classes and relations) helping users to gradually understand the conceptual modelling mechanisms. These core concepts are mainly inspired amongst existing modelling approaches ([39
]), although differences might occur in a defined vision of the representation of time, uncertainty or multiple interpretations. In a future evolution, we plan to integrate, through a mapping, our model to existing initiatives. A commonly accepted version of the metamodel is then adopted and serve as a framework for the design of the conceptual model of the organisation’s HIS-PC.
The core concepts are four classes (object, state, event and document), three components (spatial, temporal and functional) and the relation between classes (see Figure 7
). Each of these four classes can be in relation with another class or with itself and might have spatial, temporal or functional components, which is in line with the well-known Peuquet’s triad [57
]. An object is a class referring to the core elements targeted through the modelling process (e.g., a wall). A state is a stable combination in time of several characteristics related to an object (e.g., the state of a wall composed of stones during a given period and at a given elevation and shape). A state does not exist without a clear relation to one object (e.g., a set of stones and mortars combined during a certain period at a particular location is considered as corresponding as a state of a given wall). An event leads to a change of properties which triggers the creation of a new state (e.g., the destruction of part of a wall during a fire leads to the apparition of a new state of the wall with a different size). A document is a source of information which can be linked to an event or a state (e.g., a written report mentions the occurrence of a fire at a given place at a given moment in time). Depending on the applications, an element could be either associated to an object or a document (e.g., a written report can be a document in an archaeological site context, but it could be an object in a library description context).
The adopted version of the metamodel for the Coudenberg project is presented in Figure 8
. In particular, only the event class has a temporal component, and only the state class has a spatial component (with a minor exception for one object—“Site”; see Figure 9
The creation of a conceptual data model based on the metamodel is a collaborative and iterative step, gathering the users and the developers. The proposed modelling formalism is UML [58
], but other formalisms could be used. We pointed out ConML, which is a generic formalism dedicated to digital humanities application [55
]; it has the benefit to be specialised for cultural heritage applications in its CHAMR (Cultural Heritage Abstract Reference Model) extension [59
]. In addition to the metamodel, some modelling strategies can be adopted but are not mandatory. For instance, due to our experience in archaeological modelling, we suggest the following guidelines:
A distinction between existence and presence. This vision of an object lifecycle allows to sequence all the step of an object definition from its conception, to each transformation and finally to its final destruction. We assume that each transformation, considered as an event, is accessed through documentation that describes the change.
The temporal states of an object are cumulative. The complete historical sequence is the combination for every state of an object. Consequently, an interpretative sequence is a sub-selection of some states in the complete object history.
A heritage object is a part of another heritage object. This mereological approach of the heritage components gives considerable latitude to the stakeholders and the final system users to define their vision of the heritage site segmentation. It ensures that the proposed division is closely related to the user’s applications and correspond effectively to their needs.
From this initial design, we derive a more detailed and formal UML class diagram specialised for the Coudenberg HIS, presented in Figure 9
. It is worth to mention that this model is specific to the Coudenberg project and does not claim to be the right candidate for other heritage information developments. It corresponds to the best conceptual data model considering the current needs of the users and their validation. In order not to overload the diagram with non-essential elements for general understanding, only important classes, attributes and names of non-explicit associations are represented. Moreover, this model is likely to evolve in order to adapt to users’ new needs (as described in Section 5.2
, the implemented solution for data storage must be able to manage evolutive data models).
This data model shows a concrete application of the metamodel. Therefore, the four meta-classes “Event”, “State”, “Document” (“Documentation”) and “Object” (“Element”) are represented. In addition, other classes (“Site”, “Architectural element”, etc.) answer to specific needs of Coundenberg Museums. They can inherit from metaclasses (“Architectural element” is an element/object) or not (“Site” is independent of any metaclass) regarding final users’ requirements. A site is spatially defined as a 2D geo-referenced polygon. A site includes elements which can be any object of archaeological interest (a building, a room, a wall, a stone, a plastron, etc.). In a first approach, we define two classes of elements (more can be added in the future): containers and architectural elements. Architectural elements are physical objects (depending on types and specific materials) while containers are spaces with specific functions like rooms. Containers can be associated to one or several excavations. “Part-of” is a recursive association of “Element” allowing a hierarchical structuration of objects semantic. For example, a wall is part of a room which is part of a palace. Because of spatial changes of elements during their lifetime, geo-referenced geometries are attached to the class “state”.
The spatial definition of “state” can then be either a 3D point (only located), a 3D polygon (surface) or a 3D bounding box (volume). All geometries follow ISO and OGC standards and are defined in a spatial coordinates reference system like WGS84 (EPSG 4326). As far as an inaccurate temporal approach has to be managed, the states are temporally delimited by events themselves characterised by estimated start date and end date. Finally, each event, data modelling, documentation is related to a source managed through a document. The documents are heterogeneous information about states and events (observation collected by archaeologists working on the site, historical images, plans, schemas, etc.). This information is represented by the class “documentation”. Once this conceptual model is set up, we approach the development of the HIS architecture mock-up, described in the following Section 4.3
4.3. Information System Architecture Mock-Up
The information system architecture mock-up was developed during the conceptual design step (see Figure 6
—2.B). Figure 10
represents the three-tier architecture of the HIS. It is composed of the three following layers:
A client layer regrouping interfaces which are the end users’ entry points to the HIS
An application layer which allows the communication between the interfaces (client layers) and the data (data layer).
A data layer regrouping all the data sources (databases or data files), structuring the data lake.
In the HIS architecture, we propose a distinction between point cloud interfaces, dedicated to spatial objects (objects defined in space), and semantic interfaces, dedicated to other information (objects defined by time, materials, documentation, etc.). Since everything can be grouped in a single interface, this distinction is not mandatory. However, point cloud and spatial information can quickly be entrusted to business-oriented software based on popular spatial data formats and standards.
No matter the distinction between semantic and point cloud interfaces, these two aspects are merged in the application layer: objects (created, searched or visualised by users) are not only semantic or spatial anymore but both semantic and spatial. It leads to the definition of geographic objects which can be queried and represented based on these two aspects (e.g., “A 3D map showing rooms superior to 25m² and coloured in the function of their last building date”).
Once again, a distinction is proposed in the data layer to easily take advantages of different database management systems (DBMS). Indeed, some tools can be efficient for spatial data (spatial database) while others can be more adapted to heterogeneous information (semantic database) or huge point clouds (point cloud data). These three data components can be separated or possibly grouped into one DBMS if such a tool meets all the users’ requirements. No matter which DBMS is used, it is up to the application layer to query the different DBMS and eventually merge results to rebuild geographic objects.
Finally, end users can perform several operations, as shown in Figure 11
, which are managed through the different layers of the HIS architecture. These operations are mainly linked to the semantic and spatial interfaces, being:
Creation/modification of semantic information for objects (e.g., creation of an object “wall” with its building date and material)
Representation of all the semantic information of objects (e.g., what is the material of this wall and when was it built?)
Search of objects based on semantic aspect and/or spatial predicates (e.g., which are the walls made of granite, built after the 13th century and higher than 2 m?)
Point cloud visualisation
Creation/modification of an object’s spatial definition (e.g., a located vector volume around a wall based on point cloud data)
Spatial visualisation of objects (e.g., point cloud part intersected by a vector volume defining a wall)
All operations mentioned above and illustrated lead to specific queries distributed in the different databases, and whose eventual results are processed by the application layer before their visualisation in the appropriate interface. Note that point clouds are considered as a persistent data source and support for spatial objects definition and visualisation. With a dedicated DBMS, points clouds could also be involved in queries more directly.