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

[Einar Stefferud <Stef=calendar@xxxxxxx>]

After struggling to understand the traffic on this list, I want to
raise the level of discourse by at least one meta-level.

I do not understand the reasons for excluding "WHAT" as a sibling of
WHEN, WHERE, and WHO.  I have long memories (perhaps ancient - try
1958) of information system designs where-in the inventors could not
conceive of why any user would (and hence should not) ever want to do
X, where X turns out soon to be the raging thing for users to do.

MAJOR CAUTION: Our task is to generally enable, not disable.

That means that we can specify how to do X, if you want to do X, and
that we must specify things so that not wanting to do X will not
disallow what you do want to do.

Further, we are (I believe) in the business of providing strong typing
tools for labeling objects to be stuffed into bit-bags called Calendar
"objects".  

In the vernacular, this is called "tagging and bagging".

I see little reason to distinguish schedule objects from calendar
objects.  So, we are in the business of defining ways to create
attributes with values, give them labels, stuff them into and remove
them from, labeled envelopes on opposite ends of exchanges.

The better the labeling, the easier it will be to automate the
processing.  The more we must "sniff" object content with powerful
Artificial Intelligence software to guess what what meaning might be
contained, the greater the difficulty in achieving our goals.

However, I we must remember that at times, structure becomes the
enemy, especially when it causes a need for increased complexity in
core infrastructures.

In rather high level terms then, a calendar or schedule is just a time
ordered collection of labeled calendar objects.  They might be in the
future, or in the past (in which case we call them HISTORY).

I fail to see any relevance to suggesting that we are only interested
in future events.  Why would we want to disallow events to be recorded
in history?  I don't even see why we want to call our objects events
and then argue about what is or is not included in the object class
called "events".

For my money, we are talking about the tagging and bagging of calendar
objects for transfer via electronic media, over the Internet, among
other possible transport modes and media.  The key is that they must
be useful in the Internet, whether they can also travel in other media
or not.  Take note the the Internet includes all the end points that
are reachable via the Internet.  You cannot be outside the Internet if
you are attached to it.  (Think hard about this;-)...



The bagging part of our problem has already been determined for the
Internet by its adoption of MIME as the primary transport envelope for
Application Information Object Exchange, designed to facilitate
protection of the object from damage by the transport facility, and to
carry the labels which provide for strong typing of the contained
information.

I will argue that MIME envelopes can be carried in any elecronic
medium and there-in provide the same labeling and protection against
damage in transit, including EMail, HTTP, TCP, FTP,
SneakerNet-diskettes, or most any other way you want to move
electronic information.  MIME has even been used for typing files in
files systems with weak typing.  It has also been used to define
W-window widgets that accept MIME objests and do the right thing with
them.

So, the task I see to be completed is to decide how to structure
calendar objects into MIME envelopes.  I see little reason to engage
in discussions at this point about how to limit what such an object
might contain, or to decide that certain attribute values must be
untagged.

What I hope for is an Internet Technology system where I can stuff any
MIME envloped calendar object into my calendar/scheudling/logging
system, and see them "do the right thing with it" because of the
labeling and the damage protection provided by MIME.

Cheers...\Stef

>From Robert C. Tatar's message Mon, 05 Aug 1996 02:01:51 -0400:
}
}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.
}
[SNIP]...