The point of using RDFical (iCalendar in RDF) is to combine it with different namespaces, so you can say things about people, locations and documents and images, and their relation to events. Examples might include: pictures and weblogs of people attending this meeting, location of this meeting. See RDF calendar workshop report for more usecases. There are lots of usecases for this. We almost never want to talk about an event without talking about people, documents or places.
If you’re not going to combine different vocabularies together, then you might as well stick with icalendar, which is used by many applications including Mozilla calendar and Apple ical. This is why in the RDFiCal work we have simply translated iCalendar to RDF and not added or changed anything; and have focussed on being able to roundtrip between RDFical and iCalendar itself.
Here are a few examples of using RDFical with the FOAF and geo vocabularies, both with FOAF files and within RDFical files. These are preliminary, and may change (let me know if you think there are problems with these approaches).
RDFical and location, with a slightly dodgy interepretation of geo in iCalendar (see RFC 2445 4.8.1.6 Geographic Position). See also GeoInfo wiki page and Geo workspace.
Attendee in RDFical, pointing to FOAF files, and – basic icalendar files and RDFical files and templates for movable type.
Saying you are attending an event in a FOAF file. See also
Vinay Pawar’s suggestion and thread, and discussion on #foaf
See also representing plans to attend which is more tricky.
One issue that keeps coming up is referencing events rather than calendars. Calendars often have urls in iCalendar; they are some arbitrary group of events. Events in iCalendar do not usually have urls (as generated by many applications) but they can do (see RFC 2445, section 4.8.4.6 Uniform Resource Locator, “This property may be used in a calendar component to convey a location where a more dynamic rendition of the calendar information associated with the calendar component can be found.“)
This is interesting because it implies authority. Who says this is the ‘real’ url of the event (or the ‘real’ uid for it for that matter)?. Some practical way around this is essential, or we won’t all be able to say – “I was at WWW2003”, and similar. Dan Brickley has suggested using foaf:homepage as an InverseFunctionalProperty for RDFical events. That’s ok if there is a page for the event, though there may not be (you can imagine nasty confusions with the homepage of a conference being regarded as the homepage of a talk at the conference, and the talk disappearing in a puff of owl logic).
There’s an associated problem which also bears on RSS and RDFical (chatting with Chris Heathcote last night about his excellent London art aggregator, following an interesting comment from Danny Ayres). My experiments with RDFical and RSS 1.0 use foaf:topic to separate the RSS 1.0 feed item (with its url) from the event itself (which might have a homepage, but is not itself a url). This issue is analogous to people and urls. People are not webpages though they may have homepages. Events are not webpages, though they may have homepages and other pages about them. If we ignore this distinction we get things like:
<item rdf:about="http://www2004.org"> <title>WWW2004</title> <ical:dtstart rdf:parseType="Resource"> <ical:dateTime>2004-05-17</ical:dateTime> </ical:dtstart> <ical:dtend rdf:parseType="Resource"> <ical:dateTime>2004-05-22</ical:dateTime> </ical:dtend> </item>
– now the webpage of www2004 has a startdate and an enddate, not what we intended. We know that that isn’t what is meant by this, but the machines don’t know, and confusion will result.
Chris was arguing that the rss link did not have to be a url, but could be a non-url uri, and therefore not confusable with a webpage. Ok, that seems more reasonable, although I worry that people will in fact tend to use actual urls of webpages, especially because that’s what RSS is designed for. Comments very welcome – it would be nice to get some of these issues resolved.