Skip to Content

Enactment and the Unit Registry

Printer-friendly versionPrinter-friendly version
Fall 2010

Mason Kortz (CCE,PAL)

The lifecycle of a technical project is often divided into three phases: Design, Development, and Deployment. Science studies researchers have identified a fourth phase that both follows and supports the previous three: Enactment. Enactment is the encouragement of usage of a standard or resource within the target community. Enactment also provides feedback to the developers, which may result in further iterations of the project lifecycle. This article summarizes the Unit Registry enactment activities over the last several months, as well as the benefits provided by this approach.

Summary of Prior Phases

The LTER Unit Working group began a community-based Design phase of the Unit Registry ( in spring 2009. Following the design phase, programmers Mason Kortz and James Conners began the Development phase in summer 2009. The first release of the Unit Registry web service was in fall 2009, followed by a web client with browse, search, and management capabilities in winter 2010. With the completion of the web client, the primary development cycle of the Unit Registry was finished, and in spring 2010 the working group began the Deployment phase. Deployment of the Unit Registry involved migrating web services, clients, content, and documentation to LNO servers, where they would be available to the LTER community. With the software, source code, and documentation deployed, the Unit Registry project proceeded to the Enactment phase.

Cross-Site Visits

The CCE and PAL LTER sites have hosted two cross-site visits in San Diego as part of the Enactment phase of the Unit Registry project: one in May 2010 with Sven Bohm (information manager, KBS LTER), and a second in August 2010 with Ken Ramsey (information manager, JRN LTER) and Justin Jensen (programmer, JRN LTER). The goals of these meetings were numerous: to develop clients that would allow KBS and JRN to use the Registry; to ingest the KBS and JRN custom units into the Registry database; to gain feedback on and make changes to the existing Registry data model, service, and client; and finally, to understand the benefits of a face-to-face enactment meeting so that we could improve future site visits.

The primary focus of the site visits was enactment at a technical level. During both visits, a client was developed that would integrated the Unit Registry web service with the site’s existing metadata system. We, as Unit Registry developers, were able to provide guidelines for the development of site clients and rapidly address bugs, missing features, or unclear documentation. The visiting site representatives were able to work with us to design an approach that would leverage the network-level aspects of the Unit Registry while supporting their site needs. By the end of each three-day visit, the site had a functioning client that was integrated with their local site metadata system, and the Unit Registry had been improved for future usage.

In addition to the technical enactment goals, each visit culminated with a discussion about the value of small, face-to-face meetings. While costs prevent meeting individually with every site, the two enactment visits provided two key benefits. First, it allowed a period of rapid design and development for both the sites and the Unit Registry, allowing us to gain experience and make improvements that would facilitate future remote enactment steps. The models that KBS and JRN are using to access the Unit Registry provide concrete working examples for other sites implementing a unit system. Second, the visits demonstrated the viability of site-developed modules providing network-level resources as part of the LTER Network Information System.

Developer/Network Office Visit

In June 2010, the Unit Registry developers visited the LTER Network Office for three days. The scheduled purpose of the visit was to migrate the Registry to an LNO server, completing the Deployment phase of the project. Due to the planning and support provided by the LNO technical team, the software migration took much less time than anticipated. This allowed us to focus on discussions about the integration of the Unit Registry, as well as site-developed web services in general, into the larger LTER Network Information System. This turned out to be an essential step in the enactment not just of the Unit Registry project, but also represented part of the enactment of the Network Information System as a whole.

The Unit Registry developers are responsible for providing a product to the LTER network, but are also clients, or enactors, in the network as well. The three-day visit to LNO gave an opportunity for the NIS developers to engage us in this capacity, providing information and receiving feedback much as we did with KBS and JRN during the site visits in San Diego. The result is that we accomplished both the technical task of migrating the database and the organizational task of learning how the NIS development would impact information managers both as users and developers.

Unit Ingestion Effort

Following the 2010 IMC meeting, Unit Working Group co-chair Linda Powell has been helping sites to submit their custom units to the Unit Registry. Part of the feedback we received during the site visits was that having a common space to address unit standardization would have to occur before the standards-making process could be complete. To meet this goal, we have encouraged all sites to contribute units regardless of compliance with the current Best Practices. The LTER sites have shown great support for this initiative – 17 sites have responded with unit lists, and the remaining sites are working to compile and submit units in the near future.

The Benefits of Targeted Enactment

The Unit Working Group has pursued a policy of targeted enactment for the Unit Registry project. This means that in addition to using broad, open-ended enactment steps – public documentation, demos, and VTCs – we have arranged for and participated in dialogues with individuals or smalls groups to encourage use of the Registry. This type of targeted enactment is expensive,both in terms of funding (for the site and LNO visits) and time (Linda has spent a great deal of time in the last month and a half helping IMs submit their units).

However, there are noticeable benefits to this approach. Targeted enactment allows for rapid response to specific enactors’ concerns. Not only does this feedback improve the project as whole, the quick response also improves confidence in the product. Enactors who feel directly engaged are more likely to participate in the project, be it as users, testers, or future developers. Such users are also able to engage other members of the community. Thus the enactment of the project builds on itself and spreads throughout the network. With the Unit Registry, we have already seen sites using and contributing to the Registry who were not part of the site visits, but who are building off the products, both technical and organizational, that resulted from them. As we move forward, we hope that use of the Unit Registry will continue to grow and that the project lifecycle can provide a model for future product development, from Design to Enactment.