RDF Calendar - an application of the Resource Description Framework to iCalendar Data

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This draft discusses the state of the art in the RDF calendar task force of the Semantic Web Interest Group in the Semantic Web Activity. This work began at the Semantic Web calendaring workshop in October 2002. While a number of issues remain open, the design is backed by a few dozen test cases and it is increasingly useful and stable. Please send comments to www-rdf-calendar@w3.org, a mailing list with public archive.

Publication as an Interest Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

1. Introduction

The Web did two things for sharing information with documents: first, HTML and TCP/IP provided a neutral answer to the questions about which word processor's format to use, which operating system, and which networking technology; second, the Web integrated individual documents into a whole information system so that if the information was already in the Web somewhere, you could just link to it. HTML is feature-poor when compared to other document formats, but the integration benefits of linking outweigh the costs.

Fifteen years later, this works pretty well for documents. If you have a document and someone asks you to provide it to each of a dozen different people that each use different kinds of computers, you can just put it on the Web in HTML and be reasonably sure they can all read it. But the integration problem is still there for data. When a soccer coach distributes a schedule for the season, each of the players has to re-key the information for their calendar system if they want their computer to help them manage conflicts. When an airline sends itineraries, each passenger manually processes them.

The problem is addressed at least in part by an Internet standard^st for calendar data, iCalendar[RFC2554]. But it's not clear that iCalendar provides sufficient integration benefits to outweigh the cost of migrating to open systems from more mature closed calendaring systems. At a Semantic Web calendaring workshop in October 2002, we explored the additional benefits of applying the Resource Description Framework (RDF) to iCalendar data, allowing us to linked it with social networking data (FOAF), syndicated content (RSS), multimedia metadata (dublin core, musicbrainz) etc.

The iCalendar specification is fairly large, with 142 sections and a number of complex interactions. The widely available software seems to cover much of the useful functionality, but not every aspect of the specification; for example, we have not seen tool support for exception rules. Meanwhile, at the workshop, we did have a number of actual iCalendar data files, representing real-world events, that had been converted to RDF either manually or with scripts. The resulting RDF/XML analogs served useful purposes to at least some of the participants and seemed to be correct, by inspection, to all present. This provided critical mass to begin maintaining a test suite

2. Collaboration challenges and rewards

A particularly rewarding aspect of this collaboration is exploring language and culture boundaries. Even though there is a six hour time gap between Chicago and London, office hours overlap regularly, and while the difference in dialect and etiquette is often entertaining, it is rarely an obstacle to understanding. Our colleagues from Japan are much more able to converse in English than we are in Japanese. Even so, without the benefit of non-verbal clues, remote conversations are particularly challenging. Email offers the chance to read and compse at your own pace, but the the timezone gaps between America, Europe, and Asia effective impose a 24 hour round-trip time that is a real barrier to conversation. Internet Relay Chat (IRC) allows near-real-time feedback and clarification as well as the clarity of written text and a chance to reflect at least a few minutes to digest one message and compose another, but only if all parties can devote their attention at the same time.

We use an archived mailing list, www-rdf-calendar@w3.org, as the forum of record, with any significant work that happens by chance in IRC reported there after the fact. We also conduct a form of meeting over IRC, called with advanced notice of a week or so, where some conscious effort is given to agenda management, due process for decision making, follow-up on actions, and the like. We have given the name ScheduledTopicChat to this collaboration pattern. RdfCalendarMeetings serves as an index of meeting records.

3. A simple example

At a glance, converting iCalendar data to RDF is quite straightforward; in iCalendar terms, an event is a component with various properties:

BEGIN:VEVENT
UID:20020630T230445Z-3895-69-1-7@jammer
DTSTART;VALUE=DATE:20020703
DTEND;VALUE=DATE:20020706
SUMMARY:Scooby Conference
LOCATION:San Francisco
END:VEVENT

and RDF/XML has analagous class and property constructs:

      <Vevent>
        <uid>20020630T230445Z-3895-69-1-7@jammer</uid>
        <dtstart>2002-07-03</dtstart>
        <dtend>2002-07-06</date>
        <summary>Scooby Conference</summary>
        <location>San Francisco</location>
      </Vevent>

4. Namespaces: grounding terms in URI space

The terms Vevent, uid, etc. in the RDF/XML example above are actually abbreviations. The Vevent element is dominated by an element with namespace declarations:

<rdf:RDF
  xmlns="http://www.w3.org/2002/12/cal#">
...
      <Vevent>
        <uid>20020630T230445Z-3895-69-1-7@jammer</uid>
        <dtstart>2002-07-03</dtstart>
        <dtend>2002-07-06</date>
        <summary>Scooby Conference</summary>
        <location>San Francisco</location>
      </Vevent>

The result is that the element name Vevent is short for a full URI http://www.w3.org/2002/12/cal#Vevent.

5. Calendar objects, components and files

iCalendar data typically consists of a CALENDAR component with VEVENT components and such inside it. An initial design identified the calendar object with the RDF/XML document ala

  <Vcalendar rdf:about="">
   ...
  </Vcalendar>

i.e. "this document is a Vcalendar with ... ." But we ran into a case of iCalendar data with more than one calendar in a file. There was some discrepancy among implementations as to whether this was good data; mozilla did not seem to accept it, but this was reported as a bug^#179985 and indeed, section 4.4 iCalendar Object says

The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together.

So we decided^2003-02-12 to drop rdf:about="" from our icalendar<->RDF mapping.

iCalendar syntax has no name for the relationship between an outer component and an inner component; it just uses the position in the syntax to express the relationship. Syntactic position in RDF only tells the "part of speech," i.e. subject, predicate, or object of a relationship, so we needed a name for this relationship. We decided^2003-02-12 to use ical:component to relate calendars to events.

We have explored using the iCalendar uid property to make URIs for event components^2003-08-19. It's not clear whether events in separate files bearing the same uid should be considered identical or merely different views of the same event. For example, if they are identical, they have the same alarms. One approach that seems to work well is to use the uid as a fragment identifier rather than as a full URI.

7. Choosing a namespace policy

Capitalization is one of many issues that had a number of efforts to relate iCalendar and RDF (A quick look at iCalendar by Tim Berners-Lee in 2001, hybrid.rdf by Miller and Arick in 2001, ical2rdf.pl by Connolly in 2002) had explored independently. At the workshop 2002, we agreed to work together on a shared RDF Schema, that is: a shared document in the Web that provides definitions, of a sort, for a number of related terms. After consideration of preserving the investment in each of the existing iCalendar schemas, it seemed the data that referenced them might have been composed with an expectation that those schemas would not change. We chose a new namespace name, http://www.w3.org/2002/12/cal#.

The issues around managing changes to an RDF schema are similar to managing changes in other documents: should you update the content in place, or should you keep the old version there and put the new version at a different place in the Web? We chose a process that is reasonably simple and has proven to be quite robust and scalable: the schema is subject to change, with notice and appeal; that is: all changes to the schema are announced to the www-rdf-calendar mailing list; if anyone objects within a week, the change is rolled back for further discussion.

8. Generating a schema from examples

The regular structure of the iCalendar specification, with components and properties, suggests declaring corresponding RDF classes and properties in an RDF schema should be straightforward. But an attempt to do it manually ( hybrid.rdf by Miller and Arick in 2001) proved unwieldy.

We explored using rules to generate a schema from our example data. Rules such as "if something is related to semething else by ?P, then ?P is a Property" and "if something is a ?C, then ?C is a Class" can be expressed in Notation3 rule syntax:

{ [] ?P []. } => { ?P a r:Property }.
{ [] a ?C } => { ?C a s:Class }.

This approach worked to enumerate the classes and properties we were using in our test data, but it did not provide important schema information such as value types.

4.8.2.4 Date/Time Start

   Property Name: DTSTART

   Purpose: This property specifies when the calendar component begins.

   Value Type: The default value type is DATE-TIME. The time value MUST
   be one of the forms defined for the DATE-TIME value type. The value
   type can be set to a DATE value type.

<h2 id="sec4.8.2.4">4.8.2.4 Date/Time Start</h2>
<dl>
<dt id="dtstart">Property Name</dt>
<dd class="PropertyName"><pre>    DTSTART

</pre>
</dd>
<dt>Purpose</dt>
<dd class="Purpose"><pre>    This property specifies when the calendar component begins.

</pre>
</dd>
<dt>Value Type</dt>

<dd class="ValueType">The default value type is <a
 rel="default-value-type"
 href="#Value_DATE-TIME">DATE-TIME</a> <pre>   . The time value MUST
   be one of the forms defined for the <a
 rel="allowed-type"
 href="#Value_DATE">DATE</a>-TIME value type. The value
   type can be set to a <a
 rel="allowed-type"
 href="#Value_DATE">DATE</a> value type.

</pre>
</dd>

  <rdf:Description rdf:ID="dtstart">
    <rdfs:label>DTSTART</rdfs:label>
    <rdfs:comment>This property specifies when the calendar component begins.</rdfs:comment>
    <rdfs:comment>
    default value type: DATE-TIME</rdfs:comment>
    <spec:valueType>DATE-TIME</spec:valueType>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
    <rdfs:range>
      <owl:Class>
        <owl:unionOf rdf:parseType="Collection">
          <owl:Class rdf:about="#Value_DATE-TIME"/>
          <owl:Class rdf:about="#Value_DATE"/>
          <owl:Class rdf:about="#Value_DATE"/>
        </owl:unionOf>
      </owl:Class>
    </rdfs:range>

                   ('Vevent',
                    {"ATTACH": ('attach', 'URI', 0, None),
                     "CATEGORIES": ('categories', "TEXT", 0, None),
                     "SUMMARY": ('summary', "TEXT", 0, None),
                     "DTEND": ('dtend', 'DATE-TIME', 0, None),
                     "DTSTART": ('dtstart', 'DATE-TIME', 0, None),

10. Extension Tokens and Product Identifiers

The iCalendar syntax allows extension tokens in a number of places. Ideally, we would like to ground these extension tokens in URI space as well, but none of the approaches we have tried is completely satisfactory.

One approach was to specify a namespace for x- tokens on the command line, at conversion time. The drawbacks of this approach are

1. It is limited to one extension namespace. We have not explored in detail any iCalendar data with extension tokens from more than one source, but it is possible, at least in theory.
2. The user must somehow know the URI for the extensions in the file. RDF schemas for these extensions are not widely deployed, so users would be left with the problem of publishing them in many cases.

iCalendar data is labelled with a product ID that serves a similar role to an XML namespace name, though it is not expressed as a URI. We decided^2003-02-26 to institute an ical product registry. When we found some extensions used by some product, we would publish a schema for those extensions using a URI starting with 'http://www.w3.org/2002/12/cal/prod/' followed by a function of the product id.

The drawback of this approach is that it does not seem to be worth the trouble. In practice, we seem to be more content to just disregard the extended properties. Handling extensions remains an outstanding issue in our test suite^2003-08-20.

Now that we have explored the schema and extension tokens, let's look at the calendar data itself.

11. Shop hours, recurring events and timezones

Consider the case of a shop with regular hours. Contemporary directory services provide telephone numbers and street addresses, complete with automated driving directions. But you still have to pick up the phone and call them to find out when they're open. Typical shop hours can be expressed using recurring events in iCalendar. The bus-hrs.rdf test expresses "Open 11:30a-11:30p Wed-Sun; Open Tue 4-11p" in RDF^ttl:

@prefix : <http://www.w3.org/2002/12/cal/icaltzd#> .
@prefix NY: <http://www.w3.org/2002/12/cal/tzd/America/New_York#> .
   <#20030314T052745Z-25601-69-1-8@dirk> a :Vevent;
         :class "PUBLIC";
         :dtend "2003-03-12T23:00:00"^^NY:tz;
         :dtstart "2003-03-12T11:30:00"^^NY:tz;
         :rrule  [
             :byday "SU,WE,TH,FR,SA";
             :freq "WEEKLY";
             :interval "1" ];
          :summary "Open 11:30a-11:30p Wed-Sun".
    <#20030314T052656Z-25601-69-1-0@dirk> a :Vevent;
         :class "PUBLIC";
         :dtend "2003-03-11T23:00:00"^^NY:tz;
         :dtstart "2003-03-11T16:00:00"^^NY:tz;
         :rrule  [
             :byday "TU";
             :freq "WEEKLY";
             :interval "1" ];
         :summary "Open Tue 4-11p".

There is a question of whether timezone rules should be given by reference or by copy. Some data from early releases of Apple's iCal application lacked explicit VTIMEZONE components, but the specification is clear that they are required and this was acknowledged as a bug in Apple's iCal^2003-03-12 and has since been fixed. So the bus-hrs.rdf file includes timezone rules:

    NY:tz     a :Vtimezone;
         :daylight  [
             :dtstart "1970-04-05T02:00:00"^^:dateTime;
             :rrule  [
                 :byday "1SU";
                 :bymonth "4";
                 :freq "YEARLY";
                 :interval "1" ];
             :tzname "EDT";
             :tzoffsetfrom "-0500";
             :tzoffsetto "-0400" ];
         :standard  [
             :dtstart "1970-10-25T02:00:00"^^:dateTime;
             :rrule  [
                 :byday "-1SU";
                 :bymonth "10";
                 :freq "YEARLY";
                 :interval "1" ];
             :tzname "EST";
             :tzoffsetfrom "-0400";
             :tzoffsetto "-0500" ];
         :tzid "/softwarestudio.org/Olson_20011030_5/America/New_York";
         x-lic:location "America/New_York" .

While those rules are an accurate model of the timezone in New York at least as far back as 1970, the Energy Policy Act of 2005 is intended to change them in 2006. While the Olson database is likely to reflect these changes in due course, the copies in all the iCalendar data out there will fail to accurately represent the timezone rules for New York.

One approach, exemplified by the datetime design pattern in the microformats community, is to not use iCalendar timezones, but only UTC dates^delt.

Another approach is to put the timezone rules in the Web, establish change control policies with some minimum notice, and pass timezones around by reference. As a step in this direction, we have published each entry in a version of the Olsen database in our RDF Calendar workspace. For example, NY:tz, i.e. http://www.w3.org/2002/12/cal/tzd/America/New_York#tz. We are considering some way to connect this data to the relevant political decision-making processes. Ultimately, it would be best if the respective policitcal organizations published the data by themselves.

There are a few other issues to note from the example above, some of which are resolved:

• We punctuate dates with hyphens, following XML Schema datatypes, rather than using iCalendar syntax exactly.
• The interval is given explicitly, even though it is the default value, "1". Defaults are a form of closed world assumption; it's simpler to avoid them in Semantic Web data^2003-02-12.

and some of which are not:

• Note that NY:tz timezone is used as a datatype. Earlier, we used separate properties for time and timezone, which is initially appealing but problematic for reasons that are detailed in the InterpretationProperties pattern.
  • Objections were raised when this change was made to the original ...2002/12/cal/ical# schema. This design is using a somewhat experimental^2005-03-30 namespace name, ...2002/12/cal/icaltzd#.

We hope to find a consensus with a number of parties on issues around timezones and recurring events:

• The daml-time work looks promising; we have some outstanding questions^2005-02-18 for them.
• The IETF calsify WG is reconsidering recurrence rules, with input such as the Calconnect Recurrence Questionnaire.

13. Using RDF graph comparison for round-trip testing

The vehicle for our exploration of schema and data issues is a test suite. At this point, we have a schema supported by a useful, if not complete, collection of tests and conversion tools:

• Each test consists of a $testcase.ics file that is judged to be a correct iCalendar file (i.e. it conforms to RFC 2445 and one or more popular iCalendar tool consumes it correctly and/or allows the user to produce it) and a corresponding $testcase.rdf file that is judged to agree. For example, cal01.ics and cal01.rdf are one test case.
• An iCalendar to RDF conversion tool can be tested as follows:
  1. Use the tool under test to convert $testcase.ics to a temporary $testcase-actual.rdf file.
  2. Compare the actual results with $testcase.rdf, the expected results, using an RDF graph comparison tool.
• A tool to convert to iCalendar from RDF can be tested with respect to a correct tool that goes the other way:
  1. Use the tool under test to convert $testcase.rdf to $testcase-temp.ics.
  2. Use the known-good tool to convert $testcase-temp.ics to $testcase-actual.rdf.
  3. Compare $test-case-actual.rdf to the expected results, $testcase.rdf, using an RDF graph comparison tool.
• The schema can be checked against the test data to see that...
  • each class and property in the schema is used in one or more test cases,
  • each class or property used in a test case is declared in the schema, and
  • each $testcase.rdf is logically consistent with the schema.

The following table shows, for each component and property, the test case files that use that property on that type of component:

  <item rdf:about="http://conferences.oreilly.com/p2p/">
    <title>The O'Reilly Peer-to-Peer and Web Services Conference</title>
    <link>http://conferences.oreilly.com/p2p/</link>
    <ev:type>conference</ev:type>
    <ev:organizer>O'Reilly</ev:organizer>
    <ev:location>Washington, DC</ev:location>
    <ev:startdate>2001-09-18</ev:startdate>
    <ev:enddate>2001-09-21</ev:enddate>
  </item>

15. Conclusions and future work

While the RDF Calendar vocabulary is still a work-in-progress, it provides anyone with RDF or XML tools a useful alternative to dealing with the character-level syntax of iCalendar. Our test-driven approach to Semantic Web vocabulary development has allowed us to manage changes as we explored and resolved a variety of issues. The "subject to change with notice and appeal" change policy for our schema seems to work well.

We have exploited the graph model of RDF in our round-trip testing work, but explorations into comparisons, especially for the purpose of synchronizing changes, are at an early stage. See Delta: an ontology for the distribution of differences between RDF graphs for one approach.

We are still in relatively early stages of mixing calendar data with other Semantic Web data. As an illustrative example, consider using the FOAF vocabulary to describe an attendee of an event:

[]    a       :Vevent ;
      :attendee
              [ a       foaf:Person ;
                :calAddress <mailto:me@example.com> ;
                foaf:mbox <mailto:me@example.com> ;
                foaf:name "My name"
              ] ;
      :dtend  "2002-06-30T10:30:00"^^NY:tz ;
      :dtstart "2002-06-30T09:00:00"^^NY:tz ;
      :summary "Tree Conference" .

The iCalendar specification has some prohibitions against publishing email addresses. This is one of many privacy considerations with calendar data.

Queries and rules to relate photos to events via metadata such as date-taken is another promising area of work.

<abbr class="dtstart" title="2005-10-05">October 5</abbr>