Energy Market Information Exchange is an XML vocabulary to express
price and characteristics, so the means of communicating is not part of
I can't speak to the oBIX data modeling.
Brian Frank wrote:
Hi Bill and Toby,
Any potential integration with oBIX and its data modeling?
Is the intention of this specification to be a REST-ful data model with
On Tue, Jul 28, 2009 at 5:46 PM, William Cox
The attached charter for the
OASIS Energy Market Information Technical
Committee is ready for submission to OASIS to formally create the TC
after a review period.
If you would like to be added as a supporter, please contact me and
Toby Considine immediately; I'll be sending reconfirmation emails to
those on my list in the next 24 hours or so.
This work addresses portions of the price cross cutting issue and
action plan in the NIST Smart Grid program, though the genesis predates
that work. See section 6.2.1 of the Interim Roadmap at
and the Priority Action Plan (a living document) at
Background information from the first draft charter (message at
). Thanks to the many reviewers; all remaining errors are mine.
This TC is intended to address the prices,
other information for energy trading, buying, and selling. I was
inspired to start working on this from discussions in and around the
NIST Building-to-Grid and Industry-to-Grid Domain Expert Working
Groups, and continued interest from first round reviewers and from
people attending GridEcon 2009 in Chicago (http://www.gridecon.com
slides are available on line at the agenda link).
>From my perspective as an enterprise software architect, this fits
a simple three layer stack with interoperation protocols (how
to communicate) as the fundamental layer. I put the OASIS Energy
Interoperation TC/OpenADR work here
), with parts of the message payload
in the next layer.
The middle layer is what is communicated -- for
markets, things like price, quantity, units, time (of use), and
characteristics of the energy sold -- from source (e.g. gas-fired
plants, coal, solar, coal plant with scrubbers, wind) to derived
information (e.g. carbon data), and also trading information (is this a
bid, a price quote, an accepted transaction?).
The goal is to create an XML vocabulary that can be used in a broad
range of market exchanges with minimal differences (and where there are
differences, arranged in a simple way) for the various consumers of the
The third layer is the market design and definition; since markets have
varying degrees of complexity I'm leaving this alone for now :-). This
is a potentially complex area, and an interesting one. Accordingly, I'd
like to carefully define the EMIX work to focus on layer two.
Thanks for your interest.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com