W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > May 2001

RDF vs. iCal

From: Michael Arick <marick@cse.ucsc.edu>
Date: Wed, 30 May 2001 16:02:32 -0700
Message-ID: <3B157C08.2000104@cse.ucsc.edu>
To: www-rdf-calendar@w3.org
Hey y'all:

I just wanted to say that the idea of a simple, but extensible 
RDF-Calendar format seems to be less valuable than one that implements 
all of iCal (and thus is not simple), but is also  extensible.  iCal is 
quite complex, that is true, but it is complex FOR A GOOD REASON: 
anything that is not defined in iCal will break interoperability with 
other iCal-based systems.  Thus, it was necessary (for example) that 
iCal (and presumedly RDF-Cal) define how to work with timezones, 
recurring events, alarms, and other stuff.  Please note that not all 
clients use all
this data, but at least they can recognize which data isn't necessary 
because it is defined in the spec.

It is necessary for any calendaring format to be able to handle much of 
the data represented in iCal, but certainly different systems need 
different subsets of that data.  In iCal, this is done through optional 
properties and property parameters.  To ensure interoperability, 
however, it is necessary to define what those extra properties and 
parameters do.

RDF gets around this problem (if I understand it correctly) by defining 
the semantics through URI's.  Even so, every RDF-calendar will have to 
link to the same URIs, or
interoperability is difficult to ensure.

Furthermore, as I understand it, we are trying to provide a framework 
for transition from iCal to RDF-based calendaring, so leaving any iCal 
data out is NOT a good idea.  

Finally, iCal isn't all THAT complicated, really.  Read over my UML 
diagrams (available at 
http://www.cse.ucsc.edu/~marick/iCalendarUML.html).  In theory, even if 
you've never seen the iCal spec, it should be possible to figure it out 
from just the UML.  I certainly hope that's the case.  

Received on Wednesday, 30 May 2001 19:01:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:10 UTC