RDF Calendar - an application of the Resource Description Framework toiCalendar Data

W3C Interest Group Note 29 September 2005

This version

http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/

Latest version

http://www.w3.org/TR/rdfcal/

Authors

Dan Connolly, W3C

Libby Miller, ASemantics

Copyright ©2005W3C^®(MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademarkanddocumentuse rules apply.

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

This draft discusses the state of the art in the RDF calendar taskforce of theSemanticWeb Interest Group in theSemantic Web Activity. Thiswork began at theSemanticWeb calendaring workshop in October 2002. While a number of issuesremain open, the design is backed by a few dozen test cases and it isincreasingly useful and stable. Please send comments towww-rdf-calendar@w3.org, amailing list withpublicarchive.

Publication as an Interest Group Note does not implyendorsement by the W3C Membership. This is a draft document and may beupdated, replaced or obsoleted by other documents at any time. It isinappropriate to cite this document as other than work inprogress.

Contents

• 1. Introduction
• 2. Collaboration challenges and rewards
• 3. A simple example
• 4. Namespaces: grounding terms in URI space
• 5. Calendar objects, components and files
• 6. Capitalization and naming conventions
• 7. Choosing a namespace policy
• 8. Generating a schema from examples
• 9. Gleaning a schema from the specification text
• 10. Extension Tokens and Product Identifiers
• 11. Shop hours, recurring events and timezones
• 12. Events, places, names, and coordinates
• 13. Using RDF graph comparison for round-trip testing
• 14. Related Work
  • 14.1. xCalendar
  • 14.2. RSS event module
• 15. Conclusions and future work
  • 15.1. hCalendar and microformats
• 16. Acknowledgements
• 17. References

1. Introduction

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

Fifteen years later, this works pretty well for documents. If you have adocument and someone asks you to provide it to each of a dozen differentpeople that each use different kinds of computers, you can just put it on theWeb in HTML and be reasonably sure they can all read it. But the integrationproblem is still there for data. When a soccer coach distributes a schedulefor the season, each of the players has to re-key the information for theircalendar 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 providessufficient integration benefits to outweigh the cost of migrating to opensystems from more mature closed calendaring systems. At aSemantic Webcalendaring workshop in October 2002, we explored the additional benefitsof applying the Resource Description Framework (RDF) to iCalendar data, allowing us tolinked 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 anumber of complex interactions. The widely available software seems to covermuch of the useful functionality, but not every aspect of the specification;for example, we have not seen tool support forexception rules. Meanwhile, at the workshop, wedid have a number of actual iCalendar data files, representing real-worldevents, that had been converted to RDF either manually or with scripts. Theresulting RDF/XML analogs served useful purposes to at least some of theparticipants and seemed to be correct, by inspection, to all present. Thisprovided critical mass to begin maintaining a test suite

2. Collaboration challenges and rewards

A particularly rewarding aspect of this collaboration is exploringlanguage and culture boundaries. Even though there is a six hour time gapbetween Chicago and London, office hours overlap regularly, and while thedifference in dialect and etiquette is often entertaining, it is rarely anobstacle to understanding. Our colleagues from Japan are much more able toconverse in English than we are in Japanese. Even so, without the benefit ofnon-verbal clues, remote conversations are particularly challenging. Emailoffers the chance to read and compse at your own pace, but the the timezonegaps between America, Europe, and Asia effective impose a 24 hour round-triptime that is a real barrier to conversation. Internet Relay Chat (IRC) allowsnear-real-time feedback and clarification as well as the clarity of writtentext and a chance to reflect at least a few minutes to digest one message andcompose another, but only if all parties can devote their attention at thesame time.

We use an archived mailing list,www-rdf-calendar@w3.org, astheforum of record, with any significant work that happens by chancein IRC reported there after the fact. We also conduct a form of meeting overIRC, called with advanced notice of a week or so, where some conscious effortis given to agenda management, due process for decision making, follow-up onactions, and the like. We have given the nameScheduledTopicChat tothis collaboration pattern.RdfCalendarMeetingsserves as an index of meeting records.

3. A simple example

At a glance, converting iCalendar data to RDF is quite straightforward; iniCalendar terms, an event is acomponent withvariousproperties:

BEGIN:VEVENTUID:20020630T230445Z-3895-69-1-7@jammerDTSTART;VALUE=DATE:20020703DTEND;VALUE=DATE:20020706SUMMARY:Scooby ConferenceLOCATION:San FranciscoEND: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 termsVevent,uid, etc. in the RDF/XMLexample above are actually abbreviations. TheVevent element isdominated 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 nameVevent is short for afull URIhttp://www.w3.org/2002/12/cal#Vevent.

5. Calendar objects, components and files

iCalendar data typically consists of aCALENDARcomponent withVEVENTcomponents and such inside it. An initial design identified the calendarobject with the RDF/XML document ala

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

i.e. "this document is a Vcalendar with ... ." But we ran intoacase of iCalendar data with more than one calendar in a file. There wassome discrepancy among implementations as to whether this was good data;mozilla did not seem to accept it, but this was reported as a bug^#179985and indeed, section4.4 iCalendar Objectsays

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-12to droprdf:about="" from our icalendar<->RDF mapping.

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

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

p

or more precisely: on the value type of the property. Each property type has a default value type; for example,DTSTART defaults toDATE-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 torelate iCalendar and RDF (A quick look atiCalendar by Tim Berners-Lee in 2001,hybrid.rdfby Miller and Arick in 2001,ical2rdf.pl by Connolly in 2002) hadexplored independently. At theworkshop 2002, we agreed towork together on a shared RDF Schema, that is: a shared document in the Webthat provides definitions, of a sort, for a number of related terms. Afterconsideration of preserving the investment in each of the existing iCalendarschemas, it seemed the data that referenced them might have been composedwith an expectation that those schemas would not change. We chose a newnamespace name,http://www.w3.org/2002/12/cal#.

The issues around managing changes to an RDF schema are similar tomanaging 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 adifferent place in the Web? We chose a process that is reasonably simple andhas proven to be quite robust and scalable:the schema is subject tochange, with notice and appeal; that is: all changes to the schemaare announced to thewww-rdf-calendar mailing list; if anyoneobjects within a week, the change is rolled back for further discussion.

8. Generating a schemafrom examples

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

We explored using rules to generate a schema from our example data. Rulessuch as "if something is related to semething else by ?P, then ?P is aProperty" and "if something is a ?C, then ?C is a Class" can be expressed inNotation3 rulesyntax:

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

This approach worked to enumerate the classes and properties we were usingin our test data, but it did not provide important schema information such asvalue 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>4.8.2.4 Date/Time Start</h2><dl><dt>Property Name</dt><dd><pre>    DTSTART</pre></dd><dt>Purpose</dt><dd><pre>    This property specifies when the calendar component begins.</pre></dd><dt>Value Type</dt><dd>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 andProduct 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 toan XML namespace name, though it is not expressed as a URI. We decided^2003-02-26to institute an ical product registry. When we found some extensions used bysome product, we would publish a schema for those extensions using a URIstarting 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 thetrouble. In practice, we seem to be more content to just disregard theextended properties. Handling extensions remains an outstanding issue in ourtest suite^2003-08-20.

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

11. Shop hours, recurring events and timezones

Consider the case of a shop with regular hours. Contemporary directoryservices provide telephone numbers and street addresses, complete withautomated driving directions. But you still have to pick up the phone andcall them to find out when they're open. Typical shop hours can be expressedusing recurring events in iCalendar. Thebus-hrs.rdf testexpresses "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 referenceor by copy. Some data from early releases of Apple's iCal application lackedexplicit VTIMEZONE components, but the specification is clear that they arerequired and this was acknowledged as a bug in Apple's iCal^2003-03-12and 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 atleast as far back as 1970, the Energy Policy Act of 2005 is intended tochange them in 2006. While the Olson database is likely to reflect thesechanges in due course, the copies in all the iCalendar data out there willfail to accurately represent the timezone rules for New York.

One approach, exemplified by thedatetimedesign pattern in the microformats community, is to not use iCalendartimezones, but only UTC dates^delt.

Another approach is to put the timezone rules in the Web, establish changecontrol policies with some minimum notice, and pass timezones around byreference. As a step in this direction, we have published each entry in aversion 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 areconsidering some way to connect this data to the relevant politicaldecision-making processes. Ultimately, it would be best if the respectivepolicitcal organizations published the data by themselves.

There are a few other issues to note from the example above, some of whichare 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 ofclosed world assumption; it's simpler to avoid them in Semantic Web data^2003-02-12.

and some of which are not:

• Note thatNY: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 theInterpretationProperties 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 aroundtimezones and recurring events:

• The daml-time work looks promising; we have some outstanding questions^2005-02-18 for them.
• The IETFcalsify WG is reconsidering recurrence rules, with input such as theCalconnect 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 oftests andconversion 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 andcal01.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 casefiles 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 providesanyone with RDF or XML tools a useful alternative to dealing with thecharacter-level syntax of iCalendar. Our test-driven approach to Semantic Webvocabulary development has allowed us to manage changes as we explored andresolved 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 ofsynchronizing changes, are at an early stage. SeeDelta: an ontology forthe distribution of differences between RDF graphs for oneapproach.

We are still in relatively early stages of mixing calendar data with otherSemantic Web data. As an illustrative example, consider using theFOAF vocabulary to describe an attendeeof 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 emailaddresses. This is one of many privacy considerations with calendar data.

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

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