Semantic Web Calendaring vocabularies and usecases

Nearby: SWAD-Europe workshop on Semantic Web Calendaring | SWAD-Europe

Date: 2002-10-03

(current) author: Libby Miller <>

Description: This document contains a summary of my current understanding of the issues relevant to the SWAD-Europe semantic web Calendaring workshop, to be held on 9th October 2002. I'm hoping that this document can serve as a useful pre-meeting summary document, but also be added to as a result of the workshop.

Aims of the workshop

Proposed process for achieving these aims


iCalendar-related vocabularies

iCalendar is an RFC version of Vcal, an industry specification. It was written by the CalSch working group, which is still going. iCalendar is a model and syntax for describing events, todos and the like (RFC 2445, 1998). It's used in many devices and applications (see here and here). The working group has also created iTip (RFC 2446, Nov 1998) - semantics for group scheduling methods; iMip (RFC 2447, Nov 1998) for binding icalendar to email; Calendar attributes for vCard and LDAP (RFC 2739, Jan 2000) - ie ways of finding a uri for users calendar (Jan 2000); and Guide to internet calendaring (RFC 3283, June 2002). This last one is a good introduction to how these fit together.

The group has also produced two internet drafts: Calendar access protocol (CAP) Internet Draft, June 30 2002 and iCalendar DTD (xCalendar) Internet Draft, July 25th 2002.



iCalendar is specified in the ABNF notation of RFC 2234, and is based on the Mime Directory content type (an attribute-value format) RFC 2425 content type. Its syntax is case insensitive.


Michael Arick's iCalendar in UML might be helpful here. iCalendar contains:

General property parameters

These are mostly properties of the value of the property rather than being a qualifier on the property, e.g.

Parameter Name: CN

   Purpose: To specify the common name to be associated with the
   calendar user specified by the property.


   This parameter can be specified on properties with a
   CAL-ADDRESS value type.

Other examples are ALTREP, CUTYPE, DELEGATED-FROM, DELEGATED-TO, DIR, ENCODING, FMTTYPE, LANGUAGE (I think), MEMBER, PARTSTAT, SENT-BY, TZID. RELTYPE seems more like a property qualifier. ROLE seems rather uncertain; also RSVP. I'm not sure about ?FBTYPE, LANGUAGE?, ?RANGE?, ?RELATED?,

Value data types
Purpose: To explicitly specify the data type format for a property

e.g. duration, boolean, datetime, date, time; but also cal-address, uri, utc-offset

So these are like objects in an RDF model - types rather than just datatypes. In iCalendar they are defined as 'restrictions on properties', but apply to the values of the properties. (but this fits quite nicely with the range of properties in RDF).

A property is the definition of an individual attribute describing a
   calendar or a calendar component. A property takes the form defined
   by the "contentline" notation defined in section 4.1.1.

   The following is an example of a property:


Properties are somewhat like a property and its value together. There is no ordering of properties.

Calendar components

These are the main objects we want to talk about - events, todos, journal entries; also alarms, and timezones. These can be represented as RDF types.


Date and time

There is a conflict between the subset of iso 8601 that iCalendar specified and that described in the W3C's note on dates and time formats. This is potentially an issue, for example if we subsetted iCalendar to use with RSS 1.0, which uses W3C's dates and times.
In iCalendar you can use

There is a value type called UTC Offset, but it seems that this datatype is used only with timezone objects, to specify daylight savings times and so on.

W3C's profile says that you can use

In addition the subsets of iso 8601 they use are syntactically different, with W3C's profile using dashes and colons to separate the parts of date and time respecticely, while iCalendar has no separators.

Recurring events

The difficulty here is that recurrence requires specifying rules, so you really need a rules language (could OWL do this?). iCalendar does specify rules for recurrrance, but there are a few problems with them (see below). Recurrence is really useful though - e.g. TV schedules, opening hours.


4.3.10 Recurrence Rule

   Value Name: RECUR

   Purpose: This value type is used to identify properties that contain
   a recurrence rule specification.

A rule can be counted number of recurrances or a date until it stops (examples are by minutes, by day) and then a list of values, e.g. every day in January for 3 years


This is a bit odd - there's BYMONTH and BYHOUR but not BYYEAR. I guess freq is just a shorthand for every x, so dont have to do a list. You can also specify an interval on a freq, e.g. FREQ=YEARLY;INTERVAL=2 = every other year.

The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule. Valid values are 1 to
   366 or -366 to -1. It MUST only be used in conjunction with another
   BYxxx rule part. For example "the last work day of the month" could
   be represented as:


There are some difficulties with this (calsch wg mails) - here, here and here

The problems with recurrence rules were
summarized best by Damon Chaplin in, reposted (
and edited) here:

o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH
and/or BYWEEKNO set, does the BYDAY modifier apply to the year day, the
month day, or the week day?

o Should BYWEEKNO and BYMONTH be mutually exclusive? They make no sense
together. (This would also avoid part of the previous problem.)

o Is it possible to use BYMONTHDAY in a WEEKLY frequency, or BYYEARDAY in
a MONTHLY or WEEKLY frequency?

o BYSETPOS is limited to 366 values (or maybe 999 values if the comment
doesn't count as part of the spec!), yet a complete expansion for every
second in every day of the year would result in much larger sets.

o The algorithm to calculate the first week in the year may be awkward,
since some people/countries may be used to other numbering schemes.


I'm not sure if this was ever resolved (the archives are hard to search)

Greg Fitzpatrick has proprosed a more elegant model for recurrance.

iCalendar example

See at the end of RFC 2445. Here's one example from there for info:

The following example specifies a three-day conference that begins at
   8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,

     BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
     1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
     DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
     CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
     DESCRIPTION:Networld+Interop Conference
      and Exhibit\nAtlanta World Congress Center\n
      Atlanta, Georgia END:VEVENT END:VCALENDAR

iCalendar is complex and lengthy, and the semantics are somewhat unclear to me (but see Michael Arick's UML version)

However, it is very widely used - many applications are partially compliant. Here are some usecases, a white paper, and a useful summary.


The xCalendar Internet Draft provides an annotated DTD for iCalendar.

This memo defines an alternative, XML representation for the standard
   iCalendar format defined in [RFC 2445].  This alternative
   representation provides the same semantics as that defined in the
   standard format.

It does not allow mixing namespaces:

The publication of XML version 1.0 was followed by the publication of
   a World-wide Web Consortium (W3C) recommendation on "Namespaces in
   XML".  A XML name-space is a collection of names, identified by a
   URI.  In anticipation of the broader use of XML namespaces, this memo
   includes the definition of the URI to be used to identify the
   namespace associated with the iCalendar DTD element types in other
   XML documents.  XML applications that conform to this memo and also
   use namespaces MUST NOT include other non-iCalendar namespaces in an
   iCalendar XML document.

The mapping to the DTD from iCalendar was done like this:


Example taken from the xCalendar internet draft

     <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"

      <vcalendar method="PUBLISH"
            prodid="-//HandGen//NONSGML vGen v1.0//EN">
           <summary>Project XYZ Review</summary>
           <location>Conference Room 23A</location>


SkiCal is an Internet Draft of a vocabulary for extending iCalendar for public events such as concerts, opening hours. It is partially specified in XML, partially in mime-directory format. Greg FitzPatrick and Jonas Liljegren also did early work on transforming SkiCal to RDF.

RDF and calendaring

'hybrid' schema

'hybrid' vocabulary url, previous versions. This is an annotated version of iCalendar in RDF, written by Libby Miller and Michael Arick, and based where possible on Tim Berners-Lee's quick look at iCalendar. After some thought and discussion we decided to stay as close as possible to the iCalendar model because of its wide use.

Main issues:

The main issues were in interpretation of iCalendar in terms of RDF and interpretting the intentions of the iCalendar authors.


We decided to use rdf:value, like DAML+oil. RDFCore will be recommending an RDF datatyping approach soon.


This was an issue because it requires inventing a rules language, which seems to be at a different level to RDF.

Various niggles and a few errors

mail from Terry Payne

        I've just been trying to resolve a couple of issues with the
hybrid-ical ontology, and noticed that there is the property LOCATION
whose range is ical:TEXT.  Fair enough.  But there are also two other
properties (ALTREP & LANGUAGE) who's range is also LOCATION, i.e. a
property which is the range of a property.  Is this legal?  I've an odd
feeling that it might be, but then what exactly does it mean?

Also, there is the following comment in the ontology:

In the SWWS ontology, a GEO is used as the range of the property
LOCATION.  This brings me to the question - are the following both
valid... and are they equivalent?

      <ical:TEXT rdf:value="TCSEQ Center" />


Any thoughts?


mail from Paul Buhler


Regarding Terry's earlier post Question/Anomaly regarding LOCATION, I
believe LOCATION should be text only. Also LOCATION is not the range of
ALTREP and LANGUAGE, but one of the members of the domain.

Now on to the other issues....

Just a few of the inconsistencies I noticed while beginning to update
the rdf markup of rfc2445.

Problems/Suggestions below:

1. remove VFREEBUSY as a subclass of CAL-COMPONENT
        this leaves CAL-COMPONENT as the super class for VEVENT, VTODO,
        VFREEBUSY, VTIMEZONE, and VALARM are each special in their own

**** Note the following items assume that item 1 was accomplished.

2. add iCalendar:COMMENT ( in RFC 2445)
3. add VALARM to the domain of DESCRIPTION
4. GEO description states a may be textual, this conflicts with the RFC.
Only lat & long as float separated by a ':'
5. GEO should have domain of VEVENT & VTODO
6. GEO-NAME not necessary, covered by LOCATION and not in spec
7. remove VEVENT from the domain of PERCENT-COMPLETE
8. change the domain of RESOURCES to VEVENT and VTODO from CAL-COMPONENT
9. remove CAL-COMPONENT from the domain of DTSTART, add VEVENT, VTODO,
VFREEBUSY to the domain
10. remove CAL-COMPONENT from the domain of DURATION, add VEVENT, VTODO,
11. add VFREEBUSY to domain of URL
12. FBTYPE should be a choice see 4.2.9 of RFC2445
13. remove REC-VFREEBUSY (rfc2445 pg 59 states that the recurrence
properties are not permitted within a VFREEBUSY calendar component.
14. comment for LONGITUDE should read between -180 and 180, not 0 and
15. comment for LATITUDE should read between -90 and 90, not 0 and 90
16. comment for UTC-OFFSET should be replaced with "Offset from UTC to
local time, between -1200 and 1200"
17. PARTSTAT should be a choice based upon calendar component type, see
4.2.12 in rfc2445

HMMM.. upon further reflection it appears that maybe nos. 12 and 17
above were TEXT to account for the possibility of x-name, some
unspecified experimental type. I can accept that; however, what is the
difference between text and literal. I ask because CN and CUTYPE are
rdfs;Literal. Something is awry here.


palmagent schemas (Dan Connolly)

Dan Connolly has been writing personal information management tools such as palmagent, and creating schemas that these tools use. Here's a iCalendar schema - I haven't had time to do a detailed comparsion with the 'hybrid' one yet. A Palm datebook schema is also available.

RSS 1.0 + events module

RSS 1.0 is a simple RDF application - essentially a way of presenting an ordered list of links with titles and descriptions. A key feature is that it is extensible using modules - e.g. for Dublin Core, and syndication. Other important features include simplicity and popularity.

The events module was proposed by by Soren Roug of the European Environment agency in 2001.

This specification is not a reimplementation of RFC2445 iCalendar in RDF. 
In particular, it lacks such things as TODO and repeating events, and 
there is no intention of adding those parts to the specification.

There are five properties in this module. All are simple attribute-value type properties, with no intervening node. only one property is required - startdate:

Required. The date/time when the event starts. If the ev:startdate 
doesn't specify timezone, then the timezone is implied in the ev:location. 
Time intervals are not allowed.

'implied timezone' seems very weak, since there's no formal mapping between location and tz - and location is 'a short description', but

 Use semantic augmentation if you desire to give i.e. a URL to the place.

I'm not sure what this means


The date/time when the event ends. If the ev:enddate is the same as 
ev:startdate or not specified, then the event has no duration. The 
ev:enddate can have a different time zone than the ev:startdate. 
Time intervals are not allowed.


The name of the organization or person who organizes the event. 
Use semantic augmentation if you desire to give i.e. a phone number 
to the organizer. 

No way of identifying the person is suggested



The type of event, such as conference, deadline, launch, project meeting. 
The purpose is to promote or filter out certain types of events that the 
user has a particular (lack of) interest for. Avoid the use of subject 
specific wording. Use instead the Dublin Core subject element.


Which is rather vague.


RSS is constrained to using W3C Date and time formats.

Modelling issues. RSS uses urls to identify the objects of interest. It is easy to confuse a web page about an event with the event itself.

Definitions are vague. As described above, in several cases, the content of tags is not machine processible.


This section will expand a lot. At the moment all there is is Jerome Euzenat's document on Semantic web and calendaring


other urls:

URLs from this document


CalSch working group

Lists of iCalendar evices and applications

iTip (RFC 2446)

iMip (RFC 2447)

Calendar attributes for vCard and LDAP RFC 2739

Guide to internet calendaring RFC 3283


iCalendar DTD (xCalendar)

ABNF notation  (RFC 2234)

Mime Directory format

Recurrence issues

Greg Fitzpatrick's 'Orlando' recurrence model

Michael Arick's iCalendar in UML

iCalendar Usage


W3C Date and Time formats

RDF and calendaring

A quick look at iCalendar, Tim Berners-Lee

Skical in RDF:

'hybrid' model

problems with the hybrid model



RSS 1.0

RSS events module

Last Modified $Date: 2002/12/07 16:27:28 $