Web-based construction projects are rapidly becoming commonplace. Domain-specific collaboration platforms, the so-called Common Data Environments (CDEs), facilitate complex interactions between the various stakeholders participating in a project. CDEs are developed and maintained by the large BIM companies allowing deep integration with BIM authoring tools. Notwithstanding the benefits such integration ofers, usage of proprietary tools, data models and platforms holds the risk of a vendor lock-in and creates dependencies on platform APIs as the sole funnels trough which project data can be accessed - even when using open data formats. Recently, technologies for re-decentralising the Web are under increasing interest, as they allow decoupling data storage from applications. The Solid initiative bundles these technologies in a domain-independent way. In previous work we have already discussed data patterns for the AEC industry, using these technologies - the LBDserver. In this paper, we demonstrate how these very generic data organisation patterns can be aligned with organisational structures of some common industry standards: ISO 19650, ISO 21597 and the BCF API specifications. To achieve full alignment with all three standards will be out of scope for this paper. Rather the aim is to demonstrate a Linked Data-based, federated environment such as the LBDserver is compatible with existing (centralised) approaches while maintaining the benefits of organising digital projects in a federated way.
In recent years, the construction industry has been digitising rapidly. One of the driving forces behind this digitisation are advancements in Web-based collaboration, another one is data interoperability - achieved through usage of open standards. Nowadays, Web-based collaboration is often managed via centralised platforms, called Common Data Environments (CDEs). The most widely used CDEs are commercial platforms, tightly integrated with traditional (proprietary) BIM authoring tools. This integration ofers an as seamless-as-possible workflow, but also holds the risk of a vendor lock-in, both regarding the use of proprietary formats and the storage of project data on centralised platforms. Only reachable via specific API endpoints, the possible interactions of project stakeholders with their own models lies in the hands of third-party software vendors.
At the same time, domain-agnostic Web technologies aim towards a re-decentralisation of
data on the Web. Essentially this means that there is no one-on-one relationship between an
application and the data it uses: data can be federated on the Web, aggregated by a client that
knows how to discover, retrieve and combine this information in a meaningful way. Important
here is the Solid project [
Aligning digital project organisation with the federated nature of the industry is only one of
the advantages commonly associated with the application of Semantic Web technologies for the
AEC industry. The large majority of research in this area is concerned with data interoperability
and linking cross-domain information on a data level [
However, using the Semantic Web for federated data storage is decoupled from using the
same technologies for structuring AEC datasets. This means that the benefits of federated
storage are available without disrupting a notoriously traditional and largely file-based industry:
it is perfectly possible to wire a federated network of heterogeneous project data (including
proprietary file formats) with a client still handling it as if the data is centralised [
1Solid specifications, https://github.com/solid/solid-spec, visited 15/02/2022 2Resource Description Framework, http://www.w3.org/1999/02/22-rdf-syntax-ns#, visited 15/02/2022 3https://github.com/solid/webid-oidc-spec 4Building Topology Ontology, https://w3id.org/bot#, visited 16/02/2022 5Damage Topology Ontology, https://w3id.org/dot#, visited 16/02/2022 6Ontology For Property Management, https://w3id.org/opm#, visited 16/02/2022
In this paper, we investigate compatibility of the federated data structures of the LBDserver ecosystem (proposed in earlier papers) with existing industry practices. We will demonstrate by example how a Linked Data-based, federated environment such as the LBDserver is compatible with existing (centralised) approaches, while maintaining the benefits of organising digital projects in a federated way. Hence, the research questions discussed in this publication can be formulated as follows: • RQ1: Does a metadata-based organisation of federated AEC project data allow flexible mapping and filtering of this data in query-based ‘virtual views’? • RQ2: Can such virtual views be used to present federated project data in standardcompliant ways?
In our handling of these research questions, we base upon established standards rather than proprietary formats. National and international standards such as ISO 19650, ISO 21597, PAS 1192:2013 (UK) and the BCF API specifications 7 provide specifications for digital collaboration in the Architecture, Engineering and Construction (AEC) industry, in an efort to enable information exchange between disparate CDEs. This is achieved by devising common API structures, containerisation of project files and shared data formats. After a brief overview of related technologies (Section 2), we present a methodology for metadata-based generation of virtual views on federated projects, which present project data to the client complying with these standards. We evaluate and illustrate this methodology with virtual views on: • The stages of data publication as defined in ISO 19650; • Generating a project container based on ISO 21597 (ICDD); • Exposing project issue data (‘Topics’) in a way compatible with the BCF API specifications) .
The former two can be achieved entirely client-side (Section 3), the latter focuses on how a middleware service can be used to present the data in a standard-compliant way (Section 4). The paper concludes with a discussion and overview of future work.
In this section, we introduce the main technologies on which this work will rely. Describing
the basics of the Semantic Web is out of scope for this paper; for the reader in need we refer to
[
In the following sections, we briefly cover resource containment with the Linked Data Platform (LDP) (Section 2.1), metadata resources using the DCAT vocabulary (Section 2.2), and the data patterns used in the LBDserver (Section 2.3), upon which this paper will base its contribution.
As the main specification for serving resources, Solid bases upon the Linked Data Platform Specification (LDP) 9. In LDP, resources are aggregated (ldp:contains) in ldp:Container-s. This containment structure can be used to mimic a folder-based structure in a RESTful API, allowing a read/write Web of data. LDP has proven very useful as a straightforward mechanism for organising data containers in Solid Pods. However, its expressive power is limited, which means that other frameworks need to be used to express semantically rich metadata.
When we model a digital construction project as a federated multi-model, a data model is needed
to allow discovery and aggregation of its resources. The Data Catalog vocabulary (DCAT)10
ofers domain-independent definitions for this purpose. In DCAT, a dcat:Catalog references
‘datasets’ (dcat:Dataset); metadata descriptions of resources. Datasets may, in turn, have
multiple ‘distributions’ (dcat:Distribution), which contain the actual information. As
DCAT is RDF-based, catalogs can be federated - which makes them an ideal fit to describe
building datasets [
< d a t a s e t 1 # d i s t r i b u t i o n 2 > . < d a t a s e t 1 # d i s t r i b u t i o n 1 > a dcat : D i s t r i b u t i o n ; dcat : mediaType < h t t p s : / /www. iana . org / assignments / media − types / t e x t / t u r t l e > ; dcat : downloadUrl < d a t a s e t 1 / d i s t r i b u t i o n 1 > .
In [
way, as illustrated by the SPARQL query in Listing 2. Using a query engine that supports link
traversal [
Listing 2: SPARQL query to discover LBDserver project access points and their constituent partial projects.
SELECT DISTINCT ? p a r t i a l WHERE { # i n i t i a l source : http : / / l o c a l h o s t : 5 0 0 0 / t e s t / p r o f i l e / card #me < http : / / l o c a l h o s t : 5 0 0 0 / t e s t / p r o f i l e / card #me> l b d s : h a s P r o j e c t R e g i s t r y ? reg . # l i n k t r a v e r s e d source : ? reg ? reg ldp : c o n t a i n s ? p r o j . # l i n k t r a v e r s e d source : ? p r o j ? p r o j l b d s : a g g r e g a t e s ? p a r t i a l . }
An lbds:PartialProject contains several registries, of which the ‘dataset registry’ is the most important in this context: it contains a flat list of metadata containers, describing project resources as dcat:Dataset-s. A query for discovering datasets is given in Listing 3. Filtering project resources in Section 3 will be based on this flat list.
Listing 3: SPARQL query to discover project datasets on a partial project.
SELECT DISTINCT ? ds WHERE { # a p a r t i a l p r o j e c t < http : / / l o c a l h o s t : 5 0 0 0 / t e s t / lbd /51 fdc267 −0 dfd −46b8 −902e −335 fb2e73ad0 / l o c a l / >
l b d s : h a s D a t a s e t R e g i s t r y ? dsreg . # l i n k t r a v e r s e d source : d a t a s e t r e g i s t r y ? dsreg ldp : c o n t a i n s ? ds . }
A partial project may indicate an alternative endpoint (SPARQL, MongoDB, SQL ...) where this data is served, as an alternative to the file-based approach common in current Solid implementations (a ‘satellite’).
This paper tests the flexibility of LBDserver dataset storage by applying virtual views and
re-alignments on three existing industry standards. These standards are:
• ISO 19650: the main ISO standard for organising information about an asset during its
life cycle. It focuses on a file-based information exchange in a shared Common Data
Environment. In this paper, we will only focus on a very small part of the standard for
demonstrative purposes, which defines the stages of publication for a resource:
‘work-inprogress’, ‘shared’, ‘published’ and ‘archived’.
• ISO 21597: The Information Container for linked Document Delivery (ICDD) defines a
container format to exchange and archive heterogeneous ‘multi-models’ of a built asset,
based on RDF ontologies. ICDD containers, which can be considered a dump repository of
the project, consist of a root ‘index.rdf’ document, a subfolder with RDF-based resources
(‘Payload Triples’), one with non-RDF-based resources (‘Payload documents’) and finally
a subfolder containing the used ontologies (‘Ontology resources’). A comparative study
on the structures of ICDD and LDP is covered in [
In Section 3, the metadata stored in LBDserver datasets will serve as the input to query the federated project and generate views according to parameters put forward by the abovementioned standards.
When an LBDserver project has been discovered, a union of all partial projects forms the knowledge graph of the project. Federated queries can be executed on this list of project resources. Depending on the setup of the Solid Servers in the project, such queries can be carried out completely client-side (using a client-side query engine and source discovery as described in Section 2.3) or in a hybrid way - when partial projects are served via an access controlled SPARQL endpoint (lbds:hasSparqlSatellite). In this section, these queries are concerned with filtering and organising resources in a specific way, and hence have metadata resources, i.e., DCAT datasets, as their main sources. We propose the use of Linked Data Platform (LDP) Containers (ldp:Container) to exchange sets of project resources adhering to the query - in other words, filters on the available datasets will be presented as if they were default LDP Containers. Applications relying on Solid data structures will thus experience no diference between query-based (virtual) containers and efectively hosted Solid containers. A SPARQL CONSTRUCT query can immediately generate such virtual container. In the following section, we illustrate the flexibility of this approach by remapping the LBDserver datasets structure to common (standardised) data patterns. Note that this does not change the resources themselves: they are only grouped (filtered) in an alternative way, as a list of resource URLs aimed at discovery.
The example in Listing 4 yields an ldp:Container that references all project resources labelled as ‘shared’. This aligns with a first use case mapping, where the ISO 19650 stages of data publication can be dynamically generated in a federated project: virtual containers can be created for ‘work-in-progress’, ‘shared’, ‘published’ and ‘archived’ tags.
Listing 4: SPARQL query to filter a project datasets and return their distributions as LDP containers.
CONSTRUCT { ? v i r t u a l C o n t a i n e r ldp : contains ?downloadURL } WHERE { # _____Dataset discovery s t a r t i n g from P r o j e c t Access Point____ # i n i t i a l source : p r o j e c t access point ? aggr lbds : aggregates ? p a r t i a l . # l i n k t ra v er se d source : p a r t i a l p r o j e c t 11The BCF API, https://github.com/BuildingSMART/BCF-API, accessed 23/02/22
BIND ( UUID ( ) as ? v i r t u a l C o n t a i n e r ) Listing 5: Example result of a dynamically generated LDP container, based on the query in Listing 4. The project ID allows identification of the project on the diferent stakeholder Pods. Short IDs are used in this listing to keep URLs brief.
A similar approach can be taken for generating an ICDD-compliant view of the project.
Listing 6 illustrates the query to extract the resources for the ‘Payload Triples’ folder. The query for ‘Payload Documents’ is identical, with the exception of the mediatype (‘?mt’) filter being changed to ‘NOT IN’. The query to retrieve the ontologies is given in Listing 7.
Listing 6: SPARQL query to discover project datasets on a partial project.
CONSTRUCT { ? v i r t u a l C o n t a i n e r l d p : c o n t a i n s ? download } WHERE { [ . . . d a t a s e t d i s c o v e r y p a t t e r n s s t a r t i n g from P r o j e c t Access P o i n t ( c f . L i s t i n g 4 ) ] ? ds d c a t : d i s t r i b u t i o n ? d i s t . ? d i s t d c a t : downloadURL ? download ;
d c a t : mediaType ?mt .
FILTER ( ? mt IN ( < h t t p s : / /www. i a n a . org / a s s i g n m e n t s / media − t y p e s / t e x t / t u r t l e > , < h t t p s : / /www. i a n a . org / a s s i g n m e n t s / media − t y p e s / a p p l i c a t i o n / r d f +xml > , < h t t p s : / /www. i a n a . org / a s s i g n m e n t s / media − t y p e s / a p p l i c a t i o n / l d + json > ) ) BIND ( UUID ( ) as ? v i r t u a l C o n t a i n e r ) }
Listing 7: SPARQL query to map the ontologies used on the project.
CONSTRUCT { ? v i r t u a l C o n t a i n e r l d p : c o n t a i n s ? v o c a b u l a r y } WHERE {
[ . . . d a t a s e t d i s c o v e r y p a t t e r n s s t a r t i n g from P r o j e c t Access P o i n t ( c f . L i s t i n g 4 ) ] } ? ds void : v o c a b u l a r y ? v o c a b u l a r y .
BIND ( UUID ( ) as ? v i r t u a l C o n t a i n e r )
Next is the linkset, which connects sub-document identifiers in an ICDD container. This
corresponds with the Reference Registry in the LBDserver, which is similar to ICDD but
incorporates metadata and distributions on the one hand and diferentiates between enrichment
of ‘real objects’ and enrichment of digital files on the other hand. As the LBDserver approach
for sub-document linking can be considered a superset of ICDD [
Listing 8: SPARQL query to generate ICDD links from LBDserver references CONSTRUCT { ? c o n c e p t a l s : Link ;
l s : hasLinkElement ? l e . ? l e a l s : LinkElement ; l s : hasDocument ? d i s t r i b u t i o n ; l s : h a s I d e n t i f i e r ? i d .
? i d l s : i d e n t i f i e r ? i d e n t i f i e r . } WHERE { [ . . . r e f e r e n c e r e g i s t r y d i s c o v e r y p a t t e r n s ( l b d s : h a s R e f e r e n c e R e g i s t r y ) ] sources and basic metadata (e.g. format, creation date, label and original file name) - information that will be generally stored in the LBDserver metadata as well (Listing 9). Note that the result of this query will not be an LDP container but a single resource directly following the ICDD
Listing 9: SPARQL query (partial) to generate index.rdf for the ICDD container. links.rdf patterns.
CONSTRUCT { ? index c t : containsDocument ? d i s t ; c t : c r e a t o r ? c r e a t o r ; c t : d e s c r i p t i o n ? p r o j e c t D e s c r i p t i o n . ? d i s t a c t : InternalDocument ; c t : d e s c r i p t i o n ? d s D e s c r i p t i o n ; c t : format ? format ; c t : f i l e n a m e ? f i l e n a m e . } WHERE { [ . . . d a t a s e t d i s c o v e r y p a t t e r n s s t a r t i n g from P r o j e c t Access P o i n t ( c f . L i s t i n g 4 ) ] # l i n k t r a v e r s e d s o u r c e : d a t a s e t r e g i s t r y ? d s r l d p : c o n t a i n s ? ds . ? ds d c t : c r e a t o r ? c r e a t o r ;
r d f s : comment ? d s D e s c r i p t i o n ; BIND ( UUID ( ) as ? index ) BIND ( r e p l a c e ( s t r ( ? mt ) , s t r ( " h t t p s : / /www. i a n a . org / a s s i g n m e n t s / media − t y p e s / " ) , s t r ( " " ) ) as ? format )
Of course, metadata can only be filtered when the triple patterns in the query are actually available. However, requirements to metadata can be easily configured (standardised, projectwide or stakeholder-specific) using RDF validation languages such as the SHApes Contstraint Language (SHACL)12. Upon creation of datasets, adherence to these shapes should be validated. A discussion on specific workflows for such validation-based resource posting is beyond the scope of this paper.
12SHACL, https://www.w3.org/TR/shacl/, visited 18/02/2022
Although the use of LDP containers allows to deliver the data in a standardised format, it is still up to the client to interpret this information, further modify it and present it to the end-user in a meaningful way. However, the use of such containers goes beyond the interfacing aspect. For example, a middleware API can use these mappings as an intermediary mapping to expose the project as an ICDD dump to the outside world. Another example is dynamic access rights management. For example, if a resource is still ‘work-in-progress’, a satellite on top of the LBDserver can set the access rights so only employees of the producing ofice are allowed to view it. When the publication status changes to ‘shared’, it can be opened to other stakeholders of the project. The example in Section 4 will further discuss these middleware-oriented mappings.
In the previous section, client-based views were constructed on LBDserver projects. Although these views can be used for multiple purposes, such as generating a standard-compliant ICDD archive or presenting project information to the user in a specific hierarchy, more can be done when these views are constructed by intermediary agents - headless servers - to expose federated project data as if the project were centralised (Figure 1). This way, backwards compatibility with existing tools and standards can be more easily achieved.
The BCF API proposes a tree-like HTTP endpoint structure to retrieve project issue data.
Mirroring this tree to a Solid/LDP-based environment is the topic of [
Because the LBDserver allows storage of all kinds of project information, mapping to the BCF API involves creating a subset of the available datasets: e.g., only those which are tagged as bcfowl:Topic are relevant in this case. We will consider an exemplary request of the BCF API specification, namely GET TOPICS. Other endpoints for the BCF API can be constructed in a similar way. A standard BCF API response for this request is given in Listing 10. Listing 10: Example response for a GET TOPICS request according to the BCF API (from https://github.com/BuildingSMART/BCF-API) GET / b c f / { v e r s i o n } / p r o j e c t s / { p r o j e c t _ i d } / t o p i c s [ . . . o t h e r T o p i c s , { " guid " : " A211FCC2 −3A3B−EAA4−C321 −DE22ABC8414 " , " s e r v e r _ a s s i g n e d _ i d " : " ISSUE − 0 0 0 7 8 " , " c r e a t i o n _ a u t h o r " : " Architect@example . com " , " t i t l e " : " Example t o p i c 2 " , " l a b e l s " : [ " A r c h i t e c t u r e " , " Heating " , " E l e c t r i c a l " ] , " c r e a t i o n _ d a t e " : "2014 −11 −19 T14 : 2 4 : 1 1 . 3 1 6 Z "
Additionally, the BCF API relies on JSON for serving its information. The JSON-based RDF format JSON-LD allows us to attach a context to a JSON object, which means that the response can be at the same time compliant to the (contextless) BCF API and avoid losing semantic information. Upon request for ‘/topics’, a BCF server that relies on an LBDserver ecosystem for data storage thus first queries the project with the query listed in Listing 11 and then easily converts the resulting RDF graph to JSON-LD using the context given in Listing 12. If required, further alignment can rely on JSON-LD framing and the JSON-LD framing API13. As in this use case the focus does not lie on discovery, but on presenting actual information, the use of ‘virtual’ LDP containers (cf. Section 3) is omitted. An alternative approach is to just filter the datasets that are bcfOwl:Topic-s, using the LDP containers indeed, and then retrieve the entire dataset as JSON-LD.
Listing 11: SPARQL query retrieve bcfowl:Topic-s in the federated project. CONSTRUCT { ? ds d c t : i d e n t i f i e r ? i d e n t i f i e r ; dc : c r e a t o r ? c r e a t o r ; d c t : t i t l e ? t i t l e ; r d f s : l a b e l ? l a b e l ; d c t : c r e a t e d ? c r e a t i o n D a t e . } WHERE { [ . . . d a t a s e t d i s c o v e r y p a t t e r n s s t a r t i n g from P r o j e c t Access P o i n t ( c f . L i s t i n g 4 ) ] ? ds a bcfOwl : Topic ; d c t : i d e n t i f i e r ? i d e n t i f i e r ; dc : c r e a t o r ? c r e a t o r ; d c t : t i t l e ? t i t l e ; r d f s : l a b e l ? l a b e l ; d c t : c r e a t e d ? c r e a t i o n D a t e . } { Listing 12: Context to make the results compatible with BCF API response without losing semantics. " @context " : { " guid " : " h t t p : / / p u r l . org / dc / terms / i d e n t i f i e r " , " c r e a t i o n _ a u t h o r " : { " @id " : " h t t p : / / p u r l . org / dc / terms / c r e a t o r " , " @type " : " @id " 13JSON-LD framing, https://w3c.github.io/json-ld-framing/, visited 07/03/2022
In this paper, we showed how datasets on multiple Solid Pods (the LBDserver ecosystem) can be re-structured to be backwards compatible with existing industry standards. This was done using a programming language-agnostic approach, relying on the properties of SPARQL, RDF and JSON-LD. As illustrated by the use cases, these mappings can serve a mere interface-oriented purpose, e.g. to allow diferent views on the same datasets (through the use of virtual LDP containers), or a more infrastructural one, hiding LBDserver complexities behind a middleware service layer. We have demonstrated that the data storage patterns of the LBDserver are lfexible enough to support basic mappings to divergent standards. However, future research should determine the limits of more complex mappings, e.g., involving the relationships of LBDserver datasets with other datasets. For example: when a BCF Topic references its Comments and Viewpoints, all these instances may be separate LBDserver datasets hosted on diferent stakeholder Pods. In this case, the use of the LBDserver Reference Registry (not covered in this paper) is expected to ofer solace - but this should be tested more thoroughly. Additionally, in such situations, the diference between metadata and actual content is more ambiguous: isn’t an issue always metadata on some larger subject? This as well should be clarified in future research.
Nevertheless, this research shows that data storage on Solid Pods does not need to exactly follow a specific storage pattern: the LDP-compliant REST API as implemented in Solid may be only the first layer in a series of mappings. When resources are described by their metadata and their URLs bear no implicit semantics or tags, as is the case in the LBDserver, URLs will be much more stable as they do not need to reflect an ever-changing folder structure (a common challenge for Solid Pods in general). The flattened list of project resources in an LBDserver can be considered ‘pluripotent’, since creating a new view or folder-structure upon this data or structure is not the responsibility of the Pod (or the LDP resource tree) anymore: these views are just a virtual layer that can be applied at every point in the flow of data exchange. By illustrating this concept holds for multiple industry standards, we hope this research can lower the threshold for further integration of Web- and data-based Building Information Management practices.
This research is funded by the Research Foundation Flanders (FWO), by means of the Strategic Basic Research Grant (grant no. 1S99020N).