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

W3C Interest Group Note 29 September 2005

This version
Latest version
Dan Connolly, W3C
Libby Miller, ASemantics


This report discusses an effort to apply the Resource Description Framework (RDF) to iCalendar data in order to integrate calendar data with other Semantic Web data such as social networking data, syndicated content, and multimedia meta-data. We demonstrate the effectiveness of a test-driven approach to vocabulary development and we discuss a number of social as well as technical issues.

Status of this document

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 standardst 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

an IETF Proposed Standard, to be exact. The IETF Calendaring and Scheduling Standards Simplification (calsify) working group is chartered to "Advance the Calendaring and Scheduling standards to Draft Standard," among other things.

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:

SUMMARY:Scooby Conference
LOCATION:San Francisco

and RDF/XML has analagous class and property constructs:

        <summary>Scooby Conference</summary>
        <location>San Francisco</location>

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:

        <summary>Scooby Conference</summary>
        <location>San Francisco</location>

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="">

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 decided2003-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 decided2003-02-12 to use ical:component to relate calendars to events.

We have explored using the iCalendar uid property to make URIs for event components2003-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.

6. Capitalization and naming conventions

While these examples suggest that the mapping is straightforward, they also demonstrate one of the early issues: capitalization. In iCalendar, component and property names are case insensitive and conventionally written in all caps. But due to internationalization and simplicity considerations, XML names and URIs are case sensitive, and RDF class and property names inherit constraints from XML and URIs. In addition, the established convention is that RDF class names are capitalized and RDF property names begin with a lower case letter, and both use camelCase to join words.

The first attempts to convert iCalendar data to RDF were perl scripts of a hundred lines or so that just manipulated the punctuation. But this approach breaks down when the punctuation of a property depends on the name of the propertyp. Soon it became clear that there were details beyond capitalization that varied from property type to property type; the conversion process needed information from a schema.

or more precisely: on the value type of the property. Each property type has a default value type; for example, DTSTART defaults to DATE-TIME. But a property parameter can be used to set the value type of an individual property; for example: DTSTART;VALUE=DATE:19960401 .

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.

9. Gleaning a schema from the specification text

The iCalendar specification has a very regular structure for value types and such: 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.

We converted this structured plain text to XHTML with semantic markup for two reasons:

  1. to make it easier for people to navigate the structure of the document
  2. to facilitate generation of an RDF schema using XSLT

A python program, slurpIcalSpec.py, produces XHTML including typed links from properties to value types:

Property Name
    This property specifies when the calendar component begins.
Value Type

The default value type isDATE-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.

The markup uses semantic class names and link relationships:

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

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

<dt>Value Type</dt>

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


An XSLT transformation, webize2445.xsl, turns this into RDF/OWL:

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

This approach does not produce schema information for the component property discussed above, nor for properties such as interval and byday used in recurrence rules. Those should be added in due course.

The schema also currently lacks information about which properties are functional or inverse-functional, which are needed for certain diff/sync techniques2004-03-23. Unfortunately, adding that information conflicts with certain OWL DL restrictions, and makes it harder to use OWL DL checking tools with this schema. This remains an open issue.

Another python program, compDecls.py, reads the schema and prints it as a python data structure for use in our iCalendar to RDF conversion utilitytd, fromIcal.py:

                    {"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),
Actually, we don't trust this conversion completely quite yet. The schema is actually integrated into fromIcal.py in a test-driven manner: not until a property is found in an actual test case is the relevant declaration copied from the output of compDecls.py into the source code of fromIcal.py, after careful inspection.

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 decided2003-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 suite2003-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 RDFttl:

@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 iCal2003-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 datesdelt.

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:

and some of which are not:

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

here we display the data using the turtle syntax for RDF. The N3 primer is a gentle introduction to the turtle subset of N3.
with some syntactic support for offsets like -0400

12. Events, places, names, and coordinates

The iCalendar specification includes two features related to places. The location property "... defines the intended venue for the activity defined by a calendar component." That is, it gives a name of the place where the event occurs. For example:

    <#20020630T230445Z-3895-69-1-7@jammer>     a :Vevent;
         :summary "X3 Conference";
         :location "San Francisco";
         :description "can't wait!\n";
         :dtstart "2002-07-03"^^XML:date;
         :dtend "2002-07-06"^^XML:date;
         :uid "20020630T230445Z-3895-69-1-7@jammer" .

The geo property takes a list of 2 floats: latitude and longitude. For example:

    geo:CDC474D4-1393-11D7-9A2C-000393914268     a :Vevent;
         :summary "meeting 23";
         :geo  (
        -79.945815  );
         :dtstart "2003-01-08T13:00:00"^^New:tz;
         :dtend "2003-01-08T14:00:00"^^New:tz .

The relationship of these properties to the Basic Geo (WGS84 lat/long) Vocabulary also in development in the Semantic Web Interest Group has been discussed, but not conclusively. Note that location relates an event to the name of a place, not the place itself; likewise, geo relates an event to a pair of coordinates, not a place. If we take :place to be a property that relates an event to a place where it occurscyc, It seems reasonable to relate them using rules such as:

{ ?E cal:geo (?LAT ?LONG) }
  <=> { ?E :place [ geo:lat ?LAT; geo:long ?LONG ] }.
{ ?E cal:location ?TXT }
  <=> { ?E :place [ rdfs:label ?TXT ] }.
compare #$eventOccursAt in the cyc vocabulary

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:

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

Index: Test Coverage
Component Property Value Type $testcase.rdf
VALARM ACTION TEXT 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf,
VALARM DESCRIPTION TEXT TestTermin.rdf, cal01.rdf, cal02.rdf,
VALARM TRIGGER DURATION 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf,
VEVENT ATTENDEE CAL-ADDRESS 20030115mtg.rdf, 20030122mtg.rdf, cal01.rdf, cal02.rdf,
VEVENT CATEGORIES TEXT cal01.rdf, cal02.rdf, tag-bug.rdf,
VEVENT CLASS TEXT MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf,
VEVENT COMMENT TEXT gkexample.rdf,
VEVENT DESCRIPTION TEXT 20030205mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf, tag-bug.rdf,
VEVENT DTEND DATE-TIME 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, mtg.rdf, openingHours.rdf, querymeetings.rdf, tag-bug.rdf,
VEVENT DTSTAMP DATE-TIME 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf,
VEVENT DTSTART DATE-TIME 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, mtg.rdf, openingHours.rdf, querymeetings.rdf, tag-bug.rdf,
VEVENT LOCATION TEXT TestTermin.rdf, cal01.rdf, cal02.rdf,
VEVENT ORGANIZER CAL-ADDRESS 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf,
VEVENT RRULE RECUR bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, openingHours.rdf, tag-bug.rdf,
VEVENT SEQUENCE integer 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf,
VEVENT SUMMARY TEXT 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, tag-bug.rdf,
VEVENT TRANSP TEXT TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf,
VEVENT UID TEXT 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, tag-bug.rdf,
VTIMEZONE TZID TEXT 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, Todos1.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf,
VTODO SEQUENCE integer Todos1.rdf,
VTODO UID TEXT Todos1.rdf,

14. Related Work

There are a number of related calendar data format projects.

14.1. xCalendar

XCalendar is a simple syntactic conversion of iCalendar to XML. For events with simple attribute-value properties it produces results very similar to RDF case; the differences are syntactic (capitalization) or have to do with the model RDF imposes.

An XSLT transformation from xCalendar to iCalendar is provided.

We have considered a syntactic profile of RDF calendar that would meet the same requirements, but we have not managed to develop a tool to produce this profile given an arbitrary RDF calendar graph as input.

14.2. RSS event module

RSS Events is a proposed module for RSS 1.0. It uses a simple vocabulary inspired by iCalendar:

  <item rdf:about="http://conferences.oreilly.com/p2p/">
    <title>The O'Reilly Peer-to-Peer and Web Services Conference</title>
    <ev:location>Washington, DC</ev:location>

It uses the homepage of an event as the url for the description of the event.

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 ;
              [ 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.

15.1. hCalendar and microformats

hCalendar is an emerging microformat, i.e. a set of semantic XHTML markup conventions. It is based on iCalendar. The approach to human-readability is interesting; for example:

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

We are working on a glean-hcal.xsl, a transformation from hCalendar to RDF Calendar. Using hCalendar with GRDDL is particularly promising, though it goes beyond the scope of this report.

Note that open source implementaitons of the following transformations are available, either from the RDF Calendar workspace or projects nearby:

from iCalendar hCalendar RDF Calendar
to iCalendar X2V toIcal.py
RDF Calendar fromIcal.py glean-hcal.xsl

16. Acknowledgements

We are greatful to Masahide Kanzaki for his RDF calendar service, to Olivier Gutknecht and Paul Cowles for their commercial product development perspective, and the collaborators in www-rdf-calendar, including Julian Reschke, Doug Royer, Tim Berners-Lee, Dave Thewlis, Karl Dubost, Charles McCathieNevile, Michael Arick, Norman Walsh, Tim Hare, and Dan Brickley.

17. References