RE: RDF Calendar todo list

Libby,

I had a quick glance at the proposed module and there is one thing I
would be sorry about if that spec would remain like it is.

I thought I have mentionned this already here but the part on date
precision:

>Date precision
>In many cases an event does not need to take place on a specific second 
>or minute. An event can have the same precision as an W3CDTF date.
>For example, if the startdate and enddate are both 2001-08-19 this 
>means the event has no duration and takes place sometime on the 19th of
>August.
>If the startdate is 2001-08-19 and the enddate is 2001-08-20 this means 
>the event takes a full day and ends just before the day rolls into 
>August 20.

is really not what I think would be a good thing.

The precision of a time periode is given by the form it is in.
The USAGE defines if (in absolute sense) you should take the lower or
the upper limit within the precision range of the given period.
Why should I say an event ends on 2001-08-20 if it ends on 2001-08-19
18:00 but I don't want to (or can't) give the time?
Difficult to be more illogical and unnatural.

I think a better way to handle this is to "expand" (when necessary) it
in the following ways:
Lower limit use (e.g. <ev:startdate>): 
2001-08-18 -> 2001-08-18 00:00:00
and upper limit use (e.g. <ev:enddate>):
2001-08-20 -> 2001-08-20 23:59:59

The same reasoning works also fine for single dates: in genealogy the
only thing we often know is: X is born in 1924.
So the birth EVENT dates would be 1924-01-01 - 1925-01-01 ? or
1924-01-01 - 1924-12-31 ? or if you need to "calculate" in seconds :
1924-01-01 00:00:00 - 1924-12-31 23:59:59?

This has the advantage that when the time is also given, it will not
change the way you can look at the data.

The usage in upper limits and lower limits should be clear as we are
handle a semantic rich (and hopefully well defined) environment.

IMHO we, human beings, handle periods (explicit or implicit) in this
way. 
The proposed way is a typical example of lazyness. Most computers expand
dates with 00:00:00 time elements if they are not given, the programmer
hasn't much to do for handling dates, so just let the ordinairy user
adapt his ways of thinking and handling to this. :-(
I thought we were working in another direction.

And Libby, this is not to you personal, I know you didn't wrote that. I
just want this community to make good decisions.

Friendly greetings

Ronald Poell






Libby Miller wrote:
> 
> I'd agree - this is a good reason to divide it up into separate
> namespaces perhaps, since simplicity is a precondition for
> widespead uptake, which is something that RSS 1.0 could
> provide. Similar considerations apply to datetimes - keep it simple -
> which might mean UTC offsets allowed.
> 
> I guess everyone has seen the RSS proposed events module?
> 
> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_event.html
> 
> cheers
> 
> Libby
> 
> On Mon, 2 Jul 2001, David King wrote:
> 
> > What I would like to see come out of this work is something that can be used
> > with an RSS 1.0 iCalendar module.  Hopefully this can be kept in mind during
> > the current process.
> >
> > For the last few months I've been thinking about the syndication of events.
> > The syndication of headlines has already proved itself to be quite cool and
> > I thought the model translated well over to events.  Ultimately, I would
> > like to be able to subscribe to an event feed and have the events show up in
> > my calendar user agent.
> >
> > -David King
> >
> >

-- 
Ronald Poell
Consultant Knowledge Management
Netherlands Organization for Applied Scientific Research (TNO)

Oude Waalsdorperweg 63
P.O. Box 96864
2509 JG The Hague
The Netherlands

T +31 70 374 02 00
F +31 70 374 06 52

http://www.tno.nl

email poell@fel.tno.nl