Extended Environments Markup Language

From P2P Foundation
Jump to: navigation, search

Extended Environments Markup Language

URL = http://www.eeml.org/

Description

“The Extended Environments Markup Language (EEML) (which is the protocol around which much of Pachube is based) is being developed to make the idea of “dynamic, responsive and conversant environments” a reality. It works with existing construction standards like Industry Foundation Classes (IFCs), but exists to extend them to account for dynamic, responsive and, dare I say it, conversant buildings.

A key member of the Pachube team doing EEML development is Chris Leung.” (http://www.ugotrade.com/2009/01/28/pachube-patching-the-planet-interview-with-usman-haque/)

Discussion

Usman Haque:

“The Extended Environments Markup Language (EEML) (which is the protocol around which much of Pachube is based) is being developed to make the idea of “dynamic, responsive and conversant environments” a reality. It works with existing construction standards like Industry Foundation Classes (IFCs), but exists to extend them to account for dynamic, responsive and, dare I say it, conversant buildings. In the perhaps prosaic world of construction, this helps to facilitate a number of architectural requirements such as post-occupancy evaluation, realtime site-based environmental feedback at the design phase and simulations that synchronise with realworld installation. With EEML and Pachube you’ll be able to start working with, say, an Autocad model at the design phase, and include *real time* environmental data from the site, as well as to model expected sensor and assumed energy consumption data of the design; use the same model during the construction phase (because it will translate fine to standard modelling descriptions), and keep working with the same set of information even after the building is occupied and running — making it a whole lot easier to learn from the design and maintenance processes than it is currently. At the same time this does not exclude the possiblity of talking about “sensors” (as SensorML wants to), but we are more easily able to consider, say, the dozens of different ways that different clients will want to address, access or search for those sensors; the changing contextual motivations for actually processing sensor information; and the capacity for flexible sensor ontologies — where you don’t need to know from the beginning everything you’ll be looking for once you’ve recorded mountains of data.” (http://www.ugotrade.com/2009/01/28/pachube-patching-the-planet-interview-with-usman-haque/)