I think David stated my position correctly. Except that I would not define buyer/seller as a role. Buy or sell is the Side of a Tender or a Transaction and the Side may change with each Tender or Transaction. ( in my early writing for this group I used Party role for buy/seller but saw the error in this).
With respect to Toby’s statements:
“So are all Wal-Marts in North America identified as the same PartyID? If so, Registration is primarily concerns with identifying your PartyId.”
My answer is Wal-Mart can register a PartyID for each store or a PartyID for each Store and an Account for each store. It may also have trading accounts not associated with a store but a trading hub with no meter. Registration is concerned with assigning a Party ID and Account IDs for the Party.
My view is that a Party is not required to be 1-1 with a VEN but can be in some cases. A VEN is 1-1 with a ResourceID, but a ResourceID in the CIM is defined, for example, for generators. I don’t think we will be clear if EI calls nuclear generators VENs. I believe the IRC assigns a Resource ID for a DR Resource. So if we don’t want both just use Resource ID. So the unanswered question is why do we need a VENID?
The concept of a Resource Aggregator and Dispatcher/Manager ( Gale Horst called this is a REC – Resource Energy Controller ) seems to be what a VTN is about. In any case a relationship between a Resource and a REC or a VEN and VTN is established in the context of enrollment in a Program wherein these roles are established for that Program. Note that this is similar to Side (Buy or Sell) that is established as an element of a Tender or Transaction and not as a role for a Party.
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los
Altos, CA 94022
650-949-5274
cell: 408-621-2772
www.cazalet.com
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los
Altos, CA 94022
650-949-5274
cell: 408-621-2772
www.cazalet.com
From:
Girish Ghatikar [mailto:]
Sent: Wednesday, July 27, 2011 7:10 AM
To: Considine, Toby (Campus Services IT)
Cc: Holmberg, David; ; Bartell, Bruce; Ed Cazalet; Koch, Edward;
Subject: Re: [energyinterop] Registration and Party IDs
This discussion seems like it's worth spending some time on defining the relationships between VTN, VEN, Parties, and resources (others?) -- in different scenarios/applications.
Thanks,
-Rish
On Wed, Jul 27, 2011 at 7:05 AM, Considine, Toby (Campus Services IT) <
> wrote:
Some inconsistency here…
If a Party is 1-1 with a VEN (if it is a VEN), and if a VEN is 1-1 with a Resource, why do we need a ResourceID? Can a resource be moved to a different VEN? Can a Resource be transferred to a different Party? Is it because a Resource can be resold by an aggregator?
“You can’t have multiple Parties per customer”
So are all Wallmarts in North America identified as the same PartyID? If so, Registration is primarily concerns with identifying your PartyId.
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
From:
Holmberg, David [mailto: ]
Sent: Wednesday, July 27, 2011 9:55 AM
To:
; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward';
Subject: RE: [energyinterop] Registration and Party IDs
Toby,
It seems you and EdC have a different perspective on Party. You seem to view it as equivalent to a resource, such that VEN is identified with a PartyID. EdC sees it as a customer with an account (or a customer with a SDP). This allows a Party to have multiple resources. Thus, a VEN has an associated PartyID, but a Party may have 0 to * Resources. Bill agrees with this, I think, or at least that a Party is not the same as a Resource. I think then that a Party is tied closely to a customer and you can’t have multiple Parties per customer. But a VEN and Resource are 1 to 1.
Interesting question about VTN/VEN, buyer/seller. I think a customer has a PartyID, and enters into market transactions to either buy or sell some resource. If selling, there should be an indication of that role, but not a SellerID, and there will be an associated ResourceID (for the generator or DR resource). If buying, there will be an indication of that role, and no associated ResourceID. A VEN should have an associated PartyID, SDP (meter mRID maybe, premise location?), and URL. Whether something is acting as VEN or VTN is maybe simply a role that is also indicated in a service exchange.
David
From:
Toby Considine [mailto: ] On Behalf Of Toby Considine Sent: Wednesday, July 27, 2011 9:10 AM
To: 'Bartell, Bruce'; 'Ed Cazalet'; Holmberg, David; 'Koch, Edward';
Subject: RE: [energyinterop] Registration and Party IDs
Slight change of pace here – into the schemas
We seem to be congealing around “Registration is how you get a Party ID”
A VEN is identified by a PartyID
A VTN is identified by a PartyID
A Transactive [agent] is identified by a PartyID
Several Parties may be part of some larger entity. If the Parties are acting as VENs, we may call that larger entity a Customer.
-
A Customer is the business entity behind 1-to-many VENs that have a common relationship to the entity behind a VTN , each identified by a PartyID.
-
Is there a common entity behind multiple VTNs that should have an ID as well?
-
Is there a common entity behind multiple [agents] as well?
Parties have Roles: “Buyer” and “Seller”. Should we have a BuyerID and a SellerID instead of a CustomerID and “%%%”?
The eiParty is an existing type. The type consists of a partyID, a partyName, and a partyRole. Is this correct? Does it line up with the narrative above? If so, then it implies that a party enrolling as both a VTN and as a VEN should have two PartyIDs. This does not feel correct.
Where does the eiParty fit in the Transactive world?
tc
"He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
Toby Considine TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Email:
Phone: (919)619-2104
http://www.tcnine.com/ blog: www.NewDaedalus.com
--
Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111,
Berkeley, CA 94720
+1 510.486.6768
+1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].
