Re: RDF calendar schemas

Shannon J. Clark <shannon@jigzaw.com> wrote:

> For a few "simple" illustrations consider the following questions - think
> about how a "simple" solution might address all of them.

Sounds like a worthwhile thought experiment. I'm game:

> One - what is the problem that the RDF is intended to be employed to solve?

The description of events, which relates to a number of use cases which
Libby has kindly organized.

> Calendars mean many DIFFERENT things to people - a doctor's use of a
> calendar is different from a students which is different from a room
> scheduler's which differs from an airlines.

Sure, but they all have a lot in common. They may use different software to
deal with the data but the underlying schema can be the same.

> Two - what is the usage pattern of the RDF based software? Is it designed
> for ONE user? For MANY users? For Multiple organizations running on multiple
> servers coordinating scheduling questions?

It is designed for the entire world to coordinate scheduling questions in a
decentralized manner.

> Three - Do you have to consider timezones?
> Four - Do you have to handle Daylight Savings?

Possibly, this may be offloaded to the software, rather than the language.

> Five - will you have to handle multiple languages? Unicode and/or multi-byte
> languages?

XML takes care of this for us.

> Calendar systems OTHER than Gregorian? (i.e. Lunar calendars
> etc.)

I think we agreed not to.

> Six - are you working ONLY in the future? Or does your calendar have to
> handle the past as well - if so how far in the future or how far back in the
> past? The needs of an astronomer or geologist are very different from those
> of businessman.

Our calendaring system should go both way forward and back far enough for
the average person (i.e. not astronomer or geologist, although that would be
nice).

> Seven - Are the "users" even humans? People have proposed using elements of
> iCalendar in phone switches and internet cache systems that have complex
> time-dependant rules to execute and schedule - the issues and requirements
> here can be VERY different from those of human end users.

The users are both humans and software.

> There are many more - reoccurring events, how to handle and consider events,
> what assumptions if any to make about "units" (for example do you ignore
> Leap Seconds?)

This is the kind of thing I hope to modularize.

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Tuesday, 5 June 2001 22:07:20 UTC