Delivering data and documents of a building throughout its lifecycle is a common task in construction planning, engineering, and maintenance. The international standard Information Containers for linked Document Delivery (ICDD) has been created to link data and documents together for integrated delivery. This paper describes two independent software prototypes for creating these hybrid linksets in ICDD containers and validating them with the Shapes and Constraint Language (SHACL). This research focuses on ways to link data modeled in the Resource Description Framework (RDF) to non-RDF resources like documents and entities within documents. It argues that current ICDD mechanisms for linking to RDF resources are cumbersome and do not exploit the advantages of Linked Data. It also argues that the ICDD specification regarding the usage of Linked Data is very restrictive, thereby blocking the full benefits of Linked Data. The paper presents two strategies to alleviate these barriers to using ICDD; one approach is within the ICDD standard but adds additional agreements on top of the current ICDD standard. The other approach is technically outside the ICDD standard. Eventually, conclusions and recommendations are drawn from the presented implementations and strategies.
Stakeholders of the built environment and the construction industry constantly share
heterogeneous information. In the complex landscape of the built environment, there is a need to
exchange information in a standard way without losing the context of the information and
only relying on vendor-specific formats [
The ISO 21597 [
CPWrEooUrckResehdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g CEUR Workshop Proceedings (CEUR-WS.org) with a structure that holds the payload that has to be exchanged. In this container, a header ifle is present to register and describe the contained files with metadata. Link files describe the (deep) links between these files. Both metadata files are formatted using Linked Data (LD) and Semantic Web formats, i.e., the Resource Description Framework (RDF) and the Web Ontology Language (OWL). RDF and OWL are standardized by the World Wide Web Consortium (W3C).
If the payload happens to be (partly) LD, the standard specifies that links should still be created through the linkset files. However, because deep linking between datasets is natively supported in LD, the proposed linking mechanism of ICDD is unnecessarily cumbersome. Furthermore, the overhead of the linking structure in ICDD could lead to redundancy in the data if direct links between the LD payload persist. Further, the standard does not specify how to transfer the data model and requirements that might be encoded using Semantic Web standards, e.g., Shapes Constraint Language (SHACL). Such functionality would make the container even more self-describing and enable the software to verify the exchanged data.
In this paper, we discuss how a revision of the ICDD standard might change the container to use the characteristics of LD better and consequently use the standard languages of LD (e.g., RDF, OWL, SHACL). However, because the conformance paragraph in the standard prohibits any extensions of the structures specified in it, only one of the two proposed solutions will conform to the standard. In the following, we will examine two independent software prototypes for ICDD regarding their usability with LD payloads, their handling of the linkage between RDF data and documents, and their ability to validate the contents of ICDD containers with SHACL. After concluding problem statements from the analysis of the prototypes, strategies for extensions of the ICDD standard are defined, and general recommendations are given in the conclusions.
Information exchange in the construction industry is conducted according to ISO 19650 [
LD is provided through publicly available base and domain-specific ontologies that can be
leveraged to represent building data in a modular ontology combination. Base ontologies contain
commonly agreed terminology that is valid for multiple domains, while domain ontologies
extend the base ontologies with domain-specific knowledge. These ontologies are also referred
to as Terminology-Box (T-Box). The W3C Linked Building Data (LBD) Community Group1
is one instance that proposes well-established base ontologies such as the Building Topology
Ontology (BOT) or the Ontology for Property Management (OPM) [
The ICDD container is a successor of the Dutch COINS container, as described by Hoeber et
al. [
ls:DirectedLink ls:hasFromLinkElement: ls:LinkElement [1..] ls:hasToLinkElement: ls:LinkElement [1..] Legend Properties inheritance object property
Classes
Container Ontology (ct)
Linkset Ontology (ls) ls:Link ls:hasLinkElement: ls:LinkElement[2..] subClassOf subClassOf ls:hasLinkElement
ls:LinkElement ls:hasDocument: ct:Document [1..1] ls:hasIdentifier: ls:Identifier [0..1] ls:BinaryLink ls:hasLinkElement: ls:LinkElement [2..2]
subClassOf ls:StringBasedIdentifier ls:identifierField: string [0..1] ls:identifier: string [1..1] ls:hasDocument ls:hasIdentifier ls:Identifier subClassOf ...
ct:Document subClassOf ls:UriBasedIdentifier ls:uri: anyUri [1..1] ls:QueryBasedIdentifier ls:queryExpression: string [1..1] ls:queryLanguage: string [1..1]
Documents registered in the container index can be linked using the vocabulary from the
Linkset.rdf 3. Specific link types can be used with the ExtendedLinkset.rdf 4 vocabulary, which is
standardized in the second part of the ISO standard [
Linking between two or more documents is provided through the link structure shown
in Figure 1, defining a ls:LinkElement class that can be referenced in several link types.
The ls:LinkElement class contains exactly one document reference and optionally one
identifier of the identifier types ls:StringBasedIdentifier, ls:UriBasedIdentifier,
and ls:QueryBasedIdentifier. These identifiers allow the deep linking of entities inside
documents. Deep linking uses the above-mentioned identifiers, which form a generic mechanism
that arguably needs supplementary specifications for each file type. For example, deep linking
to a GML file could mean that ICDD’s identifier refers to a gml:id within a GML file, although
this is not documented or specified. It could also mean that the ICDD identifier refers to the
objectID property within a GML file. For linking to IFC files, ICDD’s identifier could use the
IFC-GUID property, but the line number (in the case of an IFC step physical file) is also valid.
The deep linkage of drawings and IFC models in ICDD containers has also been analyzed by
Borrmann et al. [
Validation of ICDD containers is provided by the second part of the ISO 21597-2:2020 [
An approach for validating the linksets inside ICDD containers content-wise to ensure the link
validity based on the linked entities is provided by Hagedorn and König [
In the following section, two independent software prototypes for viewing and editing ICDD containers are presented and analyzed regarding their handling of RDF-based data and linking between these RDF-based data and documents inside the container.
The RUB-IP is a viewing, editing, and collaboration platform based on ICDD information
containers. Hagedorn et al. [
RUB-IP shows the contents of an ICDD container featuring all the links between documents
following the ICDD specifications. Extra functionality is present when ICDD links refer to
other RDF files, e.g., showing the graph structure of the link data structure, the linked RDF
individuals, and direct L1 level properties of the entities. Rasmussen et al. [
Loading RDF files into ICDD containers on the RUB-IP can be done threefold. First, RDF
documents can be stored in the Payload documents folder as ct:InternalDocument instance.
Moreover, RDF files can also be referenced as ct:ExternalDocument instances via their
respective URI, under which an RDF serialized format is retrievable. Both options store the LD
in the Payload documents folder. The third option to add LD to ICDD containers in the RUB-IP is
to store it under Payload triples as defined in Part 2 of ISO 21597. As of the standards definition,
only the linksets from the Payload triples are registered in the container index file, but neither
the other RDF files in the Payload triples folder nor the ontologies in the Ontology resources
folder are considered. For registering RDF files from the Payload triples folder in the container,
the ICDD ontologies are extended, as described in [
The Wistor ICDD Viewer [
The properties panel (bottom left widget) shows the extra properties of the selected object. These properties are gathered from an RDF file. The connection between the selected IFC element and the RDF file resources is specified using the ICDD classes.
Multiple verification steps are available to ensure the exchanged data complies with the specifications. First, the ICDD container is verified to meet the ISO 21597 conditions. As the client primarily wants IFC files using their specifications related to (necessary) documents and wants extra object information according to their SHACL OTL, additional verification steps are required. IFC files are checked to ensure they comply, and the extra LD is validated against the SHACL OTL.
The Wistor ICDD Viewer had to make its own extra decisions to enable a more holistic veriifcation of ICDD data encompassing IFC files, ICDD links, and additional LD based upon an OTL (in SHACL). The first decision was to load extra LD in the Payload documents folder within the ICDD specification. Primarily the idea was to put additional RDF files in the Payload triples folder, but Wistor’s interpretation was that this was not according to the ISO standard. A second decision was to load an LD OTL to make more information on object types available to the viewer. As the OTL was based upon SHACL, the extra LD set could be validated, ensuring that the exchanged data conforms. This was the third decision (validating the supplementary dataset against a SHACL/OTL).
Another decision was to use ls:LinkElement and ls:StringBasedIdentifier to link to an LD data resource. Instead, the foundation of LD proposes to use IRIs to link to resources. However, this approach was at least complying with the ICDD standard. As multiple ways are present to handle a link to an LD resource (e.g., ls:UriBasedIdentifier), extra guidelines are necessary for ICDD container creators to ensure they use the same approach. Data structures for linking to external documents were also present within the OTL, enabling cardinality restrictions or simply enabling the specification of mandatory documents. However, these data structures are present in the supplementary RDF files and not related to ICDD links, consequently introducing redundancy and potential conflicts.
Based on the two prototype implementations, remarks and problem statements on the usability
of ICDD for ontology-driven data linking and link validation for the construction industry
are drawn. Both prototypes evaluated use cases where RDF data was available inside the
container in addition to the container metadata and linksets, allowing users to load RDF
ifles into the container. Both prototypes demonstrated a cumbersome way to link to an RDF
resource using the ICDD linking structure with either the ls:StringBasedIdentifier or
the ls:UriBasedIdentifier according to the standard and consequently ignoring very basic
LD solutions. In the second prototype, this leads to a definition of links in the LD itself and
not in the linksets of the ICDD, so the advantage of separating links in the linksets from the
original data in the payload is not maintained anymore. This can lead to duplicate linking and
additional efort in maintaining the container and linksets. Using the ICDD linking structure
combined with LD in a linkset or payload LD is not allowed by the standard and would fail the
SHACL validation provided by ISO 21597-2 [
Moreover, both prototypes use SHACL for validating and rule execution to validate and visualize the interconnections to additional LD in the ICDD containers. However, link validation is not genuinely possible for deep linking, as especially the ls:StringBasedIdentifier as a key-value-pair representing the identifier does not convey a unique meaning or identification. Thus, it is only usable within the defining system unless there is an agreement on how the identifiers are used. As the standard provides schema validation, the next step is validating the linking and context, which the standard does not cover yet. The standard does not deliver a solution where to store the SHACL shapes that should be evaluated for the specific container.
After comparing the implementations and considering the lack of solutions for deep linking RDF data in ICDD, the challenges are: (1) to overcome the quite complex standard for simple data linking, (2) to uniquely identify deep linked elements with the built-in identifiers, (3) to exploit the added value of LD and (4) to enable identification of SHACL files that are meant for data validation. To overcome these challenges, it is necessary to acknowledge that RDF data difers from other payloads in the container. The authors identified potential solutions in two strategies to put the strengths of the ICDD data structure together with the full power of LD.
The first strategy (stay-within-the-standard) contains solutions within the ICDD standard resulting in best practices or even additional agreements on dealing with LD datasets within ICDD containers. This could result in LD modeling agreements and an LD adapter implementation agreement. The second strategy (extend-the-standard) contains solutions that are technically not compliant with the ICDD standard because they extend or change the schema provided by the standard. These two strategies will be discussed further in the following paragraphs.
Compliant solutions can be met by storing RDF data and SHACL files in the Payload documents folder without having them treated specially. Linking to RDF data must then be done via the ls:URIBasedIdentifier provided by the standard to make the linking resolvable for other container recipients. This linking mechanism is present in the current standard and is the closest way to bridge the gap to a handy and usable application of LD in ICDD. Regarding the unique identification of entities in other file types, e.g., IFC models, GIS data, or calculation spreadsheets, a common understanding of how to use the ls:StringBasedIdentifier using adapters and implementation guidelines is necessary. The two prototypical implementations have shown that even for IFC documents, diferent key-value pairs for referring to the IFC GUID can be used for linking, e.g., when utilizing diferent keys: "GUID", "globalID", "IFC GUID". This makes it hard for software systems to implement ICDD in an interoperable way.
In the above section, solutions compliant with the current specifications in ISO 21597 were elaborated. This section presents approaches that deviate from the specifications of ISO 21597 while retaining the concept of information containers.
The first solution could be to allow extensions of the linkset ontology, including the necessary modifications to accommodate this. For instance, the ranges and restrictions on the predicates ls:hasLinkElement, ls:hasFromLinkElement, and ls:hasToLinkElement could be adjusted to not only allow instances of ls:LinkElement. One possibility would be a generic restriction to any rdfs:Resource so that either ls:LinkElement referencing the documents or RDF entities could directly be addressed, which is depicted in Figure 4. ls:hasFromLinkElement :linker_xx
PAYLOAD_TRIPLES_1 inst:BuildingElement_01
The advantage of this approach is that the ls:LinkElement, ls:Identifier, and the identifier declaration can entirely be omitted for one side of the link, and only the reference to the entity is referred to via ls:hasFromLinkElement. With this change in the modeling principle of the links, RDF data must not necessarily be registered in the index but must be present in the Payload triples folder.
T-Box files, like SHACL shapes and extensions of the linkset ontology, must be placed
in the Ontology resources folder. RDF datasets (A-Box) must be put into the Payload triples
folder. Company-specific OTLs or T-Box datasets like the upcoming Semantic Modeling and
Linking (SML) standard draft could arguably be used with the ICDD standard. This could bridge
the gap between hybrid modeling of semantics and documents at this point [
Eventually, a more generic solution is an approach that uses a combination of the above proposals and also considers the usage of the link type classes (defined in part 2) as property values. In this solution, the original container structure (of the three folders for Ontology resources, Payload documents, and Payload triples along with the overarching index file) is ct:ContainerDescription
LinkEllesm:hansTo rdf:type et
ls:hLainskFErolemment
:link002
rdf:type
:linker_xx
rdf:type
els:IsControlledBy
ls:LinkElement
retained as the essential information container structure. To illustrate this, Figure 5 showcases
an example container index file snippet (green oval), with the linkset file (purple oval), in
which two documents :document1 and :document2 are linked using the two hierarchy
levels: first declaring documents as ls:LinkElement and this is then used to link (by using
ls:hasToLinkElement and ls:hasFromLinkElement) to an instance :linker_xx which
is finally assigned to a link class els:IsControlledBy. If this mandatory declaration of both
ls:Link and ls:LinkElement can be omitted, and the current restrictions on the usage of
link types are removed, it is possible to assign a link class as a property value directly (this is
illustrated by the blue dotted arrows in the figure) [
Adopting LD for the built environment results in the need to exchange data using LD in conjunction with other documents. The development and adaption of the ICDD standard for the construction industry is a logical step toward data-driven storage and exchange of information. Two independent prototype developments were presented within this research focusing on the linking of data, the storage of LD datasets, and the validation of the container contents. However, the authors have recorded that the ICDD linking structure for RDF resources is cumbersome and does not exploit the full potential of LD. In the current standard state, additional agreements are necessary to facilitate an ICDD software ecosystem that maintains and verifies ICDD containers containing extra LD datasets. Possible solutions for improving the ICDD standards were given. The recommendations are summarized, and an outlook on future research is shown in the following. Based on the research carried out in this paper, several recommendations for action are outlined: • When using ICDD in its current standardization, supplemental agreements for structuring link elements and identifiers for specific file types, e.g., IFC, GIS, or spreadsheets, could help interpret the links inside ICDD in diferent systems uniquely. • The basic idea of ICDD should be that the potential of LD is not limited by its use as a simple ZIP archive without touching the benefits of LD. • For extending the ICDD standard for an ideal interaction with LD, the extensions of classes and properties of the ICDD ontologies should be allowed. • The storage of internal and external RDF files should be registered in the index file. • SHACL shapes residing in a dedicated folder or referenced from a web resource should be registered inside the index file as requirements for container exchange.
Regardless of the presented solutions for improving the linking of LD datasets in ICDD, the
validation of containers is needed and should be supported by the standard for the conformity
check and the validation of content. Regarding further research, there is also ongoing
standardization regarding the use of LD for modeling and linking building data as SML resulting
in a standard draft of BS EN 17632 [