The BIM Collaboration Format (BCF) is a buildingSMART standard used to exchange issues in a digital model between heterogeneous software applications and planners. Although the BCF issues are spatially located in a model and provide links to building elements, the format is only loosely connected to the actual BIM model. While the format is well suited for its original use case, it lacks the exibility to retrieve information from the BCF in conjunction with the BIM model. In this paper, we introduce the BIM Collaboration Format Ontology (bcfOWL), which translates the format to the Semantic Web and harnesses the expressive richness of OWL. We present the structure of the ontology and highlight the di erences with existing implementations of BCF. Using example queries, we show how extended relationships between a BIM model and BCF information are enabled by bcfOWL. We show that by transferring BCF to Linked Data, the format's applicability is enhanced without losing compatibility with existing implementations and work ows. In doing so, the ontology aims to integrate into the Linked Building Data environment and facilitates access to synergies between heterogeneous building data.
Issue management is an integral part of most BIM processes in the
Architecture, Construction, Engineering, Owner and Operator (AECOO) industry.
Today this is often implemented by using the BIM Collaboration Format (BCF)
of the buildingSMART organization. It represents a standardized way of
communicating issues between heterogeneous software applications. There are two
standard approaches for exchanging data: a le-based work ow, where Issues are
written into a ZIP container using the BCF XML5 schema, and a server-based
approach, which uses the BCF API6 speci cation for the data exchange. It is
based on the principles of a RESTful API. It allows users of di erent disciplines
using di erent software to communicate the reported Issues online, eliminating
the need to exchange les via email or a data device. [
Common use cases for such Issues include clash detection during partial domain model integration and change or information request in the design phase of a building. They often result in hundreds of Issues in a single information handover or integration scenario. For such common scenarios, the management of Issues captured in individual les is highly impractical and queries for speci c data are challenging to implement via the API.
Over the last years, there have been many approaches to compose Linked
Building Data. The ifcOWL ontology [
The Linked Building Data Community Group (LBD-CG)7 of the World Wide
Web Consortium (W3C) is devoted to advance the adoption of the Linked Data
and Semantic Web technologies in AECOO. The vision is to enable web-based
information exchange and work ows, provide open and versatile standards for
di erent domains, and facilitate distributed data integration. [
In this paper, we present the BIM Collaboration Format Ontology (bcfOWL)8 that shares the principles of Linked Building Data, and which provides a way to create BCF information that is interlinked in the context of a building. We describe the design principles used and demonstrate the bene ts of the approach by example queries. We discuss the di erences from the BCF API server de nition and argue how the representation of Issues as semantic graphs are bene cial in continuous information integration scenarios in common BIM-based work ows. The underlying research questions are: 1. How can Issues that arise in common work ows be integrated and linked with the BIM work ow? 2. How to express the core ideas of BCF by following the best practices of ontology design and still keeping the result compatible with the original BCF API and BCF XML standards?
The paper is structured as follows: The rst section describes the current implementations of BCF and highlights a rst approach of converting BCF to an ontology. The following section deals with the newly created ontology, bcfOWL, and focuses on which design principles and best practices were considered when creating it, and how it compares to the current implementations of BCF. In section 4, we provide example use-cases and show how SPARQL can be used to query BCF information. We discuss the results of bcfOWL, conclude the paper, and give an overview of future work in section 6.
2 2.1
BCF XML BCF was initially developed by the companies Solibri and Tekla, and the Institute of Applied Building Informatics to exchange problems within a digital building model between di erent software applications.9 The format is often used in the area of issue management and collision checking. The original version of BCF is based on an XML format, and the Issues are organized in sub-folders within a ZIP le. This le can then be distributed and imported into other software applications that support the standard. The BCF XML format also allows round-tripping, where the same le can be extended with additional Issues, and existing Issues can be modi ed. Thereby preventing that the Issues are stored over several les, and thus a clear structure is lost. 2.2
BCF API
Although this round-tripping of the BCF XML les already reduces ambiguity
and helps stricter, machine-readable representations of Issues, the exchange of
les via e-mail or data storage media is a weak point of related processes and
work ows. [
The 2.1 version of the BCF API contains a Public Service, responsible for a rudimentary User Management, and a Documents Service, which can be used to interchange BIM models via the BCF server and link an Issue to a speci c Document or File. Version 3.0 already separates the Public Services to an API, called the Foundation API and serves as a common base layer on an upcoming multi-tier architecture for open standards for Common Data Environments10 (openCDE APIs). For the Document Service, a Documents API is under development as well. These APIs are intended to enable a standardized, vendor-independent exchange of BIM models and their associated data. BCF is an integral part of this infrastructure, as it can be used within an openCDE to document issues and create change requests across multiple documents.
2.4
Although BCF XML and BCF API are based on di erent data serialization formats, both variants are compatible on a structural level. They are based on the basic concepts of Projects, Topics, Comments, and Viewpoints, which are organized hierarchically. The combination of Topics, Viewpoints, and Comments is often referred to as an Issue. When talking about an Issue, this is to be equivalent to the Topic, which is the connecting element for the Viewpoints and Comments. In the le structure of the BCF XML, the term Markup is used. The general structure can be reviewed in Figure 1.
Except for free text parameters, the Topics must be lled with data de ned in the Extension Schema. The concept of Viewpoints establishes a spatial link to the BIM model and conveys the information about which parts of the building are visible or selected in the respective camera view. The position and rotations are speci ed in a Cartesian coordinate system with vectors (X|Y|Z). 2.5
In [
Furthermore, the connection to BIM happens via two parameters in the BCF Format. On the one hand, the Issues are spatially linked with the model via 11 https://restfulapi.net/rest-api-n-1-problem/ location and rotation in the Viewpoints. On the other hand, the Components subconcept can link to a building element via Globally Unique Identi er (GUID). Nevertheless, currently neither allows to query BCF information in a spatial context or a context of the accompanying building elements referenced by the Issue. Already downloaded Issues and BCF XML could be queried with customdesigned functions in such a way, but just in the context of the BCF information currently loaded into the model. 2.6
A rst approach of mapping the BCF format to Linked Data can be seen in
[
bcfOWL
bcfOWL aims to lift BCF to the Linked Data domain and thereby enable the
format to be put in a larger context within the Linked Building Data, including
the BOT and ifcOWL ontology. The conversion should not just be a translation
of the BCF API or the BCF XML but speci cally tailored to the needs in a
Linked Data context. At the same time, compatibility with existing formats
should not be jeopardized. Therefore we considered guides, checkers, and best
practices to achieve this goal:
{ In [
The Projects are a core element of BCF responsible for assigning each Issue to a project, and thus a speci c building. The link to the Project in the BCF API happens via URL (Listing 1.1), where the Projects GUID is provided. In BCFXML, the Project is de ned per le and there is no further assignment to it. Since resources from bcfOWL are not queried via parameters in the URL, and a le-based approach is not the sole scope of our work, the link to the Project has to be provided in the classes of the Topics, Comments, and Viewpoints. (Listing 1.2) The Project itself links to the Extension Schema, described in the following section.
GET /bcf/3.0/projects/{project_id}/topics Listing 1.1. GET request to a BCF server. The Project is provided as parameter @prefix bcfOWL: <http://lbd.arch.rwth-aachen.de/bcfOWL/> . bcfOWL:Comment rdf:type owl:Class ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty bcfOWL:hasProject ; owl:cardinality "1"^^xsd:int ] , [...] .
Listing 1.2. The Project has to be provided for the Topics, Viewpoints, and Comments and therefore a cardinality of 1 is speci ed. 3.2
In the BCF context, the Extensions are used to create project-speci c parameters when inserting new Issues. In a Project, parameters such as Status, Labels, and Users are de ned in advance in the Extensions. With parameters such as Title or Comment, on the other hand, free texts are used. Especially with the BCF API, the correct parameters are controlled by the server during the upload since it only allows the parameters mapped in the Project's Extensions.
bcfOWL also provides the possibility to de ne these Extensions to be used in the Projects. However, since the allowed values can change from project to project, we provide only a generic and backwards-compatible way to de ne the property sets. The extension and validation mechanisms will be studied further in future work. 3.3
Same as in the Projects, the Topics, Comments, and Viewpoints need to be linked to each other to generate a complete Issue. In the BCF API, these links are primarily provided in the URL parameters. For example, the link of the Viewpoint to its Topic is only provided by the URL and is not part of the JSON schema. In the BCF XML, this link is provided by the Markup. In bcfOWL, these connections are provided in the respective classes of the Comments and Viewpoints as Object Properties, linking to the Topic. The Markup concept was discarded, thus reducing the complexity of the ontology. This is in line with BCF API, where it had been left out. 3.4
The transformation of an Issue is an integral part of the principles of the BCF.
It is described with a Camera View Point in a Cartesian coordinate system, a
Camera Direction, an Camera Up Vector for describing the rotation of the view
in the coordinate system, and an Aspect Ratio. Depending on if the camera is
described as an Orthogonal Camera or a Perspective Camera, a View to
WorldScale or a Field Of View has to be provided. The transformation of the camera
is described in the Viewpoint of an Issue. To express the vectors and points,
bcfOWL relies on the representation in well-known-text (WKT) as proposed
for the ifcOWL format in [
In BCF, most Issues are accompanied by a Snapshot from the source application to help understand the problem described since not all models are loaded in every software in which an Issue is considered. Thus, the problem cannot be veri ed without further context. In the BCF XML, the images are stored as PNG or JPEG in the sub-folder with the Markup. They are linked to the Viewpoint via an GUID. In the BCF API, when a new Snapshot is created, the image is passed in base64 format, included in a JSON. When requesting a Snapshot, the image is passed as a binary le from the BCF server. Since including images with base64 strings in RDF leads to extensive and slow graphs, the locations of the images are linked in bcfOWL by URI. For compatibility reasons, the URI is the same as in the BCF API approach and the up- and download of the Snapshots can be achieved by simple GET and POST requests. 4
By introducing BCF to OWL, we can now use this format with more advanced queries, where the user can specify what data should be fetched from a server. In this section, we provide an example use case for bcfOWL. The queries were tested with Apache Jena Fuseki. 4.1
While a request with the BCF API, for example, for a Topic, can be handled via a simple GET request (Listing 1.1), the same request in the SPARQL context is more extensive (Listing 1.3). However, this problem can be partially circumvented by using template functions to map the standard requests to the BCF server used in the REST API.
PREFIX bcfOWL: <http://lbd.arch.rwth-aachen.de/bcfOWL/> SELECT ?s ?p ?o WHERE { ?s a bcfOWL:Topic ;
?p ?o . }
Listing 1.3. Sample SPARQL query for getting Topics. 4.2
An important feature to bring building data closer together with BCF is to
query building elements to see if Issues related to them already exist. Software
applications such as Solibri discovered the need for such information and have
integrated a corresponding feature into their application. However, the feature
only supports a local (o ine) context and cannot align the Issues for the building
elements with the Issues stored on a server without downloading them rst.
Speci c queries like these are not possible with the current API, or only to a
limited extent, because the existing hierarchy requires all Issues on the server
to be searched rst to get the IDs of the building elements. [
PREFIX bcfOWL: <http://lbd.arch.rwth-aachen.de/bcfOWL/> SELECT ?topic WHERE { ?topic a bcfOWL:Topic . ?viewpoint a bcfOWL:Viewpoint ; bcfOWL:hasTopic ?topic ; bcfOWL:hasSelection ?selection . ?selection bcfOWL:hasComponent ?component .
?component bcfOWL:hasIfcGuid "1ZwJH$85D3YQG5AK5ER1Wc" .
} Listing 1.4. SPARQL example for querying Topics with a speci c GUID in the selection. 4.3 Referencing a Building Element in the Selection or the Visibility can either be achieved by a GUID, an Authoring Tool ID, or by linking an object (by a dereferenceable URL). The rst two options seem to be less in line with Semantic Web concepts but is helpful if the IFC and its elements do not exist in a Linked Data context. This ensures compatibility with a wide range of formats while linking with a Linked Data object is still possible.
inst:Element_1 a bcfOWL:Component; bcfOWL:hasIfcElement inst:BotElement_1; bcfOWL:hasIfcGuid "1zMXMGg3H1MOhxQ9qjUS4B" ; bcfOWL:hasAuthoringToolId "312213" ; bcfOWL:hasOriginatingSystem inst:ExampleCAD .
Listing 1.5. Components provide a link and/or the GUID of the element.
The examples show that bcfOWL can address use cases beyond the capabilities of the current BCF formats. It was demonstrated by the example of querying a graph database for building elements for which Issues exist. The connection to the building elements can be described with the ontologies of BOT and ifcOWL via URIs and a conventional IFC or native BIM model via GUID. bcfOWL can thus be integrated into existing work ows. Although individual parts have been excluded from bcfOWL , the underlying concepts remains the same. A conversion of bcfOWL data to BCF XML or BCF API is still applicable.
However, this extended functionality comes at the cost of using the SPARQL
language, which can be a hurdle for users and developers [
Since the concept of inverse relationships does not exist in BCF, it has not been incorporated into the ontology at this time. It should be discussed in the future whether the advantages of inverse relations justify a more complex ontology. 6
We have shown in this paper that a transformation of BCF into a Linked Data approach is viable and opens new possibilities for the format. While BCF XML and BCF API applications can actualize and interpret the indirect GUID references of a BIM model when the BIM models are loaded to the memory, the proposed Linked Data approach allows better integration. The new data format makes it easier to retrieve relevant issue data and attach and track provenance information over di erent life-cycle stages. Further, deeper analysis is left for future work. Using Linked Data, the BCF and BIM data models can be integrated into a shared knowledge graph, making it possible to harness the power of semantic queries, e.g. using a SPARQL engine. Spatial localization is achieved via the WKT format, but further emphasis needs to be placed on enabling and testing spatial queries. bcfOWL is by no means intended to replace the existing formats but merely to add further possibilities. A conceivable scenario would be to use bcfOWL as an internal data format for a BCF server, which can then be exposed via a SPARQL endpoint, and via an intermediary service using the BCF API. Thus the strengths and weaknesses of the respective formats could be balanced, and compatibility to already existing approaches could remain. The proposed method allows using Linked Building Data content like assertions that use ifcOWL or the BOT ontologies connected with or beside regular IFC and BIM models. The data can also be linked to available Linked Data sources.
When creating bcfOWL, we focused on the core functions necessary when
creating Issues within a building. Subjects such as handling and linking to and from
Documents and Files and user management were excluded from the bcfOWL
definition. Like bundling the di erent buildingSMART APIs, a Linked Data based
Open CDE infrastructure could also be applied here. First approaches to such
considerations can already be observed in [
Another starting point in conjunction with bcfOWL could be a connection to the Shapes Constraint Language14 (SHACL), which is used to validate RDF graphs. Since in the BCF context, Projects are provided with Extensions, and thus no parameters should be used in these Projects that do not appear in them, a SHACL implementation would be a potential complement to bcfOWL.
By introducing BCF into the Semantic Web, we hope that the application possibilities of the format will be extended. This includes increased possibilities to analyze BIM processes and harness the underlying data graphs to interlink and trace dependencies, provenance, and historical evolvement of Issues. We also see potentials in the interoperable interlinking of Issues with heterogeneous, nonIFC, and legacy information types for multi-model containers, e.g., the ICDD and OpenCDE-APIs. bcfOWL should enable synergies with other ontologies such as ifcOWL and the Building Topology Ontology and thus contribute to the goal of Linked Building Data. 7
This research had been funded by the EU through the H2020 project BIM4REN. 14 https://www.w3.org/TR/shacl/