iCalendar Object Examples in RDF

libby.miller@bristol.ac.uk 2001-06-14

iCalendar in RDF

1. The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996.
   Example 1
   "full" [gif]
   "skical" [gif]
2. The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified.
   Example 2
   "full" [gif]
   "skical" [gif]
3. The following is an example of an iCalendar object passed in a MIME message with a single body part consisting of a "text/calendar" Content Type.
   Example 3
   "full" [gif]
   "skical" [gif]
4. The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.
   Example 4
   "full" [gif]
   "skical" [gif]
5. The following is an example of a journal entry.
   Example 5
   "full" [gif]
   "skical" [gif]
6. The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb.
   Example 6
   "full" [gif]
   "skical" [gif]

Notes on "full" version

• we need to add properties matching VEVENT, VTODO, VTIMEZONE, VALARM etc; or have a CAL-COMPONENT property.
• do datetimes have an rdf value? do they also need a prop saying what the type of that value is (e.g. UTC) - this would be instead of the Z or T? notation?
• VTIMEZONE has 2 parts - standard and daylight. I'm unsure how to model this. Each of them has a start time and a recurrance rule. I've made each a sublass of VTIMEZONE and REC-CAL-COMPONENT
• CATEGORIES/CATEGORY
• CLASSIFICATION/CLASS
• FREEBUSY-PROP to VFREEBUSY-PROP
• not one VFREEBUSY but as many as there are periods.
• Should we break out the parts of DURATION (hours, minutes, weeks etc)

Notes on "SKICal" version

• Should Organizer and Attendee be like SKICal person? (because a Organizer and attendee may have roles. rsvp etc attatched to them).
• Should mailto be a uri? what about uuid? how about making uuid the rdf:ID of the calendar component?
• Should dates be like Price, say, because they may have time zone information attatched to them, much like Price might have currency information attatched to it? If so, should they always be structured like this, even if they haven't got a time zone property?
• How should time zones be tackled, particularly the separation of standard and daylight parts? (see example 2)
• What about Integers, Text etc. Should these be like Price or just literals? (Integers should ideally be typed somehow, maybe using XML schemas?) Text objects in iCalendar can have things attatched to them, and therefore might be better seen as objects with an rdf:value.
• Any thoughts about Vfreebusy objects? (example 6) I'm not sure if there should be three or maybe four (one containing three), or something else.