Proposed
Copyright © 2001 by the Author.
Permission to use, copy, modify and distribute this RDF Site Summary 1.0 Module Specification and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of the specification for any purpose. It is provided "as is" without expressed or implied warranty.
This copyright applies to this RDF Site Summary 1.0 Module Specification and accompanying documentation and does not extend to the RSS Module's format itself.
With RSS we have the ability grab news and summaries from other websites and display them on our portals. However, a key property of news is that they describe something that just happened. Therefore the most interesting news are the newest news.
Not so with events such as conferences, product launches, training courses etc. Events take place on a certain date in the future, and can be announced years or just a few days in advance. So when we announce them, we need to sort them on the date of the event. because the most interesting events are those that are going to happen in the near future.
Imagine, that you have a calendar on your website. Imagine then that this calendar can be set up to automatically grab announcements of events from the O'Reilly events website - letting know when the next Perl/Open Source conference is - or the next IRC chat with Tim - or the release schedule for a new book. This is what the event module will provide.
This specification is not a reimplementation of RFC2445 iCalendar in RDF. In particular, it lacks such things as TODO and repeating events, and there is no intention of adding those parts to the specification.
<item> Elements:
Required. The date/time when the event starts. If the ev:startdate doesn't specify timezone, then the timezone is implied in the ev:location. Time intervals are not allowed.
The date/time when the event ends. If the ev:enddate is the same as ev:startdate or not specified, then the event has no duration. The ev:enddate can have a different time zone than the ev:startdate. Time intervals are not allowed.
The place of the event. The content is a short description. Use semantic augmentation if you desire to give i.e. a URL to the place.
The name of the organization or person who organizes the event. Use semantic augmentation if you desire to give i.e. a phone number to the organizer.
The type of event, such as conference, deadline, launch, project meeting. The purpose is to promote or filter out certain types of events that the user has a particular (lack of) interest for. Avoid the use of subject specific wording. Use instead the Dublin Core subject element.
<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ev="http://purl.org/rss/1.0/modules/event/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/" > <channel rdf:about="http://events.oreilly.com/?_fl=rss1.0"> <title>O'Reilly Events</title> <link>http://events.oreilly.com/</link> <description>O'Reilly Events</description> <items> <rdf:Seq> <rdf:li rdf:resource="http://conferences.oreilly.com/p2p/" /> <rdf:li rdf:resource="http://www.oreilly.com/catalog/progxmlrpc/" /> </rdf:Seq> </items> </channel> <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> <dc:subject>P2P</dc:subject> </item> <item rdf:about="http://www.oreilly.com/catalog/progxmlrpc/"> <title>Programming Web Services with XML-RPC</title> <link>http://www.oreilly.com/catalog/progxmlrpc/</link> <ev:startdate>2001-06-20</ev:startdate> <ev:type>book release</ev:type> <dc:subject>XML-RPC</dc:subject> <dc:subject>Programming</dc:subject> </item> </rdf:RDF>
Even though the international standard on dates and times (ISO8601) has a means to specify a time interval, the W3 recommendation, which is a profile of ISO8601 is silent on the issue, and I must therefore conclude that few existing date parsers will be able to parse a time interval. Personally I would have preferred to use ev:date and the full ISO8601 specification because it is more flexible. We would have had several ways to specify a period. But the RSS 1.0 specification demands W3CDTF. On another level, I'm relieved that the W3CDTF profile restricts the date formats, as it makes parsing the date much more straight forward.
Humans effortlessly works with two types of events: One where they physically have to be present and events where some kind of telecommunication device is used such as television, telephone etc. People living in Europe who are going to attend a meeting in California will pencil the appointment into their calendar without any time zone information, because they know that once they have arrived in California the calendar is correct. But if they were to have a phone meeting, then they calculate the 9 hour difference and write an appointment for 3 am in the calendar.
Calendar designers could be tempted to do the conversion automatically making the hours displayed in the user's local time. It works pretty well if the events are television broadcasts, but in general, this is a very difficult thing to do, as the calendar has no way of knowing if the user chooses to attend the event in person or participate by telephone. In addition, a problem with ISO8601 date specification is that is doesn't specify which rule determines when a location changes to/from daylight savings time. It is therefore not possible to automatically convert a date to your local time zone unless it is acceptable to be up to an hour off the mark.
In many cases an event does not need to take place on a specific second or minute. An event can have the same precision as an W3CDTF date.
For example, if the startdate and enddate are both 2001-08-19 this means the event has no duration and takes place sometime on the 19th of August.
If the startdate is 2001-08-19 and the enddate is 2001-08-20 this means the event takes a full day and ends just before the day rolls into August 20. An example of this could be Ascension day.
If startdate and enddate have different precisions, the startdate precision takes precedence.
The syndication of an event should not stop until after the enddate has passed. The receiving end might have chosen to keep historic information, so don't assume the receiving end will discard the announcement when you do.