Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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
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.
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>
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
.
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 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.
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.
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.
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.
The iCalendar specification has a very regular structure for value types and such:
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.
We converted this structured plain text to XHTML with semantic markup for two reasons:
A python program, slurpIcalSpec.py, produces XHTML including typed links from properties to value types:
- Property Name
DTSTART- Purpose
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">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>
An XSLT transformation, webize2445.xsl, turns this into RDF/OWL:
<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>
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:
('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),
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
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.
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:
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.
...2002/12/cal/ical#
schema. This design is using a
somewhat experimental2005-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 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 ( 40.442673 -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 ] }.
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:
$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.$testcase.ics
to a
temporary $testcase-actual.rdf
file.$testcase.rdf
, the
expected results, using an RDF graph comparison tool.$testcase.rdf
to
$testcase-temp.ics
.$testcase-temp.ics
to $testcase-actual.rdf
.$test-case-actual.rdf
to the expected results,
$testcase.rdf
, using an RDF graph comparison tool.$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:
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 | DURATION | DURATION | 20030115mtg.rdf, |
VEVENT | EXDATE | DATE-TIME | tag-bug.rdf, |
VEVENT | LAST-MODIFIED | DATE-TIME | bus-hrs.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 | PRIORITY | INTEGER | TestTermin.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 | LAST-MODIFIED | DATE-TIME | Todos1.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 | COMPLETED | DATE-TIME | Todos1.rdf, |
VTODO | DTSTAMP | DATE-TIME | Todos1.rdf, |
VTODO | DTSTART | DATE-TIME | Todos1.rdf, |
VTODO | DUE | DATE-TIME | Todos1.rdf, |
VTODO | PRIORITY | INTEGER | Todos1.rdf, |
VTODO | SEQUENCE | integer | Todos1.rdf, |
VTODO | STATUS | TEXT | Todos1.rdf, |
VTODO | SUMMARY | TEXT | Todos1.rdf, |
VTODO | UID | TEXT | Todos1.rdf, |
There are a number of related calendar data format projects.
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.
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> <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>
It uses the homepage of an event as the url for the description of the event.
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.
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 | |
hCalendar | |||
RDF Calendar | fromIcal.py | glean-hcal.xsl |
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.