Tariff ontology/language

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tariff ontology/language

grampajohn
Administrator
One of the things that I think may be holding us up is not knowing exactly what a tariff is. I've looked at Prashant's proposed tariff structure, and I went back and looked at the ontology that Carsten worked on briefly last year. I'm becoming convinced that a tariff needs to be expressed as a set of statements/clauses in a formal language, rather than a rigid data structure. That means we need a grammar and semantics. I propose we use OWL for describing tariffs, along with a formal ontology. This is not terribly hard to do, and if we stick with OWL-DL, there are fast inference engines available that will work in our technical environment, such as Pellet. We used OWL-DL and Pellet in the MinneTAC annotations project, and it was quite successful.

Here's a UML class diagram that represents a first cut. It does not yet address all the issues, and I have not yet tried constructing the formal ontology, but this may give you a flavor of concepts and relationships. As always, your comments and suggestions are welcome. I would plan to put the ontology itself into the domain-data repository. You will need a copy of Protege (I'm using 4.1) to work on this.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tariff ontology/language

grampajohn
Administrator
I have committed a first draft of a Tariff ontology in domain-data. You may use your favorite OWL tool to examine it - I use Protege-OWL version 4.1.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tariff ontology/language

Carsten Block
Administrator
Hi John,

very nice ontology. No doubt about that!
When looking at it in more detail a statement about TAC AdAuctions that David Pardoe made back in Austin came into my mind. He basically stated that the AdAuctions domain is very complex with about 180 different relevant attributes end users can adjust in the production systems of google or yahoo. Then he said that the game developers in the group of Michael Wellmann did an excellent job reducing the complexity of the real domain by cautiously choosing a subset of product attributes, which essentially lead to a competition product space of 4 x 4 (right, Wolf?) different product combinations.

What does that mean for our project? So far we developed a product space, which enables us to realistically describe all kinds of tariffs for the energy domain. But as we're not aiming for a simulation in agent based computational economics but a competitive simulation, which needs to attract even domain outsiders (such as David Pardoe), the hard part - I feel - is still in front of us: Drastically cutting complexity!

Thoughts anybody?

Cheers,
Carsten     
  


Am 27.11.2010 um 21:19 schrieb grampajohn [via Power TAC Developers]:

I have committed a first draft of a Tariff ontology in domain-data. You may use your favorite OWL tool to examine it - I use Protege-OWL version 4.1.


View message @ http://power-tac-developers.975333.n3.nabble.com/Tariff-ontology-language-tp1964514p1978955.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tariff ontology/language

grampajohn
Administrator
I agree that it's too complex, and I've been thinking about exactly how
to simplify it. However, I feel like we need to understand the full
problem before we decide how to simplify it. Otherwise, we run the risk
of completely omitting an important dimension. So what I'm hoping is
that we can start with a rich description and then decide which
dimensions to remove or simplify in a way that we can explain in a way
that will be credible to those who are possibly more familiar with the
domain than we are.

A couple of thoughts:

- the version I committed does not deal with power sources, so you
cannot yet offer a tariff that guarantees a limit on carbon content, or
that 50% comes from wind, or whatever. I have a revision almost ready to
cover that.

- I can see three ways to simplify: (1) remove dimensions, (2) reduce
the number of options along a dimension, by making a continuous
dimension discrete, and by reducing the number of choices along a
discrete dimension, and (3) restrict combinations of choices across
multiple dimensions.

Having the full richness of the domain in the ontology does not mean
that all combinations need to be valid. It will, however, make it much
easier to adjust our decisions about which features to emphasize in the
competition, and it may make it much easier for researchers to
experiment with choices that are simplified out of the competition version.

So let's do two things to make progress:

1. Choose a small subset to implement as a prototype. We can probably
write SWRL rules for validation, which would then define the subset.

2. Work out a target set of features for Version 1.0, and incrementally
add features until we get there.

Here's an example of a simple subset:
- Choice of fixed rate, time-of-use rate without weekends, or variable
rate with one-hour notice.
- Production rates equal to consumption rates with a fixed discount ratio.
- Two-part tariff possible with a fixed periodic payment.
- Fixed contract duration (6 months?). Open question: what happens when
the contract expires?
- No signup fee/credit
- Fixed penalty for early withdrawal equal to some portion of (expected)
monthly bill, prorated by the remaining contract duration.
- No batteries or thermal storage.

I'm sure there's more, but let's work out how to formalize the subset
before we go too much further.

John


On 11/29/2010 01:33 AM, Carsten Block [via Power TAC Developers] wrote:

> Hi John,
>
> very nice ontology. No doubt about that!
> When looking at it in more detail a statement about TAC AdAuctions that
> David Pardoe made back in Austin came into my mind. He basically stated
> that the AdAuctions domain is very complex with about 180 different
> relevant attributes end users can adjust in the production systems of
> google or yahoo. Then he said that the game developers in the group of
> Michael Wellmann did an excellent job reducing the complexity of the
> real domain by cautiously choosing a subset of product attributes, which
> essentially lead to a competition product space of 4 x 4 (right, Wolf?)
> different product combinations.
>
> What does that mean for our project? So far we developed a product
> space, which enables us to realistically describe all kinds of tariffs
> for the energy domain. But as we're not aiming for a simulation in agent
> based computational economics but a competitive simulation, which needs
> to attract even domain outsiders (such as David Pardoe), the hard part -
> I feel - is still in front of us: Drastically cutting complexity!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tariff ontology/language

grampajohn
Administrator
This post was updated on .
I have posted a class diagram and a short wiki page with a proposal for a simplified tariff structure that retains many of the important elements of the full ontology, with the exception of bundling across multiple power types (consumption, production, electric vehicles, etc.). The class diagram and explanation are in the domain-data wiki on github. It should be a simple matter to implement this structure. It's compact for simple tariffs, and should be serializable in one step for transport.

I have been looking through a set of published tariffs in the UK and I believe we can represent all of them with this structure.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tariff feature: interruptibility

grampajohn
Administrator
I'm working on the tariff representation description for the game specification, and I think we need one more feature in the tariff. The problem is that some energy sources (CHP for example), as well as batteries and EVs, should allow some amount of external control, in exchange for payment or discount/premium. For example, a home or greenhouse with a CHP system would presumably be willing to allow their power output (and therefore temperature) to vary somewhat in exchange for a premium price. This is just another example of load-shifting, and should not be hard to model.

In fact, interruptible loads are really the same thing. A household with an interruptible water heater or heat pump is simply offering to allow the broker to shift their loads by some amount in exchange for a discount on their rates for that portion of their consumption.

So my question is, should we eliminate "interruptible load" as a separate PowerType, and integrate interruptible loads and sources into the representation in a simple way? One possibility could be that Customer models incorporate some portion of interruptible loads, and that a defined portion of CHP output is also interruptible. Tariffs could then simply specify a discount for interruptible loads, and a premium for interruptible sources, which is applied to whatever rate is in effect at the time the interruption happens.

When does interruption happen, you ask? It happens when a Broker bids it into the balancing market, and the bid is accepted. The Broker is then credited or debited for the amount of the interruptible capacity used, and the Customer's consumption or production is adjusted accordingly. Of course, the missing production or consumption will then need to show up in a subsequent timeslot, because these actions cause time-shifting, not an overall increase or decrease in production/consumption.
Loading...