Introduction

Common Data Environments (CDEs) are used in the industry and are investigated in research as platforms that provide project stakeholders with a single source of information [1]. They bring structure to construction projects and make communicating between stakeholders easier [2]. Considerable effort is made to define and regulate these concepts of CDEs in the standards of ISO 19650 [3] and the DIN SPEC 91391 [1]. To avoid isolated solutions, these standards aim to make these platforms accessible to other applications and developers so that data gathered throughout the life cycle of the buildings can be leveraged.

From a technical point of view, buildingSMART International is offering a collection of application programming interfaces (APIs) -called openCDE APIs [4] -that cover some of the functionalities of these CDEs and make them accessible. The currently available APIs enjoy great popularity and are widely used throughout the industry. From a research perspective, we can also see a rising increase in interconnecting data and breaking the data silos of single applications and providers. This applies to the realm of CDEs and, generally, the linking of building-related data. For example, the Linked Building Data (LBD) community has set itself the task of investigating and defining Linked Data appliances for building life cycles 1 .

While Linked Data and its underlying technology are promising approaches to solving interconnectivity issues, front-end developers are often unfamiliar with them [5], making it difficult for them to integrate them into a production environment. More so, domain experts in the built environment and building owners who are the end users of CDEs cannot be expected to master the complexity behind Linked Data and utilise it appropriately.

While other research focuses on the manifestation of the concepts of CDEs (ISO 19650 and DIN SPEC 91391) and their containerisation, this paper investigates how to connect the widely adopted technology of buildingSMART's openCDE APIs with the concepts of Linked Data and its underlying container concepts. As covering all CDE functionalities in this paper is out of scope, we will illustrate our approach using the Issue Management process as a primary use case. Issue Management is commonly used in the construction industry to identify and communicate Issues -such as clashes of or missing properties in building elements -during, but not exclusively, the design phase of a building. While there are several vendor-specific options for conducting Issue Management, the BIM Collaboration Format (BCF) API is one of the most developed and prominent processes covered by the openCDE APIs.

This research builds on the author's previous work, which dealt specifically with the topics of BCF and CDEs and their application with Linked Data [6,7]. This work is limited to verifying incoming data for storage in a web container for compatibility with buildingSMARTs specifications. However, it does not address how the client communicates the data to the final destination in a container. Therefore, this should lead the way to connecting the advances from both industry and research without disrupting achievements in one or the other.

The paper is structured as follows. The subsequent section (Section 2) provides background information on related work and research in the Architecture Engineering and Construction (AEC) industry. Section 3 then examines how constraints can be imposed on containers, applies this approach to the general framework of CDEs, and further specifies this approach using the CDE subset Issue Management. The following section (Section 4) discusses how this approach can be technically implemented in the communication between the server and the client. The work is concluded in Section 5, and future work is outlined. @PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @PREFIX ldp: <http://www.w3.org/ns/ldp#> . @PREFIX bcfOWL: <http://lbd.arch.rwth-aachen.de/bcfOWL#> . @PREFIX sh: <http://www.w3.org/ns/shacl#> .

Listing 1: Prefixes used throughout this paper.

Related Work

Information Container

Information container is a term in the AEC industry that describes how files reside in a web environment or a file system. Although several definitions of this term exist, they generally all describe the same concept. DIN SPEC 91301 describes them as "[...] the smallest unit for a file or a model and logical construct for file or model management within a CDE" [1]. According to the standard, these can be nested and also contain multi-models. ISO 19650 describes them as "[...] named persistent set of information retrievable from within a file, system or application storage hierarchy" [3]. The following two subsections present two technical implementations that can be considered information containers.

Information Container for Linked Document Delivery

The Information Container for Linked Document Delivery (ICDD) is an ISO-standardised (ZIP) Container for exchanging heterogeneous files between different stakeholders while allowing for establishing and communicating links between the documents or elements inside the documents [8,9]. It was originally designed with the use cases of information requests and deliveries in the AEC industry in mind. ICDD containers are files themselves and are exchanged between the different project stakeholders. ICDD is based on the Resource Description Framework (RDF) and has two base ontologies, one for container2 and one for linksets 3 . It requires the following structure:

• Index Document: Contains general information about the container and its contents.

• Ontology Container: This contains all ontologies necessary to interpret the RDF data in the ICDD. Dereferenceable ontologies from the web do not necessarily need to be stored in the folder. • Payload Container: Contains all documents in a folder structure.

• Payload Triples Container: Contains the links for the documents to internal and external resources

In AEC, researchers investigate, for example, how to link RDF with non-RDF data for document delivery [10] or how to publish ICDD container on CDEs based on the DIN SPECs 91391 openCDE API [11,12].

Linked Data Platform

The Linked Data Platform (LDP) is a World Wide Web Consortium (W3C) recommendation that provides a structure to serve (Linked Data) resources via the Hypertext Transfer Protocol (HTTP) on the web [13]. The platform specification is published in various documents, including examples, best practices and recommendations [14,15,13]. An ontology for the specification is published on the web 4 . LDPs are based on URLs, meaning that a dereferenceable URI shall name every entity, and entities can point to other dereferenceable URIs. Therefore, following links to traverse through the platforms using LDP is possible. The core structure of LDP comes down to two main concepts:

• Resources (ldp:Resource) represent entities on the web • Containers are specialised resources that shall contain other resources.

On the LDP, RDF is used to describe the metadata of the Containers and Resources, even though the specific contents of a resource may be in RDF (ldp:RDFsource) or a native format (ldp:NonRDFsource). Besides this, LDP is not enforcing any rigid structure on where to store the data. Oversimplified, it is comparable to a file explorer, whereas the containers are similar to folders and the resources to files. Several implementations of LDP exist, while one of the most current ones -Solid [16] -is loosely based on it.

LDP is used in AEC-related research, for example, to federate CDEs [17,18,6], by using the LDP implementation of Solid, or by combining the DIN SPECs 91391 openCDE API and ICDD with the LDP in [11].

Linked Data Validation

Utilising Linked Data, it is important to have a mechanism that can validate incoming data that shall be added to a graph. A validation process can ensure that the data conforms to specific standards and project requirements. While it is theoretically possible to incorporate restrictions into the ontologies with the Web Ontology Language (OWL), these are not necessarily usable in validation because of the open-world assumption 5 . Although SPARQL could validate the data, this leads to complex and impractical queries [19]. Therefore, the Shapes and Constraint Language (SHACL) [20] -a W3C recommendation -was developed to validate RDF. The restrictions are defined in a concept called Shapes, which themselves are also serialised in RDF andlike ontologies -can be published on the web. For a more in-depth discussion of validation, the reader is referred to [21]. SHACL is frequently used in the AEC industry and academia. For example, SHACL is used in [22] to check building legislation and in [23] to define scheduling constraints. Furthermore, Hagedorn et al. discuss how to validate containers in ICDD with SHACL [24]. Finally, [25] suggests a way to define SHACL shapes via Visual Programming, which should improve usability and enable the approaches to non-linked data experts.

Open CDE APIs

The openCDE APIs are an initiative of buildingSMART to provide standardised APIs to communicate with CDE providers. They are not to be confused with the openCDE API described in the DIN SPEC 91391 [26]. The current collection of APIs contains:

• The Foundation API as a common ground for the different APIs to cover authentication and users 6 . • The BCF API for communicating issues occurring in the (digital) building between different stakeholders and applications 7 . • The Documents API for uploading and downloading files that reside on a CDE 8 . Furthermore, buildingSMART plans to develop additional APIs for CDEs, like an interface for "[...] data-driven object exchange [...]" [4]. The topic of the BCF API already has connections with the area of Linked Data. In [27] and [7], an ontology is proposed that maps the schema of BCF to Linked Data, and in [18] and [6] a framework for federated CDEs is proposed on the example of BCF.

Constraining the Container

For this paper, the Linked Data Platform was chosen to store and constrain the data. The platform's architecture is already tailored towards the web and is, therefore, a suitable candidate for Common Data Environments. In a basic setup of a container in LDP (ldp:Container), it simply lists all its containing resources (Listing 2), <.../ldp/Container_1> a ldp:Container; ldp:contains <Resource1>, <Resource2>, <Resource3> . <Resource1> a ldp:Resource . but LDP also comes with the property of ldp:hasMemberRelation, which can be used to point out the class of the resources a container contains (Listing 3) when using the concept of a specialised ldp:DirectContainer. This, e.g., is a filter mechanism when discovering data on the platform. If containers are equipped with this property, it can be determined immediately when discovering the platform whether a container contains the requested data or not. Even though this is already narrowing down what should be expected from the resources when looking at the container, it is not enforcing that the resources stick to a specific schema or structure. This indicates that the property is mainly used for exploring data on a platform rather than creating new data that must adhere to the specialisation of the corresponding ldp:Container. To enforce more specific schemas for ldp:Container, ldp:constrainedBy can be employed, as shown in (Listing 4). In LDP, it is defined that this property can point to any rdfs:Resource. It is, therefore, not limited to what a constraint mechanism can be used for it. For this paper, it was decided to use SHACL since this is -as LDP -a W3C recommendation. Nevertheless, since LDP just describes an architecture for a platform based on Linked Data on the web [13], it does not describe how this constraint shall be enforced by the platform. The functionality has to be either integrated into an application that uses the LDP architecture or could be used by a middleware that checks for these constraints before it posts to an ldp:Container.

Application with CDEs

In the previous section, we covered a basic architecture on applying SHACL shapes on the LDP to constrain what ldp:Resource can be added to an ldp:Container. In this section, the approach is taken one step further and applied to the concept of a CDE to check data that is uploaded to the CDE for conformity to either project internal or external constraints.

An internal constraint can be, for example, an agreement between the different project stakeholders on specific naming conventions or labels that shall be used when creating new issues in the process of clash detection. These individual requirements and conventions in AEC projects are often defined in the Exchange Information Requirements (EIR) and the BIM Execution Plan (BEP) and vary from project to project. Although it is beyond the scope of this work, a machine-readable and directly translatable conversion of these documents into constraints -e.g. by functionalities as suggested in [25] -seems desirable.

External constraints, on the other hand, such as industry-wide standards like BCF, can define specific formatting that the data must adhere to in order to be considered compliant or compatible with them. Contrary to the internal constraints, these are consistent throughout the projects. New versions of the standards are exceptions, however, and should be made available under a new URL.

Therefore, the constraints of a CDE based on LDP should be established in two ways. On the one hand, the stakeholders define their own project's internal constraints. On the other hand, there must be publicly available external constraints -preferably compatible with the FAIR principles [28] -that guarantee uniformity across projects and applications (Figure 1). An ldp:Container in the CDE context can, therefore, be used with both internal and external constraints at the same time, resulting in containers with multiple constraints (Listing 5).

Linked Data Platform

SHACL Shape

Project Contraints ContainerInformation Container

Applied to Issue Management

In this section, we apply the approach to the subset of CDEs with the field of Issue Management in the form of buildingSMART's BCF.

<.../cde/project_1/BCF/TopicsContainer/> a ldp:Container; ldp:constrainedBy externalShapes:TopicShape projectShapes:TopicShape; ldp:contains <Topic1> . <Topic1> a bcfOWL:Topic ; bcfOWL:hasTopicStatus "Active" ; bcfOWL:hasTitle "A generic topic title" ; bcfOWL:hasLabel project:Architecture .

Listing 5:

Example BCF Topic Container with shortened content.

The Topic container itself is constrained by an external and an internal shape (Listing 5). The external shape (Listing 6) is a universally applicable BCF shape that ensures compatibility with buildingSMART's specifications. It is not responsible for checking the specific values of the bcfOWL:Topic but ensures that the structure is correct. For a BCF Topic, the minimum requirement is that it contains at least a title. Other properties such as bcfOWL:hasTopicStatus can either not be present in a Topic or only occur once. <...external-url/TopicShape> a sh:NodeShape; sh:targetClass bcfOWL:Topic ; sh:property [ sh:path bcfOWL:hasTitle ; sh:minCount 1; sh:maxCount 1; ]; sh:property [ sh:path bcfOWL:hasTopicStatus; sh:maxCount 1; ] .

Listing 6: External shape requiring a title for each Topic and allowing only one Status.

The internal shapes are based on the project agreements. There, it can, for example, specify what terms should be used for defining if a Topic's status is still open or what values are acceptable for bcfOWL:hasLabel. This can be checked with shapes as seen in Listing 7. While APIs often work with datatypes like strings, dates and numbers, we can leverage more advanced properties in Linked Data and allow meta descriptions of objects. Therefore, our example shows the potential uses on the one hand with a string for the Status and on the other hand with an object consisting of a URI for the Labels. How this is implemented in the end depends on the project, but it should generally be ensured that the values specified as URIs are dereferenceable. <.../cde/project_1/constraints/TopicShape> a sh:NodeShape ; sh:targetClass bcfOWL:Topic ; sh:property [ sh:path bcfOWL:hasTopicStatus ; sh:in ("Resolved" "Active" "Closed") ; ] ; sh:property [ sh:path bcfOWL:hasLabel ; sh:in (project:Architecure project:MEP project:Documentation) ; ] .

Listing 7: Internal SHACL shape used to constrain the Status and the Labels.

Another example is the Comment, which is not constrained by any project-specific values in BCF. But it is constrained because it needs to have a link to a specific Topic and either a link to a bcfOWL:Viewpoint, a textual comment, or both. This can be expressed in SHACL, as seen in Listing 8 and would be defined in an external universal shape.

Conceptual Implementation

This section describes the theoretical scenario in which a client wants to create a new Topic with the status "Active". The data should be validated against the shapes from the previous section. Therefore, we envision an infrastructure consisting of the clients sending the Topic (POST), the LDP for storing the Issue Management data, and a middleware that acts an intermediary for negotiating the communication between these agents. The middleware is responsible for checking the Topic requests against the constraints specified in the LDP container. Suppose the client wants to POST Topic data to the LDP. In that case, the middleware checks the container at the location of the route for the predicate ldp:constrainedBy, and if such a constraint exists, the middleware fetches the constraints -in our case, the SHACL shapes from Listing 6 and 7and checks the data against them. The constraints may reside either on the LDP itself and are based on project agreements or on more general standards that, e.g. check for conformity with a specific format like BCF.

In our scenario, the constraints are violated because the string "Active" is not allowed as a status in this project and "Open" shall be used. Therefore, the middleware rejects the POST with an HTTP 400 and an error message. The client should now exchange "Active" with "Open" and send the request again. The server and the middleware should now respond with an HTTP 201 and the content of the newly created Topic. The process is depicted in Figure 2.

Conclusion

This paper explores how information containers can host CDE-specific data following buildingS-MART's openCDE APIs. First, different container approaches were investigated, and the W3C recommendation LDP was decided on since it reflects the structure of the web and describes resources as dereferenceable, which allows data accessibility. Subsequently, it was demonstrated through the example of Issue Management in the form of BCF. As CDEs are meant for web-based collaboration, LDP also supports that behaviour. Using provided predicates, ldp:hasMemberRelation and ldp:constrainedBy, the specification can constrain the incoming data by using SHACL shapes as constraints without any extension of the standard. Due to the decentralised structure of Linked Data and LDP, the constraints do not necessarily reside in the exact location of the resources. Still, they can be split into project-specific and general applicable requirements, reflecting the nature of the AEC industry. In addition, it also allows the reuse of these requirements, preventing the need to set them up repeatedly. While the LDP can define that a container is constrained, it is simply a specification and not a framework that can be used to host containers and resources. An official approach to implementing and enforcing these constraints still needs to be agreed on. Therefore, adding these constraints to an ldp:Container will only achieve the desired behaviour with an additional setup. Potential solutions for this problem are implementing a checking mechanism directly into an LDP or using a middleware that checks for these constraints. The latter approach was described in this paper by using a middleware that checks incoming data and decides to store or reject the data, depending on its conformance to the constraints. In subsequent steps, the conceptual implementation presented here will undergo further evaluation and will be tested in prototype. In doing so, not only will the validation of constraints be examined, but also, how to create these requirements user-friendly without overwhelming users with Linked Data. While this paper has explained how incoming data can be examined for conformity, future work will investigate how the data can be sent to the LDP. Serialising the data into RDF seems disadvantageous and would pose a significant disruption to current workflows. Therefore, the aim is to explore how the concepts of openCDE API communication can be combined with Linked Data approaches. Furthermore, research will be conducted on how approaches beyond specific APIs in CDEs can be used in conjunction with Linked Data. The AEC industry is based on many universal and project-specific requirements that are documented, for example, in the EIR and BEP as text. Combining these in a machine-readable format with the principle of LDP is a promising next step.