RE: representing scheduled events

On Tue, 17 Apr 2001, Charles F. Munat wrote:

> I'm wondering how we can represent scheduled events without having some
> notion of a calendar involved. And if a calendar is involved, my question
> is, Which one? Are we just assuming that this will be based on the Gregorian
> calendar? An event occurring "every Tuesday" does not make much sense unless
> the software knows what "Tuesday" means.
>
> Forgive me if I seem a little dense. I'm still a bit unclear on exactly what
> this RDF calendar is supposed to do. I've read a variety of suggestions, but
> have seen no simple synopsis. Does anyone have a link to a synopsis or a
> list of goals? Is there a "home page" for the calendaring effort?
>
> Also, if a calendar is part of this, what about using something like the
> modified Julian day number as the base and then converting to Gregorian,
> Julian, Chinese, Indian, etc. as necessary?
>
> Or am I misunderstanding this entirely?

Valid point. Various people have described a number of scenarios thay'd
like to see the work handling. This varies from "represent iCal in RDF"
to "represent everything in RDF" :-)

I'm (slowly) going through what you might describe as a literature
review of current calendaring schemes. This is out-of-hours work, so it
basically depends on me having some CFT in the evenings. Take a look at

	http://ioctl.org/jan/cal/critique

for a list (incomplete, but getting there) of the sort of things that I
consider to be important, or at least worth thinking about.

With a (highly) distributed protocol, we can effectively remove the need
for all systems to understand "every Tuesday". The agent responsible for
scheduling that appointment might understand it; everything else can
call out to it to ask it for the dates/times of the next _n_
occurrances. The downsides here are two: firstly, we'd like to be able
to have the scheduling process finish before the event happens :-) - and
secondly, we'd ideally like to keep our individual scheduling activities
as private as possible - calling out to third parties might leak
information. The usual caveats about distributed algorithms apply too.

jan

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
The Java disclaimer: values of 'anywhere' may vary between regions.

Received on Thursday, 19 April 2001 11:45:16 UTC