CODEcomp: Deconstructing Energy Codes Michael Madison Pacific Northwest National Laboratory Richland, WA [email protected] results, CODEcomp aids the user in organizing and grouping the content, simplifying the analysis process.

ABSTRACT

This paper describes CODEcomp, a new application currently in development for the Department of Energy’s Building Energy Codes Program. CODEcomp uses a novel blending of search techniques to give users a powerful tool for searching and analyzing the content and topics of energy codes.

RELATED WORK

Today, websites like Amazon.com give user immense power to refine their searches using faceted browsing technology. At Pacific Northwest National Laboratory (PNNL) the faceted browser has been successfully implemented on a number of recent, large-scale data and visualization projects. The Knowledge Encapsulation Framework (KEF)[10], Building Component Cost Community (BC3), IN-SPIRE [11], and the Scalable Reasoning System (SRS) [12] are just a few of the projects that use the faceted browser to give users the ability to explore a data set. Early research for CODEcomp also identified Moritz Stefanner’s Elastic Lists project from 2007 [9] as an exemplar for design inspiration.

KEYWORDS

Energy codes, faceted search, HCI, information retrieval, query, human computer interaction, user experience INTRODUCTION

Buildings represent a significant portion of our day-to-day interaction: we eat, sleep, work, meet, and play in them. They can fundamentally affect the outcome of a person’s life, have significant impact on a country’s operation, and influence the future and health of the planet. It is no surprise then, that in a country like the United States the construction of buildings is strictly regulated by a series of energy codes[1][2].

Faceted browsing is most effective when the data set has been semantically tagged [13] and categorized in such a way as to find commonalities within the taxonomy. CODEcomp expands on this concept by using the taxonomy not only for search but also for analysis.

These codes range in topic and specificity, regulating building components in different climate zones and states and types of buildings (residential[3], federal[4], commercial[5])[6]. Therefore it is not uncommon for a building professional to have multiple codes to reference, each containing its own ontology and relationships between themes and topics. Problems arise when a comparison is needed between such codes. As a result, it can be quite difficult and time consuming for the building professional to search for a common topic between multiple energy codes.

DESIGN SITUATION

Energy codes are organized into international, federal, and private sector codes. These codes contain many of the same broad topics, but the requirements for each will differ. For example, the “roof” topic will likely be in all three types of code. However, this does not imply that the definition and requirements would be the same in a federal code versus a private-sector code. Each code is presented as either a physical book or as a digital artifact [14] (usually in PDF format). The codes are organized into sections, called provisions. So, in the same way that an outline is broken into sections and sub-sections, an energy code is broken into provisions. Typically, a building professional has a set of codes he will reference based on his clients and the type of work he performs. He will explore these artifacts by locating the desired topic in the index, and then physically turning the pages (or clicking his mouse) to locate the appropriate provision(s).

Currently in development is CODEcomp an energy code comparison tool funded by the Department of Energy’s (DOE) Building Energy Codes Program (BECP). CODEcomp gives building professionals the ability to quickly locate a topic and browse the energy codes’ content to find related material. CODEcomp uses a faceted browser powered by Apache SOLR technology [7][8]. (A faceted browser allows the user to make a series of selections to narrow search results based on a pre-defined set of categories.) This gives the user access to CODEcomp’s ontology, which is a blending of terms from the various energy codes contained within the application. Users can use these terms to visually identify and select the topic(s) they are interested in exploring. Once they have a set of

While this method does support a use case where only one energy code is used, it is not “cross-code” friendly. In other words, if a user wanted to explore multiple energy codes to see what each of them says about roofs, the user will have a

1

difficult time accomplishing this. The user will have to identify the specific instance in the first code he wants to compare. He will browse the index and read the available provisions on the roof topic. Then, he will repeat this process for each of the other codes, drilling down by provision until he finds the one on roofs in another code that aligns with the first code. This process, while functional, is perhaps more archaic than necessary given technology currently available.

Drawing information from research into projects like Elastic Lists[18] and the Knowledge Encapsulation Framework[19], the concept of CODEcomp began to change. CODEcomp’s interface has been re-envisioned to give users direct access to the underlying taxonomy through a faceted browsing system.

EARLY APPLICATION REQUIREMENTS

CODEcomp’s goal is to allow a user to easily compare the topics within multiple codes. By transferring some of the initial processing requirements from the user to the application, it will allow the user to focus on the analysis of the material. This will avoid a system where the user must constantly recall[15][16][17] information that may be unnecessary. Instead CODECOMP focuses on presenting the user with only the most relevant data. There are two basic use cases that were initially explored: 1. 2.

The user has a topic and wants to find provisions that relate to this topic. The user has located a provision in one code and wants to find related provisions in other codes

Initially, the thought was to have a single search box that would facilitate both use cases. The user will be presented only with provisions that match the topics outlined in the search. Each resulting provision will have a reference back to its code, so it may be easily referenced in the original artifact outside of CODEcomp. For copyright purposes, each provision will be summarized to tell the user what it contains. Unfortunately, the full text, tables, and graphics are only available to those individuals and companies who have purchased the code. The user must reference the codebook for that code and the full text of the provision. CODEcomp therefore is a tool that eases the process of locating and analyzing provisions, not a fullblown content management system for the actual energy codes.

Figure 1: CODEcomp base interface

Through this interface, the user can make selections based on the Building Type (e.g. Commercial or Residential, etc.), Category (e.g. Envelope, Lighting, Mechanical, etc.), Topic (e.g. Doors, Roof, etc.) and Sub-Topic. While the end result will still be the same as was originally planned (the provision with the relevant code citation and a summary of the text), this path is a much simpler one. Now, the user is able to browse our ontology and conduct his analysis based on what is presented to him, without having to guess at our hierarchy or the proper keywords. This also allows the user to continue refining his search, narrowing down the provisions he wishes to read.

WORKFLOW

Applying an understanding of Human Computer Interaction (HCI) standards to the initial design identified some areas for growth. While the search box was certainly better than having the user juggling multiple codebooks to find data, the initial CODEcomp process relied heavily upon users to formulate a search query, without giving them insight into the underlying content and taxonomy. It also assumed that the average user could distinguish between the two types of searches that could be conducted from the same interface component. Finally, without the ability to further drilldown into the topics, users would not necessarily be presented with fewer options in the application than they would have by simply flipping through the codebook’s index.

Figure 2: Provision Search

CODEcomp does provide the user with a provision search, as there are still use cases when the faceted search may be inappropriate. For example, if the user knows the exact provision he wishes to use as the baseline, it would be much faster to start from that provision than trying to use the facets to build the query. So, if the user does happen to know the provision he is interested in, he can still do a direct search for the related content based on that provision

number. However, user feedback indicates this use case is now considered to be a secondary use for the tool, as most users want to start with a topic and explore all the codes via the faceted browser.

Figure 4: Grouping

Once the user has a set of results, it is possible he may want to further explore this space without having to refine his results. CODEcomp provides this through the grouping feature. Below the facets and along the left side of the screen, the user is provided with a listing of the same five items that appear in the facets (Code, Building Type, Category, Topic, and Sub-Topic). When the user selects a “grouping” field, each of the results in the main content area is put into a widget that contains a count of the number of provisions within it. This widget can be expanded and collapsed, giving the user a higher degree of control over what he is exploring.

Figure 3: Initial Selection

Once a user has made a selection, either from the faceted browser or the provision search, the interface will immediately update to provide results. In Figure 3, a SubTopic has been selected out of the facet (Solar) and the results that are returned are those provisions from all codes that have been categorized with Sub-Topic: Solar. The facets always show the taxonomy for the current data set, so after this initial selection the number of options in the facets will shrink, as well as the number of results. The user can either clear the current search and start over, or continue adding additional filters via the facets. For example, the user could select the Topic of “Glazing” and the UI would update again. Now the user is only shown the provisions that categorized as both Topic: Glazing and Sub-Topic: Solar.

DESIGN IMPLICATIONS

CODEcomp is a novel tool designed to act unlike any other traditional faceted browser. It not only provides a rapid method for locating data, it goes one step further to provide an analysis of that data. This analysis promotes easy code comparison in a maze of topic, sub-topics, and provisions. Through CODEcomp’s grouped search results, the user has the capability to recognize thesir provisions without having to modify the search, making traditional search engines, which require refining or paging away, cumbersome and obsolete. Traditional search methods make comparison difficult[20], since the results are not side by side. CODEComp re-organizes the search results without further limiting these results so the user can to explore the same data more effectively.

The user is provided with results that have been tagged to indicate how they have been classified. This will make finding related material much simpler, as it directly links each provision to the ontology outlined in the facets. This also gives the user an incredible amount of power to locate a provision based on a fairly abstract concept, and then narrow his search using facets to pinpoint the exact topic of interest.

Although a faceted browser provides many advantages, one drawback is that an unknowing user might unintentionally exclude provisions that are of interest by “over selecting.”[21] While CODEcomp does not allow a user to return a wholly empty search it is possible for a user to unintentionally exclude results that t might wish to see. An example might be limiting his results to the IECC code within the code facet, when a user might have wanted to see all of the codes. The grouping feature attempts to mitigate this risk, and it is much more likely that a user will not “over select” while using CODEcomp, as they can still explore a sizable dataset with ease.

Finally, the user may instantly update a search to query on a single provision. Tags listed for each provision will also contain a “browse similar provisions” link that will clear the current search and bring back only results that exactly match the selected provision. While this is similar to the provision search feature, it allows the user to start with an abstract understanding of what he is looking for, use the faceted browser to find a provision that matches this abstract, and then instantly find all provisions in the system that fit within the same criteria.

3

CONCLUSION

CODEcomp is a unique tool designed to ease the difficulties of navigating the complex world of Energy Codes. CODEComp’s structure, design and query techniques all contribute to it’s ability to return desired search results. The resulting application allows a variety of users to easily access the provisions contained across a wide array of energy codes. For the first time in this discipline, Energy Codes can be compared on a modern stage, using technology at its fullest to unlock future analysis. ACKNOWLEDGMENTS

The author would like to acknowledge the support and feedback of team members from CODEcomp and the Building Energy Code Program. Special thanks also goes to Department of Energy as well as the reviewers and editors who have helped refine this paper and the associated research. REFERENCES

1. Building Energy Codes Program. 18 May 2011. United States Department of Energy. 10 June 2011. http://www.energycodes.gov. 2. Department of Energy Energy Efficiency & Renewable Energy. “Codes 101.” United States Department of Energy. May 2010. 3. American Society of Heating, Refrigerating and AirConditioning Engineers. 2011. United States. http://www.ashrae.org 4. International Code Council. 2011. United States. http://www.iccsafe.org 5. 10 CFR 433 Energy Efficiency Standards for the Design and Construction of New Federal Commercial and Multi-Family High-Rise Residential Buildings. 2011. United States. http://ecfr.gpoaccess.gov/cgi/t/text/textidx?c=ecfr&rgn=div6&view=text&node=10:3.0.1.4.21. 1&idno=10 6. Conover, David and Bartlett, Rosemarie, and Halverson, Mark. “Comparison of Standard 90.1-07 and the 2009 IECC with Respect to Commercial Buildings.” Building Energy Codes Program. December 2009. 7. Apache SOLR. 7 July 2011. http://lucene.apache.org/solr/ 8. Elizabeth (Bess) Sadler, (2009) "Project Blacklight: a next generation library catalog at a first generation university", Library Hi Tech, Vol. 27 Iss: 1, pp.57 - 67 9. Stefaner Moritz, Urban Thomas, and Seefelder Marc. 2008. “Elastic Lists for Facet Browsing and Resource Analysis in the Enterprise.” In DEXA Workshops, pp. 397-401. IEEE Computer Society. 10. Cowell AJ, ML Gregory, EJ Marshall, and LR McGrath. 2009. "Knowledge Encapsulation

Framework for Collaborative Social Modeling." In AAAI Spring Symposium: Technosocial Predictive Analytics , vol. SS-09-09, pp. 12-19. AAAI Press, Menlo Park, CA. 11. Antonio Sanfilippo, Richard May, Gary Danielson, Bob Baddeley, Rick Riensche, Skip Kirby, Sharon Collins, Susan Thornton, Kenneth Washington, Matt Schrager, Jamie Van Randwyk, Bob Borchers, Doug Gatchell, "An Adaptive Visual Analytics Platform for Mobile Devices," sc, pp.74, Proceedings of the 2005 ACM/IEEE conference on Supercomputing, 2005 12. Dowson ST, JR Bruce, DM Best, RM Riensche, L Franklin, and WA Pike. 2009. "Visual Analytics for Law Enforcement: Deploying a Service-Oriented Analytic Framework for Web-based Visualization." In SPIE Defense, Sensing & Security, Visual Analytics for Homeland Defense and Security. 13. Cowell AJ, ML Gregory, EJ Marshall, and LR McGrath. 2009. "Automated Knowledge Annotation for Dynamic Collaborative Environments." In Proceedings of the 22nd International Florida Artificial Intelligence Research Society (FLAIRS) Conference , ed. HC Lane and HW Guesgen. AAAI Press, Menlo Park, CA. 14. Lowgren, Jonas and Stolterman, Erik. Thoughtful Interaction Design. The MIT Press. Cambridge, Massachusetts and London, England. 2004. pp. 1 15. MacDougall, Robert. “Recognition and Recall.” The Journal of Philosophy, Psychology and Scientific Methods. Vol. 1, No. 9 (Apr. 28, 1904), pp. 229-233 16. du Plessis, Erik. “Recognition versus recall.” Journal of Advertising Research, Vol 34(3), May-Jun 1994, 75-91. 17. Milner, Brenda. “Visual recognition and recall after right temporal-lobe excision in man.” Neuropsychologia, Volume 6, Issue 3, September 1968, Pages 191-209 18. Moritz Stefaner, Boris Muller, "Elastic lists for facet browsers," dexa, pp.217-221, 18th International Conference on Database and Expert Systems Applications (DEXA 2007), 2007 19. Knowledge Encapsulation Framework (KEF). Pacific Northwest National Laboratory. 2011. http://kef.pnl.gov 20. Kules, J. Kustanowitz, B. Shneiderman (2006) Categorizing Web Search Results Into Meaningful And Stable Categories Using Fast-Feature Techniques. International Conference on Digital Libraries 21. Sacco, Giovanni Maria. “Some Research Results in Dynamic Taxonomy and Faceted Search Systems.” Dipartimento di Informatica, Università di Torino Corso Svizzera, 185 10145 Torino, Italy.