Digital and intelligent buildings are critical to realizing efficient building energy operations and a smart grid. With the increasing digitalization of processes throughout the life cycle of buildings, data exchanged between stakeholders and between building systems have grown significantly. However, a lack of semantic interoperability between data in different systems is still prevalent and hinders the development of energy-oriented applications that can be reused across buildings, limiting the scalability of innovative solutions. Addressing this challenge, our review paper systematically reviews metadata schemas and ontologies that are at the foundation of semantic interoperability necessary to move toward improved building energy operations. The review finds 40 schemas that span different phases of the building life cycle, most of which cover commercial building operations and, in particular, control and monitoring systems. The paper’s deeper review and analysis of five popular schemas identify several gaps in their ability to fully facilitate the work of a building modeler attempting to support three use cases: energy audits, automated fault detection and diagnosis, and optimal control. Our findings demonstrate that building modelers focused on energy use cases will find it difficult, labor intensive, and costly to create, sustain, and use semantic models with existing ontologies. This underscores the significant work still to be done to enable interoperable, usable, and maintainable building models. We make three recommendations for future work by the building modeling and energy communities: a centralized repository with a search engine for relevant schemas, the development of more use cases, and better harmonization and standardization of schemas in collaboration with industry to facilitate their adoption by stakeholders addressing varied energy-focused use cases.

The CSCW community is reliant upon technology-centric models of groupware and collaboration that frame how we examine and design for cooperative work. This paper both reviews the CSCW literature to examine existing models of collaborative work and proposes a new, expanded conceptual model: the Model of Coordinated Action (MoCA). MoCA is a broader framework for describing complex collaborative situations and environments including, but not limited to, collaborations that have diverse, high-turnover memberships or emerging practices. We introduce MoCA's seven dimensions of coordinative action and illustrate their connection to past and current CSCW research. Finally, we discuss some ramifications of MoCA for our understanding of CSCW as a sociotechnical design space.

Software is an integral element of the work of science yet it is not commonly an object of inquiry in studies of scientific infrastructures. This paper presents findings from an ethnographic study of a cosmology group's collaborative scientific software production. We demonstrate how these cosmologists use plots to simultaneously test their software and analyze data while interrogating multiple layers of infrastructural components. We broaden perspectives on scientific software development using a sociotechnical, software studies lens to examine this work of scientific discovery as a creative and embodied, yet exacting and methodical, activity that requires a 'human in the loop'. We offer a new reading of scientific software practices to convey how creating scientific software is often really the act of doing science itself--an intervention we believe is necessary to more successfully support scientific software sharing and infrastructure production.

Middleware software, which provides an abstraction layer between low-level computational services and domain-specific applications, is a key component of cyberinfrastructure. This paper presents a qualitative study of how cyberinfrastructure middleware development is accomplished in two supercomputing centers. Our investigation highlights key development phases in the lives of middleware projects. Middleware development is typically undertaken as part of collaborations between technologists and domain scientists, and middleware developers must balance the pressure to meet specific scientific needs and the desire to explore their own R&D agendas. We explore how developers work to sustain an ongoing development trajectory by aligning their own work with particular domain science projects and funding streams. However, we find that the key transition from being a component in a domain-specific project to a stand-alone system that is useful across domains is particularly challenging for middleware development. We provide organizational and national policy implications for how to better support this transition.

This paper considers sensemaking as it relates to everyday software engineering (SE) work practices and draws on a multi-year ethnographic study of SE projects at a large, global technology company building digital services infused with artificial intelligence (AI) and machine learning (ML) capabilities. Our findings highlight the breadth of sensemaking practices in AI/ML projects, noting developers' efforts to make sense of AI/ML environments (e.g., algorithms/methods and libraries), of AI/ML model ecosystems (e.g., pre-trained models and "upstream" models), and of business-AI relations (e.g., how the AI/ML service relates to the domain context and business problem at hand). This paper builds on recent scholarship drawing attention to the integral role of sensemaking in everyday SE practices by empirically investigating how and in what ways AI/ML projects present software teams with emergent sensemaking requirements and opportunities.

The production and use of software pipelines is a key component of much modern scientific research. We present emerging findings from our qualitative, social science study of a radio astronomy group developing software pipelines as they produce a data processing infrastructure. This paper examines how these researchers co-produce data products and software pipelines to enact their research infrastructure. We investigate the work of co-producing data and software to illustrate that to better support data-intensive science, we need to understand the practices that enable and produce data products, software, and ultimately infrastructures.