RDF Calendaring update

Jerome Euzenat asked me offlist what was happening with RDF Calendaring,
so below if a summary of where we've got to and some of the problems
encountered. I'd be glad to hear of any other news.

Libby

2002-05-217

Summary of some issues from the RDF Calendar Taskforce
libby.miller@bristol.ac.uk

The taskforce [1], [2] was started in March 2001. Its aim was to create
a schema for calendar use in RDF.

We achieved a draft schema quite quickly [3] (sample data [3a]) - I put
some work into it, as did Michael Arick, who also did a UML verson of
iCalendar [4].

We chose to use iCalendar [5] as our starting point, as it is widely
deployed in desktop applications and personal information managers [6].

However there were a few problems:

* iCalendar is very large and complex.
It is used for lots of different things, not just events but todo
items, journals, alarms.

We did not define clearly what it was we wanted an RDF calendar schema
to do, but my idea was something smaller, for conferences, meetings etc

Aside from its broad functonality, iCalendar's sheer size made it
difficult to write into RDF, difficult for people to understand and
process, and ofputting as something to implement.

* As far as I could discerne there is no clear model behind the
iCalendar document

This seems  to have been party because of different views of modelling.
The iCalendar people seemed to be thinking in a document-centric
fashion. RDF people think in a much more object-centric fashion, and
the two were not always very compatible. Michael Arick's UML document
provided something of a bridge between the two.

* It was not clear what the tradeoffs were in diverging from iCalendar

This applies to both small and large aspects, for example changes from
upper to mostly lower case to make iCalendar compatible with RDF and
XML conventions (a small aspect); and also changes in the apparant
structure of the model used in RDF calendar to better allow things like
merging on uris, and correcting modelling  'errors' like confusing an
email addresss with a person.

* It was not clear how to model datatypes and related things in RDF
from iCalendar

For example datatypes had not (and still have not) been finalized in
RDF (RDFCore is working on them now [7]). We wanted to use something that
would allow us to attach for example timezones to dates, so we needed a
node-indirection sort of datatype for date. We used a DAML-style [8]
structure (a typed node with rdf:value pointing to a literal
representation, and XML schema datatypes).

* It was not clear how to handle the DC/RSS 0.91 and related communities

There was a very clear preference in the RSS 0.91 community (and also
to an extent the RSS 1.0 community) for very simple datatypes, i.e. no
indirection. This conflicted with my instincts for the clearest way to
reuse the icalendar schema we had written as a module for RSS.

* Minor inconsistencies in time formats between iCalendar and XML datatypes

iCalendar and XML datatypes use slightly diffrent subsets of the iso
8601 standard. RSS 1.0 is mandated to stick with the W3C date formats
note which conflicts with the iCalendar format. In particular the
appending of timezones is a real problem for iCalendar but is preferred
in RSS formats, and acceptable in W3C formts.

* Modelling issues in general

- Modelling time/place: for example the time depends on the place -
hence timezones
- Modelling subevents - e.g. a conference has a subevent of a speach.
- Modelling repeating events. The iCalendar people found this
difficult; I also did because to be repeating events looked to me like rules.

I found all of these difficult to model, and tempting to diverge from iCalendar.

* Recently

I've been using RSS 1.0 events module [9], which is four properties of
iCalendar: startdate, enddate, location and organizer. All the dates
are flat structures with no indirection. Timzones are represented by
offsets from Z (UTC) as a suffix. Date formats are W3C formatted. More
detail about the differences is available here [10].

You can still do a great deal with this, although problems will
potentially occur with timezones at the margin.

A little demo [11] shows how you might display this information using
RDF query and JSP.

I've also been investigating writing DAML+oil schemas for iCalendar and
SKICal - I've got a paper at XMLEurope [12].

Some Conclusions

Dan Connolly has said to me that the iCalendar RDF schema is useful to
him because it directly mapps to iCalendar itself, and that conversion
between formats is just fine as far as he is concerned. This implies
that we were right to stick closely to iCalendar: it should be simple
to convert iCalendar information to iCalendar in RDF.

It should be noted that many devices that use iCalendar as an internal
format have a very small partial implementation - they implment what
they need (for example my T39 Ericsson phone which does time, date,
alarm but not recurrance, for example, or todos).

For those wishing to take this forward, I would suggest looking at the
events RSS 1.0 module, and if this doesn't meet your needs, skim
Michael Arick and my 'hybrid' [3] RDF schema for iCalendar, which you
can pick the parts of that you need and supplement with other schemas,
like foaf [13], DC [14] and so on.


[1] http://lists.w3.org/Archives/Public/www-rdf-calendar/
[2] http://www.ilrt.bris.ac.uk/discovery/2001/04/calendar/
links: http://swordfish.rdfweb.org/calendar/links/
[3] http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf
[3a] sample data: http://www.ilrt.bris.ac.uk/discovery/2001/06/content/
[4] http://www.cse.ucsc.edu/~marick/iCalendarUML.html
[5] http://www.imc.org/rfc2445, http://www.imc.org/ietf-calendar/
[6] http://www.imc.org/pdi/
[7] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/
[8] http://www.daml.org/
[9] http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_event.html
[10] http://ilrt.org/discovery/2002/01/cal-rss/issues.html
[11] http://swordfish.rdfweb.org/discovery/2002/05/rsscal/
[12] http://www.ilrt.bris.ac.uk/discovery/2002/03/skical-daml/
[13] http://xmlns.com/foaf/0.1/
[14] http://dublincore.org/documents/dces/

Received on Tuesday, 21 May 2002 09:42:27 UTC