Protocol for sharing sensor data between remote environments, based on an extension of Industry Foundation Classes
Extended Environments Markup Language (EEML) is a protocol for sharing real time sensor data between remote responsive environments, both physical and virtual. It can be used to facilitate direct connections between any two environments; it can also be used to facilitate many-to-many connections as implemented by the web service Pachube, which enables people to tag and share real time sensor data from objects, devices and spaces around the world. Further information is available at http://www.eeml.org/ (now owned by LogMeIn, following the acquisition of Pachube).
EEML became the core protocol used by Pachube as described here. A Ruby wrapper and Python package for EEML were also available. This page is retained to document the original intention behind the Extended Environments Markup Language initiative.
EEML supports installations, buildings, devices and events that collect environmental data and enables people to share this resource in realtime either within their own organisations or with the world as a whole via an internet connection or mobile network access. It can enable buildings to "talk", sharing remote environmental sensor data across the network in order to make local decisions based on wider, global perspectives. The EEML protocol supports datastream sources that respond to and exchange data with other installations, buildings, devices and events through data stream tagging. (This user-configurability allows people who use Pachube to identify their datastreams to others who can then search for data streams that they want to use).
EEML is a markup language that describes the data output of sensors and actuators, often in an architectural context but also in interactive environments, interface devices and even Second Life. Crucially, EEML supports the addition of context or "meta-data" about where the data came from. This is meaningful both to machines and humans when searching for data streams that they particularly need without knowing the exact details of the source. It is also important for those wishing to make spontaneous or previously unplanned connections between data streams from different sources with common contexts. The source that EEML is designed to support is data from sensors and devices deployed in the environment. The term "environment" encompasses both the physical world of, for example your home or studio as well as the virtual world of, for example Second Life.
EEML can be used along side well-established XML formats for data interchange such as Industry Foundation Classes in the construction industry, developed by the International Alliance for Interoperability where IFC2x has gained acceptance as one of the formats for Building Information Modeling or BIM. Crucially, using EEML, sensor data from buildings can be mapped onto building components in realtime and exchanged with simulation software and facilities management software thus extending the benefits of BIM to the post-occupancy phase.
EEML is designed to be extensible to support on-going development of types of responsive environments not envisaged at the start of development.
The precursor to EEML was known as Environment XML, released in 2006, which provided a kind of "RSS feed" for tagged environmental data, enabling anyone to release realtime environmental data from a physical object or space in XML format via the internet in such a way that this content becomes part of the input data to spaces/interfaces/objects designed by other people.
Just as Flickr does with photos, Environment XML would enable this data to be shared, tagged and aggregated with similarly tagged temperature data from a number of other projects streaming from around the world and would itself form part of a wider global temperature-related data stream that could become inputs to other's projects.
As a first step this project is being constructed using Processing/Arduino which many designers and artists use for their interactive objects and environments. Data could include local temperature; local light level; the height of a pile of dirty dishes; whether windows were open or closed; whether bookshelves were empty; the length of the shadow of the neighbouring building; the number of people currently interacting with the device; or even people's positions in space. The designer simply needs to provide the sensors to calculate these variables - the Processing/Arduino combo would stream the data.
Just like Flickr, the environment "transmitter" (i.e. your project) would tag the data on its way out to the public, and the environment "receiver" (i.e. somoeone else's project) would interpret the tags in whatever way they need. The data might be used by an object, or perhaps a spatial interface (projection, facade, acoustic environment) or even simply a web-based processing applet or flash swf.
With Environment XML, a designer could choose what environmental data to have their space/interface respond to; from particular remote spaces, from an aggregate of many spaces, from an aggregate of environmental variables around the planet, or from any number of things that, crucially, the people who released that data did not necessarily plan for. All that is required is the Processing/Arduino/EnvironmentXML combo, an internet connection and a design for something that "does something". If you use the Environment XML data you will also be required to share your own data with others.