What’s New with BEDES?, The Version 1.2 Release and How You Can Benefit! Webinar (Text Version)

You are here

Below is the text version of the webinar What’s New with BEDES?, The Version 1.2 Release and How You Can Benefit!, presented in October 2015. Watch the webinar.

Nancy Gonzalez:
Presentation cover slide:

Hi, everyone. This is Nancy Gonzalez with DOE. I think we can go ahead and get started. We have a threshold, so I will pass it along to my colleagues Elena Alschuler and Paul Mathew.

Paul Mathew:
Great. Thank-you, Nancy. Hello, everyone. This is Paul Mathew at Lawrence Berkeley National Laboratory. On behalf of the DOE and LBNL BEDES team, I'd very much like to welcome you to this webinar, where we're going to give you an update on what's new with BEDES.

First slide:
So here's what we have in store for you today. We have -- initially we're just going to share a little bit about some background on BEDES, because many of you may actually not be familiar with BEDES. We'll give you a little update on Version 1.2 and what were some of the changes there are. And then the highlights of our webinar are actually going to be some highlights from the early adopters. We have four of the early adopters on the phone, on the webinar today, and they'll be sharing some of their applications as well as how they intend to integrate BEDES. And then for the discussion section, we'd like to talk about expanding the adoption of BEDES, as well as extending the scope of BEDES. I will say that because we have quite a few registrants, we are not able to do just open audio, just because of concerns around background noise. Please do use the chat feature for any questions and for any suggestions. And you can just send those in, and then once we're done with the presentation, we'll take them in the order that they're received.

Next slide:
So with that, I'd like to turn it over to Elena Alschuler at DOE, who's the project manager for BEDES, to just present a little bit about the motivation and background. Elena?

Elena Alschuler:
Thanks, Paul. Welcome, everyone. I'm going to move pretty quickly through this, because I think we have a lot of our BEDES believers on the call already. So while we'll go through sort of a quick history of how we got to where we are today, and then we're going to spend most of our time today actually featuring people that are using BEDES, which I'm really excited to hear about. So the reason we did this is that there's a lot of sort of ambiguity in data definitions. When people are trying to have software tools talk to each other or combine data that was collected in different programs or for different reasons, you lose a lot of accuracy and specificity in the data when you're trying to merge together datasets. And so we saw this within DOE, with our own programs, and then we started talking to people and realized it was a problem across the industry. So we came up with BEDES to enable the exchange of data. If you've looked at the actual dictionary itself, it's really wonky. It's really designed for software-to-software interaction and really precise terms and definitions. So, you know, one of the things that we've talked about in BEDES is you can actually call the term anything you want, as long as the definition aligns in the back end and you know how everything maps. The idea here is to try and reduce costs, and increase quality in the data admin factor. Next slide.

Next slide:
So just quickly going through what BEDES covers. As I mentioned, it's terms, definitions, and field formats. And we hope it will be used voluntarily across public and private sector: databases, research, software tools, things like that. And we are adopting it internally, as well, at DOE. It covers all of the building sectors: residential, commercial, multifamily. Because it's completely sort of deconstructed down to the individual words, you can arrange them to describe a building, a campus, a project, a tenant space. So it doesn't lock you in to a particular sort of unit of a project, or of a record. And we also cover everything physical, operational, consumption, energy investments, things like that. Next slide.

Next slide:
So I think I mentioned this briefly in a previous slide, but basically, we originally started developing this dictionary to make DOE's own tools and software more interoperable and to be able to continue using datasets. If there was a dataset that was collected for one particular project, we would be able to still use that data in the future for other projects. And then we realized it was a broader -- we just started getting requests from folks, that they wanted to use what DOE was using. And so we did a scoping study and actually confirmed that this is a big problem in the industry and it's something that folks would appreciate some federal leadership on. So LBNL -- gosh, it's almost two years ago -- started a working group process. We had about 60 to 100 stakeholders participate. We reviewed I think 40 or so different common data formats and mapped them all together, and had the working group try to deal with any places where there were conflicts in commonly used definitions, or areas where a new definition needed to be created. And then we came out with BEDES Version 1 just about a year ago. It's been great. We've gotten a lot of people just picking up and using it. The main reason why we're on the call today is to show you how it's already being deployed in the market and to start talking about where we might want to go from here.

Next slide:
So I'll hand it back to Paul to talk a little bit more about the nitty-gritty, and then we'll get into handing it over to some of our early adopters to talk about what they're doing.

Paul Mathew:
Great; thanks so much, Elena. I just wanted to frame BEDES in the context of the broader efforts of data standardization. As we started thinking about this, I want to kind of highlight what it is and what it's not. When we started thinking about this, a year or two ago, in a perfect world, which is off here on the left, you would have -- the green bubbles here are all the different applications -- and you would have one single universal exchange schema that everyone uses in order to exchange data. And technically, this is very, very feasible. This is not hard to do, technically. The challenge, of course, is that in a very, very fragmented market it's very hard to get people to actually adopt a single universal exchange schema because of the variety of use cases and so on and so forth. So it's almost sort of a utopia, at some level. Worth aspiring to, of course. But not something that's going to happen immediately. A next sort of almost perfect world is where you might have a set of standard exchange schemas for different use cases. So for example, in the residential space, audit space, there's a standard called HBXML. Some of you are familiar with that. Which is an attempt to standardize how auditing of residential information is exchanged. There's an emerging one called BuildingSync, which is also BEDES compliant, for the commercial space audit data. And so on. And then, in a somewhat less-perfect world, which is sort of where we rest today, where BEDES is, we said that, well, even if we can't get here or here -- the perfect world -- let's at least try and standardize the terms and definitions, even if we can't get to the schemas eventually. So that's what BEDES is attempting to do right now. And then as it grows, we hope the industry will evolve toward this almost-more- perfect world.

Next slide:
So again, to emphasize what BEDES is and is not. It's a dictionary of terms. It has data terms, definitions, units of measure, and data types. And what it's not: It's not a database. It's not a schema, either relational or hierarchical. So the way to think about it analogously to a dictionary is that it's not a grammar guide. So we want to just emphasize that.

Next slide:
Also, we should say that we didn't want to try and conquer the whole world of the buildings space initially with BEDES. What we thought is that, let's focus on some use cases where we know and are familiar with the pain that people are feeling, in terms of exchanging data. So these are the ones where we've picked, to focus on. And our data fields initially are really kind of around to support BEDES use cases. The first is energy efficient investment decision-making. So this is only the managers using building energy performance information to assess capital operation opportunities. And so on. So that's mostly whole building data, whole building characteristics, and so on. Likewise, building performance tracking. So these are entities who are looking to implement disclosure policies. Now there are something like 12 -- more than a dozen cities, actually -- that have disclosure policies, and they need to collect and clean and analyze massive amounts of data from many different sources. And so they're definitely feeling the pain of lack of data standardization. So there's that. And a third is efficiency programs, either utilities, or states, and so on, that often, again, have to collect data from many different sources for roll-ups and so on. That's another area where we thought initially BEDES could focus.

Next slide:
So what's new in Version 1.2? As I think Elena mentioned in an earlier slide, Version 1.0 was released about a year -- almost exactly a year ago, actually. And then we created an update, Version 1.1 in the spring, in March or early April, I believe. And then we just released -- at the beginning of this month, we released Version 1.2. It's mostly I think minor updates. I mean, there are many updates, but they're fairly minor. It's a few new terms and enumerations. What's interesting is that most of these updates have actually come based on feedback from developing BEDES-compliant products for our early adopters. So it's sort of when the rubber meets the road. We suddenly realized, oops, we're missing a enumeration for this particular HVAC type, or lighting type, or oops, we had a redundant term over here, which creates ambiguity, so let's delete one of the terms and so on. And so mostly it's coming out of that experience. We haven't really expanded it to new areas. But that is a topic we're thinking about, and we'll discuss more in the discussion section here. And finally, the other thing we did is that we also created a set of standardized procedures to develop BEDES-compliant mappings. This is, again, probably just to provide guidance on how to do it, because it can be a little involved. There are 601 terms in the latest version of BEDES, and plowing through all of them can be a little difficult. So it takes a while to get familiar with that and how to actually create these mappings and so on. So we've created some procedures for that, to help in that process.

Next slide:
OK. So now to the highlight of our webinar, really, which is to talk a little bit about BEDES adoption.

Next slide:
First of all, what does it mean to be a BEDES adopter? What makes you an adopter? Well, it could be one of three things, at this point, anyway. First is to simply publish a mapping between your terms and BEDES terms. Because again, what we're trying to do is socialize the idea of standardization and sharing common terms. So just publishing a mapping between the terms that you currently use in your application or in data exchange formats and what BEDES terms are is helpful, because then, when there are many applications that do that, someone looking to merge data from multiple applications can use BEDES as a Rosetta stone, essentially -- those mappings as a Rosetta stone. So that's one. The second is to actually use BEDES terms in your data exchange templates or formats. So we'll highlight a couple cases where applications are thinking about, in their data export format, be it a CSV format, for example, they will have both their terms as well as the BEDES terms, the equivalent BEDES terms. So to be compliant you don't have to drop all your terms. You can have your terms but also indicate the BEDES terms for that. The third way, of course, is to actually use the BEDES terms in your applications, particularly if you're developing new apps or you're creating a new survey form or something. Or you're setting up a new database for your application, and you're thinking about what terms to use. We've actually had a couple cases like this, where they say, I don't want to think about this from scratch; I might as well use something that's out there, with (inaudible) component to it. So that's the third area that you can use BEDES and become an adopter.

Next slide:
So here is -- I'm not going to go through this line by line, but I just want to give you a flavor for BEDES compliance to date. These are things that are either planned or in development or have been completed. We started with some of our own in-house things, like the Building Performance Database. In fact, the things we've experienced with data assimilation for that project is what kind of prompted the BEDES project, even. I mentioned BuildingSync earlier. That's actually an audit exchange schema, which is compliant with BEDES. And that will actually be -- there's a plan to create an export from that in the buildings conversion from ASHRAE SPC 211. The audit standard. We've created a mapping for ENERGY STAR® Portfolio Manager fields. There are several project software tools. The AIA Design Data Exchange, and EcoPros and EnergySavvy are software tools, that, in fact, we'll feature a couple of these shortly, where BEDES templates are in development.

Next slide:
Likewise, in fact, we'll feature FS Energy, as well, shortly. Green Button, which is a -- many of you know, a utility there. We created a mapping there, and so on. And finally, we'll also feature the Real Estate Standards Organization. That's another one we're pretty excited about. So you could be on this list. And we would very much encourage -- our game is adoption here. We want to get more and more people to adopt BEDES. And the nice thing about BEDES right now is that it's not in the context of some complicated standards process. It can be fairly nimble in terms of adapting it and changing it, in order to be able to accommodate new early adopters.

Next slide:
Some more about that later. So now I'd like to go to adopter highlights. We've got four adopters we'd like to highlight. So I'll list them. We're going to go through them in alphabetical order by organization name.

Next slide:
So the first one is the AIA 2030 Design Data Exchange. And we're very happy to have Melissa Wackerle here from the AIA. And Melissa, I will hand it over to you. Just tell me when to advance the slides.

Melissa Wackerle:
Thanks a lot, Paul. I'm really happy to join you and really excited about using BEDES to communicate from our database to others. Our database is actually a little bit different from some of the databases that are out there, because we're looking at predicted energy performance. So we're looking at architects. And so architects are designing projects, and we want to understand how those designs are performing preliminarily with hopefully modeled energy performance. So we're collecting that modeled energy performance, or the design energy performance, and predicted energy use intensity. And so the idea is that we take the projects from design through construction, and then in the long run, connect it to an operational database such as Building Performance Database or Porfolio Manager. So when we're planning to the tool, we're doing it in partnership with Department of Energy and the Building Technologies Office, and so in order to plan for that link in the future, we developed it based on the BEDES taxonomy. So it's really thinking long-term. You can go ahead and advance the slide.

Next slide:
What the tool does is it's an input piece where the firm will put individual projects into their own portfolio and then submit that project into a larger programwide portfolio. And so what you see here on the right is a scatter plot of individual projects, and that's really designed based on Building Performance Database, and so there's kind of a direct homage to that database, and how we could potentially link up with that in the future using BEDES. So it's a matter of reporting and then analyzing at the firm level, especially, but then also at the portfolio level. So let's continue; I'm sorry.

Next slide:
And so what we're really trying to do is develop mapping between our DDx reporting platform and BEDES. And the reason we're doing this is mainly to, again, communicate out to those operational databases. We're also looking at how we can import information from things like energy modeling software tools into the DDx, so that if firms are already modeling their software, their projects, they don't have to duplicate effort by reentering everything directly into DDx. So they can just do a seamless import and manage their workflow a little bit more smoothly that way. So what we're really trying to do is think about leading by example, not necessarily to be kind of out there in the forefront, which is nice, but it's really thinking about how we can connect to things in the future by using the same language. So we can create a unified API to connect to things like modeling software programs without having to do one-off development each time. And I think that's pretty -- that's all I got.

Paul Mathew:
Great. Thanks so much, Melissa. Appreciate that.

Next slide:
The next one is EcoPros, eAuditPro, and I'm going to hand it over to Avery Gitner and Wayne Alldredge.

Elena Alschuler:
I'm sorry, before you get started: If folks have questions for the individual presenters, even if you just want to say, hey, I want to connect with you offline about your cool product, feel free to put it in the chat box, and we'll go through the questions at the end and/or connect people as needed. Thanks.

Wayne Alldredge:
This is Wayne Alldredge. I'll start. Thank-you for having us, to begin with. We're very excited to be part of the BEDES mapping program, if you want to call it -- BEDES compliance. We feel that it's really going to push the industry and really enable intercommunication, and it's a big benefit through the industry as a whole. So we're very excited to be part of it. Real quickly: eAuditPro is an energy auditing software as a service. If you think about it as you can either hire a CPA to do your taxes or you can go get some software as a service like -- I don't want to mention any certain brand names, but you know those brand names that do your taxes online or software that you can buy. That's very much what we're looking at. Rather than having to have an energy auditor who has years of experience and training, we're automating all of that knowledge that energy auditor has, enabling the software to allow the end user, the building owner, the building manager, to actually enter their data directly into a database, and therefore saving them a lot of time and making the process, energy auditing, very affordable. The configuration of eAuditPro currently is for ASHRAE Level 1. We are designing ASHRAE Level 2. But it currently can produce an ASHRAE Level 1 report directly from the owner or the manager of a property without having to go through any expensive contracts by hiring an energy auditor. We have designed from the very get-go to be interconnectible through different databases. We use standard languages. We use standard exports. And so when we learned about BEDES, we were very excited, because that enables us to tie in to other databases and also to export data that comes directly from the horse's mouth, so to speak, and go into other databases. So we're very excited about that, and we're building an API for export to automate that process for other users and other software companies to get into the database. We can go on to the next slide.

Next slide:
So very quickly, before I turn it over to Avery: We're developing those mappings, and we also intend to use BEDES terms in our future templates, so that we don't really need to have any sort of a translator, so to speak, to move data in-between other databases. It'll be not necessarily native, but the terminology will be standardized. And that's what we're doing for our future development. And we're looking at some of the other schema in SEED and some other processes that are looking at the BEDES terminology. We're looking at some of that schema and trying to incorporate from that, too, trying to make the process as seamless as possible from our software into other analysis software and modeling software. I'll turn it over to Avery.

Avery Gitner:
Oh, thanks, Wayne. First I'll say thanks to Paul and the BEDES team for all the assistance they've been providing in the work that we've been engaged with, and helping to develop the BEDES standard definitions and schema. I think, just to echo a little bit on what Wayne talked about, we just recognize that we have hundreds of thousands of buildings and a limited number of audit professionals out there to tackle data collection. In order to share, we've got to have consistency, in the datasets, and a consistent framework for pulling that information together. So the eAuditPro and EcoPros and others who are on this call and are participating in this endeavor, I think, all recognize, to have the highest and best use of human capital in gathering the data, we need more efficient tools. And eAuditPro is specifically geared to that, so that we might be able to deploy the effort of data collection over a much larger population of facilities managers, students who are training to be in the energy space and looking at buildings and procuring the data. Other folks who are involved with nonprofit organizations that are serving sustainability and green building efforts, having a universal portal that people can utilize to gather the data, will help leverage our deeper engineering talents on reviewing data and analyzing what has been collected, and meeting with building owners and discussing what the opportunities are for moving forward. But it also creates an opportunity to be a data feed into some of the other audit process or more particularly in the simulation process. And that's part of what I believe is our future for Pro and the BEDES program, is effective collection of energy data that feeds our modeling and simulation process, so that we have more of the tipping point and more engagement within the community to improve the performance of our buildings. Thanks for the opportunity to be with you today.

Paul Mathew:
Thanks, Avery. Alright, so the next one is FS Energy, and I'm going to hand it over to Aaron Mehta.

Aaron Mehta:
Thanks. So FS Energy is the energy subsidiary of First Service Residential. We created this subsidiary realizing that roughly 30 percent of multifamily, coop, condo, HOA association budgets were going toward energy. And one of the areas we started was capturing the monthly utility bill information -- the costs of consumption by account -- for all the meters in the building, as well as all the building characteristics. So building information, details about the commercial spaces, mechanical and electrical systems, plumbing, water use, energy services, as well as energy services provided to individual apartments by the association and by those directly provided through the utilities. And as we were doing this, so kind of the scope of the data for buildings we were trying to collect was roughly 6,000 complexes worth of data across North America, covering 1.6 million units. We started sending out typology forms and had to get our property managers or resident managers to actually fill them out. And then kind of aggregate them and put it all into our database. And basically, we had a giant mess on our hands, where a lot of the fields were open-ended and there's a lot of -- it was the same exact system, but it was worded differently. And we needed some type of consistency. So we were looking for a way to standardize how we're actually collecting this information. And initially, we started trying this internally. Then we started reaching out, seeing if anyone else had this problem. And that's kind of where we ran into BEDES. Can I get to the next slide?

Next slide:
So because we were at the point where we basically just had enough, we didn't really start down the path of normalizing it ourselves. It was a really, really fantastic find, seeing what the BEDES working group had created. And basically just adopting it. We were happy that there was an industry standard being developed. And we started adopting BEDES terms and updating our field names in our database to match those earlier this year. Going forward, we're now utilizing the BEDES terms for even more granular building information. So for example, if a lighting audit is done, we're using the lighting terms in BEDES 1.1, 1.2. We got a lot of help from Paul and Robert and their team. And kind of as we start kind of organizing our data, utilizing the BEDES data dictionary, it's been incredibly helpful for us internally. And we're at the very early stages of this, but we're now trying to see if we can encourage our ecosystem of vendors and efficiency programs that we deal with, software providers, to also adopt BEDES. Because one of the reasons we are capturing this information is to analyze how our buildings are using energy and target our efforts for efficiency improvement projects to those buildings is going to make the biggest difference. And any engineering firm or contractor that we call in to actually implement a retrofit, they're basically looking for the same information. So to the degree that their systems and their software that they're using is using the same data terms, it's going to make it a lot more efficient for us to share the data that we have to the relevant contractors and engineering firms. So they can actually do what they need to do.

Paul Mathew:
Great. Thank-you so much, Aaron.

Next slide:
And last but certainly not least, we have Rob Larson from the Real Estate Standards Organization, representing the RESO data dictionary. So Rob?

Rob Larson:
Yea. You hear me OK?

Paul Mathew:
Yep.

Rob Larson:
OK, excellent. So to give a little bit of background to you all. The multiple listing service, which I'm sure you've heard about, wasn't really founded so much about data, but it's a system of cooperation amongst real estate professionals. Some of the byproducts, though, of the evolution of this industry has been that in order for that cooperation to occur, the information being there is part and parcel to what the MLS does. And that information has branched off into some other areas, such as the evaluation on the property, and also the marketing of the property. So even though it's not really our core business, if you will, it's pretty core to the end results of what the MLS does. Some years ago, I got involved with a working group from the National Association of Realtors, where the value of high-performance anything being done to homes wasn't really being identified very well. And one of the key uses of the MLS system is the appraisal industry, when they're evaluating a home, will take a look at comparative houses that have been recently sold or are up for sale or currently in escrow. So they'll take a look at these properties, and if they can't identify, say, a type of insulation, or a certification that might be on the property, even if they can identify that in the house that they've been hired to appraise, it's very hard for them to see if there's any comparative property to see what that certification's true value is in the marketplace.

So that started us going down this path, because at the end of the day, if the appraisal doesn't include the value that's been applied to the house, then the mortgage industry, in their typical 80/20 percent loan out to the consumer, isn't going to include that value. And the building industry was kind of calling out, saying, hey, we'd love to do this, but we've got a problem with the value showing up in loans, and we might end up with a smaller pool of buyers as a result. We still may sell this house for the value that we need to, but we're just not getting the lending and the consumers seeing this, both from the lending and the marketing standpoint. That was sort of the kicker for us to get involved and start moving down this avenue. We today very much have fields built around the notion of certification, around specific features that you might have. And we have fields around the marketing aspect, which is probably the most removed from the BEDES standard. We look at this as this is our best interface -- single interface -- to be able to talk to the world, those of you who are out there actually measuring these things, really defining these things that make up a high-performing home. So you want to go ahead and go to the next slide there, Paul.

Next slide:
So we've been in touch for a little while now. We've got a mapping in place between the two, to start that process. I very much look at it from the standpoint of this is hopefully going to be my one- stop shop to interact with what we're starting to see as emerging sources of data for the MLS. And our ideal for utilization of this information is that MLSes already today will go out to other sources of data and use a process that we call autopop. In other words, we will auto-populate an input form for the listing agent. And some of this data is information that the agent may audit and interact with. Other data, some of the tax data, they will -- the tax is their source for that information. We hope to create these sources and create the convenience of bringing that information into the listing input form, so that we can very gracefully take a lot of this critical information that we see around properly identifying what a home has from the performance perspective, and get that into the listing, so that history of that information around that home resides inside the listing data. And so then when you get out to that situation of an appraisal, says, hey, you know this home has a certification. So the agent has gotten their training, and they've identified a few things. The appraiser can come in and find comparatives in the neighborhood, so that they can figure out what that value's going to be, which it's certainly more than just a home without any of these things.

So the steps that we've most recently taken is, the RESO dictionary, which was put together to unify the MLS datasets that are out there. There are currently a disputed number of them, unless it's in the country somewhere between 650 and 800 multiple listing services, many with completely different datasets. We have our Rosetta stone to bring us all together, and things have been moving forward swimmingly for us. Our standard has been going since 2011. We have backing at the NREA level, to require all MLSes to adopt. So we're all coming together. And we're intersecting BEDES in -- where it's going to first be seen in our industry is we're moving from essentially a spreadsheet-based, which we're all kind of familiar with to view a data-type dictionary, out to a wiki. And we have the BEDES mapping incorporated in that wiki. So we're really happy how this has worked out timewise, too. Because we're going to have a lot of renewed attention to the dictionary. In addition to NREA requirements being effective on the first of next year. So right now, everyone is very much engaged in the process of implementing the RESA dictionary, and so we feel that there will be a lot of eyes brought onto this. At the end of the day, you know, I had mentioned BEDES -- I'm looking at it as our bridge to all this energy-related information, and having those bridges when it comes to mapping -- you know, we have, a typical MLS will have about 7,000 data points. So at those nights when I was up at 3 a.m. and mapping data between myself and another source, to have something like a BEDES or like a RESA data dictionary to be able to make that mapping not only faster but more predictable and more reliable is a really good thing. And especially to have something like BEDES, which is based the experts of that data, we see it as a opportunity for the MLS to even expand its dataset.

So now we might be bringing in information that, from one aspect we'll want to sort of summarize or distill down into something that could be used for marketing. So we may have some particular data around the certification, and we want to be able to generically say, hey, you know, this is a feature of this home that the layman can understand. But we also see that we could potentially expand what we have to carry real specific data that maybe the consumer or agents will use, but from the appraisal and other processes that would like to rely on the MLS data to identify these homes that have sold that have these things, that we can be a conduit for this. We're pretty excited about being able to expand our borders of how useful our data might be to other parties out there. And that's kind of it. Thank-you very much.

Paul Mathew:
Thank-you, Rob. Thanks so much. Again, I'd really like to thank the four presenters we have here, and all the other early adopters, because in a fragmented industry pushing standards is a long slope. To use an overused cliche -- I know it's a marathon, not a sprint. So I really appreciate all the early adopters, because it's always a heavier lift, frankly, for early adopters than it is for later adopters, when it comes to things like standards. So we really appreciate your extra efforts in that regard. OK.

Next slide:
So just a couple more slides before we open it up for discussion, in terms of looking ahead here.

Next slide:
There are two things we want to do over the course of the next year. One is to expand adoption. And there are two ways that we think we want to do this. The first is to just continue to publish new mapping. As I mentioned earlier, mapping sort of serves as a Rosetta stone, and the more of them there are -- it's sort of a bit of echo effect -- the more useful they become. And also, just more generally it helps socialize BEDES and the idea of data standardization more broadly. So it just helps in the overall cause, if you will. But the second area of expanding adoption is to actually find cases in the near term where BEDES can really help solve a near-term problem or some pain that people are feeling. So for example, if data exchange or mashup could be multiple applications where there's no commonality right now, that's where BEDES could come in and sort of serve as a translation hub by creating these mappings and so on. So that's one. And related to that is just to -- is for BEDES to be a source for terms and definitions when developing new apps or expanding existing apps. So Aaron, for example, in his presentation, briefly mentioned that as they're developing lighting data they used BEDES as a source for some of the lighting terms and so on. So here is the task for everyone on the webinar now, so we'll get your brains working on, let us know of potential adopters where particularly apps, or standards, or data collection forms and so on. Particularly where there's a data exchange or data mashup between multiple applications, because I think that's where BEDES is most valuable. And we can provide technical support -- the "we" being LBNL providing -- has been tasked by DOE to provide technical support for some of these mappings and so on. So that's one, expanding adoption.

Next slide:
And the second, which is sort of related, is that we may need to extend the scope of BEDES domains that it covers. I mentioned some of the earlier use cases or the initial use cases that we were focused on. And so we'd like to get your thoughts on suggestions and priorities for extending BEDES. The BEDES team doesn't have any particular bias in terms of domains that we want to expand it to. Our only real concern, or consideration I should say, is, you know, are there specific use cases where there's really a good case for using BEDES and a common standard? Are there motivated stakeholders in that space? Are there any existing standards that we could leverage, for example. So those are some of the things that will determine our selection of which areas to expand into. Over the past year or more, we've gotten various suggestions. They include things like expanding into the financing space to cover details of financing terms and so on, operations and maintenance specifications, water, waste, building permitting, simulation and (inaudible). There's a bunch of ideas that have come in, and we're going to go through a small little scoping exercise to kind of figure out where should we expand. We don't want to take all of these on. We can't take all of these on, because then it will just collapse under its own weight. We kind of want to take this one step at a time here, by identifying good use cases. So again, we'd really, really like your input. And unfortunately, with the number of registrants, we can't just open up the lines, because of background noise problems. So sorry, you'll have to type in your suggestions in the chat box, but don't worry, we won't read out your spelling errors. So just go ahead and type those in.

Elena Alschuler:
I think we also may be able to unmute people selectively. (multiple voices talking) ...

Nancy Gonzalez:
I know a number of folks are looking at your GoToWebinar viewer, but you should also have a dashboard on the right-hand side of your screen. And if you expand -- there's a little orange button, and if you expand that, you can see the full dashboard. And it has different functions. There is a raise-hand function. If you raise your hand, I can go ahead and unmute you if you have a question, or you can use the chat feature to enter your question. (multiple voices talking) ...

Elena Alschuler:
So anything coming in the chat box or raised hands?

Nancy Gonzalez:
Yea, we do have a couple questions in the chat box already. So I encourage those, if you have a question you want to voice, raise your hand, but we'll start off with the chat box. A couple of participants are asking about the relationship between Portfolio Manager and BEDES and whether you can elaborate on that.

Paul Mathew:
Sure. We have actually created a mapping between Portfolio Manager terms and BEDES terms, and that mapping's actually published on the BEDES technical website. So you can go and download that. It's basically a spreadsheet that shows you that mapping. So that's how I characterize it. Elena, anything else you want to add to that?

Elena Alschuler:
Ah, no, just that we utilize Portfolio Manager terms to the extent possible in actually creating BEDES, similar with Green Button and ASHRAE definitions of equipment types. We didn't reinvent a wheel if there was already a good definition out there. So we're very, very closely aligned to Portfolio Manager. The only real changes we did sometimes was to make the definitions apply to more broad building types, or not be specific to a building. I'm trying to think of a good example. Paul, you probably can think of a better one than I can. But basically maintaining the Portfolio Manager definition but making it more broadly applicable.

Nancy Gonzalez:
Great, thanks. Another question is how is BEDES incorporating building information models?

Paul Mathew:
I'm sorry, could you say that again, Nancy? I think you broke up a little bit.

Nancy Gonzalez:
The question was whether BEDES incorporates building information models. And one reference was to industry foundation classes.

Paul Mathew:
Yes, yea, thanks. Now I get it. Yes. BEDES as a -- in fact, let me just quickly go back to that slide, about what it is and what it is not. Right. This one. So BEDES, again, is a dictionary. So it's a dictionary of terms and definitions and so on. So it does not have a hierarchical structure that describes in the way that a BIM does. An ISC, for example. I think that's the way I can characterize it. The other thing is that from what I know of ISC, and we did actually look at ISC, by the way, as one of the many standards -- we reviewed it in the process of doing BEDES. ISC probably has a lot more detail because they're really trying to describe all of the details -- or a specific number of the details of the building, whereas we limited BEDES to those three initial use cases that I mentioned. So that's the key difference. BEDES is not a building information model. It is a dictionary of terms.

Nancy Gonzalez:
Great. Thanks. Another question is, some folks are interested in the U.S. Green Building Council and whether they are working with BEDES on any efforts to become compliant.

Paul Mathew:
Yea, good question. We've had some discussions with the U.S. Green Building Council and we would love to. Everyone agrees with the concept of standardization. I've never found somebody who doesn't agree with that, to date, anyway. It's just, you know, figuring out when and how and so on. I will say that an offshoot from the U.S. Green Building Council, the -- called GRESB, and I'm going to blank out on exactly what GRESB stands for, but anyway, it's an international organization that tries to collect data on portfolios of buildings and so on. So we're actually working with GRESB right now to create a mapping with the GRESB terms, so that they can collect data more efficiently. Elena, anything more that you want to say about connections with USGBC?

Elena Alschuler:
Yea. The only thing other than that to note is that USGBC, most of the data they collect for LEED in the energy space is directly from Portfolio Manager. So for this current scope of BEDES, we're actually very well-aligned with LEED. The question is, do we want to expand BEDES to cover indoor environmental quality and materials and waste and things like that? And certainly if we decided to expand BEDES into that space, we would be looking very closely at just directly adopting LEED definitions for many of those terms.

Nancy Gonzalez:
OK, thank-you. Some folks are wondering if there are any free data visualization tools in the market that you see specifications.

Paul Mathew:
Data visualization tools. Not that I'm aware of. Again, BEDES is sort of just out there, so we don't always hear about all the people that are using BEDES. We actively try and work with certain early adopters, and those are the ones we named in the webinar just now, and it's also on our website. So I'm not familiar with any data visualization tools that are using BEDES right now.

Nancy Gonzalez:
Thanks. Some participants are interested in knowing more about creating a BEDES-compliance database and whether it's expected that you would be using the BEDES terms of your data points.

Paul Mathew:
Yea, good question. You could if you're creating a -- you're creating a new application, for instance, you could certainly use BEDES terms as a source for your data terms and so on. But really, the primary push we're making is in data exchange, not the internal databases of applications and not necessarily the user interfaces of applications. It's really for the data exchange -- that's where there's all this ambiguity when people are trying to map data from one application to another, or merge data from many different applications. So yes, as I mentioned in one of the earlier slides, you can certainly use BEDES terms in your databases themselves, but you could also use them for exchange of data.

Nancy Gonzalez:
Great, Paul. And we have one last question. Unless folks -- there's still a couple minutes, so I encourage you to raise your hand or send us your questions via the chat box. One person is asking how BEDES relates to Project Haystack? Are you familiar with that?

Paul Mathew:
Yes, I am familiar -- well, I know of Project Haystack. I wouldn't say I'm familiar with all the details. Right now, Project Haystack deals a lot of the data around controls and so on. And right now, that is not in the scope of BEDES. If BEDES were to expand into that space, we would definitely look at Project Haystack and its definitions. But having said that, there are probably terms right now even, or terms of BEDES right now, that are covered in Project Haystack, and I think would be useful as kind of an easy way of mapping to those. But the vast majority of Project Haystack terms I suspect are not in the current scope of BEDES.

Nancy Gonzalez:
Another question is, how do you -- how should you give credit or cite when using the BEDES terms?

Paul Mathew:
Gosh. I wish I could say I've thought about that more. I think -- there isn't a licensing process, as such, or anything, for using BEDES. It's out there. It's a public dictionary. We'd love to know if you are. And we'd love it if you kind of indicated that you are using BEDES. Again, because our agenda quite simply is just simply to expand standardization in the industry with the diverse data terms. Elena, anything you'd want to add to that?

Elena Alschuler:
No, that's pretty good. We'll have to think more about that one.

Nancy Gonzalez:
And a lot of folks are wondering if the presentation will be made available. I think we can send out the slides after the presentation to those who are on.

Paul Mathew:
Definitely.

Nancy Gonzalez:
And that's it. We don't have any other questions, so any last words, Paul?

Paul Mathew:
No, and again, I want to emphasize a couple things maybe. One is let us know if you're interested in creating -- making your own application BEDES compliant, or if you know of other potential early adopters. We're obviously looking to expand that over the next year. And also where -- which areas BEDES might extend into, in terms of broadening scope. So we'd really like your input on that. And then get involved. Creating a BEDES-compliant (inaudible). I already mentioned that. You can also just become an endorser. Maybe you don't have an application or don't have a particular use for BEDES, but you really just like the idea, and you think it's needed. You can just sort of just let us know by email, and give us your company logo, and we'll just add you to an endorser list. Because again, that's just to kind of create buzz around BEDES. Again, tell us how you're using it, share your thoughts on the BEDES forum. We have a forum. And so on. Just spread the word. If you have any questions, you can see there's contact information over here. And actually, I'd definitely like to acknowledge our technical team here at LBNL, that helps with creating the -- goes through the onerous work of creating these mapping between all these hundreds of terms, when we work with applications. Yea, thanks very much. And again, feel free to reach out to us, and we look forward to expanding data standardization. Thanks, everyone.

Elena Alschuler:
Thanks, everybody. Thanks for joining. Bye.