Re: Why do we need RDF calendaring? (fwd)

forwarded to the list with permission - libby


---------- Forwarded message ----------
Date: Mon, 7 May 2001 21:40:54 -0700 (PDT)
From: kellan <kellan@protest.net>
To: Libby Miller <Libby.Miller@bristol.ac.uk>
Subject: Re: Why do we need RDF calendaring?


i realize this is a big idea question, but i'm going to nitpick it
a little bit.  i came to this list recently, and haven't seen much traffic
on it, and am still hoping for some sort of clear vision to emerge from
it.

> Basically, the interchange format of iCalendar is just fine for
> most calendaring and scheduling purposes.

actually if you monitor the calsch mailing list you can find numerous
complaints with iCal; it describes a public activities calendar poorly
(enter skical), its ambigious and horridly complex to parse (enter iptel),
its design precludes security (no solution yet).

> The IETF have spent a great deal of time and effort getting it right.

so much so that there really isn't a working, shipping product after 5
years.  calendaring is hard, but this is clearly a case of
over-engineering.

> * unique identifiers (but iCalendar uses email addresses and urls to
> identify people and locations)

ical doesn't really use urls, each ical object is supposed to be totally
self-contained.  some parts of cap specify urls, but cap is a long way
from done.

> * tools for parsing (RDF tools are not mature; XML tools are more
> mature; iCalendar tools are very mature)

huh?  what ical tools exists?  and which of them could possibly be called
mature.  there are a handful of propietary and barely interoperable
commerical implementations (lotus, msoft, netscape all have them) and two
alpha or pre-alpha quality open source implementations.  this is a totally
false statement.

i see hope for a rdf calendaring project, as one that would inherently
understand the benefits of the network, and modularity, too tools that
would make iCal (and iTip, iMip, and CAP) much more powerful and simple,
but are precluded by their self-contained, and monolithic designs.

kellan

Received on Wednesday, 9 May 2001 10:48:07 UTC