Nearby: SWAD-Europe workshop on Semantic Web Calendaring | SWAD-Europe
Date: 2002-10-03
(current) author: Libby Miller <libby.miller@bristol.ac.uk>
Description: This document contains a summary of my current understanding of the issues relevant to the SWAD-Europe semantic web Calendaring workshop, to be held on 9th October 2002. I'm hoping that this document can serve as a useful pre-meeting summary document, but also be added to as a result of the workshop.
iCalendar is an RFC version of Vcal, an industry specification. It was written by the CalSch working group, which is still going. iCalendar is a model and syntax for describing events, todos and the like (RFC 2445, 1998). It's used in many devices and applications (see here and here). The working group has also created iTip (RFC 2446, Nov 1998) - semantics for group scheduling methods; iMip (RFC 2447, Nov 1998) for binding icalendar to email; Calendar attributes for vCard and LDAP (RFC 2739, Jan 2000) - ie ways of finding a uri for users calendar (Jan 2000); and Guide to internet calendaring (RFC 3283, June 2002). This last one is a good introduction to how these fit together.
The group has also produced two internet drafts: Calendar access protocol (CAP) Internet Draft, June 30 2002 and iCalendar DTD (xCalendar) Internet Draft, July 25th 2002.
iCalendar is specified in the ABNF notation of RFC 2234, and is based on the Mime Directory content type (an attribute-value format) RFC 2425 content type. Its syntax is case insensitive.
Michael Arick's iCalendar in UML might be helpful here. iCalendar contains:
These are mostly properties of the value of the property rather than being a qualifier on the property, e.g.
[[
Parameter Name: CN
Purpose: To specify the common name to be associated with the
calendar user specified by the property.
[...]
This parameter can be specified on properties with a
CAL-ADDRESS value type.
]]
Other examples are ALTREP, CUTYPE, DELEGATED-FROM, DELEGATED-TO, DIR, ENCODING, FMTTYPE, LANGUAGE (I think), MEMBER, PARTSTAT, SENT-BY, TZID. RELTYPE seems more like a property qualifier. ROLE seems rather uncertain; also RSVP. I'm not sure about ?FBTYPE, LANGUAGE?, ?RANGE?, ?RELATED?,
[[ Purpose: To explicitly specify the data type format for a property value. ]]
e.g. duration, boolean, datetime, date, time; but also cal-address, uri, utc-offset
So these are like objects in an RDF model - types rather than just datatypes. In iCalendar they are defined as 'restrictions on properties', but apply to the values of the properties. (but this fits quite nicely with the range of properties in RDF).
[[
A property is the definition of an individual attribute describing a
calendar or a calendar component. A property takes the form defined
by the "contentline" notation defined in section 4.1.1.
The following is an example of a property:
DTSTART:19960415T133000Z
]]
Properties are somewhat like a property and its value together. There is no ordering of properties.
These are the main objects we want to talk about - events, todos, journal entries; also alarms, and timezones. These can be represented as RDF types.
There is a conflict between the subset of iso 8601 that
iCalendar specified and that described in the W3C's note on dates and
time formats. This is potentially an issue, for example if we
subsetted iCalendar to use with RSS 1.0, which uses W3C's dates and
times.
In iCalendar you can use
There is a value type called UTC Offset, but it seems that this datatype is used only with timezone objects, to specify daylight savings times and so on.
W3C's profile says that you can use
In addition the subsets of iso 8601 they use are syntactically different, with W3C's profile using dashes and colons to separate the parts of date and time respecticely, while iCalendar has no separators.
The difficulty here is that recurrence requires specifying rules, so you really need a rules language (could OWL do this?). iCalendar does specify rules for recurrrance, but there are a few problems with them (see below). Recurrence is really useful though - e.g. TV schedules, opening hours.
[[ 4.3.10 Recurrence Rule Value Name: RECUR Purpose: This value type is used to identify properties that contain a recurrence rule specification. ]]
A rule can be counted number of recurrances or a date until it stops (examples are by minutes, by day) and then a list of values, e.g. every day in January for 3 years
RRULE:FREQ=YEARLY;UNTIL=20050131T090000Z;
BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
This is a bit odd - there's BYMONTH and BYHOUR but not BYYEAR. I guess freq is just a shorthand for every x, so dont have to do a list. You can also specify an interval on a freq, e.g. FREQ=YEARLY;INTERVAL=2 = every other year.
[[
The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
44) separated list of values which corresponds to the nth occurrence
within the set of events specified by the rule. Valid values are 1 to
366 or -366 to -1. It MUST only be used in conjunction with another
BYxxx rule part. For example "the last work day of the month" could
be represented as:
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
]]
There are some difficulties with this (calsch wg mails) - here, here and here
[[ The problems with recurrence rules were summarized best by Damon Chaplin in http://www.imc.org/ietf-calendar/mail-archive/msg03656.html, reposted ( and edited) here: o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH and/or BYWEEKNO set, does the BYDAY modifier apply to the year day, the month day, or the week day? o Should BYWEEKNO and BYMONTH be mutually exclusive? They make no sense together. (This would also avoid part of the previous problem.) o Is it possible to use BYMONTHDAY in a WEEKLY frequency, or BYYEARDAY in a MONTHLY or WEEKLY frequency? o BYSETPOS is limited to 366 values (or maybe 999 values if the comment doesn't count as part of the spec!), yet a complete expansion for every second in every day of the year would result in much larger sets. o The algorithm to calculate the first week in the year may be awkward, since some people/countries may be used to other numbering schemes. ]]
I'm not sure if this was ever resolved (the archives are hard to search)
Greg Fitzpatrick has proprosed a more elegant model for recurrance.
See at the end of RFC 2445. Here's one example from there for info:
[[
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.
BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
DESCRIPTION:Networld+Interop Conference
and Exhibit\nAtlanta World Congress Center\n
Atlanta, Georgia END:VEVENT END:VCALENDAR
]]
iCalendar is complex and lengthy, and the semantics are somewhat unclear to me (but see Michael Arick's UML version)
However, it is very widely used - many applications are partially compliant. Here are some usecases, a white paper, and a useful summary.
The xCalendar Internet Draft provides an annotated DTD for iCalendar.
[[ This memo defines an alternative, XML representation for the standard iCalendar format defined in [RFC 2445]. This alternative representation provides the same semantics as that defined in the standard format. ]]
It does not allow mixing namespaces:
[[ The publication of XML version 1.0 was followed by the publication of a World-wide Web Consortium (W3C) recommendation on "Namespaces in XML". A XML name-space is a collection of names, identified by a URI. In anticipation of the broader use of XML namespaces, this memo includes the definition of the URI to be used to identify the namespace associated with the iCalendar DTD element types in other XML documents. XML applications that conform to this memo and also use namespaces MUST NOT include other non-iCalendar namespaces in an iCalendar XML document. ]]
The mapping to the DTD from iCalendar was done like this:
Example taken from the xCalendar internet draft
[[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt">
<iCalendar>
<vcalendar method="PUBLISH"
version="2.0"
prodid="-//HandGen//NONSGML vGen v1.0//EN">
<vevent>
<uid>19981116T150000@cal10.host.com</uid>
<dtstamp>19981116T145958Z</dtstamp>
<summary>Project XYZ Review</summary>
<location>Conference Room 23A</location>
<dtstart>19981116T163000Z</dtstart>
<dtend>19981116T190000Z</dtend>
<categories>
<item>Appointment</item>
</categories>
</vevent>
</vcalendar>
</iCalendar>
]]
SkiCal is an Internet Draft of a vocabulary for extending iCalendar for public events such as concerts, opening hours. It is partially specified in XML, partially in mime-directory format. Greg FitzPatrick and Jonas Liljegren also did early work on transforming SkiCal to RDF.
'hybrid' vocabulary url, previous versions. This is an annotated version of iCalendar in RDF, written by Libby Miller and Michael Arick, and based where possible on Tim Berners-Lee's quick look at iCalendar. After some thought and discussion we decided to stay as close as possible to the iCalendar model because of its wide use.
The main issues were in interpretation of iCalendar in terms of RDF and interpretting the intentions of the iCalendar authors.
We decided to use rdf:value, like DAML+oil. RDFCore will be recommending an RDF datatyping approach soon.
This was an issue because it requires inventing a rules language, which seems to be at a different level to RDF.
[[
People,
I've just been trying to resolve a couple of issues with the
hybrid-ical ontology, and noticed that there is the property LOCATION
whose range is ical:TEXT. Fair enough. But there are also two other
properties (ALTREP & LANGUAGE) who's range is also LOCATION, i.e. a
property which is the range of a property. Is this legal? I've an odd
feeling that it might be, but then what exactly does it mean?
Also, there is the following comment in the ontology:
In the SWWS ontology, a GEO is used as the range of the property
LOCATION. This brings me to the question - are the following both
valid... and are they equivalent?
<ical:LOCATION>
<ical:GEO>
<ical:GEO-NAME>
<ical:TEXT rdf:value="TCSEQ Center" />
</ical:GEO-NAME>
</ical:GEO>
</ical:LOCATION>
<ical:LOCATION>TCSEQ Center</ical:LOCATION>
Any thoughts?
]]
[[
Regarding Terry's earlier post Question/Anomaly regarding LOCATION, I
believe LOCATION should be text only. Also LOCATION is not the range of
ALTREP and LANGUAGE, but one of the members of the domain.
Now on to the other issues....
Just a few of the inconsistencies I noticed while beginning to update
the rdf markup of rfc2445.
Problems/Suggestions below:
1. remove VFREEBUSY as a subclass of CAL-COMPONENT
this leaves CAL-COMPONENT as the super class for VEVENT, VTODO,
VJOURNAL
VFREEBUSY, VTIMEZONE, and VALARM are each special in their own
ways.
**** Note the following items assume that item 1 was accomplished.
2. add iCalendar:COMMENT (4.8.1.4 in RFC 2445)
3. add VALARM to the domain of DESCRIPTION
4. GEO description states a may be textual, this conflicts with the RFC.
Only lat & long as float separated by a ':'
5. GEO should have domain of VEVENT & VTODO
6. GEO-NAME not necessary, covered by LOCATION and not in spec
7. remove VEVENT from the domain of PERCENT-COMPLETE
8. change the domain of RESOURCES to VEVENT and VTODO from CAL-COMPONENT
9. remove CAL-COMPONENT from the domain of DTSTART, add VEVENT, VTODO,
VFREEBUSY to the domain
10. remove CAL-COMPONENT from the domain of DURATION, add VEVENT, VTODO,
VFREEBUSY
11. add VFREEBUSY to domain of URL
12. FBTYPE should be a choice see 4.2.9 of RFC2445
13. remove REC-VFREEBUSY (rfc2445 pg 59 states that the recurrence
properties are not permitted within a VFREEBUSY calendar component.
14. comment for LONGITUDE should read between -180 and 180, not 0 and
15. comment for LATITUDE should read between -90 and 90, not 0 and 90
16. comment for UTC-OFFSET should be replaced with "Offset from UTC to
local time, between -1200 and 1200"
17. PARTSTAT should be a choice based upon calendar component type, see
4.2.12 in rfc2445
HMMM.. upon further reflection it appears that maybe nos. 12 and 17
above were TEXT to account for the possibility of x-name, some
unspecified experimental type. I can accept that; however, what is the
difference between text and literal. I ask because CN and CUTYPE are
rdfs;Literal. Something is awry here.
]]
Dan Connolly has been writing personal information management tools such as palmagent, and creating schemas that these tools use. Here's a iCalendar schema - I haven't had time to do a detailed comparsion with the 'hybrid' one yet. A Palm datebook schema is also available.
RSS 1.0 is a simple RDF application - essentially a way of presenting an ordered list of links with titles and descriptions. A key feature is that it is extensible using modules - e.g. for Dublin Core, and syndication. Other important features include simplicity and popularity.
The events module was proposed by by Soren Roug of the European Environment agency in 2001.
[[ 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. ]]
There are five properties in this module. All are simple attribute-value type properties, with no intervening node. only one property is required - startdate:
[[ 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. ]]
'implied timezone' seems very weak, since there's no formal mapping between location and tz - and location is 'a short description', but
[[ Use semantic augmentation if you desire to give i.e. a URL to the place. ]]
I'm not sure what this means
ev:enddate
[[ 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. ]]
ev:organizer
[[ 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. ]]
No way of identifying the person is suggested
ev:type
[[ 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. ]]
Which is rather vague.
RSS is constrained to using W3C Date and time formats.
Modelling issues. RSS uses urls to identify the objects of interest. It is easy to confuse a web page about an event with the event itself.
Definitions are vague. As described above, in several cases, the content of tags is not machine processible.
This section will expand a lot. At the moment all there is is Jerome Euzenat's document on Semantic web and calendaring
other urls: http://ilrt.org/discovery/2001/06/content/ http://ilrt.org/discovery/2002/01/cal-rss/ http://dev.w3.org/cvsweb/2001/palmagent/ http://www.ilrt.bris.ac.uk/discovery/2001/04/calendar/ URLs from this document iCalendar http://www.ietf.org/rfc/rfc2445.txt CalSch working group http://www.calsch.org/ Lists of iCalendar evices and applications http://www.calsch.org/icalsite.html http://www.wfu.edu/~rbhm/cal.html iTip (RFC 2446) http://www.ietf.org/rfc/rfc2446.txt iMip (RFC 2447) http://www.ietf.org/rfc/rfc2447.txt Calendar attributes for vCard and LDAP RFC 2739 http://www.ietf.org/rfc/rfc2739.txt Guide to internet calendaring RFC 3283 http://www.ietf.org/rfc/rfc3283.txt CAP http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-08.txt iCalendar DTD (xCalendar) http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt ABNF notation (RFC 2234) http://www.ietf.org/rfc/rfc2234.txt Mime Directory format http://www.ietf.org/rfc/rfc2425.txt Recurrence issues http://www.imc.org/ietf-calendar/mail-archive/msg00222.html http://www.imc.org/ietf-calendar/mail-archive/msg00223.html http://www.imc.org/ietf-calendar/mail-archive/msg00623.html Greg Fitzpatrick's 'Orlando' recurrence model http://www.idealliance.org/papers/xml2001/papers/html/05-04-06.html Michael Arick's iCalendar in UML http://www.cse.ucsc.edu/~marick/iCalendarUML.html iCalendar Usage http://www.wfu.edu/~rbhm/cal.html http://www.imc.org/pdi/vcalwhite.html http://reefknot.sourceforge.net/bootstrap-guide/t1.html SkiCal http://www.ietf.org/internet-drafts/draft-many-ical-ski-05.txt W3C Date and Time formats http://www.w3.org/TR/NOTE-datetime RDF and calendaring A quick look at iCalendar, Tim Berners-Lee http://www.w3.org/2000/01/foo Skical in RDF: http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0109.html 'hybrid' model http://www.w3.org/2001/Europe/200210/rdf-cal.rdf http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf http://ilrt.org/discovery/2001/06/schemas/ical-full/old/ problems with the hybrid model http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Sep/0007.html http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Sep/0012.html DAML+oil http://www.daml.org/ Palmagent http://dev.w3.org/cvsweb/2001/palmagent/ http://dev.w3.org/cvsweb/~checkout~/2001/palmagent/icalVocab.rdf?rev=1.3&content-type=text/xml http://www.w3.org/2000/08/palm56/datebook.rdf RSS 1.0 http://www.purl.org/rss/1.0/ RSS events module http://web.resource.org/rss/1.0/modules/event/
Last Modified $Date: 2002/12/07 16:27:28 $
Maintainers: libby.miller@bristol.ac.uk danbri@w3.org