WHAT IS AN EVENT? (was Re: Accurate location information is a "must have" requirement)

["Robert C. Tatar" <rct@xxxxxxxxxxxxxx>]

I've read with great interest the debate about "location" in calendaring
software. Because the following is rather long, I've included some
titles to summarize the key point of each section.

EVENTS ARE "PEOPLE (and location) TOO"

It is primarily because of Pete Resnick's strong reaction to Skip's
message 
that I was inspired to write this though is not intended as an attack on
Pete
in any way. His perspective is very likely shared by many others who
have been
involved with "meeting scheduling" software development for some time
and thus
I feel a strong need to respond to his statements and perhaps clear up
what may be a misinterpretation of our suggestions.

Though Pete supports the importance of incorporating extensive 
descriptions of time, he misses some key characteristics of what we mean
by "event". His final comment, however, actually supports our contention
about the importance of a more general description of event:

> Actually, the geographical dispersion argues more against having a single
> location field in an event. More and more people will be having
> teleconferences where locations will be multiple.

IMPORTANCE OF CAPTURING THE CONCEPT NOW

During the meeting on the 24th, it was mind-expanding to listen to 
the potential list of interoperability applications involving 
desktop systems, robots, hand-held devices and other machines.
The goal in simple form was to have all of these devices exchange
some rather simple, even trivial, information that I'll call an "event".

While I am not convinced that we will ever reach complete semantic 
agreement on the term "event", it is difficult to imagine how this 
group will achieve the goals in the proposed charter until more
consensus is reached on this term. I think much of the debate has to do
with our different perceptions of what is implicitly included in the
concept of an "event".

Simply put, Skip and I (as well as a few others) are arguing for the 
use of a more general description of "event" than appears to be assumed
by many current developers of scheduling software. We feel that
thinking this through a bit more carefully now will greatly simplify
future software development by avoiding the need for future software
hacks and arbitrary, non-standard extensions to adapt some key
concepts that were not included when they should have been.

THE THREE FACES OF EVEnt (SUMMARY)

We echo Roland Alden and Rafael Weinstein [in slightly different form]
that three components: participants, location and time are prerequisites 
to the concept of an "event". We argue that these three components need 
to be addressed in the architecture and protocols developed by this 
group even if all such components need not be explicitly stated or 
precisely specified to adequately describe every particular "event".

Clearly, the "what" of an event is also essential for the user (e.g. 
phone call, rock concert, IPO, wedding, etc.), but semantic
interpretation 
of this information for the purpose of interoperability does not 
seem to be required by a general calendaring system (anyone have strong
counterarguments about this?). Thus, unlike Rafael, I prefer to think of 
the "what" as an "event property" that can be handled transparently by 
the communications protocols.

Our basic claim is that each component (who, when, where) is critical 
to the concept of an event within the scope of this proposed IETF
and therefore these components require equal treatment. 

Furthermore, we suggest adaptability to a range of precision in each
component.
If we choose to allow a broad range of precision in temporal
descriptions 
(e.g. 8:05:30 EST vs. Monday morning), then we should allow for a 
range of precision in specifing location (e.g. Mosaic Room, Netscape, 
Mountain View CA USA vs. Internet) as well as a range of precision
in specifying participants (e.g. Benjamin Franklin & George Washington
vs. 
anyone who can read).

To imagine that the temporal component requires precise treatment, and
the
other components do not, misses the most fundamental nature of an
"event"
and would limit the ability of any calendar system to treat well only
a small subset of possible events.

EVENTS AS TRANSFORMATIONS OF MATTER-ENERGY IN SPACE-TIME

To motivate a general interpretation of "event", I'll start with
a physical model which I feel is consistent with Rafael's line of
thought.

A physicist might propose that an "event" is a transformation of matter
or energy at a particular place and time. A relativist might rather 
say "a transformation of matter-energy at a point in space-time". 
This physical perspective suggests an inseparability of the three 
components of what we call an event. In our view, the participants 
are required to perform the "transformation".

Furthermore, the blurring of the distinction between space and time 
arising from Einstein's observation about the consequences of an 
upper limit to speeds within the physical universe--which includes 
the Internet--is suggestive of the appropriateness of handling temporal
and spatial components in a more democratic way.

On the face of it, this rather abstract definition seems to work for
many of the scenarios that arise in scheduling. We usually plan a 
"meeting" of people at a specific "time" and "place". (Actually, both
start and end times are usually specified, but this does not impair the
discussion--read on.) The process of a meeting usually results in the
transformation of chemical energy into biochemical energy needed to
arrange or rearrange words and ideas. 

Even "to do" events include: 
 1) a transformation of some type,
 2) by an implied participant, 
 3) at an implied location. 

Examples such as 
  "Walk the dog", 
  "Send roses to Sue.", 
  "Rework the employment contract to include free lunches.", 
  "Call the boss.", 
  "Read IETF-CAL.", 
involve explicity actions by at least one person with implicit 
locations such as:
  "outside in the woods", 
  "at a florist", 
  "in a workplace",
  "at a telephone", 
  "on the Internet",
respectively, notwithstanding these interpretations may only apply to 
my specific "todo" list and may also contain only vague specifications 
of "where".

Clearly, some events have very precisely specified parameters of "who",
"when", and "where". On the other hand, that some "events" may include a 
vague specification of "where" or "who", is no more significiant than 
than the fact that some anticipated events include relatively vague 
specification of "when", e.g. 
  "have a meeting this morning", 
  "go to a party this weekend", 
  "take a vacation next summer", 
  "get an inheritance after the king dies", or
  "read the responses to this message". 

Again (with emphasis) the fact that it may not be essential to specify a
location in order to comprehend an event does not mean that explicit 
specification--no matter how inconvenient the language--would alter the 
event symantics, nor that some interpretation of location does not exist
(as Rafael has observed). 

USE ONLY WHAT YOU NEED

I want to make it clear that we are not proposing to require all 
"events" to use all the software structures implied by these three
components (as apparently some have inferred), just that the structures
"must be" available for use when needed.  I am especially intrigued by 
Roland's suggestion of blending vCalendar and vCard specifications to at
least partially achieve this and I think it could form a very useful
starting point.

MORE THAN A POINT

The discussion so far refers to an event as if it occurs at a particular
"point" of space-time, but this could be generalized as Pete observes
to include a larger set of space-time points such as 

  "Monday, Wednesday and Thursday at noon at Jack's", or
  "Every city in California on the Fifth of June", or  

a recurring series such as 

  "Every Tuesday at 8PM at Madison Square Garden", or 

even a continuous distribution of points such as 

  "From 8 AM to 9 AM in Dave's office", or 
  "The entire State of New York on September 2".

EVENTS ARE ANTICIPATED

We don't usually schedule rainfall, accidents or heart attacks, even
though these are "events" in the physical definition above. Therefore,
the definition ought to include only "physical events" that we 
anticipate or plan. 

PARTICIPANTS ARE DIFFERENT FROM RESOURCES

It's true that a system designed to switch on a coffee pot before 
breakfast does not involve a human participant. It does, however, 
involve a planned "participant" (the coffee pot) that is vital to 
the concept of this event. I agree with Pete that there may be other
resources (e.g. slide projector, building with a room, etc.) that may
be required for the activity to occur, but which can be included as
parameters or "resources".

LET'S SCHEDULE A VOTE

As a working definition of event to guide our thinking, I propose 
"a planned activity of participants at a given place and time".

Though perhaps the members of Automatrix are "new comers" to scheduling 
software, we feel that we've spent at least as much time thinking about 
software systems to handle planned events as many of the participants
of this mailing list. 

I strongly urge that we go down this path. "Where" and "who" are as
vital as "when" to the concept of an event. Even in the era of
inflated school scores, getting 33% of a concept right is still 
failure. I think we can do much better than this and earn everyone
an outstanding grade.

:Bob

rct@calendar.com