Re: Accurate location information is a "must have" requirement

[Pete Resnick <presnick@xxxxxxxxxxxx>]

On 8/3/96 at 1:07 PM -0500, Skip Montanaro wrote:

>Subject: Accurate location information is a "must have" requirement

I could not disagree more.

>There is a lot of attention paid to meeting times, but virtually no
>discussion of accurate location information.

The reason for this, I hope to show in this message, is that *seperate*
location information is not a needed component of a calendaring or
scheduling protocol. As some of us brought up during the meeting, a
location of an event is not a property of the event, but is much more
simply expressed as a resource of the event, like an overhead projector or
a computer.

>Bill Spencer treated timezones
>pretty carefully in the SWTP spec, and with recurring dates and all, it's
>pretty clear that they need to be carefully considered.

That's right. But this is because *time* is the important item of
information. We often express times in local time and therefore need
timezone information to convert it to something useful. But it is not
location which is important here, but the ability to calculate absolute
time.

>However the only
>real location tags I remember seeing are the LOCATION properties in SSTP and
>SWTP (both free-format text fields) and the GEO field in vCalendar (which
>takes a lat/long tuple).
>
>Neither of these is adequate for a number of reasons:
>
>    1. Lat/long information isn't enough to infer timezones because people
>    at various places in the world have adopted different ideas about the
>    correct relationship between the Earth's lines of longitude and the
>    clock on the wall.  Simply put, there are some pretty daft people out
>    there pushing the boundaries around.  (Take a look at the world map in
>    the front of your handy-dandy "Rand McNally Comprehensive World Atlas"
>    if you think I'm kidding.)

But no location information solves this problem anyway, at least in the
absense of a rather extensive database which would need constant updating.
People not only have adopted different ideas about geographical time zones,
but they change those ideas at assorted times in history. Location
information by itself does nothing at all to determine time information. It
is time zone information that must be encoded in the times of the event
itself.

>    2. Many applications that will want to interface to calendar systems
>    (like our event calendars, Musi-Cal and the Internet Conference
>    Calendar) will place as much emphasis on location as time.  It would be
>    a shame to think that that basic events could only travel one way
>    (toward calendar systems) because loss of information prevents it going
>    the other direction.

Again, as was said in the meeting, it is only an accident of the types of
events you deal with that they always involve a location to which all of
the participants must go. In most of the events I am involved with (like
phone conferences), a location is not part of the event; there are several
locations over which the event takes place. Certainly for to-do items,
location is never at issue. Location is a property of a particular
participant at a particular event.

>    3. People will think up all sorts of different ways to enter information
>    in free-format location fields so people trying to parse them will
>    invariably run into snags.  (Believe me, I squeek from experience.)

That *may* argue for (as Roland mentions) location information being
formally defined, but only in the attendees list for the event. It does not
indicate that we need a machine parsable location for the event.

>    4. There seems to be an implicit assumption that events are entered
>    one-by-one.  We get information in huge batches sometimes, often with
>    varying degrees of consistency.  I have never seen concert or conference
>    listings that indicated timezones.  Most listings don't even give event
>    times.  It's impossible in most cases to add timezone information
>    manually because of the sheer volume of data we deal with, and for most
>    purposes it's pretty irrelevant.  Inferring it from accurate
>    city/region/country information is the only chance of being able to feed
>    it to calendar software.

a) You need to find out the location of the venue for your sorts of events,
and that is simply a participant in the event.

b) Even with the city/region/country information, you will not be able to
figure out what time the event takes place at without a current database of
time zones and daylight savings time rules. Having tried to build such a
thing for a long time, I can tell you from experience that you will find it
impossible to keep one up to date and universal.

>    5. Finally, event location will take on greater and greater importance
>    as scheduling reaches out beyond small groups to encompass organizations
>    that are geographically dispersed.  No longer will it be sufficient to
>    indicate "Mozilla Room" as the sole indicator of a meeting's location.
>    If I add a conference in Miami, Florida to my scheduler it's not too
>    wacky to think it should automatically add a to-do for two weeks prior
>    to the conference as a reminder to book my super-saver tickets.

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.

I urge that we don't go down this path. Location for an event is a property
of a participant. Making it a property of an event will cause many more
problems than it will solve.

pr

--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980