Mapping Federated AEC projects to Industry Standards using dynamic Views Jeroen Werbrouck1,3 , Pieter Pauwels1,2 , Jakob Beetz3 and Erik Mannens4 1 Department of Architecture and Urban Planning, Ghent University, Ghent, Belgium 2 Department of the Built Environment, TU Eindhoven, Eindhoven, The Netherlands 3 Faculty of Architecture, RWTH Aachen, Aachen, Germany 4 Department of Electronics and Information Systems, Ghent University – imec, Ghent, Belgium Abstract 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 offers, 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. Keywords BIM Level 3, Solid, DCAT, Linked Data Platform, Common Data Environment 1. Introduction 1.1. Context 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 offers an as seamless-as-possible workflow, LDAC 2022: 10th Linked Data in Architecture and Construction Workshop, May 29, 2022, Hersonissos, Greece $ jeroen.werbrouck@ugent.be (J. Werbrouck)  0000-0002-4972-1189 (J. Werbrouck); 0000-0001-8020-4609 (P. Pauwels); 0000-0002-9975-9206 (J. Beetz); 0000-0001-7946-4884 (E. Mannens) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) 65 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 [1] and the Solid specifications1 , which rely on the Semantic Web and its core standard the Resource Description Framework (RDF)2 to accomplish this. In Solid, every agent (human or digital) has its own ‘decentral’ identity on the Web (‘WebID’), and a data storage point (‘Pod’) where access-regulated information can be disclosed to specific people (using their WebIDs) or made public3 . A WebID is a URL that resolves to an RDF document (the ‘card’) which contains public information about the agent and which can be used as a ‘decentral username’ on the Web, thereby facilitating decentral authentication and authorisation mechanisms. A global perspective on applying the Solid specifications on the needs of the (very ‘federated’) AEC industry is given in [2], while data patterns for a ‘federated CDE’ based on Solid are discussed in [3], in context of the LBDserver 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 [4]. Specific domain models for the AEC industry are the official RDF-based representation of the Industry Foundation Classes (IFC), ifcOWL [5], and the modular stack of ontologies covered by the W3C Linked Building Data Community Group, among which the Building Topology Ontology (BOT)4 , the Damage Topology (DOT)5 and the Ontology for Property Management (OPM)6 . 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 [6]. At the same time, it is clear that ontology-based projects ease the integration and coupling with other federated datasets: using scoped, modular domain ontologies like the ones mentioned above can be rather easily connected to adjacent domain knowledge such as GIS, governmental datasets, Facility Management information or historical knowledge - all most likely to live on the Web on different servers (and hence part of a federated knowledge graph), in contrast with a centralised approach. 1 Solid specifications, https://github.com/solid/solid-spec, visited 15/02/2022 2 Resource Description Framework, http://www.w3.org/1999/02/22-rdf-syntax-ns#, visited 15/02/2022 3 https://github.com/solid/webid-oidc-spec 4 Building Topology Ontology, https://w3id.org/bot#, visited 16/02/2022 5 Damage Topology Ontology, https://w3id.org/dot#, visited 16/02/2022 6 Ontology For Property Management, https://w3id.org/opm#, visited 16/02/2022 66 1.2. Research Questions and Paper Overview 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 standard- compliant 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 specifications7 provide specifications for digital collabora- tion in the Architecture, Engineering and Construction (AEC) industry, in an effort 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. 2. Related 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 [7], which gives an elaborate introduction to the topic. Regarding decentral access control in a Solid-based environment, the comprehensive background is provided by the Solid and OpenID Connect (OIDC)8 specifications, while pattern- and role-based extensions for the AEC industry are described in [8]. 7 https://github.com/BuildingSMART/BCF-API 8 OpenID Connect, https://openid.net/connect/, visited 16/02/2022 67 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. 2.1. Linked Data Platform 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. 2.2. Metadata and Data Catalogs on the Web 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 offers 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 [9]. Listing 1 provides an example of such dataset description. Listing 1: A dcat:Catalog can reference multiple dcat:Dataset-s; each dataset can have multiple dcat:Distribution-s with specific properties # contents of the / l o c a l / d a t a s e t s / container < partialCatalog1 > a dcat : Catalog ; lbds : DatasetRegistry ; # see section 2.2 dcat : dataset , , . # contents of the / l o c a l / d a t a s e t s / dataset1 / container a dcat : Dataset ; dct : t i t l e " the t i t l e of the d a t a s e t " ; d c a t : keyword " damage " ; dcat : d i s t r i b u t i o n , . a dcat : Distribution ; d c a t : mediaType < h t t p s : / / www. i a n a . o r g / 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 > ; d c a t : downloadUrl < d a t a s e t 1 / d i s t r i b u t i o n 1 > . 2.3. Project Discovery and Data Patterns of the LBDserver In [3], data patterns are described to manage federated construction projects using Solid, LDP and DCAT. A cascading structure of ‘aggregators’ allows the discovery of ‘project access points’, i.e. containers referencing (lbd:aggregates the contributions of other stakeholders, each one stored in (remote) container or lbds:PartialProject. Knowing the WebID of a project partner is then enough to discover their projects and contributions in an access-controlled 9 Linked Data Platform, http://www.w3.org/ns/ldp#, visited 17/02/2022 10 Data Catalog vocabulary, https://www.w3.org/TR/vocab-dcat-2/, visited 17/02/2022 68 way, as illustrated by the SPARQL query in Listing 2. Using a query engine that supports link traversal [10], dynamic data discovery is possible by sending an initial query to the stakeholder’s WebID. However, the query can also be split up into separate sub-queries to discover relevant datasets one by one, in a more classic approach. 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 s o u r c e : h t t p : / / l o c a l h o s t : 5 0 0 0 / t e s t / p r o f i l e / c a r d #me < h t t p : / / l o c a l h o s t : 5 0 0 0 / t e s t / p r o f i l e / c a r d #me> l b d s : h a s P r o j e c t R e g i s t r y ? r e g . # l i n k t r a v e r s e d source : ? reg ? reg ldp : contains ? proj . # link traversed source : ? proj ? proj lbds : aggregates ? 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 ? d s WHERE { # a partial project < h t t p : / / l o c a l h o s t : 5 0 0 0 / t e s t / l b d / 5 1 f d c 2 6 7 −0 dfd −46 b8 −902 e −335 f b 2 e 7 3 a d 0 / l o c a l / > lbds : hasDatasetRegistry ? dsreg . # link traversed source : dataset 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 imple- mentations (a ‘satellite’). 2.4. Standards considered in this paper 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-in- progress’, ‘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 [11]. 69 • BCF API: The BIM Collaboration Format (BCF) API11 is a member of the OpenCDE Foundation API specification family, a buildingSMART-covered initiative for facilitating information exchange between CDEs on the market. It defines a series of HTTP endpoints to retrieve project issue data (‘Topics’) in a tree-like fashion, using standardised response bodies. 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 above- mentioned standards. 3. Client-side views on Federated Project Data 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 difference between query-based (virtual) containers and effectively 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. 3.1. UC 1: stages of publication according to ISO 19650 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 con- tainers. 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 ? downloadURL } WHERE { # _ _ _ _ _ D a t a s e t d i s c o v e r y s t a r t i n g from P r o j e c t A c c e s s P o i n t _ _ _ _ # i n i t i a l source : project access point ? aggr l b d s : aggregates ? p a r t i a l . # link traversed source : p a r t i a l project 11 The BCF API, https://github.com/BuildingSMART/BCF-API, accessed 23/02/22 70 ? p a r t i a l lbds : hasDatasetRegistry ? dsr . # link traversed source : dataset r e g i s t r y ? d s r ldp : c o n t a i n s ? ds . # _____Subquery f o r d a t a s e t f i l t e r i n g _ _ _ _ # link traversed source : dataset # a g g r e g a t e a l l r e s o u r c e s w i t h s t a t u s " s h a r e d " ( example o n t o l o g y ) ? d s ex : p u b l i c a t i o n S t a t u s " s h a r e d " ; d c a t : d i s t r i b u t i o n / d c a t : downloadURL ? downloadURL . BIND ( UUID ( ) a s ? 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 different stakeholder Pods. Short IDs are used in this listing to keep URLs brief. <> l d p : c o n t a i n s < h t t p s : / / pod . a r c h i t e c t − o f f i c e . com / l b d / 4 5 8 1 0 7 b5 / l o c a l / d 4 4 d b 8 3 8 / d s 1 / m a i n D i s t , < h t t p s : / / pod . a r c h i t e c t − o f f i c e . com / l b d / 4 5 8 1 0 7 b5 / l o c a l / 8 c 6 d 7 3 1 7 / d s 8 / m a i n D i s t , < h t t p s : / / pod . e n g i n e e r i n g − o f f i c e . de / l b d / 4 5 8 1 0 7 b5 / l o c a l / 5 c 0 8 d d b 2 / d s 2 5 / m a i n D i s t , < h t t p s : / / pod . a r c h i t e c t − o f f i c e . com / l b d / 4 5 8 1 0 7 b5 / l o c a l / 3 4 e d 9 b 8 d / d s 1 2 / m a i n D i s t , < h t t p s : / / pod . hvac − s t u d i e b u r e a u . be / l b d / 4 5 8 1 0 7 b5 / l o c a l / 9 e d b f e 3 c / d s 1 4 / m a i n D i s t . 3.2. UC 2: Virtual view templates for ICDD containers (ISO 21597) 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 A c c e s s 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 . o r g / 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 . o r g / 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 . o r g / 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 + j s o n > )) BIND ( UUID ( ) a s ? 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 A c c e s s 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 ( ) a s ? 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 differentiates between enrichment of ‘real objects’ and enrichment of digital files on the other hand. As the LBDserver approach 71 for sub-document linking can be considered a superset of ICDD [3], mapping these to ICDD is straightforward (Listing 8). Listing 8: SPARQL query to generate ICDD links from LBDserver references CONSTRUCT { ? concept 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 ; ls : h a s I d e n t i f i e r ? id . ? id ls : i d e n t i f i e r ? i d e n t i f i e r . } WHERE { [ . . . reference registry discovery patterns ( lbds : hasReferenceRegistry )] # link traversed source : Reference r e g i s t r y ? c o n c e p t a l b d s : C on ce p t ; lbds : hasReference ? le . ? le lbds : h a s I d e n t i f i e r ? id ; l b d s : hasDocument ? d i s t r i b u t i o n . ? id lbds : h a s I d e n t i f i e r ? i d e n t i f i e r . } The index.rdf file bundles information about the project with a listing of the contained re- 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 links.rdf patterns. Listing 9: SPARQL query (partial) to generate index.rdf for the ICDD container. CONSTRUCT { ? index c t : containsDocument ? d i s t ; ct : creator ? creator ; ct : description ? projectDescription . ? d i s t a ct : InternalDocument ; ct : description ? dsDescription ; ct : format ? format ; ct : filename ? filename . } 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 A c c e s s P o i n t ( c f . L i s t i n g 4 ) ] # link traversed source : dataset r e g i s t r y ? d s r ldp : 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 ( ) a s ? i n d e x ) 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 . o r g / a s s i g n m e n t s / media − t y p e s / " ) , s t r ( " " ) ) as ? format ) } 3.3. Notes on virtual container views 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, project- wide 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. 12 SHACL, https://www.w3.org/TR/shacl/, visited 18/02/2022 72 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 office 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. 4. Mapping LBDserver datasets to standardised APIs 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. Figure 1: Middleware APIs facilitate the mapping of LBDserver storage patterns to standardised HTTP endpoints and responses, such as the BCF API specification. 4.1. UC3: serving federated project data conform the BCF API 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 [12]. The approach in [12] eliminates the need for an intermediary API, but hard-wires the data storage patterns of BCF into the Pod structures, based on the bcfOWL ontology, an RDF-based version of the BCF data structures[13]. In the below paragraphs we will explore an alternative approach, based on virtual views. This will require an extra middleware service to be set up, but also allows for a more independent way of storing project data. An intermediary service accesses project data on the Pod (exposed via LDP) and remoulds this data in the desired shape via its own REST API. Note that the service is not integrated with the Solid Server hosting the Pod - from this perspective, it is both a client (fetching remote data) and a server (exposing data on the Web). 73 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 [ . . . otherTopics , { " g u i d " : " 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 " : " A r c h i t e c t @ e x a m p l e . 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 " : " 2 0 1 4 − 1 1 − 1 9 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 ; dct : t i t l e ? t i t l e ; rdfs : label ? label ; dct : created ? creationDate . } 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 A c c e s s P o i n t ( c f . L i s t i n g 4 ) ] ? d s a bcfOwl : T o p i c ; dct : 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 ; dct : t i t l e ? t i t l e ; rdfs : label ? label ; dct : created ? creationDate . } Listing 12: Context to make the results compatible with BCF API response without losing semantics. { " @context " : { " g u i d " : " h t t p : / / p u r l . o r g / dc / t e r m s / i d e n t i f i e r " , " creation_author " : { " @id " : " h t t p : / / p u r l . o r g / dc / t e r m s / c r e a t o r " , " @type " : " @id " 13 JSON-LD framing, https://w3c.github.io/json-ld-framing/, visited 07/03/2022 74 }, " t i t l e " : " h t t p : / / p u r l . o r g / dc / t e r m s / t i t l e " , " l a b e l s " : " h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / r d f − schema # l a b e l " , " c r e a t i o n _ d a t e " : " h t t p : / / p u r l . o r g / dc / t e r m s / c r e a t e d " } } 5. Discussion and Conclusion 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 different 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 flexible 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 different stakeholder Pods. In this case, the use of the LBDserver Reference Registry (not covered in this paper) is expected to offer solace - but this should be tested more thoroughly. Additionally, in such situations, the difference 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. Acknowledgments This research is funded by the Research Foundation Flanders (FWO), by means of the Strategic Basic Research Grant (grant no. 1S99020N). 75 References [1] E. Mansour, A. V. Sambra, S. Hawke, M. Zereba, S. Capadisli, A. Ghanem, A. Aboulnaga, T. Berners-Lee, A demonstration of the solid platform for social web applications, in: Proceedings of the 25th International Conference Companion on World Wide Web, 2016, pp. 223–226. doi:10.1145/2872518.2890529. [2] J. Werbrouck, P. Pauwels, J. Beetz, L. van Berlo, Towards a decentralised common data environment using linked building data and the solid ecosystem, in: 36th CIB W78 2019 Conference, 2019, pp. 113–123. [3] J. Werbrouck, P. Pauwels, J. Beetz, E. Mannens, Lbdserver - a federated ecosystem for heterogeneous linked building data, Semantic Web Journal (submitting). [4] P. Pauwels, S. Zhang, Y.-C. Lee, Semantic Web Technologies in AEC industry: A Literature Overview, Automation in Construction 73 (2017) 145—-165. doi:10.1016/ j.autcon.2016.10.003. [5] P. Pauwels, W. Terkaj, EXPRESS to OWL for Construction Industry: Towards a Recom- mendable and Usable ifcOWL Ontology, Automation in Construction 63 (2016) 100—-133. doi:10.1016/j.autcon.2015.12.003. [6] R. Verborgh, Reflections of knowledge: Designing web apis for sustainable interactions within decentralized knowledge graph ecosystems, 2021. URL: https://ruben.verborgh.org/ blog/2021/12/23/reflections-of-knowledge/. [7] J. Hendler, F. Gandon, D. Allemang, Semantic Web for the Working Ontologist: Effective Modeling for Linked Data, RDFS, and OWL, Morgan & Claypool, 2020. [8] J. Werbrouck, R. Taelman, R. Verborgh, P. Pauwels, J. Beetz, E. Mannens, Pattern-based access control in a decentralised collaboration environment, in: Proceedings of the 8th Linked Data in Architecture and Construction Workshop, CEUR-WS. org, 2020. [9] M. Bonduel, A framework for a linked data-based heritage bim, 2021. URL: https: //lirias.kuleuven.be/handle/123456789/674476. [10] R. Verborgh, R. Taelman, Guided link-traversal-based query processing, arXiv preprint arXiv:2005.02239 (2020). [11] M. Senthilvel, J. Oraskari, J. Beetz, Implementing information container for linked doc- ument delivery (icdd) as a micro-service, in: EG-ICE 2021 Workshop on Intelligent Computing in Engineering, Universitätsverlag der TU Berlin, 2021, p. 66. [12] J. Oraskari, O. Schulz, J. Werbrouck, J. Beetz, Enabling interoperable issue management in a federated building and construction sector, in: EG-ICE 2022 Workshop on Intelligent Computing in Engineering, submitting. [13] O. Schulz, J. Oraskari, J. Beetz, bcfowl: A bim collaboration ontology (2021) 142–153. 76