Re: [emix] EMIX use cases showing requirements for defining geographicregions

[Anne Hendry <ahendry@pacbell.net>]

IF EMIX includes Meter, THEN it includes Region.

The conclusion does not necessarily follow.

As a matter of fact, the more I delve into the California tiered pricing example, the less it follows.  The way seeming location-dependent decisions are made in the California example is grounded in practicality with people making decisions that fallback on a system of pre-existing conditions, data, and common practices that have less to do with specifying precise regional boundaries and more to do with common knowledge, best practices, and historical decisions.  And it's much more focused on specific delivery points than regions of service.  That is why I was asking for more use cases.

Regardless, for possible future use cases, I'd like to advocate a more general/generic approach following the 80/20 rule, which is to provide a level of basic locational support to cover the majority of our use cases.  That could include allowing for multiple 'locations' that could be interpreted as a 'region', but that interpretation would happen at a level beyond EMIX (at the trading partner level, for instance) by including the ability for users to specify a coordinate system of choice if they want a different interpretation applied to that generic support.  The argument for this approach is that there exist (and are constantly coming into being) many distinct systems for identifying a specific location in space and we shouldn't constrain users to any specific system of interpretation.  This approach also allows for transition from existing/legacy systems.


-A


Considine, Toby (Campus Services IT) wrote, On 2/24/2011 4:22 AM:

49388A5276025649AC24AF97ADB9DA62711D7FDF45@facmailmb3.facilities.unc.edu" type="cite">

Energy is time and location sensitive. IF EMIX includes Meter, THEN it includes Region. An argument could be made that it excludes both, but I do no thin that's a winning argument.

tc


"It is the theory that decides what can be observed."   - Albert Einstein

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
http://www.oasis-open.org 
blog: www.NewDaedalus.com



-----Original Message-----
From: Anne Hendry [mailto:ahendry@pacbell.net] 
Sent: Wednesday, February 23, 2011 10:59 PM
To: Considine, Toby (Campus Services IT)
Cc: emix@lists.oasis-open.org
Subject: Re: [emix] EMIX use cases showing requirements for defining geographic regions

Do you consider that in scope for EMIX?

Considine, Toby (Campus Services IT) wrote, On 2/23/2011 6:46 PM:
  

One thing that *I* have been asked about is EI signals going out by FM radio. In some parts of CA, DR signals have been sent by CAP alert. Clearly, I, in my house, will not be contacted by CAP alert directed at my meter, so the question is how will I know it is for me....

Geographical polygon is the natural follow-on.



"It is the theory that decides what can be observed."   - Albert Einstein

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture 
Committee Facilities Technology Office University of North Carolina 
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com


-----Original Message-----
From: Anne Hendry [mailto:ahendry@pacbell.net] 
Sent: Wednesday, February 23, 2011 6:11 PM
To: emix@lists.oasis-open.org
Subject: [emix] EMIX use cases showing requirements for defining geographic regions

I'm looking for any EMIX use cases that show there is a requirement for defining a geographic region when communicating price and/or product information.  I know the discussion started some time ago, but don't recall the reason/driver.  I know about California tiered pricing based on climate zones as one example, but am assuming there are more ...

Thanks,
-A



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php