Understanding Inheritance in WS-Calendar

Traditional service communications have assumed near real time response. Traditional schedule ahead markets have been similar to the informally communicated “allow two weeks for shipping”. Smart energy markets demand we do better, scheduling delivery of services, now and in the future, within 15 minute windows or even within 4 second intervals. Prices, and delivery and consumption will all swing every hour of every day. Real opportunities will arise for those who can help the consumer in the home or commercial property buy low, sell high, and buffer their internal needs in between.

This requires clear communication of time and schedule, whether we are talking price, or product, or service. WS-Calendar is a new specification that will be at the center of new market communications. WS-Calendar extends enterprise standards used for personal and business schedules to service communications and markets. WS-Calendar defines the Interval, and relationships between Intervals to create the Sequence. The power of WS-Calendar comes from remotely referencing Sequences and in influencing Sequences that are incomplete to define actionable services.

Sequences are composed of intervals for which a set of temporal relations have been defined. ICalendar has long defined relationships between calendar components, intervals are just another calendar component. In WS-Calendar, we reference a sequence by defining a “parent” relationship with any single interval in the sequence. We refer to the interval within a sequence that has this relationship as the Designated Interval.

Wherever there is “missing” information in the Designated Interval, it can be inherited is inherited from the referring component; we use the “parent” relationship to reference the designated interval. These references may be local or remote. Some, but not all, of the information can be inherited by the other intervals in the sequence. Adding additional references can further specify information in the sequence through inheritance; these additional references created by specifying an additional component that has a parent relation to the previous referring component. In this way, we can create a grand-parent and a great grand-parent.

Each parent bequeaths information to its child. A child inherits this information in accord with the inheritance rules. If the child is itself a parent, it bequeaths its information, the bound result of its internal information and its inheritance, to its child. Information to complete the specification of a sequence flows in this way from parent to child, from the outer reference to the inner sequence.

Inheritance by the designated interval is governed by slightly different inheritance rules than the other intervals in the sequence. In particular, only the designated interval can inherit the start date and time from its parent. The starting date and times if other intervals in a sequence are computed using the temporal relationships within the sequence. Other information can be inherited by all intervals in a sequence. Other specifications that incorporate WS-Calendar must define how inheritnace will work with their payloads.

The referring components are called Gluons. In physics, gluons are particles that affect the exchanges of force between quarks, but are not themselves quarks. By analogy, WS-Calendar Gluons affect the referencing and binding of intervals in a sequence, but are not themselves intervals or part of sequences. Because intervals can inherit almost any property from a Gluon, Gluons must contain most of the same information elements as Intervals. Because Intervals can contain information payloads for specifications that use WS-Calendar, and these payloads can inherit information from gluons in the same way intervals do, Gluons must be able to contain information payloads from those specifications as well.

Gluons are essentially pretty simple. They can be incorporated as part of a larger communication, whether e-commerce or building controls (oBIX). This gluon can invoke a sequence, or modify it, or both with a single call.

BSI and a blast from the past

Every now and then I run across an old email that I have long forgotten, but speaks to my current activities. I think that this comment, written long ago in the oBIX forum speaks to something I need to return to. Jon recently gave me and WS-Calendar and EMIX some excellent advice on on creating standards for re-use and extension.

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
Sent: Wednesday, January 05, 2005 6:36 AM
To: 'jon.bosak@sun.com'
Cc: 'Grobler, Francois ERDC-CERL-IL'
Subject: RE: oBIX Guiding Principles

There are parts of Control Systems that are very business oriented. If an embedded control system detects that it needs maintenance, and can submit a maintenance request to an identified partner, clearly that work order looks like a normal business transaction.

Meeting and occupancy schedules might look like UBL (room will be occupied tomorrow from 2-4; use oBIX to inform HVAC, Access Control, Intrusion Detection, A/V management control systems. Read the Electric Meter before and after the meeting). Does the UBL standard extend the ICAL standard, or subsume it or...? Clearly, there is a benefit for scheduling functions to re-use commonly implemented scheduling requests.

These functions are in the future. What oBIX has to start with doing is exposing the event driven world of controls to the enterprise. For the most part, this starts with state. What are all the room temperatures on the 3rd and 4th floors? For how many hours did the compressors run today?Which areas of the building are currently secured? Some of this information is creeping into QOS agreements in real estate, and so intersects with the work of OSCRE (Open Systems for Commercial Real Estate). To my knowledge, UBL does not really include the nomenclatures for this because this is outside of the normal business functions. Am I wrong? Can you refer me to any relevant portions of UBL?

I think an early use for oBIX will be to provide a platform on which GRIDWISE (www.gridwise.org) type applications are built. That may be the first place where standard UBL functions hit, as price incentives are offered to buildings on the spot market to forefend brown-outs and the like. That feels more like bid/delivery/request rebate.

The construction industry has long had a separate open standard for construction documents, known as the IFC (Industry Foundation Classes) developed by the International Association for Interoperability (http://www.iai-international.org/iai_international/) and already required in many international construction projects. The IFC space includes construction documents, spatial data, spatial modeling, etc. The EU, in particular, leans heavily on this ISO specification, particularly in the Nordic countries. The largest landlord in the world, the GSA, has mandated that all transmittals for the design, construction, and acceptance of buildings. The closely related GBXML (Green Building XML) is a lightweight variant of IFCXML focused more on performance issues. GB Modeling, using GBXML for transferring building performance data, is required for those projects that wish to be designated as compliant with programs using words such as "sustainable" and "LEEDS". We have long considered that IFCML and the closely related GBXML were our most important shared spaces. Is there a defined interface/mapping between IFCXML and UBL?

Thanks for your comments

tc

-----Original Message-----
From: jon.bosak@sun.com
Sent: Tuesday, January 04, 2005 9:20 PM
To: Considine, Toby (Facilities Technology Office)
Subject: Re: oBIX Guiding Principles

| G) If, as seem likely, this document is adopted as an OASIS standard,
| I recommend that we steal freely from this document, reusing as much
| as we can in our rules for developing subsidiary oBIX services as well
| as in the core document. It is well written and defends its decison
| in a language that is focused and apropriate for the enterprise
| developer.

Since UBL is probably going to become the dominant standard for international trade documents, why don't you just adopt the UBL schemas and have done with it? After all, UBL is based on a pretty widely adopted specification (xCBL 3.0) that was developed specifically for electronic marketplaces. If there are any data elements missing from UBL 1.0 that are needed for oBIX, we can probably include them in UBL 1.1.

Jon

Coming to Terms with EMIX

Another of the essential inter-domain standards for smart energy is being released for formal public review this week. Schedule, price & product descriptions, market interactions, and usage reporting are the standards to enable arms-length interactions between participants in smart energy. When these are stable, products that need them can come out of the labs, accelerated by common communication standards across the country. The miracle of software, silicon, and scale can begin to work its magic to balance energy supply and demand, in a world where both are more volatile than today.

EMIX, or Energy Market Information Exchange, supports market communications concerning energy. At first glance, this would appear to be a simple commodity market, with a simple product, power. Energy, however, is the most volatile commodity. Pork-bellies and wheat can be stored. Fresh produce must be used in season. Energy must be used when available, its shelf life is moments, and its cycle of seasons is completed every day. This need to coordinate precise delivery and availability times makes traditional market communications inadequate.

Energy surpluses and shortages are known in advance, at least as much as they are for other commodities. The periods are much tighter. Commodity markets price produce based upon weather during the long growing season. Secondary weather markets let investors hedge against rain during, say, soybean harvest week in Indiana. Alternative energy markets will compress the same business processes into a single day. Timing is everything in energy.

Energy use does not exist in a vacuum; it intersects with the businesses and lives that inhabit buildings and venues, and those are managed by on-line calendars. Business meetings, weddings, soccer games, and concerts are all schedules using iCalendar-based communications. WS-Calendar extends iCalendar interactions to support the needs service oriented inter-process communications.

EMIX calls the application or product definitions to schedules “Terms”. EMIX uses WS-Calendar to express schedule based information as part of product definitions. The complexity of operations schedules, and weather predictions, and market availability are reduced to schedules and prices. Whether a market is closely regulated with invariant tariffs or whether a market is dynamic and vital, the software and equipment in those markets will receive the same messages, the EMIX Terms.

Terms may be incomplete during indications of interest and tenders, may be firmed up by purchases or executing options, and may be only completed during specific calls for performance. EMIX does not pre-judge how Terms are completed, nor create market rules for their elaboration. EMIX does not dictate market rules. EMIX terms express the results of market operations and market rules, and the schedules of energy supply and demand, and the schedules that they create.

In all markets, there is more variety of appetites and needs then there are of contracts. In Real Estate, initial indications of interest may specify neighborhoods, or the number of bathrooms, or even cities with specific demographics. Over time, the deal becomes focused, the specifics become concrete, and the actual closing, even in a creative transaction, is expressed in a mundane manner.

In an analogous way, EMIX can express resource capabilities for buyers with specific needs, or for sellers seeking to find a market. The Terms of offers can be made as expressions of capabilities and requirements, applied to the schedule of how those vary over time. Other offer terms may be as specific as the final performance call.

EMIX supports more than Power markets. By describing ancillary services, it can help distributed resources find more markets in which to sell. It describes transport charges, which might enable consumers to select their energy supplier. EMIX provides the means for warrants of energy source and environmental cost to travel with the transaction. That, however, is a longer story.

Energy Market Information and Schedules

This post describes my attempts to use the OASIS specification WS-Calendar as a component of EMIX. WS-Calendar specifies how to share schedules and sequences in web services. EMIX (Energy Market Information Exchange) provides price and product descriptions for products that vary over time, including electrical power. Both standards are currently in development.

Electric energy has seasons of abundance and scarcity as do agricultural commodities. Electric energy’s seasons are measured in days instead of in years. EMIX uses WS-Calendar to describe products whose supply and value change rapidly over time.

Five KW at 2:00 AM is not the same product as Five KW at 2:00 PM. EMIX describes products for which time, the interval in which it is delivered, is an essential attribute. For energy purchases made in consecutive intervals, prices and quantities may vary for each interval. EMIX describes products for which a key characteristic is variance over time, whether the product is generation or load reduction, wind or coal, power or regulation.

For the simplest product, the dispatch of power, EMIX is simply a product description (constant power), a start date and time, a duration, a quantity, and a price. If the rate and price have been set in advance, the dispatching communication might be simple “start at 3:00 (reference uri to product), for 45 minutes.”

It is often desirable to discuss a sequence of intervals in which to purchase electric energy. In any set of intervals, most information would be redundant. The same product could be described again and again, once for each interval. Only a few characteristics, perhaps only price, or quantity, might change per interval. EMIX specifies product information once, and then specifies only the changes in each interval.

Some energy products have characteristics that present a consistent pattern over time, whenever purchased. A generator may run at half speed for an hour while warming up. A responsive load may require 15 minutes before load reduction. These characteristics may hold true whether generation or response is requested for 15 minutes of 15 hours. EMIX specifies these invariant characteristics as part of a product, while offering the variable run-time to the market.

The EMIX Product Description specifies the characteristics of a product at a given instant in time. The EMIX Product uses WS-Calendar to express how that product varies over time. WS-Calendar describes how a single specification can be shared between a sequence of time intervals, and a gluon, which describes aspects of the specification shared by all, including, perhaps, the schedule for the sequence. WS-Calendar also another gluon can associate with the another gluon to influence a gluon-sequence information set.

A sequence could also have 10 consecutive 15 minute intervals, each with a different quantity (or different price). Rather than expressing a product description, a start date and time, a quantity, and a price, 10 times, EMIX uses a gluon associated with the sequence, letting you put the product description, start date and time, and price in the gluon, and have only the quantity in each interval.

If a market rule stated that there was no price for a ramp period, the first interval could have a price of zero. In that case, that first interval could have a price of zero (blocking the price coming from the gluon). All other intervals could get the price from above.

The same override capabilities go to any variable. If the ramp periods have a fixed time, but the run time is variable (describing a typical generation resource, and perhaps most DR assets) then the duration can be expressed in the gluon, inherited by all intervals that themselves do not have a duration, i.e., the generation load, and ignored by those that do, i.e., the ramp times.

But the simplest (one price, one time, one interval, one duration, one amount) explicit invocation, and the simplest implicit (do that thing, one time) invocation are still invoking the EMIX Product, consisting of a Gluon holding a Product Definition, Start Time, and a sequence.