RE: RDF calendar schemas

Shannon Clark:

"Well, for all that iCalendar is complex, there is also a reason for this
complexity - time based information is NOT simple or trivial, very quickly a
number of individually seeming "simple" requirements combine to form a very
complicated problem domain."


I think that we're starting at the wrong end here.

To me, a calendaring system is at root a system for measuring time. We need
a unit for time, a point in the time continuum to designate time 0, and a
method for indicating times relative to time 0.

Then we need to consider that we will want to:

1. Indicate an event that occurs at a specific time (but with an effective
duration of 0).
2. Indicate an event that occurs over a specific stretch of time (duration >
0).
3. Group times and/or stretches of time to indicate an event that occurs
over multiple discrete times/stretches of time.

We will also want to be able to:

4. Indicate that certain events repeat regularly.
5. Indicate that certain events repeat regularly but relative to an
algorithm depending on a specific calendar (e.g., Easter).

(5 is probably more important).

The unit of time is obvious: the second. Time 0 is arbitrary and it doesn't
really matter what time we choose. It would be nice to be able to measure
time down to nanoseconds, however, so that the system could be used for
scientific data as well.

Once the base module is set up, individual modules can implement specific
calendars. Here is where the real complexity comes in. For one thing, we'll
need to know what dates/times are possible. For example, there is no Feb.
29, 2002. Similarly, there is no 2:30 on the first day of Daylight Savings
Time. (But, adding greater complexity, not everyone uses DST, or changes on
the same day. So there was no 2:30 AM in the U.S. on the first day of DST,
but there was in Mexico because they don't start DST until later.)

This sort of complexity can be handled in modules.

I see, for example, a module that simply converts to and from Gregorian time
(and can be queried to indicate whether a given time exists). The
appointments and events calendars can make use of the Gregorian module (or
another calendar module).

I might choose to mark events using the modified Julian system (maybe I'm an
astronomer). My wife (who's Thai) might want to use the Thai calendar.
Putting complex algorithms into the base module when they will only be
necessary for one calendar seems inappropriate and wasteful to me.

Here's another example: I want to build a web site that shows events in
history on a time line. I want the user to be able to view the events on any
calendar. Therefore, I want the events stored in some absolute system. When
the user selects a calendar, the server will apply the necessary algorithms
to covert the dates to that calendar (caching the results, of course).

Frankly, I'm hoping that this effort does not devolve into simply creating
an open-source version of iCalendar just because we're in a hurry. I'd
rather decide what we want from a system, then look at iCal for ideas we can
steal.

Furthermore, if we're looking at a calendaring system as nothing more than a
big appointment book (a la Outlook, say), then I think we're selling
ourselves short. I'd like a system that allows me to generate timelines,
create astrological charts, study numerology, predict sunspot activity,
support genealogical research, and oh, help me keep track of my
appointments. And a hundred other things I haven't thought of yet.

The only way to support such versatility is to start with a very basic
system and build on it.

It seems to me that there might be some ideas in topic maps that could help
us. Aren't we, in a sense, mapping time? It would also be nice if our
time-mapping system could tie in with space-mapping systems so that we could
have a time-and-space-mapping system, maybe using GIS. The use of GIS might
help when dealing with Daylight Savings Time or Time Zones...

Or have I lost it completely?

Charles F. Munat
Seattle, Washington

P.S. Maybe we could start with a module that measures the time left before
the end of civilization as we know it. That way we'd know whether a rush job
is in order...

Received on Wednesday, 30 May 2001 19:01:46 UTC