RdfCalendarDocumentation

From W3C Wiki

At first glance, applying the Resource Description Framework (RDF) to iCalendar data is quite straightforward; 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</dtend>
        <summary>Scooby Conference</summary>
        <location>San Francisco</location>
      </Vevent>


We worked out the details of the RDF schema for iCalendar data in a series of RdfCalendarMeetings by considering iCalendar test data, which was often not just test data but data that we were actually trying to manage, and analogs of that data in RDF produced/consumed by conversion tools. After working thru quite a few cases, the analogy largely holds, but a number of interesting issues do arise:

  • relationship between calendar components and files
  • Schema Change Control Policy (RdfCalendarChangeControlPolicy?)
  • Keeping the schema in sync with test data
  • Keeping the schema in sync with RFC2445
  • iCalendar implementation conformance issues (e.g. Apple iCalendar, Evolution, or Mozilla Calendar), (example issue).
  • extension properties
  • expressiveness issues ("next summer" non-gregorian calendars)
  • recurring events, defaults

Calendar Objects, Components and Files

iCalendar data typically consists of a calendar component with events and such as components 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 (mozilla 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.


and so we 


RESOLVED(1.2q.drop): whereas relationship beteween files and
ical:Calendars is not 1-1, drop Vcalendar rdf:about="" from our
icalendar<->RDF mapping.


iCalendar syntax has no name for the relationship between an ourter 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. In our 2003-02-12 meeting, we 


RESOLVED(1.1q4): to use { ical:component a rdf:Property;
ss:rangeIntersects ical:Vevent } to relate calendars to events, e.g. in
the case of multiple calendars in one file. { :cal1 ical:component :ev1.
:cal2 ical:component :ev2 }.


-- DanConnolly edited to here --

http://www.w3.org/2002/12/cal/ical#Vevent

RFC 2445: 


4.6.1 Event Component

Component Name: "VEVENT"

   Purpose: Provide a grouping of component properties that describe an
   event.


references from www-rdf-calendar@w3.org and in IRC ScheduledTopicChat: 


RESOLVED(1.1q4): to use { ical:component a rdf:Property;
ss:rangeIntersects ical:Vevent } to relate calendars to events, e.g. in
the case of multiple calendars in one file. { :cal1 ical:component :ev1.
:cal2 ical:component :ev2 }.


http://ilrt.org/discovery/chatlogs/rdfig/2003-02-12.html#T17-33-35 http://new-rdfig.xmlhack.com/2003/02/12/2003-02-12.html#1045063138.593306 (some context: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0007.html, also http://bugzilla.mozilla.org/show_bug.cgi?id=179985 [mozilla bug with multiple VCALENDARS in one file not importing into applications])

http://www.w3.org/2002/12/cal/ical#Vtimezone

RFC 2445: 


4.6.5 Time Zone Component

   Component Name: VTIMEZONE

   Purpose: Provide a grouping of component properties that defines a
   time zone.

[...]


   An individual "VTIMEZONE" calendar component MUST be specified for
   each unique "TZID" parameter value specified in the iCalendar object.


references from www-rdf-calendar@w3.org and in IRC ScheduledTopicChat:

some issues with Apple Ical and Mozilla calendar and Vtimezone: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0011.html

compliance with icalendar http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0037.html

published timezone data in RDF http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0010.html

http://www.w3.org/2002/12/cal/ical#action

RFC 2445: 



4.8.6 Alarm Component Properties

   The following properties specify alarm information in calendar
   components.

4.8.6.1 Action

   Property Name: ACTION

   Purpose: This property defines the action to be invoked when an alarm
   is triggered.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be specified once in a "VALARM"
   calendar component.

   Description: Each "VALARM" calendar component has a particular type
   of action associated with it. This property specifies the type of
   action


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

No more information about this found.

http://www.w3.org/2002/12/cal/ical#attendee

RFC 2445: 



4.8.4 Relationship Component Properties

   The following properties specify relationship information in calendar
   components.

4.8.4.1 Attendee

   Property Name: ATTENDEE

   Purpose: The property defines an "Attendee" within a calendar
   component.

   Value Type: CAL-ADDRESS

   Property Parameters: Non-standard, language, calendar user type,
   group or list membership, participation role, participation status,
   RSVP expectation, delegatee, delegator, sent by, common name or
   directory entry reference property parameters can be specified on
   this property.

...


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

references from www-rdf-calendar@w3.org and in IRC ScheduledTopicChat:

Plans to attend: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jun/0011.html

Attendees in public documents http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Apr/thread.html#8

http://www.w3.org/2002/12/cal/ical#byday

RFC 2445: 



   The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44)
   separated list of days of the week; MO indicates Monday; TU indicates
   Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates
   Friday; SA indicates Saturday; SU indicates Sunday.

   Each BYDAY value can also be preceded by a positive (+n) or negative
   (-n) integer. If present, this indicates the nth occurrence of the
   specific day within the MONTHLY or YEARLY RRULE. For example, within
   a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
   within the month, whereas -1MO represents the last Monday of the
   month. If an integer modifier is not present, it means all days of
   this type within the specified frequency. For example, within a
   MONTHLY rule, MO represents all Mondays within the month.

(part of 4.3.10 Recurrence Rule

   Value Name: RECUR
)


references from www-rdf-calendar@w3.org and in IRC ScheduledTopicChat:

opening hours RDF cal use case http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/thread.html#14

Examples: http://www.w3.org/2002/12/cal/test/gkexample.rdf http://www.w3.org/2002/12/cal/test/gkexample.ics

http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#bymonth

RFC 2445: 



   The BYMONTH rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of months of the year. Valid values are 1 to 12.

(part of 
4.3.10 Recurrence Rule

   Value Name: RECUR
)


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#calAddress

RFC 2445: 




4.3.3   Calendar User Address

   Value Name: CAL-ADDRESS

   Purpose: This value type is used to identify properties that contain
   a calendar user address.

   Formal Definition: The value type is as defined by the following
   notation:

     cal-address        = uri

   Description: The value is a URI as defined by [RFC 1738] or any other
   IANA registered form for a URI. When used to address an Internet
   email transport address for a calendar user, the value MUST be a
   MAILTO URI, as defined by [RFC 1738].


references from www-rdf-calendar@w3.org and in IRC ScheduledTopicChat:

representing attendance, plans to attend http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jun/0011.html

Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#calscale

RFC 2445: 




4.7.1 Calendar Scale

   Property Name: CALSCALE

   Purpose: This property defines the calendar scale used for the
   calendar information specified in the iCalendar object.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: Property can be specified in an iCalendar object. The
   default value is "GREGORIAN".

   Description: This memo is based on the Gregorian calendar scale. The
   Gregorian calendar scale is assumed if this property is not specified
   in the iCalendar object. It is expected that other calendar scales
   will be defined in other specifications or by future versions of this
   memo.


ical schema based on 1 test case: mtg.ics http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Dec/0024.html

different calendars http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jan/0020.html http://lists.w3.org/Archives/Public/www-rdf-calendar/2001May/thread.html#14 http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Dec/0027.html

Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#categories

RFC 2445: 


4.8.1.2 Categories

   Property Name: CATEGORIES

   Purpose: This property defines the categories for a calendar
   component.

   Value Type: TEXT

   Property Parameters: Non-standard and language property parameters
   can be specified on this property.

   Conformance: The property can be specified within "VEVENT", "VTODO"
   or "VJOURNAL" calendar components.

   Description: This property is used to specify categories or subtypes
   of the calendar component. The categories are useful in searching for
   a calendar component of a particular type and category. Within the
   "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one
   category can be specified as a list of categories separated by the
   COMMA character (US-ASCII decimal 44).


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#class

RFC 2445: 




4.8.1.3 Classification

   Property Name: CLASS

   Purpose: This property defines the access classification for a
   calendar component.

   Value Type: TEXT

[...]
     classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
                / x-name
     ;Default is PUBLIC


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#cn

RFC 2445: 



4.2.2 Common Name

   Parameter Name: CN

   Purpose: To specify the common name to be associated with the
   calendar user specified by the property.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#comment

RFC 2445: 



4.8.1.4 Comment

   Property Name: COMMENT

   Purpose: This property specifies non-processing information intended
   to provide a comment to the calendar user.

   Value Type: TEXT


Example: http://www.w3.org/2002/12/cal/test/gkexample.rdf http://www.w3.org/2002/12/cal/test/gkexample.ics

added to ical2rdf.pl: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0009.html

http://www.w3.org/2002/12/cal/ical#component

RFC 2445: 


3.2 Parameters

[...]

   The "component" parameter conveys the type of iCalendar calendar
   component within the body part. If the iCalendar object contains more
   than one calendar component type, then multiple component parameters
   MUST be specified.


[...]

4.6 Calendar Components

   The body of the iCalendar object consists of a sequence of calendar
   properties and one or more calendar components. The calendar
   properties are attributes that apply to the calendar as a whole. The
   calendar components are collections of properties that express a
   particular calendar semantic. For example, the calendar component can
   specify an event, a to-do, a journal entry, time zone information, or
   free/busy time information, or an alarm.




RESOLVED(1.1q4): to use { ical:component a rdf:Property;
ss:rangeIntersects ical:Vevent } to relate calendars to events, e.g. in
the case of multiple calendars in one file. { :cal1 ical:component :ev1.
:cal2 ical:component :ev2 }.


http://ilrt.org/discovery/chatlogs/rdfig/2003-02-12.html#T17-33-35

added to ical2rdf: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0009.html

http://www.w3.org/2002/12/cal/ical#cutype

RFC 2445: 


4.2.3 Calendar User Type

   Parameter Name: CUTYPE

   Purpose: To specify the type of calendar user specified by the
   property.

   Format Definition: The property parameter is defined by the following
   notation:

     cutypeparam        = "CUTYPE" "="
                         ("INDIVIDUAL"          ; An individual
                        / "GROUP"               ; A group of individuals
                        / "RESOURCE"            ; A physical resource
                        / "ROOM"                ; A room resource
                        / "UNKNOWN"             ; Otherwise not known
                        / x-name                ; Experimental type
                        / iana-token)           ; Other IANA registered
                                                ; type
     ; Default is INDIVIDUAL

   Description: This parameter can be specified on properties with a
   CAL-ADDRESS value type. The parameter identifies the type of calendar
   user specified by the property. If not specified on a property that
   allows this parameter, the default is INDIVIDUAL.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#date

RFC 2445: 


4.3.4 Date

   Value Name: DATE

   Purpose: This value type is used to identify values that contain a
   calendar date.

   Formal Definition: The value type is defined by the following
   notation:

     date               = date-value

     date-value         = date-fullyear date-month date-mday
     date-fullyear      = 4DIGIT
     date-month         = 2DIGIT        ;01-12
     date-mday          = 2DIGIT        ;01-28, 01-29, 01-30, 01-31
                                        ;based on month/year

   Description: If the property permits, multiple "date" values are
   specified as a COMMA character (US-ASCII decimal 44) separated list
   of values. The format for the value type is expressed as the [ISO
   8601] complete representation, basic format for a calendar date. The
   textual format specifies a four-digit year, two-digit month, and
   two-digit day of the month. There are no separator characters between
   the year, month and day component text.


date syntax in .ics versus RDF/XML "The group appeared to agree that writing dates with hyphens - as per XML Schema datatypes" -- differs from the iCalendar definition above. http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jul/0005.html

Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#dateTime

RFC 2445: 



4.3.5   Date-Time

   Value Name: DATE-TIME

   Purpose: This value type is used to identify values that specify a
   precise calendar date and time of day.

   Formal Definition: The value type is defined by the following
   notation:

     date-time  = date "T" time ;As specified in the date and time
                                ;value definitions

[...]

   The "DATE-TIME" data type is used to identify values that contain a
   precise calendar date and time of day. The format is based on the
   [ISO 8601] complete representation, basic format for a calendar date
   and time of day. The text format is a concatenation of the "date",
   followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal
   84) time designator, followed by the "time" format.

   The "DATE-TIME" data type expresses time values in three forms:

   The form of date and time with UTC offset MUST NOT be used. For
   example, the following is not valid for a date-time value:
     DTSTART:19980119T230000-0800       ;Invalid time format

   FORM #1: DATE WITH LOCAL TIME

   The date with local time form is simply a date-time value that does
   not contain the UTC designator nor does it reference a time zone. For
   example, the following represents Janurary 18, 1998, at 11 PM:

     DTSTART:19980118T230000

   Date-time values of this type are said to be "floating" and are not
   bound to any time zone in particular. They are used to represent the
   same hour, minute, and second value regardless of which time zone is
   currently being observed. For example, an event can be defined that
   indicates that an individual will be busy from 11:00 AM to 1:00 PM
   every day, no matter which time zone the person is in. In these
   cases, a local time can be specified. The recipient of an iCalendar
   object with a property value consisting of a local time, without any
   relative time zone information, SHOULD interpret the value as being
   fixed to whatever time zone the ATTENDEE is in at any given moment.
   This means that two ATTENDEEs, in different time zones, receiving the
   same event definition as a floating time, may be participating in the
   event at different actual times. Floating time SHOULD only be used
   where that is the reasonable behavior.

   In most cases, a fixed time is desired. To properly communicate a
   fixed time in a property value, either UTC time or local time with
   time zone reference MUST be specified.

   The use of local time in a DATE-TIME value without the TZID property
   parameter is to be interpreted as floating time, regardless of the
   existence of "VTIMEZONE" calendar components in the iCalendar object.

   FORM #2: DATE WITH UTC TIME

   The date with UTC time, or absolute time, is identified by a LATIN
   CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
   designator, appended to the time value. For example, the following
   represents January 19, 1998, at 0700 UTC:

     DTSTART:19980119T070000Z

   The TZID property parameter MUST NOT be applied to DATE-TIME
   properties whose time values are specified in UTC.

   FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE

   The date and local time with reference to time zone information is
   identified by the use the TZID property parameter to reference the
   appropriate time zone definition. TZID is discussed in detail in the
   section on Time Zone. For example, the following represents 2 AM in
   New York on Janurary 19, 1998:

          DTSTART;TZID=US-Eastern:19980119T020000


Summary: you must either have Z for UTC time or a reference to a timezone identifer and a Vtimezone object defined *in the same file*, unless you are referring to a floating time (i.e. the same time in different timeszones). Timezone offset is not acceptable. Contrast with XML schema datatypes and also [http://www.w3.org/TR/NOTE-datetime W3C date time format.

issues with representing dateTime and timezones in RDF: Interpretation properties http://ilrt.org/discovery/chatlogs/rdfig/2003-05-14.html#T16-15-19 http://esw.w3.org/topic/InterpretationProperties http://rdfig.xmlhack.com/2003/08/20/2003-08-20.html#1061387681.995163

This issue is not yet resolved (2003-09-03): http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Sep/0002.html

date syntax in .ics versus RDF/XML "The group appeared to agree that writing dates with hyphens - as per XML Schema datatypes" -- differs from the iCalendar definition. http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jul/0005.html

some issues with Apple Ical and Mozilla calendar and Vtimezone: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0011.html

compliance with iCalendar http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0037.html

Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#daylight

RFC 2445: 



   Each "VTIMEZONE" calendar component consists of a collection of one
   or more sub-components that describe the rule for a particular
   observance (either a Standard Time or a Daylight Saving Time
   observance). The "STANDARD" sub-component consists of a collection of
   properties that describe Standard Time. The "DAYLIGHT" sub-component
   consists of a collection of properties that describe Daylight Saving
   Time. In general this collection of properties consists of:

        - the first onset date-time for the observance

        - the last onset date-time for the observance, if a last onset
          is known.

        - the offset to be applied for the observance

        - a rule that describes the day and time when the observance
          takes effect

        - an optional name for the observance

(from 4.6.5 Time Zone Component)


Sources for Time Zone and Daylight Saving Time Data http://www.twinsun.com/tz/tz-link.htm

Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#description

RFC 2445: 



4.8.1.5 Description

   Property Name: DESCRIPTION

   Purpose: This property provides a more complete description of the
   calendar component, than that provided by the "SUMMARY" property.

   Value Type: TEXT


Specifying language in description: http://lists.w3.org/Archives/Public/www-rdf-calendar/2001Jun/0009.html (?)

Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#dtend

RFC 2445: 




4.8.2.2 Date/Time End

   Property Name: DTEND

   Purpose: This property specifies the date and time that a calendar
   component ends.

   Value Type: The default value type is DATE-TIME. The value type can
   be set to a DATE value type.


Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#dtstamp

RFC 2445: 




4.8.7.2 Date/Time Stamp

   Property Name: DTSTAMP

   Purpose: The property indicates the date/time that the instance of
   the iCalendar object was created.

   Value Type: DATE-TIME


see http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0019.html

which reverses http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046275343.439413

Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#dtstart

RFC 2445: 



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.


Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#duration

RFC 2445: 


4.3.6   Duration

   Value Name: DURATION

   Purpose: This value type is used to identify properties that contain
   a duration of time.

   Formal Definition: The value type is defined by the following
   notation:

     dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

     dur-date   = dur-day [dur-time]
     dur-time   = "T" (dur-hour / dur-minute / dur-second)
     dur-week   = 1*DIGIT "W"
     dur-hour   = 1*DIGIT "H" [dur-minute]
     dur-minute = 1*DIGIT "M" [dur-second]
     dur-second = 1*DIGIT "S"
     dur-day    = 1*DIGIT "D"

[...]


4.8.2.5 Duration

   Property Name: DURATION

   Purpose: The property specifies a positive duration of time.

   Value Type: DURATION


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

@@check relationship wth XML schema: http://www.w3.org/TR/xmlschema-2/#duration Note: not used in an RDF datatype way: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jan/0022.html

http://www.w3.org/2002/12/cal/ical#freq

RFC 2445: 



   The FREQ rule part identifies the type of recurrence rule. This rule
   part MUST be specified in the recurrence rule. Valid values include
   SECONDLY, to specify repeating events based on an interval of a
   second or more; MINUTELY, to specify repeating events based on an
   interval of a minute or more; HOURLY, to specify repeating events
   based on an interval of an hour or more; DAILY, to specify repeating
   events based on an interval of a day or more; WEEKLY, to specify
   repeating events based on an interval of a week or more; MONTHLY, to
   specify repeating events based on an interval of a month or more; and
   YEARLY, to specify repeating events based on an interval of a year or
   more.

(from 4.3.10 Recurrence Rule)


http://ilrt.org/discovery/chatlogs/rdfig/2003-02-12.html#T18-17-33

<gk> PROPOSED(2q1): to represent RRULE as ical2rdf.pl,v 1.6 2003/01/22 21:17:12 does, using rrule, freq, byday, and also with interval always specified. If ics interval is omitted, translation must add interval="1"

<DanCon> narrow the proposal to just the RRULE in http://www.ninebynine.org/RDFNotes/Calendaring/iCalendarExample.txt , I suggest

This was not resolved but the discussion tended towards agreeing that this was needed. (from http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0008.html)

ical2rdf.pl updated: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0009.html

Examples: http://www.w3.org/2002/12/cal/test/mtg.rdf http://www.w3.org/2002/12/cal/test/mtg.ics

http://www.w3.org/2002/12/cal/ical#interval

RFC 2445: 



   The INTERVAL rule part contains a positive integer representing how
   often the recurrence rule repeats. The default value is "1", meaning
   every second for a SECONDLY rule, or every minute for a MINUTELY
   rule, every hour for an HOURLY rule, every day for a DAILY rule,
   every week for a WEEKLY rule, every month for a MONTHLY rule and
   every year for a YEARLY rule.

(from 4.3.10 Recurrence Rule)


http://ilrt.org/discovery/chatlogs/rdfig/2003-02-12.html#T18-17-33

<gk> PROPOSED(2q1): to represent RRULE as ical2rdf.pl,v 1.6 2003/01/22 21:17:12 does, using rrule, freq, byday, and also with interval always specified. If ics interval is omitted, translation must add interval="1"

<DanCon> narrow the proposal to just the RRULE in http://www.ninebynine.org/RDFNotes/Calendaring/iCalendarExample.txt , I suggest

This was not resolved but the discussion tended towards agreeing that this was needed. (from http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0008.html)

ical2rdf.pl updated: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0009.html

http://www.w3.org/2002/12/cal/ical#language

RFC 2445: 



4.2.10 Language

   Parameter Name: LANGUAGE

   Purpose: To specify the language for text values in a property or
   property parameter.

   Format Definition: The property parameter is defined by the following
   notation:

     languageparam =    "LANGUAGE" "=" language

     language = <Text identifying a language, as defined in [RFC 1766]>

   Description: This parameter can be specified on properties with a
   text value type. The parameter identifies the language of the text in
   the property or property parameter value. The value of the "language"
   property parameter is that defined in [RFC 1766].

   For transport in a MIME entity, the Content-Language header field can
   be used to set the default language for the entire body part.
   Otherwise, no default language is assumed.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

@@hm, fix with respect to rdf and lang?

http://www.w3.org/2002/12/cal/ical#location

RFC 2445: 



4.8.1.7 Location

   Property Name: LOCATION

   Purpose: The property defines the intended venue for the activity
   defined by a calendar component.

   Value Type: TEXT

[...]

   Description: Specific venues such as conference or meeting rooms may
   be explicitly specified using this property. An alternate
   representation may be specified that is a URI that points to
   directory information with more structured specification of the
   location. For example, the alternate representation may specify
   either an LDAP URI pointing to an LDAP server entry or a CID URI
   pointing to a MIME body part containing a vCard [RFC 2426] for the
   location.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

@@fixme: geo and calendar relationships

http://www.w3.org/2002/12/cal/ical#organizer

RFC 2445: 




4.8.4.3 Organizer

   Property Name: ORGANIZER

   Purpose: The property defines the organizer for a calendar component.

   Value Type: CAL-ADDRESS


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#partstat

RFC 2445: 




4.2.12 Participation Status

   Parameter Name: PARTSTAT

   Purpose: To specify the participation status for the calendar user
   specified by the property.


(see the RFC for the lengthy list of possible values).

Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#prodid

RFC 2445: 



4.7.3 Product Identifier

   Property Name: PRODID

   Purpose: This property specifies the identifier for the product that
   created the iCalendar object.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property MUST be specified once in an iCalendar
   object.

   Description: The vendor of the implementation SHOULD assure that this
   is a globally unique identifier; using some technique such as an FPI
   value, as defined in [ISO 9070].

   This property SHOULD not be used to alter the interpretation of an
   iCalendar object beyond the semantics specified in this memo. For
   example, it is not to be used to further the understanding of non-
   standard properties.


RESOLVED to institute an ical product registry ala 'http://www.w3.org/2002/12/cal/prod/' + firstFew(prodID) + hash(prodId) and to put RDF schemas there based on data we find from deployed products I:action libby: implement it, add/update some tests

http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046279854.884486

action done: explianation here http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056556072.203619

ongoing : ACTION libby add a couple schemas under cal/prod http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056556072.203619

xproperties and prodid: Issue: roundtripping is not possible with xproperties http://ilrt.org/discovery/chatlogs/rdfig/2003-08-20.html#T15-43-10

possible solution: remove from tests. are there any we think are useful to support? 


16:27:12 <mortenf> seems there are 6 diff:
16:27:32 <mortenf> X-EVOLUTION-ALARM-UID X-LIC-LOCATION
X-WR-CALNAME;VALUE=TEXT X-WR-ITIPSTATUSML;VALUE=TEXT
X-WR-RELCALID;VALUE=TEXT X-WR-TIMEZONE;VALUE=TEXT
16:27:40 <mortenf> in all .ics files


http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Sep/0002.html

Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#related

RFC 2445: 



4.2.14 Alarm Trigger Relationship

   Parameter Name: RELATED

   Purpose: To specify the relationship of the alarm trigger with
   respect to the start or end of the calendar component.

   Format Definition: The property parameter is defined by the following
   notation:

     trigrelparam       = "RELATED" "="
                         ("START"       ; Trigger off of start
                        / "END")        ; Trigger off of end

   Description: The parameter can be specified on properties that
   specify an alarm trigger with a DURATION value type. The parameter
   specifies whether the alarm will trigger relative to the start or end
   of the calendar component. The parameter value START will set the
   alarm to trigger off the start of the calendar component; the
   parameter value END will set the alarm to trigger off the end of the
   calendar component. If the parameter is not specified on an allowable
   property, then the default is START.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#role

RFC 2445: 



4.2.16 Participation Role

   Parameter Name: ROLE

   Purpose: To specify the participation role for the calendar user
   specified by the property.

   Format Definition: The property parameter is defined by the following
   notation:

     roleparam  = "ROLE" "="
                 ("CHAIR"               ; Indicates chair of the
                                        ; calendar entity
                / "REQ-PARTICIPANT"     ; Indicates a participant whose
                                        ; participation is required
                / "OPT-PARTICIPANT"     ; Indicates a participant whose
                                        ; participation is optional
                / "NON-PARTICIPANT"     ; Indicates a participant who is
                                        ; copied for information
                                        ; purposes only
                / x-name                ; Experimental role
                / iana-token)           ; Other IANA role
     ; Default is REQ-PARTICIPANT

   Description: This parameter can be specified on properties with a
   CAL-ADDRESS value type. The parameter specifies the participation
   role for the calendar user specified by the property in the group
   schedule calendar component. If not specified on a property that
   allows this parameter, the default value is REQ-PARTICIPANT.


Example: http://www.w3.org/2002/12/cal/test/cal01.rdf http://www.w3.org/2002/12/cal/test/cal01.ics

http://www.w3.org/2002/12/cal/ical#rrule

RFC 2445: 



4.8.5.4 Recurrence Rule

   Property Name: RRULE

   Purpose: This property defines a rule or repeating pattern for
   recurring events, to-dos, or time zone definitions.


http://www.w3.org/2002/12/cal/ical#rsvp

RFC 2445: 




4.2.17  RSVP Expectation

   Parameter Name: RSVP

   Purpose: To specify whether there is an expectation of a favor of a
   reply from the calendar user specified by the property value.

   Format Definition: The property parameter is defined by the following
   notation:

     rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
     ; Default is FALSE


http://www.w3.org/2002/12/cal/ical#sequence

RFC 2445: 



4.8.7.4 Sequence Number

   Property Name: SEQUENCE

   Purpose: This property defines the revision sequence number of the
   calendar component within a sequence of revisions.

   Value Type: integer

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified in "VEVENT", "VTODO" or
   "VJOURNAL" calendar component.

   Description: When a calendar component is created, its sequence
   number is zero (US-ASCII decimal 48). It is monotonically incremented
   by the "Organizer's" CUA each time the "Organizer" makes a
   significant revision to the calendar component. When the "Organizer"
   makes changes to one of the following properties, the sequence number
   MUST be incremented:

     .  "DTSTART"

     .  "DTEND"

     .  "DUE"

     .  "RDATE"

     .  "RRULE"

     .  "EXDATE"

     .  "EXRULE"

     .  "STATUS"

   In addition, changes made by the "Organizer" to other properties can
   also force the sequence number to be incremented. The "Organizer" CUA
   MUST increment the sequence number when ever it makes changes to
   properties in the calendar component that the "Organizer" deems will
   jeopardize the validity of the participation status of the
   "Attendees". For example, changing the location of a meeting from one
   locale to another distant locale could effectively impact the
   participation status of the "Attendees".

   The "Organizer" includes this property in an iCalendar object that it
   sends to an "Attendee" to specify the current version of the calendar
   component.

   The "Attendee" includes this property in an iCalendar object that it
   sends to the "Organizer" to specify the version of the calendar
   component that the "Attendee" is referring to.


http://www.w3.org/2002/12/cal/ical#standard

RFC 2445: 




Description: A time zone is unambiguously defined by the set of time
   measurement rules determined by the governing body for a given
   geographic area. These rules describe at a minimum the base  offset
   from UTC for the time zone, often referred to as the Standard Time
   offset. Many locations adjust their Standard Time forward or backward
   by one hour, in order to accommodate seasonal changes in number of
   daylight hours, often referred to as Daylight  Saving Time. Some
   locations adjust their time by a fraction of an hour. Standard Time
   is also known as Winter Time. Daylight Saving Time is also known as
   Advanced Time, Summer Time, or Legal Time in certain countries. 

[...]

   Each "VTIMEZONE" calendar component consists of a collection of one
   or more sub-components that describe the rule for a particular
   observance (either a Standard Time or a Daylight Saving Time
   observance). The "STANDARD" sub-component consists of a collection of
   properties that describe Standard Time. The "DAYLIGHT" sub-component
   consists of a collection of properties that describe Daylight Saving
   Time.

(in 4.6.5 Time Zone Component)


http://www.w3.org/2002/12/cal/ical#summary

RFC 2445: 




4.8.1.12 Summary

   Property Name: SUMMARY

   Purpose: This property defines a short summary or subject for the
   calendar component.


http://www.w3.org/2002/12/cal/ical#transp

RFC 2445: 



4.8.2.7 Time Transparency

   Property Name: TRANSP

   Purpose: This property defines whether an event is transparent or not
   to busy time searches.

[...]

   Description: Time Transparency is the characteristic of an event that
   determines whether it appears to consume time on a calendar. Events
   that consume actual time for the individual or resource associated
   with the calendar SHOULD be recorded as OPAQUE, allowing them to be
   detected by free-busy time searches. Other events, which do not take
   up the individual's (or resource's) time SHOULD be recorded as
   TRANSPARENT, making them invisible to free-busy time searches.


http://www.w3.org/2002/12/cal/ical#trigger

RFC 2445: 



4.8.6.3 Trigger

   Property Name: TRIGGER

   Purpose: This property specifies when an alarm will trigger.

   Value Type: The default value type is DURATION. The value type can be
   set to a DATE-TIME value type, in which case the value MUST specify a
   UTC formatted DATE-TIME value.

[...]

   Conformance: This property MUST be specified in the "VALARM" calendar
   component.


   Description: Within the "VALARM" calendar component, this property
   defines when the alarm will trigger.


notes on ical2rdf.pl: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jan/0022.html

http://www.w3.org/2002/12/cal/ical#tzid

RFC 2445: 



4.2.19 Time Zone Identifier

   Parameter Name: TZID

   Purpose: To specify the identifier for the time zone definition for a
   time component in the property value.

[...]


   Description: The parameter MUST be specified on the "DTSTART",
   "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
   TIME or TIME value type is specified and when the value is not either
   a UTC or a "floating" time.

[...]
   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
   prefix, indicates that this TZID represents a unique ID in a globally
   defined time zone registry (when such registry is defined).

        Note: This document does not define a naming convention for time
        zone identifiers. Implementers may want to use the naming
        conventions defined in existing time zone specifications such as
        the public-domain Olson database [TZ]. The specification of
        globally unique time zone identifiers is not addressed by this
        document and is left for future study.


http://www.w3.org/2002/12/cal/ical#tzname

RFC 2445: 



   The optional "TZNAME" property is the customary name for the time
   zone. It may be specified multiple times, to allow for specifying
   multiple language variants of the time zone names. This could be used
   for displaying dates.

(from 4.6.5 Time Zone Component)

[...]


4.8.3.2 Time Zone Name

   Property Name: TZNAME

   Purpose: This property specifies the customary designation for a time
   zone description.

   Value Type: TEXT


http://www.w3.org/2002/12/cal/ical#tzoffsetfrom

RFC 2445: 



   The mandatory "TZOFFSETFROM" property gives the UTC offset which is
   in use when the onset of this time zone observance begins.
   "TZOFFSETFROM" is combined with "DTSTART" to define the effective
   onset for the time zone sub-component definition. For example, the
   following represents the time at which the observance of Standard
   Time took effect in Fall 1967 for New York City:

(from 4.6.5 Time Zone Component)


http://www.w3.org/2002/12/cal/ical#tzoffsetto

RFC 2445: 




   The mandatory "TZOFFSETTO " property gives the UTC offset for the
   time zone sub-component (Standard Time or Daylight Saving Time) when
   this observance is in use.

from 4.6.5 Time Zone Component)


http://www.w3.org/2002/12/cal/ical#uid

RFC 2445: 



4.8.4.7 Unique Identifier

   Property Name: UID

   Purpose: This property defines the persistent, globally unique
   identifier for the calendar component.

[...]

   Conformance: The property MUST be specified in the "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

   Description: The UID itself MUST be a globally unique identifier. The
   generator of the identifier MUST guarantee that the identifier is
   unique. There are several algorithms that can be used to accomplish
   this. The identifier is RECOMMENDED to be the identical syntax to the
   [RFC 822] addr-spec. A good method to assure uniqueness is to put the
   domain name or a domain literal IP address of the host on which the
   identifier was created on the right hand side of the "@", and on the
   left hand side, put a combination of the current calendar date and
   time of day (i.e., formatted in as a DATE-TIME value) along with some
   other currently unique (perhaps sequential) identifier available on
   the system (for example, a process id number). Using a date/time
   value on the left hand side and a domain name or domain literal on 
   the right hand side makes it possible to guarantee uniqueness since
   no two hosts should be using the same domain name or IP address at
   the same time. Though other algorithms will work, it is RECOMMENDED
   that the right hand side contain some domain identifier (either of
   the host itself or otherwise) such that the generator of the message
   identifier can guarantee the uniqueness of the left hand side within
   the scope of that domain.

   This is the method for correlating scheduling messages with the
   referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.

   The full range of calendar components specified by a recurrence set
   is referenced by referring to just the "UID" property value
   corresponding to the calendar component. The "RECURRENCE-ID" property
   allows the reference to an individual instance within the recurrence
   set.

   This property is an important method for group scheduling
   applications to match requests with later replies, modifications or
   deletion requests. Calendaring and scheduling applications MUST
   generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar
   components to assure interoperability with other group scheduling
   applications. This identifier is created by the calendar system that
   generates an iCalendar object.

   Implementations MUST be able to receive and persist values of at
   least 255 characters for this property.


Whether uid could be used to say in OWL that one event is the samething as another event is not yet resolved: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Sep/0002.html

http://www.w3.org/2002/12/cal/ical#valarm

RFC 2445: 



4.6.6 Alarm Component

   Component Name: VALARM

   Purpose: Provide a grouping of component properties that define an
   alarm.

http://www.w3.org/2002/12/cal/ical#version

RFC 2445: 



4.7.4 Version

   Property Name: VERSION

   Purpose: This property specifies the identifier corresponding to the
   highest version number or the minimum and maximum range of the
   iCalendar specification that is required in order to interpret the
   iCalendar object.

   Value Type: TEXT

[...]


   Conformance: This property MUST be specified by an iCalendar object,
   but MUST only be specified once.

   Description: A value of "2.0" corresponds to this memo.


xproperties http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0037.html

Some resolutions:

  • RESOLVED to institute an ical product registry ala 'http://www.w3.org/2002/12/cal/prod/' + firstFew(prodID) + hash(prodId) and to put RDF schemas there based on data we find from deployed products

http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046279854.884486

would bugzilla help for rdf-calendar stuff? RESOLVED: try the wiki instead for a while? http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046275378.056795

datestamps (why aren't they considered as datetimes?) RESOLVED: all is well. nothing needs changing. datestamp in this test case is ok. http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046275343.439413 [!! but see dtstamp handled like dtstart, dtend - a later decision: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0019.html]

RESOLVED that all attendees of this meeting who build robots should respect robots.txt and use ETags or at least explain why not http://new-rdfig.xmlhack.com/2003/04/23/2003-04-23.html#1051113769.199079

RESOLVED: "For now, do not check in GPL code. Establishing a GPL-friendly repository or part of one remains on the agenda" http://new-rdfig.xmlhack.com/2003/03/12/2003-03-12.html#1047488206.102209

  • RESOLVED (1.1q4): to use { ical:component a rdf:Property; ss:rangeIntersects ical:Vevent } to relate calendars to events, e.g. in the case of multiple calendars in one file. { :cal1 ical:component :ev1. :cal2 ical:component :ev2 }.

http://rdfig.xmlhack.com/2003/02/12/2003-02-12.html#1045063138.593306

RESOLVED: that folks should be encouraged to link their RDF calendars from their foaf home thingies via rdfs:seeAlso (@@e.g. dancs libbys) http://rdfig.xmlhack.com/2003/04/23/2003-04-23.html#1051113769.199079

RESOLVED: to use the wiki for meeting index. ACTION DanC http://rdfig.xmlhack.com/2003/03/26/2003-03-26.html#1048697881.388674

some actions

ACTION mortenf: take a stab at regression tests for .ics->.rdf and/or .rdf->.ics http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056557026.871899

action libby: have a go at figuring it out documenting it (RDF ical schema). http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046281084.080137

ACTION DanC: follow up in email about how folks should relate themselves to events they plan to attend. ical:attendee? cyc:socialParticipants? http://rdfig.xmlhack.com/2003/04/23/2003-04-23.html#1051113769.199079

Action libby: talk to daniel resare- ask if w3c license would suit his purpose http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046275410.047721

action libby: implement it add/update some tests (xproperties and namespace) http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#1046279854.884486

ACTION DanC: call for discussion of time/place/people/documents/money (incl images) to semantic-web@w3.org http://rdfig.xmlhack.com/2003/04/16/2003-04-16.html#1050505090.657704

ACTION libby look at skical optimeset and report back http://rdfig.xmlhack.com/2003/05/14/2003-05-14.html#1052921472.659227

ACTION libby summarise this discussion into smethign we can discuss again and maybe agree on in an email (how do we know when we're done) http://rdfig.xmlhack.com/2003/03/12/2003-03-12.html#1047488233.738425

ACTIOn libby write a converter from chefmoz opening housr format to rdf calendar format (or icalendar format maybe?) ACTION danbri_fr to have a draft of the concentric circles within100m http://rdfig.xmlhack.com/2003/04/09/2003-04-09.html#1049903200.904995

ACTION libby send a mail to rdf-interest on this topic (InterpretationProperties) http://rdfig.xmlhack.com/2003/05/14/2003-05-14.html#1052921345.552964

ACTION libby look at skical optimeset and report back http://rdfig.xmlhack.com/2003/05/14/2003-05-14.html#1052921472.659227

Some background to RFC 2445.

The information in this page was found by searching www-rdf-calendar archives, also searching for 'resolved' on the collaborative weblog (not all of these are relevant).

Suggestions for inclusion:

  • link or copy the relevant parts of the icalendar spec
  • link to decisions we have made, and actions
  • find out which properties from icalendar spec we haven't put in the rdf version
  • link to examples of use of properties and classes
  • link to examples of mixing namespaces with RDF icalendar
Retrieved from "https://www.w3.org/wiki/index.php?title=RdfCalendarDocumentation&oldid=60259"