RE: RDF calendar schemas

Shannon,

I understand your point, and am aware of some of the difficulties involved.
Nevertheless, I don't view our task as converting iCal (or any other extant
calendaring system) to RDF. Maybe I am alone in this view and should just
excuse myself.

As I said, I don't want to reinvent the wheel. You are right that there has
been a great deal of study about temporal issues -- going back at least to
the Ancient Chinese and probably further. So let's broaden our scope a bit
and see what these studies have to offer.

I am all for implementing an iCal-compatible system in RDF. I just want it
done in modular format with the fundamental time properties separated out
and available for use in other applications. Perhaps this is beyond the
scope of the RDF Calendaring effort. If so, that's a shame. Who else is
going to do it?

Why can't we build a basic module, then layer the iCal functionality on top
of it?

Chas. Munat


-----Original Message-----
From: Shannon J. Clark [mailto:shannon@jigzaw.com]
Sent: Wednesday, May 30, 2001 4:34 PM
To: Charles F. Munat; www-rdf-calendar@w3.org
Subject: RE: RDF calendar schemas


Charles,

What are talking about is the in part the subject of close to 1600+
theoretical CS papers over the past decades in the subject of temporal
databases - and yes that is in part what you have to do, pick an interval
unit (you suggested seconds which many people chose for this purpose) and
then build up from there.

Where you hit upon difficulties are in many places, but fundamentally it is
that TIME is a social construct of humans - we have built MANY complex
systems that interact in only semi-rational ways to depict the passage of
time - computer systems will always be built upon some compromises to
capture the irrational nature of our systems of measuring time (for
example - if you are building a system to present "historical" time, going
backwards is it meaningful to extend our modern concept of "leap years" back
past the year when the Gregorian calendar was created? If you are studying
revolutionary France - should you use the modern Gregorian calendar or the
Revolutionary calendar (which only was used for a few years)?)

iCal is not a perfect system by any means - but it was designed for certain
sets of temporal problems - other systems like tSQL (temporal enhanced SQL)
have been created for other sets of temporal issues.

For a good reference to this subject, look at "Developing Time-Oriented
Database Applications in SQL" by Richard T. Snodgrass. This is a fairly
dense and technical book, but invaluable for a highly technical overview of
the issues faced when dealing with Temporal data. His focus is on how this
then impacts the use and design of Relational databases - i.e. databases he
is expecting to be queried by SQL or a variant there-of. That said, much of
his work and observations are highly applicable to this group.

There are also uncountable other papers on the subject online - take a look
on  CiteSeer (http://citeseer.nj.nec.com ) for papers on "Temporal
Databases" which should quickly bring up many papers on the subject.

This is very interesting - but I don't think we should do work that hundreds
of other researchers have spent decades working - rather we should build
upon their work and researches to make a more useful and functional set of
tools and specs. iCal is an example of a practical standard that was
developed in this problem domain - I suspect without much reference to the
theoretical work in the field.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
shannon@jigzaw.com
www.jigzaw.com

-----Original Message-----
From: www-rdf-calendar-request@w3.org
[mailto:www-rdf-calendar-request@w3.org]On Behalf Of Charles F. Munat
Sent: Wednesday, May 30, 2001 6:03 PM
To: www-rdf-calendar@w3.org
Subject: 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 20:13:30 UTC