RSS+events module

From Chris Heathcoate’s art rss aggregator I found an updated version of RSS+events module. I’m really pleased to see that it’s been updated so that the event is a ‘thing’ in itself and isn’t confused with the webpage describing it, and that geo:Point has been added for geographical data. Couple of problems: I don’t think it’s legal RDF any more (the geo:Point part should use a property); and start and enddate semnatics and modelling means that it’s not possible to roundtrip from iCalendar, which I think is a shame.
So the geo:Point part could be fixed by doing this:
<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:item>
<rdf:Description>
<ev:startdate>2001-06-20</ev:startdate>
<ev:type>book release</ev:type>
<ev:location rdf:parseType=”Resource”>
<geo:lat>39.04</geo:lat>
<geo:long>-95.69</geo:long>
</ev:location>
</rdf:Description>
</ev:item>
<dc:subject>XML-RPC</dc:subject>
<dc:subject>Programming</dc:subject>
</item>
OR
<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:item>
<rdf:Description>
<ev:startdate>2001-06-20</ev:startdate>
<ev:type>book release</ev:type>
<ev:location>
<geo:Point>
<geo:lat>39.04</geo:lat>
<geo:long>-95.69</geo:long>
</geo:Point>
</ev:location>
</rdf:Description>
</ev:item>
<dc:subject>XML-RPC</dc:subject>
<dc:subject>Programming</dc:subject>
</item>
Start and Enddate.
The semantics of no timezone for these in iCalendar RFC 2445 are that where no timezone is specified the event starts (or ends) at the same time everywhere. So if we had <ev:startdate>2001-06-20T10:00:00</ev:startdate> that would be 10 am at all timezones. With a timezone (according to W3CDTF), we have
<ev:startdate>2001-06-20T10:00:00Z</ev:startdate> or
<ev:startdate>2001-06-20T10:00:00-0500</ev:startdate>
i.e. at 10am in a particular timezone.
This is a less significant issue when only dates are considered and not times.
As the authors of the new version of the events module indicate, W3CDTF version of timezones is not sufficient to calculate the current time because it cannot handle the change from daylight savings time. This is why the iCalendar specification says that you must include a timezone identifier and a description of the timezone in the same file.
This is why in the competing RDFical we have made the dates objects so we can attatch timezone information to them. This brings its own significant issues, but works with iCalendar so that roundtripping is possible.
Is roundtripping important? I think so…there are so many tools using iCalendar, including Outlook, Evolution, Mozilla Calendar, Apple iCal, and many mobile phones, that it makes sense to be able to convert back into a form that all our other devices and applications understand.