Hey friends,
Today, we're continuing our series on Nexus Lore: the core concepts that come up again and again in this newsletter, on the Nexus podcast, in the Nexus Foundations course, in Nexus Pro gatherings, and in the community chatroom.
If you want to start at the beginning, check out our white paper with all 10 parts: Nexus Lore.
Lore is never written by one person, so send us your feedback for v2!
Let's jump into Part 7, our nerdiest building block...
Let's pause our exploration of each horizontal layer and zoom in on one key part of the Independent Data Layer: the Data Model.
In order for our applications (which we'll cover next week!) to do their thing, they're going to need context.
The applications need a way to understand all the data they're consuming, including all the underlying devices and how they fit together into a system of systems. As an example, the diagram below shows just two siloed systems (HVAC and lighting) and just two rooms of a building.
See how all these devices, rooms, zones, and systems overlap with each other? Both the lighting circuit and the AHU and the VAV all “serve” room 101. The AHU and the VAV also serve room 102, which has the thermostat and the CO2 sensor that control the operation of the system.
Any application that uses HVAC data will need to know these facts—so how do we communicate those concepts in a standardized way? In most buildings today, we don't. All the silos and teams of humans represent these concepts differently.
Take naming for example: The architect might call it Room 101; it’s in the CMMS as Room_101; the BAS doesn’t even have a concept of rooms; the lighting controller calls it Zone-1 (and every controller has a Zone-1); the ACS calls it a 'Conf room'; the tenant calls it the Zeus conference room because they’ve named all their rooms after Greek gods. Crazy, right?! And naming is just one aspect of data modeling!
The key detail here is machine-readability. Most of the time we humans can infer that it's the same room, but a computer would see them as distinct concepts unless programmed otherwise. The migration to more interoperable systems comes with more machine-to-machine communication—which requires data to be understood by a computer natively. If a common data model doesn’t exist, then us humans need to map disparate data models to each other for two systems to work together.
And trust me (since I've done it): mapping is time-consuming, mind-numbing, and costly.
This is where standards come in. Using a standard ontology—like Project Haystack, Brick Schema, or Google's Digital Buildings Ontology—minimizes mapping and ensures the data model is ready for any application. However, although Project Haystack (the original) has been around for over 10 years, we're still in the early days of our industry's data modeling standards development process.
Here's a quick snapshot of where we're at today:
Given that, should each building owner just give up and do their own thing? I don't think so...
While the status quo is messy, the north star is to start with an existing standard and continue to adapt your data modeling methods (and your IDL) as the standards evolve. That way, you're not expecting the rest of the industry to adapt to your new standard...
Do you agree? What did I miss?
Let us know on LinkedIn,
—James Dice, Founder of Nexus Labs
P.S. Nexus Pro members can go deeper by checking out last year's panel discussion with members of Haystack, Brick, RealEstateCore, and more.
Here’s everything worth sharing from Nexus HQ this week:
★ PODCAST: 🎧 #104: New York City's unique RTEM program—Episode 104 is a conversation with Ryan Baxter, PropTech Advisor to the New York State Energy Research & Development Authority, AKA NYSERDA.
We talked about how New York City real estate is unique, the top 5 pitfalls for technology vendors trying to get a foothold there (and anywhere), the past, present, and future of NYSERDA’s Real Time Energy Management Program, AKA RTEM, and finally, the exciting Hackathon initiative the RTEM launched this year.
---
★ FROM THE ARCHIVE: Pro Member Gathering with all the Major Ontology Efforts (Pro members only)
---
★ MEMBERS-ONLY EVENTS IN JUNE:
Join Nexus Pro now to get the invites and access to the recordings.
---
★ ON LINKEDIN: Is AI another layer in the stack?
---
★ READ OF THE WEEK: Rob Speyer on the long arc of megadevelopment, New York’s renaissance and proptech bets
---
👋 That's all for this week. See you next Tuesday!
Hey friends,
Today, we're continuing our series on Nexus Lore: the core concepts that come up again and again in this newsletter, on the Nexus podcast, in the Nexus Foundations course, in Nexus Pro gatherings, and in the community chatroom.
If you want to start at the beginning, check out our white paper with all 10 parts: Nexus Lore.
Lore is never written by one person, so send us your feedback for v2!
Let's jump into Part 7, our nerdiest building block...
Let's pause our exploration of each horizontal layer and zoom in on one key part of the Independent Data Layer: the Data Model.
In order for our applications (which we'll cover next week!) to do their thing, they're going to need context.
The applications need a way to understand all the data they're consuming, including all the underlying devices and how they fit together into a system of systems. As an example, the diagram below shows just two siloed systems (HVAC and lighting) and just two rooms of a building.
See how all these devices, rooms, zones, and systems overlap with each other? Both the lighting circuit and the AHU and the VAV all “serve” room 101. The AHU and the VAV also serve room 102, which has the thermostat and the CO2 sensor that control the operation of the system.
Any application that uses HVAC data will need to know these facts—so how do we communicate those concepts in a standardized way? In most buildings today, we don't. All the silos and teams of humans represent these concepts differently.
Take naming for example: The architect might call it Room 101; it’s in the CMMS as Room_101; the BAS doesn’t even have a concept of rooms; the lighting controller calls it Zone-1 (and every controller has a Zone-1); the ACS calls it a 'Conf room'; the tenant calls it the Zeus conference room because they’ve named all their rooms after Greek gods. Crazy, right?! And naming is just one aspect of data modeling!
The key detail here is machine-readability. Most of the time we humans can infer that it's the same room, but a computer would see them as distinct concepts unless programmed otherwise. The migration to more interoperable systems comes with more machine-to-machine communication—which requires data to be understood by a computer natively. If a common data model doesn’t exist, then us humans need to map disparate data models to each other for two systems to work together.
And trust me (since I've done it): mapping is time-consuming, mind-numbing, and costly.
This is where standards come in. Using a standard ontology—like Project Haystack, Brick Schema, or Google's Digital Buildings Ontology—minimizes mapping and ensures the data model is ready for any application. However, although Project Haystack (the original) has been around for over 10 years, we're still in the early days of our industry's data modeling standards development process.
Here's a quick snapshot of where we're at today:
Given that, should each building owner just give up and do their own thing? I don't think so...
While the status quo is messy, the north star is to start with an existing standard and continue to adapt your data modeling methods (and your IDL) as the standards evolve. That way, you're not expecting the rest of the industry to adapt to your new standard...
Do you agree? What did I miss?
Let us know on LinkedIn,
—James Dice, Founder of Nexus Labs
P.S. Nexus Pro members can go deeper by checking out last year's panel discussion with members of Haystack, Brick, RealEstateCore, and more.
Here’s everything worth sharing from Nexus HQ this week:
★ PODCAST: 🎧 #104: New York City's unique RTEM program—Episode 104 is a conversation with Ryan Baxter, PropTech Advisor to the New York State Energy Research & Development Authority, AKA NYSERDA.
We talked about how New York City real estate is unique, the top 5 pitfalls for technology vendors trying to get a foothold there (and anywhere), the past, present, and future of NYSERDA’s Real Time Energy Management Program, AKA RTEM, and finally, the exciting Hackathon initiative the RTEM launched this year.
---
★ FROM THE ARCHIVE: Pro Member Gathering with all the Major Ontology Efforts (Pro members only)
---
★ MEMBERS-ONLY EVENTS IN JUNE:
Join Nexus Pro now to get the invites and access to the recordings.
---
★ ON LINKEDIN: Is AI another layer in the stack?
---
★ READ OF THE WEEK: Rob Speyer on the long arc of megadevelopment, New York’s renaissance and proptech bets
---
👋 That's all for this week. See you next Tuesday!
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up