Few industries are as fragmented as the building sector: during the life cycle of an asset, countless stakeholders are involved, ranging from direct stakeholders such as the architect, the owner and the facility manager towards indirect data providers like governments or geospatial institutions. This `federated' reality contrasts with the concept of a `centralised' cloud server; a `Common Data Environment' (CDE). In this paper, we propose a basic infrastructure for a `federated CDE', using domain-agnostic Web speci cations for (access-controlled) data federation. This infrastructure is illustrated via a proof-of-concept implementation, based on the open-source Community Solid Server.
1.1
Construction projects are `decentral' by nature: there is no single entity that
centralises the decision-making over the entire life cycle of a building. Instead,
multiple independent stakeholders interact with it over time - going from
design over maintenance or occupation to demolition and material reallocation.
However, as they all relate to the same physical asset, intense collaboration
between those stakeholders is often required. The rise of digital technologies such
as Building Information Management (BIM) brought a lot of bene ts for
crossstakeholder collaboration. Lately, such collaboration activities move more and
more towards specialised cloud-based ecosystems, the so-called `Common Data
Environments' (CDE) (ISO 19650). Those CDEs are mostly provided by large
BIM tool vendors, and o er an as-seamless-as-possible integration with these
(often commercial) BIM authoring tools. Yet, the bigger the scope of the project,
the higher chances are that those stakeholders do not all rely on the same
ecosystem. After all, they represent di erent disciplines, so chances are the data models
they use are not aligned. To cope with these data exchange challenges, the use
of Semantic Web technologies for information management during the Building
Life Cycle (BLC) has been gaining traction over the last years [
In this paper, we discuss a data-based setup for a federated construction project. The focus will hereby lie on discovery of and interaction with federated project data hosted by multiple stakeholders. This infrastructure, and its implementation in the decentralised Solid ecosystem, forms the core of the ConSolid project. Although examples will be given that implement speci c RDF ontologies, the underlying concepts should be generally applicable. First, we discuss some background technologies and related work on information management in a Semantic Web context (Section 2). In Section 3, structures for a federated CDE are outlined. A brief proof-of-concept is described in Section 4. The paper concludes with a discussion and an indication of future work (Section 5).
Listing 1.1. Pre xes used in this paper
2 2.1
The Linked Data Platform6 (LDP) is a W3C recommendation for performing read-write operations on Web Resources via HTTP. Those resources may or may not be based on RDF (ldp:RDFSource and ldp:NonRDFSource), and can be contained in an ldp:Container, itself a ldp:RDFSource which describes its content and metadata.
The LDP speci cation is a good starting point for organising heterogeneous
federated building data. However, it does not deal with authentication and
authorisation of agents, which is necessary to enable the setup of a federated digital
asset model, where data resides with the responsible stakeholder instead of on a
centralised CDE server. Such access-control layer is provided by the Solid
specications [
Although the original use case of Solid focuses on social networking, the
speci cations are domain-agnostic and can hence be used within various sectors,
among which the AEC industry [
Because of the federated nature of the AEC industry and the diversity of the
activities present in the BLC, a digital building model often consists of multiple
heterogeneous resources. A multi-model [
7 https://www.w3.org/2005/Incubator/webid/spec/identity/
8 https://solid.github.io/web-access-control-spec/
9 https://github.com/solid/community-server
for loose-coupling independent resources into an over-arching multi model.
Subdocument connections are made using ID-based Link Objects, grouped into
larger Link Models. The recent standard Information Container for linked Data
Delivery (ICDD, ISO 21597) heavily builds upon these concepts. ICDD is
oriented towards the delivery of data containers of the entire model, but since it
bases upon RDF as the `semantic glue' between resources, there is no reason
this data cannot be federated on the Web. For example, mappings are possible
between ICDD and LDP containers [
The Solid speci cations do not (yet) include a way to express resource metadat a10. However, expressing certain statements about an RDF or non-RDF resource, rather than about the content of this resource, is an important aspect of nding your way in a federated project. The distinction can be made here between generic metadata (e.g., last-modi ed, content-type) and speci c metadata (e.g., topic, description, tags). While the former can be expressed easily using HTTP Headers, the latter needs a more static approach such as attaching a .meta auxiliary to each resource - especially concerning domain-speci c metadata. One domain-agnostic approach to describe datasets on the web is the DCAT 2.0 speci cation11, which relates a dcat:Catalog to multiple separate dcat:Datasets, which are collections of data, published or curated by a single agent, and available for access or download in one or more representations. A dcat:Dataset, in turn, links to instances of dcat:Distribution. A distribution description may contain information on the resource's content-type (dct:type), description (dct:description) and title (dct:title) but will also point to URLs for downloading the dataset (dcat:downloadURL). 2.4
Section 1.1 mentioned the concept of a CDE. A CDE exposes contributions by speci c stakeholders to other members of the consortium, and is often integrated in an existing (commercial) BIM ecosystem. Information resides `in the cloud', to be accessed via a provider-speci c ID. CDEs often provide additional functionality to enable stakeholders to communicate about sub-model collisions, inconsistencies, or general change of plans. CDEs need to handle the double patchwork present in the AEC industry: each project has di erent stakeholders, and each stakeholder has multiple projects. A CDE is mostly project-speci c, but an ofce cannot maintain subscriptions to di erent CDEs for every project. A notable initiative here is the ongoing OpenCDE project (BuildingSMART), which provides a set of APIs that allow a client to communicate with multiple CDEs. All OpenCDE APIs share a limited amount of services and conventions, which are 10 https://github.com/solid/specification/issues/102 11 https://www.w3.org/TR/vocab-dcat-2/ bundled in the Foundation API12. Currently, the most active OpenCDE API is the BCF-API13, which supports exchange of BCF (BIM Collaboration Format) `topics' between software applications via a RESTful API; a `BCF server' as a global access point for the project. BCF API furthermore supports, amongst others, the retrieval and modi cation of existing projects, BIM snippets, comments and entire project les. 2.5
The SCOPE project (Semantic Construction Project Engineering)14 [
Another ongoing project, which integrates the concept of Linked Building
Data with the well-known BIMserver [
The DRUMbeat Platform [
A federated CDE is essentially a federated, access-controlled knowledge graph. Autonomous agents (both human and digital) have a clearly de ned set of tasks and responsibilities in each project they are involved in. We may identify three `types' of actors in the federated network: the `main' stakeholders, who are directly involved in the project, the `external' datasets, providing auxiliary information, and microservices. In the following paragraphs, we will mainly use Solid 12 https://github.com/buildingSMART/foundation-API 13 https://github.com/BuildingSMART/BCF-API 14 https://www.projekt-scope.de/en/home-en/ terminology (Pods, WebIds, ...) to outline the structure of the network. However, as the Solid speci cations base upon general Web-standards, they may be applied also in non-Solid environments. 3.1
We can roughly distinguish three types of services in the network. The rst type of service is project- or even Pod-exclusive. Their task is to keep the project synchronised, to expose project data in specialised databases or to generate speci c viewpoints on the project data (e.g., an OpenCDE-conform API or a virtual view generator (Section 3.2)). As they will often involve managing access rights as well, these services require a very high level of trust and should be administered by the owner of the Pod or a dedicated project manager. The other services are provided by third parties, with a distinction between Open Data services and functional services. While Open Data services (e.g., governmental APIs, product manufacturers, geospatial datasets) will not require any access rights to the project, functional tools (e.g., for simulations, regulation checking etc.) need to have at least `reading' rights. Functional tools can be compared to the `BIM bots'-concept featured in the BIMserver project (Section 2.5). 3.2
General structure A Solid Pod bases upon the LDP speci cation, so it has a folder-like structure that can be accessed via HTTP URLs. Starting from the WebId of an authenticated stakeholder, a client service needs to nd where LBD projects are stored. In their WebId, a stakeholder must provide a pointer (cs:hasProjectRegistry) to a project registry folder (ldp:Container). At the root of this ldp:Container, the stakeholder's local project repositories are referenced (ldp:member) - these will be ldp:Containers as well (Fig. 1). Relevant metadata about the project is attached to this ldp:Container via a .meta le, which is the default response when fetching the container resource itself. For the structure of an individual project repository, we propose not to use subdirectories but instead use a attened list of project resources. The main reason to do this, is the persistence of URIs in the project: moving resources from one sub-folder to another one will easily break links in the network. However, this attened list only exists at data storage level - using metadata resources (Section 3.2), `virtual views' on this data can be created, to improve user experience. Such virtual views will be based on speci c parameters (e.g. document status according to ISO 19650, virtual folder structures following ICDD (Section 2.2), document ownership, discipline, project task etc.) and can be either o ered by specialised services in the network, or be rendered client-side in a web app. Resource Auxiliaries We identify two types of auxiliaries to resources in a federated multi model. The rst regulates Web Access Control: rules for authorisation are expressed in an .acl document that governs either an entire ldp:Container or applies only to a speci c resource. The second is a metadata (.meta) le (Section 2.3), giving extra context about a resource. As in our infrastructure, the metadata le forms the primary access point to the actual resource, it is required that every resource in the project has their own metadata le attached. In our ecosystem, .meta les will follow the DCAT 2.0 speci cation as described in Section 2.3. An example is given in Figure 1, with the metadata le duplex.meta. The example describes a dataset with a known distribution hosted in the Pod. Section 3.2 will further elaborate on making alternative distributions available via specialised databases.
Linking external databases In the previous section, we argued that the access point for every dataset is its related .meta resource. From there on, a client can nd the distributions it needs. Exposing all distributions in a attened ldp:Container, as proposed in Section 3.2 and visualised in Figure 1, complies with the LDP and Solid speci cations, and is implementationwise the most straightforward one. However, sometimes specialised databases o er better performance or additional functionality. For example, an (access-restricted) triple store for RDF project resources will o er better server-side query performance or provide reasoning or rule-checking functionality, while availability risks are relatively low compared with public SPARQL endpoints. Another use case dwells upon the concept of content negotiation: while one `main' distribution is stored on the Pod, another one may just point to a service that converts other representations on-the- y or actively watches the main folder and caches alternative representations. In the case an (RDF-based) distribution is to be queried rather than downloaded, the property dcat:accessURL is used. When connecting external databases to a federated project network, a challenge is to pass on access-control rules for these services, which requires a very high level of trust. Therefore, we consider such services to be self-hosted or at least Pod-speci c, i.e., exclusively working on one data vault. 3.3
In Section 2.4, a BCF project server was mentioned as a single point through which BCF issues may be exchanged, pointing to project les on a model server. Similarly, commercial CDEs will provide a project identi er to nd the project on their servers, and le-sharing platforms use a folder structure to bundle resources related to a speci c topic. In a federated environment, it makes sense to determine one or more `global access points' as well. To enable discovery of a global access point, a stakeholder needs to indicate a part-whole relationship (cs:isPartOfProject) at the root of the local project repository (Section 3.2). From there on, each agent with the correct access rights can propagate through the federated multi model. A project access point can be set up by a principal stakeholder (e.g. the architect or the project manager) and has its own assigned WebId. Depending on the organisation of the project, the access point may expose its own project metadata resources (e.g., a graph of stakeholders or a list of abstract artefacts (Section 3.4) and host multiple services.
Now that local and global project access points can be discovered and the
structure of metadata has become clear, the following section will discuss how
in this federated network, resources can be linked on a sub-document level.
3.4
In a digital construction project, multiple resources may actually refer to one
and the same `real' object. A real window in the building may nd itself
semantically described in graphs produced by di erent stakeholders in the project, and
represented in multiple images, point clouds and geometries. About the latter
we can say that these are graphical representations which can act as proxies to
talk about the real `abstract' building element: if you select an element in a 3D
viewer or mark a region in an image, you only implicitly refer to this abstract
element. The same goes for resources like spreadsheets or text les, which are still
very much used in industry. To semantically de ne such references to abstract
objects, we follow the approach used in the LBD `tandem ontologies' Ontology
for Managing Geometry 15 (OMG) [
In a central environment, a `master artefact registry' could be easily set up to keep track of such references. All references to abstract artefacts are then made in this registry, which acts as a `single source of truth'. In a federated CDE, such master registry is still necessary (to avoid arbitrary local creation of new abstract elements by any stakeholder who claims the referenced element did not exist yet in the network). Several approaches may be used to set up this master registry. One of them is be to use blockchain technologies - as a fully distributed solution. Another one is to host the registry in the project access point, or in the Pod of a primary stakeholder (e.g. the project manager).
Although this registry will be the main reference to connect project resources and semantic instances, there are advantages to allow individual stakeholders to maintain a local registry as well: drafting work-in-progress, querying, o ine working, etc. Moreover, it would be undesirable that each stakeholder has full writing rights to the registry at the project access point: as a design pattern in the network, a stakeholder should only make changes to resources they host in their own Pod, or be allowed to use a proxy service that may only perform speci c data manipulations on remote resources.
We thus propose an in-between solution where each stakeholder may use a local reference to the abstract element in an artefactRegistry graph in their local project repository, indicating that there exists another URI in the master registry, which refers to the same thing (owl:sameAs). Network- speci c services (Section 3.1 should ensure local artefact registries are regularly synchronised 15 https://www.projekt-scope.de/ontologies/omg/ 16 https://mathib.github.io/fog-ontology/ 17 https://w3c-lbd-cg.github.io/opm/ with the global `base registry' and vice versa. I.e, the owl:sameAs relationship in local registries should have a backlink in the master registry, so all references to a certain abstract artefact can be easily discovered: a service locates the global artefact registry, follows the pointers to the local artefact registries, collects the references from there and bundles these for the client to use. 4
As a proof of concept, we recreated the components discussed in Section 3 as
separate modules for the AECOstore project18 [
In this paper, we discussed a method for structuring building project data in a federated manner. Without going into detail about the nature of such data, we have shown that project contributions from di erent stakeholders can be hosted on di erent servers, yet remain semantically connected and unambiguously part of the same overall project. With multiple Community Solid Server instances featuring as back-ends and a generic dashboard interface based on the LBDserver project, we implemented a proof-of-concept showing that browser-based and headless microservices can interact with this data. Depending on the use case, such microservices may o er generic functionality or provide the means for tailormade and discipline-speci c data enrichment in di erent phases of the Building Life Cycle. The limited scope of this paper prohibited topics such as archiving, versioning, multi-user editing and synchronisation streams to be covered. The conceptualization of compatible data patterns for these topics is an important remaining work package.
As we proceed with this research, the integration of the data structures described in this paper (`ConSolid') with the `AECOstore' infrastructure for micro-services and {frontends (Section 4) will become more important. The development of common API functions to interact with the data on a layered, more user-friendly level is essential to leverage the potential o ered by the combination of Semantic Web technologies with modern-day web development technologies, a combination which may eventually result in tailor-made and discipline-speci c data enrichment in di erent phases of the building life cycle. 6
This research is funded by the Research Foundation Flanders (FWO) in the form of the Strategic Basic Research grant (grant no. 1S99020N).