ACADEMIA Letters
Open data or open access? The case of building data.
Nikos Sakkas, Apintech Ltd. Polis-21 Group
Sofia Yfanti, Hellenic Mediterranean University
1. Introduction
The world of the 4th Industrial Revolution is underpinned by sharing and collaboration approaches. More and more, these are entering the mainstream and gradually putting aside the
proprietary mindset and models of the past.
Openness is what essentially unlocks these massive new opportunities. Openness can relate to either the data itself or the access to it. In the following, we will review the subtle
balance between these two approaches and consider their respective advantages and disadvantages. Although the basic concepts may be applicable across many thematic areas, we will
focus here on the case of building data and the related efforts to provide for their openness.
What is then the key driver for open data? With more data available than ever before the
industry is presented with a new challenge (Dan Prairie et al., 2016). Device data is stored and
communicated in many different formats. It has inconsistent, non-standard naming conventions, and provides very limited descriptors to enable us to understand its meaning. Simply
put, the operational data from smart devices and equipment systems lacks information to describe its own meaning. As a result, data from today’s devices, while technically “available”,
is hard to use, thus limiting the ability for building operators to fully benefit from the value
contained in it. That is exactly where open data comes to our assistance.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
1
2. Open approaches for building data
To understand what open data means, it is useful to think of the web and the HTML standard.
An HTML document is self-explanatory to any browser. It “talks” a well-defined language
that any browser can decipher and understand. HTML is a common language and it is also a
publicly available language. These two conditions are what essentially define open data.
Similarly, an open model for building data would require the development of a common
language to describe building data and, of course, this common description would need to be
made publicly available for all building-related applications to use.
In appreciation of the benefits of openness, there is intense ongoing activity in the construction industry to provide such open models. Below, we briefly review three of these models, which we consider the most dominant, though far from the only ones.
Haystack (David Karger, 2005) uses a tagging system to capture the architecture of a BMS
(building management system). Using tags, Haystack maps physical objects to entities. These
entities can be abstractions for sites (buildings with addresses), pieces of equipment (e.g. an
HVAC unit), or single points (e.g. a temperature sensor). These (site, equipment, point) are
the three hierarchical tags used for entity definition within Haystack. After setting an entity tag
to an object, every other tag assigned defines an attribute of the entity or links it to a different
entity. Haystack can also capture relationships between sensors, pieces of equipment and sites;
however, it does not capture any spatial information.
Brick (Bharathan Balaji et al., 2018), much like Haystack, uses tags to capture the architecture of a BMS system. While Haystack-based representations usually consist of ad-hoc
collections of tags, leading to inconsistent modelling across sites, Brick tries to augment its
tags with semantic rules, promoting both interpretability and consistency. Brick enriches
tags with an underlying ontology, providing a framework to create the hierarchies and relationships necessary for describing building metadata. With an ontology, metadata can be
analysed using standard tools, and restrictions that prohibit arbitrary tag combinations can
be placed (e.g. temperature sensors’ units can be restricted to Fahrenheit and Celsius). The
concept of tagsets is introduced, which groups relevant tags in order to represent different
entities. With Haystack, entities are defined by their individual tags, so their properties and
relationships with other entities can only be specified at the tag level. With tagsets, we can
have a cohesive concept of, for example, a temperature sensor. Tagsets also support the introduction of hierarchies – a zone temperature sensor is a subclass of a generic temperature
sensor, and automatically inherits all of its properties.
Brick and Haystack include no geometry-related building information. They are essentially designed with a BMS and operational building data in mind, and not CAD-like building
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
2
design applications. If the data one needs to access includes these types of descriptions then
the only option is the BIM/ IFC protocol. BIM stands for Building Information Modelling.
Every BIM software has its own BIM implementation. So BIM cannot by itself be classified
as open data. This is where IFC (Industry Foundation Classes) comes in (Renato Vieira et al,
2020). IFC offers a platform-neutral format of the BIM files (that can be read and edited by
any BIM software). IFC is an open international standard (ISO 16739-1:2018) and promotes
vendor-neutral (or so-called agnostic) and usable capabilities across a wide range of devices
and software apps. Thus, IFC is truly about open data.
The following figure illustrates the typical applicability of these three key standards with
regard to the building lifecycle.
Figure 1: Building data standards applicability across the building lifecycle
It is also interesting to note that all the above standards are in a process of constant development and refinement. New extensions are constantly introduced and their adopters are
faced with an additional burden to follow and update their implementations. As an example,
our organisation looks forward to introducing to the Brick/ Haystack working committees the
concept of an “actionable” tag property, which defines whether the user has the ability to act
upon the underlying tag. For example, weather data is clearly and always non-actionable. Indoor temperature is typically actionable as one may act upon it via the thermostat settings;
if such action is, however, for any reason not possible then this data is again non-actionable.
This piece of information is key for XAI (interpretable AI) related investigations. Also, it is
the responsibility of the data to communicate this information and not the responsibility of
the app to infer it. Just as it is necessary for the data to communicate its unit of temperature,
whether it is Celsius or Fahrenheit. Hence, the need to model this property in the open data
model itself.
It is also noteworthy that there are more and more efforts to move beyond the current
fragmentation and converge to a common standard (Gabe Fierro et al. 2019), (Gabe Fierro et
al. 2020), something that would undoubtedly change the building data landscape and lead to
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
3
greater adoption rates by the industry.
3. What about open access?
If one implements one of the above open data approaches he has made a decisive step towards
making his data available to third-party apps that speak the language. However, is this the
only way to achieve this data sharing? In other words, is open access always equivalent to
open data?
The answer is no. Open data allows open access but open access does not necessarily
require open data. How, then, can closed and proprietary data allow open access?
Data owners can do so if they publish a data access API (application programming interface). This API will allow any third party to get hold of the data regardless of their internal
structure. Thus, with an open API the owner of the data can achieve the same goal: allow
access to her data, or equivalently share her data for the use of humans or third-party apps.
4. Which, then, is superior? Open data or open access?
Technically, the advantage lies by far with open data. Going back to our web paradigm at the
beginning, simple open access (with no open/ HTML data) would mean that you would have
to implement the file public API to understand what it is about. In other words, you would be
able to read the file, but it would be a nightmare having to implement proprietary APIs every
time to figure out what is inside. Clearly, the web would have no chance at all if built only on
open access and not open- HTML structured- data.
Alas, in the building industry things are vastly different. There are huge numbers of existing proprietary systems of all types that speak no standard language at all, and for which
there is no evidence that they will adopt any of the main standards any time soon. For this
vast proprietary ecosystem, providing for open data might be difficult or outright impossible.
In any case, it is far more difficult than turning a proprietary file into HTML. The above web
analogue has some conceptual value but can be very misleading if mechanically applied in a
building data scope. Open access, however, may still present a convenient opportunity. Developing a public API allowing access to your building data may be a viable option, perhaps
even the only viable option, for data sharing and collaboration with third-party apps. Thus,
we argue that open access is an important and promising approach in the domain of building
data, a sphere where it is not realistic to expect anything as pervasive as the HTML standard
to emerge in the foreseeable future.
What, then, is the best solution for the building domain?
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
4
As discussed above, in the building domain open data cannot be the sole approach towards
data sharing. Open, API-based access is also a necessary complement to allow virtually any
building-related proprietary data model to share its data, enabling it to enter the ecosystem of
shareable data and take advantage of the associated collaborative business models.
Of course, there is no reason why this open-access API should not also be compliant with
some of the discussed standards and benefit from both worlds: open data and open access.
Thus, to answer our key question, we would suggest that the best approach is a public
data-sharing API that is also Brick/ Haystack compliant for the BMS-like subdomain, and
BIM/ IFC for the CAD-like subdomain.
5. Ongoing work
We are currently in the process of developing an open building data access API that closely
follows the Brick/ Haystack tagsets. This API is offered as part of a broader data sharing platform (https://ds.leiminte.com) (Nikos Sakkas) that could allow any data provider to publish
their building metadata and real-time data (sensor data), as well as allowing any third-party
app to get hold of data on the platform and use them to deliver its functionality. We are carrying out this work in the course of the HORIZON Programme TRUST AI project, in order
to link our proprietary BMS data to an XAI (interpretable AI) software suite that we are also
building in this project. The development has been inspired by a similar collaborative effort
in the past (Pierre Bourreau et al., 2019). The following figure illustrates the concept:
Figure 2: Architecture for a standard compliant, open access and data sharing platform
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
5
This environment can support true collaboration. Figure 3 illustrates the concept. Although the environment was constructed to link a BMS with an XAI framework (dotted lines),
its open access architecture allows any data provider to publish data and any app to read data
(continuous lines).
Figure 3: Many to many collaboration
Such an open data, open access and standard data sharing platform may have an important
public value. A BMS service provider, like us, is rather ill-suited, if not in a conflict of interest,
to harness this benefit by himself. More democratic governance is needed and to this end, we
take the opportunity here to send out an invitation to public domain entities (universities,
research centres, etc.) to join forces for the administration of such a state-of-the-art building
data-sharing platform.
6. Conclusion
Although we fully acknowledge the need for open data we still have to live with the reality
of millions of systems out there that will not adopt such emerging standards. An open-access
platform like the one briefly sketched in this work would allow such systems to share their
data and make it accessible to third-party apps. If this platform is built on open standards
such as those discussed here, the benefits of both worlds, open data and open access, can then
be simultaneously enjoyed.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
6
7. Acknowledgements
The work presented in this paper is funded by the European Commission within the HORIZON Programme (TRUST AI Project, Contract No. 952060).
References
1. Dan Prairie et al. 2016, “Project Haystack, A CABA white paper”, www.caba.org.
2. David Karger. 2005, “Haystack: A customizable general-purpose information management tool for end users of semistructured data”, 2005, Proc. of the CIDR Conference.
3. Bharathan Balaji et al. 2018, “Brick: Metadata schema for portable smart building applications”, Applied Energy, Volume 226, 1273–1292. https://doi.org/10.1016/j.apenergy.
2018.02.091.
4. Renato Vieira et al. 2020, “Supporting building automation systems in BIM/IFC: reviewing the existing information gap”, Engineering, Construction and Architectural
Management, Vol. 27 No. 6, pp. 1357–1375. https://doi.org/10.1108/ECAM-07-20180294.
5. Gabe Fierro et al. 2019, “Beyond a House of Sticks: Formalizing Metadata Tags with
Brick”, BuildSys ’19, November 13–14, 2019, New York, NY, USA.
6. Gabe Fierro et al. 2020, “Shepherding Metadata Through the Building Lifecycle”,
BuildSys ’20, November 18–20, 2020, Virtual Event, Japan.
7. Nikos Sakkas et al. 2021, “Real time Data and Application Sharing and Collaboration
for the Building Energy Domain”, World Digital Built Environment Conference, 2021.
https://wdbe2021.exordo.com/programme/presentation/3.
8. Pierre Bourreau et al. 2019, “BEMServer: An Open Source Platform for Building Energy Performance Management”, Conference: EC3 – European Conference on Computing in Construction https://doi.org/10.35490/EC3.2019.176.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
7
ACADEMIA Letters
Open data or open access? The case of building data.
Nikos Sakkas, Apintech Ltd. Polis-21 Group
Sofia Yfanti, Hellenic Mediterranean University
1. Introduction
The world of the 4th Industrial Revolution is underpinned by sharing and collaboration approaches. More and more, these are entering the mainstream and gradually putting aside the
proprietary mindset and models of the past.
Openness is what essentially unlocks these massive new opportunities. Openness can relate to either the data itself or the access to it. In the following, we will review the subtle
balance between these two approaches and consider their respective advantages and disadvantages. Although the basic concepts may be applicable across many thematic areas, we will
focus here on the case of building data and the related efforts to provide for their openness.
What is then the key driver for open data? With more data available than ever before the
industry is presented with a new challenge (Dan Prairie et al., 2016). Device data is stored and
communicated in many different formats. It has inconsistent, non-standard naming conventions, and provides very limited descriptors to enable us to understand its meaning. Simply
put, the operational data from smart devices and equipment systems lacks information to describe its own meaning. As a result, data from today’s devices, while technically “available”,
is hard to use, thus limiting the ability for building operators to fully benefit from the value
contained in it. That is exactly where open data comes to our assistance.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
1
2. Open approaches for building data
To understand what open data means, it is useful to think of the web and the HTML standard.
An HTML document is self-explanatory to any browser. It “talks” a well-defined language
that any browser can decipher and understand. HTML is a common language and it is also a
publicly available language. These two conditions are what essentially define open data.
Similarly, an open model for building data would require the development of a common
language to describe building data and, of course, this common description would need to be
made publicly available for all building-related applications to use.
In appreciation of the benefits of openness, there is intense ongoing activity in the construction industry to provide such open models. Below, we briefly review three of these models, which we consider the most dominant, though far from the only ones.
Haystack (David Karger, 2005) uses a tagging system to capture the architecture of a BMS
(building management system). Using tags, Haystack maps physical objects to entities. These
entities can be abstractions for sites (buildings with addresses), pieces of equipment (e.g. an
HVAC unit), or single points (e.g. a temperature sensor). These (site, equipment, point) are
the three hierarchical tags used for entity definition within Haystack. After setting an entity tag
to an object, every other tag assigned defines an attribute of the entity or links it to a different
entity. Haystack can also capture relationships between sensors, pieces of equipment and sites;
however, it does not capture any spatial information.
Brick (Bharathan Balaji et al., 2018), much like Haystack, uses tags to capture the architecture of a BMS system. While Haystack-based representations usually consist of ad-hoc
collections of tags, leading to inconsistent modelling across sites, Brick tries to augment its
tags with semantic rules, promoting both interpretability and consistency. Brick enriches
tags with an underlying ontology, providing a framework to create the hierarchies and relationships necessary for describing building metadata. With an ontology, metadata can be
analysed using standard tools, and restrictions that prohibit arbitrary tag combinations can
be placed (e.g. temperature sensors’ units can be restricted to Fahrenheit and Celsius). The
concept of tagsets is introduced, which groups relevant tags in order to represent different
entities. With Haystack, entities are defined by their individual tags, so their properties and
relationships with other entities can only be specified at the tag level. With tagsets, we can
have a cohesive concept of, for example, a temperature sensor. Tagsets also support the introduction of hierarchies – a zone temperature sensor is a subclass of a generic temperature
sensor, and automatically inherits all of its properties.
Brick and Haystack include no geometry-related building information. They are essentially designed with a BMS and operational building data in mind, and not CAD-like building
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
2
design applications. If the data one needs to access includes these types of descriptions then
the only option is the BIM/ IFC protocol. BIM stands for Building Information Modelling.
Every BIM software has its own BIM implementation. So BIM cannot by itself be classified
as open data. This is where IFC (Industry Foundation Classes) comes in (Renato Vieira et al,
2020). IFC offers a platform-neutral format of the BIM files (that can be read and edited by
any BIM software). IFC is an open international standard (ISO 16739-1:2018) and promotes
vendor-neutral (or so-called agnostic) and usable capabilities across a wide range of devices
and software apps. Thus, IFC is truly about open data.
The following figure illustrates the typical applicability of these three key standards with
regard to the building lifecycle.
Figure 1: Building data standards applicability across the building lifecycle
It is also interesting to note that all the above standards are in a process of constant development and refinement. New extensions are constantly introduced and their adopters are
faced with an additional burden to follow and update their implementations. As an example,
our organisation looks forward to introducing to the Brick/ Haystack working committees the
concept of an “actionable” tag property, which defines whether the user has the ability to act
upon the underlying tag. For example, weather data is clearly and always non-actionable. Indoor temperature is typically actionable as one may act upon it via the thermostat settings;
if such action is, however, for any reason not possible then this data is again non-actionable.
This piece of information is key for XAI (interpretable AI) related investigations. Also, it is
the responsibility of the data to communicate this information and not the responsibility of
the app to infer it. Just as it is necessary for the data to communicate its unit of temperature,
whether it is Celsius or Fahrenheit. Hence, the need to model this property in the open data
model itself.
It is also noteworthy that there are more and more efforts to move beyond the current
fragmentation and converge to a common standard (Gabe Fierro et al. 2019), (Gabe Fierro et
al. 2020), something that would undoubtedly change the building data landscape and lead to
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
3
greater adoption rates by the industry.
3. What about open access?
If one implements one of the above open data approaches he has made a decisive step towards
making his data available to third-party apps that speak the language. However, is this the
only way to achieve this data sharing? In other words, is open access always equivalent to
open data?
The answer is no. Open data allows open access but open access does not necessarily
require open data. How, then, can closed and proprietary data allow open access?
Data owners can do so if they publish a data access API (application programming interface). This API will allow any third party to get hold of the data regardless of their internal
structure. Thus, with an open API the owner of the data can achieve the same goal: allow
access to her data, or equivalently share her data for the use of humans or third-party apps.
4. Which, then, is superior? Open data or open access?
Technically, the advantage lies by far with open data. Going back to our web paradigm at the
beginning, simple open access (with no open/ HTML data) would mean that you would have
to implement the file public API to understand what it is about. In other words, you would be
able to read the file, but it would be a nightmare having to implement proprietary APIs every
time to figure out what is inside. Clearly, the web would have no chance at all if built only on
open access and not open- HTML structured- data.
Alas, in the building industry things are vastly different. There are huge numbers of existing proprietary systems of all types that speak no standard language at all, and for which
there is no evidence that they will adopt any of the main standards any time soon. For this
vast proprietary ecosystem, providing for open data might be difficult or outright impossible.
In any case, it is far more difficult than turning a proprietary file into HTML. The above web
analogue has some conceptual value but can be very misleading if mechanically applied in a
building data scope. Open access, however, may still present a convenient opportunity. Developing a public API allowing access to your building data may be a viable option, perhaps
even the only viable option, for data sharing and collaboration with third-party apps. Thus,
we argue that open access is an important and promising approach in the domain of building
data, a sphere where it is not realistic to expect anything as pervasive as the HTML standard
to emerge in the foreseeable future.
What, then, is the best solution for the building domain?
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
4
As discussed above, in the building domain open data cannot be the sole approach towards
data sharing. Open, API-based access is also a necessary complement to allow virtually any
building-related proprietary data model to share its data, enabling it to enter the ecosystem of
shareable data and take advantage of the associated collaborative business models.
Of course, there is no reason why this open-access API should not also be compliant with
some of the discussed standards and benefit from both worlds: open data and open access.
Thus, to answer our key question, we would suggest that the best approach is a public
data-sharing API that is also Brick/ Haystack compliant for the BMS-like subdomain, and
BIM/ IFC for the CAD-like subdomain.
5. Ongoing work
We are currently in the process of developing an open building data access API that closely
follows the Brick/ Haystack tagsets. This API is offered as part of a broader data sharing platform (https://ds.leiminte.com) (Nikos Sakkas) that could allow any data provider to publish
their building metadata and real-time data (sensor data), as well as allowing any third-party
app to get hold of data on the platform and use them to deliver its functionality. We are carrying out this work in the course of the HORIZON Programme TRUST AI project, in order
to link our proprietary BMS data to an XAI (interpretable AI) software suite that we are also
building in this project. The development has been inspired by a similar collaborative effort
in the past (Pierre Bourreau et al., 2019). The following figure illustrates the concept:
Figure 2: Architecture for a standard compliant, open access and data sharing platform
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
5
This environment can support true collaboration. Figure 3 illustrates the concept. Although the environment was constructed to link a BMS with an XAI framework (dotted lines),
its open access architecture allows any data provider to publish data and any app to read data
(continuous lines).
Figure 3: Many to many collaboration
Such an open data, open access and standard data sharing platform may have an important
public value. A BMS service provider, like us, is rather ill-suited, if not in a conflict of interest,
to harness this benefit by himself. More democratic governance is needed and to this end, we
take the opportunity here to send out an invitation to public domain entities (universities,
research centres, etc.) to join forces for the administration of such a state-of-the-art building
data-sharing platform.
6. Conclusion
Although we fully acknowledge the need for open data we still have to live with the reality
of millions of systems out there that will not adopt such emerging standards. An open-access
platform like the one briefly sketched in this work would allow such systems to share their
data and make it accessible to third-party apps. If this platform is built on open standards
such as those discussed here, the benefits of both worlds, open data and open access, can then
be simultaneously enjoyed.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
6
7. Acknowledgements
The work presented in this paper is funded by the European Commission within the HORIZON Programme (TRUST AI Project, Contract No. 952060).
References
1. Dan Prairie et al. 2016, “Project Haystack, A CABA white paper”, www.caba.org.
2. David Karger. 2005, “Haystack: A customizable general-purpose information management tool for end users of semistructured data”, 2005, Proc. of the CIDR Conference.
3. Bharathan Balaji et al. 2018, “Brick: Metadata schema for portable smart building applications”, Applied Energy, Volume 226, 1273–1292. https://doi.org/10.1016/j.apenergy.
2018.02.091.
4. Renato Vieira et al. 2020, “Supporting building automation systems in BIM/IFC: reviewing the existing information gap”, Engineering, Construction and Architectural
Management, Vol. 27 No. 6, pp. 1357–1375. https://doi.org/10.1108/ECAM-07-20180294.
5. Gabe Fierro et al. 2019, “Beyond a House of Sticks: Formalizing Metadata Tags with
Brick”, BuildSys ’19, November 13–14, 2019, New York, NY, USA.
6. Gabe Fierro et al. 2020, “Shepherding Metadata Through the Building Lifecycle”,
BuildSys ’20, November 18–20, 2020, Virtual Event, Japan.
7. Nikos Sakkas et al. 2021, “Real time Data and Application Sharing and Collaboration
for the Building Energy Domain”, World Digital Built Environment Conference, 2021.
https://wdbe2021.exordo.com/programme/presentation/3.
8. Pierre Bourreau et al. 2019, “BEMServer: An Open Source Platform for Building Energy Performance Management”, Conference: EC3 – European Conference on Computing in Construction https://doi.org/10.35490/EC3.2019.176.
Academia Letters, October 2021
©2021 by the authors — Open Access — Distributed under CC BY 4.0
Corresponding Author: Nikos Sakkas, sakkas@apintech.com
Citation: Sakkas, N., Yfanti, S. (2021). Open data or open access? The case of building data. Academia Letters,
Article 3629. https://doi.org/10.20935/AL3629.
7