Event

From The Contingency Market

Overview

An event represents a possibility, something that may happen.

Its possibility can either be undetermined (it's not happened yet, and it's not certain whether it will or won't) or determined (it's happened, or it's become impossible - it can never happen). Events are defined either because they represent things that can be involved in contingencies, or they provide the context for other such events.

In this way events have a dual purpose, they can represent potential outcomes, observations, and historical facts. The release date of a single being '2006' can start off as a potential outcome, be observed (as true, or some other value), and then become a historical fact. If someone had made a contingent deal on the event of the single being released in 2006, then their contingency would be successful if this event is officially observed, whereas it would be unsuccessful if the event's impossibility was officially observed (the single was released in 2007).

Contingencies are created in terms of potential outcomes, and settled in terms of historical fact. In the interim, the parties involved in deals contingent on potential outcomes are naturally interested in observations of the respective events.

An event becomes the context for another event using the concept of lineage. An event may have sub-events or 'child' events that can only be possible if their parent is possible, and become impossible if their parent becomes impossible. For example, the tracks in an album cannot possibly be released unless the album's release occurs. The album is thus specified as a dependent parent of the tracks. Similarly the release date of a track may be the child of the event that represents the possibility of the tracks's inclusion in the album. In the other direction, the album event may be a child event of the event that represents the continued existence of the band making the album (until it disbands), etc.

The contingency market offers access to a root event from which all others descend. This event is special in that it has no parent.

An event is very simply defined as the possibility that a parameter has a specific value (or any value inside or outside a range of specific values).

API Methods

All events are identified by an ID code. If you have this, you can retrieve the details of the event using GetEvent(). Note that all events are organised into a hierarchy. The root event can be specified by supplying a blank value for the event's ID.

You count the number of a children an event has by calling CountEventChildren() and listing them using ListEventChildren() (ids only via ListEventChildIDs()) or ListEventDescendants().

You can register an event using EnsureEventChild(), and this will use an existing, identical specification if one has already been defined. To see if one has already been defined without consequently registering one you can use MatchEventChild().

Deals can only be contingent on events if those events either happen or become impossible. You can record the fact that you have observed an event using ObserveEvent(), or to record that it has become impossible using ObserveEventImpossible(). These are inherently unofficial observations. Deals usually depend entirely upon official observations and these are made independently by the administrators of the service. Note that a collaborative reputation based mechanism will be produced to automate official observations, which will utilise unofficial observations (consequently impacting upon an agent's reputation for observation accuracy).

You can count the number of observations of an event using CountEventObservations() and list their details using ListEventObservations(). The most recent observation can be obtained using GetLatestEventObservation().

Contingencies dependent (directly or indirectly) upon a specific event can be counted using CountEventContingencies() and listed using ListEventContingencies().

When registering events you must use predefined event parameters. These can be listed using ListEventParameters(). New ones can be requested by e-mailing the service administrators.

Each event parameter has a corresponding type. These can be listed using ListEventParameterTypes(). Each parameter type is represented using a more fundamental database oriented type. The details of these can be obtained using ListValueTypes(). Note that some parameter types may have special values that have special meanings. These are listed using ListSpecialValues().

Occurrence

Although an event would be supposed to start off as unobserved (no-one has observed whether it is occurring or not), by dint of its registration and an implicit interest in its next occurrence it is presumed to be non-occurring until such time as its occurrence is observed (if ever).

Thus there is no point registering events that are known to be currently occurring. If one has an interest in an event ceasing, one instead creates the cessation as the event (inverts the event criteria) and waits for that to occur.

Thus an event has four states:

quiescent – unobserved/not occurring, but will possibly occur
occurring – observed as occurred and still occurring, but will possibly cease
impossible – observed as not occurring, and no longer possible to occur again
perpetual – observed as occurring, and no longer possible to cease occurring

The time of something occurring is the time at which it started occurring (again).

The time of something not occurring is the time at which an occurring event ceased occurring.

These times are obtained through observation.

Recurrence

Some events may recur, such as doors opening. Many events such as annual conferences do not recur, they are simply similarly described events.

The way of determining whether an event can recur is if the same action is performed each time, also that the starting, occurring, and ending states are identical in each case. Sunrise is a recurring event. A general election is not – given something different happens each time.

Duration

The duration of an event is the total time of its occurrence (until the current time if still occurring).

An event thus has duration, though this may be unlimited, e.g. the event of a mountain having been scaled. Once someone’s done it, the mountain is ‘scaled’ forever – the duration increases eternally.

Observation

There are public observers, official observers, and an automatic observer.

There is the time at which an event is observed to occur, and the time at which the observation was registered.

There are two things that may be observed about an event (initially undefined):

It's occurrence:
1. It has occurred or has started occurring
2. It has ceased or is no longer occurring
It's permanence (aka completion):
1. It is perpetual - it is occurring and will never cease
2. It has become impossible - it has never occurred or has ceased, and will never occur or recur

Once permanent, an event's occurrence and permanence cannot change (barring exceptional circumstances).

An event’s observation is recorded as follows:

null: Undefined/Unobserved – Hypothesised as possible, not yet occurred (implicit quiescence)
0: Quiescent – Stopped/Paused (possible to occur)
1: Occurring – Started/Resumed (possible to cease)
2: Impossible – Permanently ceased (can never occur)
3: Perpetual – Permanently occurring (can never cease)

Valid transitions:

unobserved->Quiescent
unobserved->Occurring
unobserved->Impossible
unobserved->Perpetual
Quiescent->Occurring
Quiescent->Impossible
Quiescent->Perpetual
Occurring->Quiescent
Occurring->Impossible
Occurring->Perpetual

An event thus has the following overlapping states:

possible/impossible
occurring/quiescent
occurred/never occurred
observed/not observed
started/stopped
changeable/permanent

Numeric Representation

The numeric representation of the state of an event at a particular time may include the total number of occurrences of the event until that point:

0 = undefined
Bit top: permanent
Bit 0 = occurring
Bits 1-top-1 = occurrences
undefined = N == 0x0000
quiescent = N&0x0001 == 0x0000
occurring = N&0x0001 == 0x0001
impossible= N&0x8001 == 0x8000
perpetual = N&0x8001 == 0x8001
occurrences = N>>1 & 0x3FFF

Thus the status of an event that had occurred three times, was currently quiescent, but might possibly occur again would be represented as 6. The number of occurrences is obtained by dividing by two. It is occurring if it is odd. It is negative if it is complete/permanent.

Permanence

An event may become impossible, e.g. it may not be possible to drink a particular bottle of wine if it is instead broken and drained into the ground.

An event may become perpetual (permanently occurring), e.g. a mountain once climbed can never become not climbed.

The recurring event of a light bulb going on and off will eventually become impossible when the bulb fails.

Class

According to who is expected to observe it, an event belongs to one of three distinct classes (determined by parameter type):

Normal: Events observed via the API.
System: Events internal to the system, automatically observed by the system.
Automatic: Events external to the system, regularly monitored and observed by the system.

Automatic events typically correspond to online changes, e.g. changes to an RSS feed.

Special parameter types are provided to register an interest in system or automatic events.

Implications for contingencies

A contingent event can succeed if (at the necessary time) the event’s observation status is occurring, i.e. between observations of occurring and quiescent.

Note that a contingency can succeed despite an event later becoming impossible to occur again. This is because the condition is that the event occur at the necessary time – not that it occurs forever.

Therefore, the conditional events specified by a contingency make it succeed as soon as all events simultaneously occur (however briefly). If prior to this situation any event becomes impossible (will never occur, or never occur again) then the contingency fails.

Event Parameters

Events are defined in terms of publicly observable variables or parameters, and simple criteria that constitute the event occurring, e.g. a flag at half-mast event is defined as the flag position being greater than 33% and less than 67% (probably refined as the duration of this event occurring for more than 1 minute).

Event parameters are not observed until an event is created that utilises such a parameter – and consequently registers an interest in its observation.

Event parameter names are a priori known. What is not known is the current value of the parameters so named. When the values are observed they are compared against the event parameter criteria to determine whether the event has occurred or become impossible.

Event Parenthood

Events are disambiguated by reference to ancestral events (parents). An event’s parental lineage also gives child events context.

Child events may occur irrespectively and independently of their parents, though often there will be a dependent relationship.

There are some automatic events that make a specific interpretation of their parent event, e.g. a duration event parameter that involves a measure of the duration of the parent event’s occurrence.

Event Parameter Types

Event parameters specify measurable quantities or observable elements, i.e. values of things that can be observed as meeting specific criteria or not.

The nature of these values can be classified into several value types: numeric, textual, temporal, and nominal.

Value Type

The fundamental data types used to represent parameter types.

Number: ±2^0-50 with 4 decimal places (SqlDbType.Decimal)
Text: Unicode text (SqlDbType.NText)
Time: Date and/or time (SqlDbType.DateTime)
Guid: Globally unique identifier (SqlDbType.UniqueIdentifier)

Here is a table of the value types known at the time of writing (see ListValueTypes() for the live result):

VTID	VTName
1	Number
2	Text
3	Time
4	Guid

Note that these types have not been chosen to keep storage to a minimum, but to keep the number of types to a minimum.

EventParameterType

Each event is governed by the observation as to whether a parameter meets specific criteria. The event name and lineage specify, unambiguously, where the measurement may be found and the event type specifies what precisely is to be measured.

An event parameter is thus given meaning by a dedicated type, its EventParameterType (itself having an underlying data type or ValueType). At the time of writing, an event parameter name cannot be associated with more than one type, but this may be necessary or useful at a future date.

The event parameter types can be obtained by a call to ListEventParameterTypes().

Some parameter types have values with special meanings. This is indicated by a flag, HasSpecial, which is true if there are values of this type that have special meanings and/or effects.

There is also another flag, Observer, which is non-zero if event parameters of this type will be automatically observed (1=internal, 2=external).

Note that an event may happen many times, but the event parameter is defined/triggered as soon as the criteria is met, or as soon as it is clear that the criteria will never be met. There may thus be several instances of the same event parameter, but with different criteria.

It is possible that an event’s dependency upon its parent may not be left as a matter of inference, but specified by an explicit Dependent flag. For such events, observations of a parent’s impossibility or non-occurrence will automatically render all dependent child events impossible or non-occurring.

In other words a dependent child may only occur if its parent is occurring. If such an parent event is officially observed impossible, then all dependent children are automatically also marked officially impossible.

Event Parameter Observer

The event parameter type has a property called Observer. This is a flag that if non-zero indicates that the event will be automatically observed (by the system, internally or externally). Event parameters of this type may have behaviour dependent upon their parent. Event types that make no sense given a particular parent type, may not be accepted (or are consequently automatically impossible).

Automatic parameters and type names when displayed may be prefixed by @ if external, and $ if internal/system.

Special Child Events

For events there are special, automatic child event parameters (derived from official observation):

Begin:$Count:Number: the parent commencement count.
End:$Count:Number: the parent cessation count.
Length:$Duration:Time: the total accumulated duration of the parent event’s occurrence.

Before an event occurs 'begin' is equivalent to 0. When it occurs it is 1.

Each time an event transitions from quiescent to occurring/perpetual 'begin' increases by 1 (starts at zero).

Each time an event transitions from occurring to quiescent/impossible 'end' increases by 1 (starts at zero).

If a contingent event is desired where it is only necessary to know if it has ever occurred, not whether it currently occurring, then an event->begin>0 should be specified, i.e. the event has begun at least once.

Root Event

‘Root event’ = Begin:$Count:Number>0

The Root event is effectively null, but it has a special child from which all other events descend.

Dependent Events

Implicitly, dependent child events cannot occur except whilst their parents are occurring.

Thus observation of child events is only necessary whilst the parent is occurring, however that doesn’t render observation of child events redundant, as such observations may be useful the moment the parent does occur.