In our Podcast series “Sh*t You Wish Your Building Did!”, Memoori explores the intersection between technology and commercial real estate through interesting conversations.

In Episode #22 of our Podcast, we sat down with Gabe Fierro, Assistant Professor at the Colorado School of Mines and Co-Founder of the Brick Schema for a free-ranging discussion about how different Metadata Schemas are converging to model buildings!

We covered how different metadata schemas like Brick Schema and Project Haystack complement rather than compete with one another. Common misconceptions about Open Metadata Schemas. When to use them? And how to actually use these RDF models in practice!

Don’t forget you can now Subscribe to ALL our Podcasts on Soundcloud, iTunes, YouTube and now Spotify!

Transcript of ‘How Different Metadata Schemas are Converging to Model Buildings!’

James: Gabe Fierro, Professor at the Colorado School of Mines and co-creator of the brick schema welcome to the podcast thanks so much for having me yeah real pleasure to uh to for you to come on and talk about uh your work uh which I find fascinating so I’m sure it’s going to be a really interesting conversation I thought maybe we could start with I think generally you know and I’ll put a description in the show notes but we most people I imagine know or have heard of brick but perhaps you could just bring us up to speed on you know where the project is now and um what you guys are working on at the moment.

Gabe: yeah absolutely so we uh as a collaboration of researchers and uh from Academia industry started brick in 2016 I guess we technically had the first conversations in 2015 with the intent of how do you model a building for the intent of making data easier to find so that you can go and write sort of data-driven applications um in terms of where we are now um we’re we’re getting to the point where we’re pretty confident in uh the design that the the design is sound and we’re um currently in the process of making sure that brick works well with the other prevailing digital representations for for buildings um it was never our goal to sort of eat the world right be the one true representation of all metadata in buildings and as our understanding of and as the landscape of of other metadata Solutions and other sort of digital representations of the buildings expands we see our role as trying to uh make sure we can be a bridge between both sort of higher level user-facing representations uh maybe emerging lower level representations things like ashrae 223p um and be a a structured representation that makes it easier to write certain kinds of code one of the things that’s become sort of clear is it’s brick and the world of what we would call sort of graph oriented or rdf metadata is not necessarily what you would want to give to any engineer or to any developer or any property owner but it is in our opinion a a very good basis for establishing what those user-oriented abstractions might be and I think if I were to try and yeah to summarize the two directions before it gets integration with existing uh standards exist existing in emerging standards um and then making sure that we’re continuing to support data-driven applications uh in a way that is is best fulfilled by the current design.

James: I think the main reason that I asked you to come on today was to talk about how you see some of these different metadata models coming together and you’ve talked about um I think this uh complementing right rather than competing um metadata models right rather than them being distinct now we they I’ve been working more together.

Gabe: yeah so one of the I think one of the pieces that first emerged for us um was when we when brick was created you know the the prevailing uh solution this space was was Project haystack uh which at the time was really more of a sort of tag dictionary rather than the more elaborated data model that’s sort of grown to be in in recent years so version one of brick you could very much see as oh it was providing a a name to a set of tags that everyone could agree on um over in uh and then we kind of got away from that a little bit and leaned more into the graph oriented nature of that but I would say the first uh major step we took towards realizing hey maybe we should be working better with with other metadata Solutions was the immersions of real estate core um focused more on spatial elements on property management you know asset management and what we sort of found was you know our scope of starting from HVAC equipment and points onto equipment and we started to have to model more spatial stuff more of the asset management and then real estate core was starting from modeling spaces and property and over time they were modeling more equipment and more points and data sources and so we had both well-established domains and that we were slowly leaking into each other’s Solutions and we started borrowing from each other’s Solutions we were using some of their concepts for locations they were using some of our concepts for equipment and at some point I think they reached out to us and we said why why are we duplicating this effort uh can we instead because we’re both using this the same graph standard for writing down these these metadata ontologies can we instead just make sure that anytime brick needs to refer to a location it refers to a real estate core location and every time real estate court needs to refer to equip enter data refers to Brick equipment or data Concepts and so what sort of became clear was we could each continue to develop our sort of core competency without and make it as much use of a of a good solution that we didn’t have to then manage and then the communication was all about how do you make sure that when someone has a modeling task or someone has a question they want to ask of their metadata representation of a building that it’s clear what representation they they go to to find that information right just like you you know when you want to ask a question about something you know you maybe you go to a certain website for these kinds of questions you go to another website for these kinds of questions or a different area of the library right those those kinds of of metaphors um and so that was that was probably the first one where we tried to clearly articulate the boundaries between metadata schemas um and that’s one form of that which is subdividing a very large domain buildings into smaller pieces that can be well modeled um and it’s one of these fundamental trade-offs that the the bigger of a subject area you try to model the more generic you have to be the less specific you can be uh and so we’ve we’ve tried to find what you might call the knee point between sort of complexity and usability in terms of how much of a domain we cover and how we approach the the modeling of that of that domain um as as newer uh so ashrae 223p is the other is the other big one in the space um and that’s why I’m here in Tampa to talk about asteroid 223p um it’s it’s a much longer story in terms of how 223p Works in this space but essentially um we think of it as maybe the Lego blocks or the the the atoms the building blocks underneath higher level representations uh two to three e may not you know have a I think in Brick we’ve got eight or nine hundred different classes of equipment and points and things like that uh ashrae 223p will probably not have that it’ll be a much shallower hierarchy but it will name the building blocks from which I could go and construct any weird vrf system or any weird chiller plant or anything that I that I want to do and something like Bricker realistic core can exist on top of that as a way of mapping very detailed information simplifying it into something that’s more maybe accessible to to a human or to a programmer the other big integration that we’ve been working on is with project Haystack with the launch of the the Zito type system that Brian Frank uh mentioned in the the latest Haystack connect there’s now an opportunity for uh for us to provide sort of well-structured translations between a haysec model and a brick or real estate core model and so one of the things I’m actually demonstrating at ashrae today is the ability to go from this very detailed ashrae 223p model generate the brick and real estate core model in the middle and then generate a haystack model on top and so you’ve got the same building modeled at multiple levels of abstraction and then this way rather than competing in terms of who whose job it is to model the whole building now it’s a question of depending on the job you want to do or the the question you want to ask I might reach for a different representation and the programs that we’ve been developing the fact that we’re building all of these on these graph standards means that we can ensure that they’re all kept up to date with one another.

James: Right because underlying all of this and you’ve referred to it at these graph standards which are you know web3 um compliant like they’re they’re standard across the IT industry and that’s I guess a huge Advantage right because it means that for example integrating or making brick and real estate core work together was a lot easier.

Gabe: Yes I mean these are actually standards that go back to the original version of the internet from Tim berners-lee um that any resource would have any online resource like a page would have structured information about what the content was how it related to other pieces of content and what we’ve done is even though his vision of the web hasn’t quite come into fruition and as he imagined it right in this what UI called the semantic web in the early version of this sure the ability to link information together in this very flexible and dynamic way has proven really powerful um and also there’s a ton of software that’s already out there that we can use to store that and manipulate this data so we don’t have to go and create all of that from scratch we can just lean into an existing ecosystem which has been very very helpful.

James: There’s levels of abstraction you talked about are really important as well right because I suppose and use it people doing different jobs need different information different data at specific times and allowing that is important right otherwise it becomes I guess confusing for people and ultimately not useful.

Gabe: Oh yeah I mean the like the example that I that I go to is uh if I want to get a list of vavs in my building it’s hard to get easier than just typing the VAV tag into the haystack um the axon search bar right at the top of that of the sky spark interface I type VAV and I get a list of my vavs that’s very convenient that’s very easy if I you know maybe for some fault detection application or if I’m creating a detailed model or a simulation of a building I might have a differential pressure sensor in Brick you know in Brick and Haystack I can both say well where is that differential pressure sensor in terms of what equipment is the differential pressure sensor about but if I want to figure out where exactly is it measuring differential pressure right it’s got two two of those leads and it’s going to measure the pressure between those and calculate the differential um or measure the differential where exactly are those leads that’s a level of detail and precision that’s that’s much harder for Brick and Haystack to to model um so there’s a lot more of the building you need to be able to express and that’s exactly what something like 223p is designed to provide.

James: Yeah so how would you recommend that people should plan for this or at least you know it’s this new direction of of metadata models coming together what is it what does it mean do you think on a you know on a day-to-day level for for people working with data.

Gabe: That’s a great question I would say two things um one is hopefully this helps engender a culture of holding on to a lot of the existing data this has been one of our primary struggles is a lot of the things we’re now seeking to model were known at some point um but due to handoffs or just the way that information moves through these sort of exchanges from firm to firm over the life cycle of a building things get lost or they they don’t get maintained and so we we are still actively working with standards like IFC right or trying to integrate with software like Revit to make sure that in places where brick Haystack 223p don’t Excel something like modeling geometry we can point to a model that’s good at that right that our tools already exist we don’t have to solve that problem all we have to do is link into that and so by making sure that there’s still utility and using that data hopefully this helps in you know uh keep your IFC models keep your Revit models um because it will help you to create your 223p your brick your Haystack real estate corn will help you create those models in terms of the other way of how you might think about this we’ve been um undertaking a series of projects and integrating semantic metadata into existing bms’s or exist with existing data Management Solutions things like um you know like Niagara things like uh Pi soft where you can think of metadata almost as a layer on top of an existing data solution so if you already have a data historian if you already have a message bus that’s that’s that’s transmitting data between pieces what’s something like two to three p brick can do is they can exist in a separate metadata database alongside your existing data solution and anytime you have software that needs to discover data or needs to know how a piece of data relates to other things in your building or other data sources it can go and query the metadata store that contains all of that information to ask for hey what are all the points on this equipment or you know what’s the what’s the Upstream temperature of of this piece of equipment or where are all the meters that the sub meters on this floor or you know whatever that question happens to be um and that’s right now we’re trying not to be too opinionated about what it looks like to adopt that um but this is I mean we’re we’re very very open right a lot of this is I’m coming at this from the academic perspective I have a set of principles from things that I think work um we do have open working groups so anytime someone has a question about how does this work or how do I integrate this we’re always happy to to engage um because our goal is not to tell you tell people what to do but we want to figure out what works for for people and and sometimes you have to assert the wrong answer in order for someone to tell you what the right one is um but currently it’s it’s a um you could think of it as a store that’s maybe parallel to your existing data solution that layers the semantics on top of um whatever you currently happen to be using.

James: Okay of course I think that’s um a pretty good segue actually because one thing I wanted to ask you was about like you know Common misconceptions that you think about uh metadata schemas I suppose like where they should be used and and how they should be used I feel like sometimes there is a disconnect between you know the let’s say the the academic View and the and the data view as opposed to the building owner building FM view.

Gabe: Well I think the the high order bit is the no matter what you might read about these so-called ontology Wars um anyone who’s actually working on any of these metadata projects really does believe and really is actively working towards bringing them together um not necessarily to A single standard if that’s a capital S standard or lowercase s standard um but at least making sure they work together and that there’s a clear path for for them to complement one another so that’s something we’re all working on the two to three p folks real estate core project Haystack Brick we’re all actively working towards that sort of unified Vision um in terms of the misconceptions um I think one of the the main ones is oftentimes brick and Haystack get get compared um and in terms of usability haystack is is absolutely the winner there right it is it’s designed to be accessible by by facility managers whereas brick is coming it like we have this whole alphabet soup if it’s oh it’s rdf and it’s Sparkle and it’s shackle and all of these these existing I mean they’re existing standards but they’re not necessarily something you would learn uh if you’re learning programming right or you’re learning Information Technology this stuff doesn’t usually get brought up um and so maybe the misconception is that this rdf stuff that graph stuff should be is what should be used by facilities managers and building managers um it is a very uh sort of persnickety low level representation um and it is difficult to it can be difficult to express questions against that and learn the query languages so are our intent and the things that we’re actively working on is how do we make that more usable uh I don’t think it’s it’s you can think of brick in 223p almost as the assembly languages right it’s writing C code or assembly code um where you do have to be very specific right if you make a mistake the computer thinks that mistake was was deliberate and sometimes your your program crashes but um you do need that representation in order to facilitate something that is easier to use your pythons your javascripts your typescripts your basic maybe even as a programming language metaphor um so we yeah I think that’s that’s misconception that that Rick should be used directly by these people um if you want to learn we’re helping we’re happy to teach you sure we think there’s there’s definitely room for better abstractions on top of that and a lot of these you know these smaller analytics firms that have been exploring the use of brick they’ve been doing that they’ve been finding their own ways of of working with that metadata and Haystack and the sky spark and that that industry of products is a great example of the kinds of higher level user-facing user-friendly interfaces that you could provide um and in our vision brick is one way of translating sort of very detailed low-level data from something like 223p into a haystack model directly so you can always derive the high level representation because the value I mean certainly from like the building owner or the operator perspective the value might be much higher up yeah what what you need what it’s doing is is working at the low level so I mean it could be just provided as part of some software that you that you purchase to do a specific job but like it’s still extremely important to have that metadata.

James: Yeah exactly right and I think one thing as well I’ve um when I’ve mentioned it to people as well is like understanding the Practical applications of it and I think as you said like perhaps It suffers a little bit from some of these uh quite technical computer science terms but you know to put it in sort of more straightforward language like what do you see as the value to a building owner operator of of using brick real estate core project haystack.

Gabe: I think it reduces integration effort by not just making sure that the configuration information the information you would need to configure software is available but also available in a structured and consistent way um which means that there’s less reading binders of what’s there inside the building and the point abbreviations it’s less clicking around in BMS interfaces designed to give you the operational state of the building not designed to tell you how the building is put together and how the subsystems work um it gets us closer to this Vision where uh software if that’s fault detection rules if that’s control sequences can be Auto commissioning um because the software is able to perform what we would call introspection on the building what’s there how’s it put together what sensors did you install what actuators did you install how are those presented in the BMS now I know what control sequence is the most suitable I know the fault detection rules that I can run and because everything is labeled consistently it there’s less human effort required in sort of wiring those those things together right so ideally this is fewer truck rolls right it’s fewer um it’s fewer hours spent by Engineers or facility managers working together to make sure that everything’s hooked up at some level you could think of you know what does structured metadata provide is uh something close to the red squiggly line that you get underneath grammatically incorrect sentence in Microsoft Word right like there is an understanding of grammar behind that there’s an understanding of rules of what can be expressed the valid ways of expressing it and the system helps you as the user make sure you’re doing things in a way that is communicating clearly and consistent and consistently um I think we it’s still emerging what the the tooling and the workflow is that helps these models be created but our goal is to understand better the existing workflows of people that are doing commissioning of the BMS that are installing and configuring software and maybe with a few tweaks to that right if you’re already running writing down a name if you change the name slightly or you’ve got a tool that helps you choose from an existing [Music] existing set of terms whatever that happens to be maybe with a few tweaks we can make it much easier to generate and maintain this this metadata and it becomes basically part of the interface of your of your building right in the same way that my my laptop has USB ports and it’s got an audio jack and as long as the connector looks the right way I know I can plug in a piece of completing a mouse or a keyboard or I know I can run word or Chrome or whatever that is I don’t have to worry too much about what kind of CPU I have or what kind of memory or what kind of hard drive is actually installed in the computer generally speaking the computer just figures it out because at some level people had a conversation about what’s the interface between the stuff that’s user facing and the stuff that’s underneath that actually helps this stuff.

James: Great point I think my final question to you as well is sort of look the role as well of soft the vendors software vendors because I think you know actually in terms of like from the metadata perspective like they have quite an important important role um do you think that are you seeing like that there are emerging roles for new startups or companies to take advantage of um or you know um what what does the landscape look like to you.

Gabe: Sure I mean I should preface this with I I’ve I’ve never had a real job right I’ve just existed I’ve just existed in in Academia um and so I would encourage people to come definitely you know send me an email come talk to us um this this entire effort from day one brick has been driven from not this we’ve really tried to avoid the sort of the Ivory Tower perspective that we know best and we’re going to tell you all how to do it it’s really been driven day one from what are the things that people actually need to do and if there’s anything wrong it’s in how we’ve been perceiving what that what that is um can you repeat your question.

James: You know just about how um the roles uh that might be fulfilled by emerging vendors.

Gabe: Yeah that’s right yes sorry so I think it’s a couple things one is we’re hoping for ever a version of this industry where the the data model is not a competitive Advantage necessarily right getting people into a particular ecosystem of how things are described is not what differentiates I think it’s I think a lot of emerging firms analytic firms really want to compete on the quality of their analytics they want to compete on the quality of their rules the quality of their of their controls and their models and so having structured metadata already there in the building reduces the onboarding time for them to get their product in there and for them to demonstrate value right you there’s there’s less this extensive onboarding process of this integration process of like well how did what what did you buy what’s in there how is that described now we have to map that into our system and if you look at many of the the early players in the in that sort of building analytics space that was exactly what they were doing right they have their own internal model that they need they needed to develop in order to actually go and get things done um and I think as we can if we come together as an industry right we almost democratize access to that kind of data and make it much much easier for firms to compete on the quality of the value the quality and value delivered to the customer rather than how quickly they can they can get into a a building right that’s not necessarily the best use of your engineers time right they’re they’re they’re uh you hired them for for other reasons rather than just hooking up you know what does ABC mean in this in this building um so I’d say I’d say it’s it’s it’s that right in the in the way that um all of my my metaphors are computer related so like you look at the early days of of the internet right being able to lift the abstraction using the Internet Protocol to the point where basically anyone could talk to anyone right these Network effects of available information and available resources you were able to abstract away the differences between you know how these internal networks worked in the same way that we might be able to abstract away some of the differences of how it is you talk to to different buildings and how equipment and points are described um that you you know in these future firms you may not have you maybe you might have one sort of metadata person right that really knows the details of these of these models and how to get that working um and the rest of everyone else is is is sitting on top of python or JavaScript or some high level representation that’s much easier to get the actual work done um rather than having to know every single detail all the way all the way down the stack.

James: Yeah that’s a great point Gabe thank you so much for your time uh I’ll make sure we put a link to some of the projects we discussed so I’ll put um break project Haystack ashrae 223p and real estate core I’ll put all the links to that in the show notes but um yeah and I guess as you mentioned you know you’re happy for people to to reach out if they want to ask questions or yes I will ask brick schema related questions cool thanks again for your time.