Building an RDF model:

A quick look at iCalendar

I spent a few hours reading 50 pages of the iCalendar RFC2445 with a view to evaluating proposals to put it into XML. My conclusion early on was that the spec should be written in terms of RDF properties, particularly as it has a clear property/value and parameter/value structure.

Epilogue: see also the RDF Calendar Workspace, started late 2002, which takes a similar approach to this "quick look" with running code, example data, and schemas.

DanC

Summary

General points I noticed included

1. The spec is full of x-extensions and IANA registries. these would all be done using namespaces in XML
2. There is no summary of properties with their domains and ranges, which would make the spec much clearer.
3. The parameter value type of "URI" implicitly causes dereferencing. This is not clear from the spec but is assumed by the examples.
4. There are a few example of wanton reification, e.g. relationship type.
5. Encodings, for cleanliness: the encoding is a relationship between two objects, not the property of an object. Same comment on XML DSig.
6. I am concerned that I have not found very much protocol defining what how agents interact, or what a message containing a calendar entry means. But maybe that is elsewhere in the spec.

Narrative

When looking for a natural representation of data in a given lanbguage in RDF, one looks at first for the natural structureo fthe language. iCalndar has a nested set of structures which naturally lend themselves to an RDF graph interpretation. Apart from the noted exceptions, this translatoin leads to a set of fairly logically defined RDF properties which could form iCalendar's contribution to the semantic web.

A "calendar" consists of a set of components, such as events, and to-do list and journal entries. These seem natural RDF types. (There is a choice of whether to introduce special a specific property as the relationship between the containing calendar and a specfic type of component, or whther to use generic inclusion property and then specifythe subtype of the component.)

The components have properties, even known as properties in iCalendar. Now each property is in fact a complex thing which has a "value" (implcitly named) and various "parameters" with names.

The named parameters are clearly easily represented as RDF properties.

The values are generally atomic things suhc as integers and strings, with two exceptions. One is when the valeu if the URI and this implies that the actual value is in a document with that URI. Another is that the value datatype "rcecur"is a string which itself has a substructure. This recurrence substructure takes the form of (guess what!) a set of attribute value pairs.

Detailed comments

2.3 Internationalization

If this were XML this would be done for you, with Unicode and the various encodings etc.

4.1 Content Lines

x-name and iana-token are extensions which XML would give for free using namespaces.

"Each property defines the specific ABNF for the parameters allowed on the property"

This makes general parsing impossible, direct conversion into XML difficult. The only hope is that in fact that it not true and there is more consistency than this line leads you to believe! This sounds like a remake of the RFC822 problem which HTTP has in spades: One parser per page of the spec.

4.1.3

Here in the example

ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
      MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
      EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE        <...remainder of "BASE64" encoded binary data...>

represents the encoding as though it were a property of the value. It isn't: it is a relationship between the value and thestring expressed here. Nicer to write that.

<attach>
   <fmttype>image/basic</fmttype>
   <base64>MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
     [...]
   </base64>
</attach>

which would mean (in XML or RDF nonstriped strawman syntax) "Something is attached which has content type image/basic and has base64 encoding MMICCblablahblah".

Note that making base64 a first class relationship (subclass of encoding) makes for brevity and extensibility: with a namespace I can introduce a new one.

Value=binary has all these problems and is unnecessary. It is assumed in base64. The earlier example with the URI

ATTACH:http://xyz.com/public/quarterly-report.doc

has an implicit dereferencing operation which it would be best to expose:

<attach>
   <uri>http://xyz.com/public/quarterly-report.doc
</uri>
</attach>

which means, consistently with the previous example, "something is attached which is identified by URI http://...."

4.2 property parameters

Property parameter values MUST NOT contain a double quote. So I guess that if i want to represent something which does... I attach it?

4.2.1

ALTREP and many of the following parameters can be represented obviously as RDF properties. There needs to be an explicit property between the introduced thing and any "value".

<description>
   <altrep>cid:asdfsadf@sdfsdaf.com</altrep>
   <text>Proext XYZ review meeting</text>
<description>

This becomes more obvious when you look at things like ATTENDEE.

4.2.2.

There seems to be an embryonic notion of type here ("properties with the CAL-ADDRESS value type". I assume this can be formalized. it would be so much simpler if this were tabulated.

4.2.3 Calendar User Type.

"mailto:" is usually in lower case. I thought it was in fact mandatory that it be in lower case.

4.2.5 Delegatees

It is very confusing who ends up being the attendee notionally when both delegates-to and -from are specified. Changing this to RDF, or contemplating doing logical operations on this make one queasy about the solidity here.

ATTENDEE;DELEGATED-TO="mailto:a@y.com";DELEGATED-FROM="mailto:b@y.com":c@y.com

What is that equivalent to? I assume a@y.com goes to the meeting.

4.2.7. See comment about 4.1.3

4.2.9 Free/Busy Time type

make relationships first class

FREEBUSY=FREE: would be better as FREE: to reduce unnecessary complication and allow extension.

If that section of the spec (4.2.9) seems to be self-referential and difficult to read, that is also because it is describing an unnatural part of a clumsy syntax. You don't say "I am free or busy as follows: 12-1pm and we are talking about free here"! because RDF makes these things first class objects and allow you to group FREE and BUSY and REALLYBUSY as subclases of FREEBUSYTYPE life is easier.

4.2.10 language

xml:lang of course is what one would get for free with XML.

4.2.15

"RELATED-TO:RELTYPE=SIBLING" is a classic wanton reification. Just say SIBLING:

Unfortunately the specification defined how calendars can be put into a hierarchical relationship but doesn't say what that relationship *means*. Maybe it does later in the spec.

4.2.18 Sent By

This is a relationship between a mailbox and another mailbox. It is that the owner of one mailbox is being represented by the owner of another. Yes, the message which asserted this data was probably sent by the agent, but the term is misleading when it crops up in the data. This will cause confusion. This is an example of the clarification which arises when you try to represent the meaning of each rdf:property (icalendar:parameter) independently.

4.2.20 Value Data Type

Note that the "URI" data type does not just constrain the value string to be a valid URI, but indicated that the value string is the document you get when you dereference the URI. Big difference, particularly when you automate the base 64 decoding of something.

In general, note XML data types are defined by XML schema working group. See draft @@. A comparison would be a useful exercise.

4.8.4.1 ATTENDEE

"If the LANGUAGE property parameter is specified, the identified language applies to the CN parameter"

That is a terrible bit of design - a typical bit of interference between different headers which is so temping for designers in these flat specs which can't use nesting. How many other clauses like this are there?

LANGUAGE is, I must admit, a problem RDF has a bug with in general. It is difficult to specify that a string has a language without making an intermediate node that you don't want. This is, I realize the same as the intermediate packaging problem: how to let a system know that what it asked for is inside, but in the mean time, here is some useful information about it. Here is a number and by the way it is prime. here is a GIF and by ht way it is copyright. Here is a common name and by the way it is in English. It is interesting to see the way iCalendar has the same problem

4.8.4 UID

There is linking between components of calendars which uses "UIDs" which are mid URIs with the prefix removed. This is a bug

• It removes calendar objects from the URI space so that one cannot refer to them with any other system which uses a URI -- unless you simply assume that you can by using mid:
• The spec is full of recommendations for making identifiers unique.
• It has a given length of 255 characters which is y2k bug asking to happen. Never specify fixed buffer sizes.

4.8.7.4 "SEQUENCE"

This is not in fact a property of an event, but is a property of a given expression of the state of an event. the rule is that it must be incremented by the organizer if the event changes significantly. In a peer-peer world, it is not obvious what to do.

Not reviewed

I skipped most of the rest of the spec but a few very similar concerns arose with some other parts I glanced at.

Conclusion

It seems that RDF nodes for the calendar, for each event etc, and for each icalendar:property is a fairly straightforward mapping.

A spinoff would be a vocabulary which would include useful reusable models of time.The timezone work could be factored out if it is definitive.

Where RDF mapping was not obvious this sometimes coincided with unclear aspects of the specification.

There are three levels at which the RDF mapping could be made

1. A very direct mapping of the ical:properties and parameters onto rdf:properties. Always use the same "value" rdf:property for the VALUE of an ical:property. This would leave some things looking illogical in RDF. It would be simple to define as a mapping, but the definitoin of the properties would be strange in some cases.
2. Make a few simple adjustments to make the RDF more natural. Places to lok for these arehese have been indicated with a @@ in the table. This will make the mapping obvious to an iCal expert reading the RDF, but at the same time make the RDF queries simpler and the properties more reusable. It would move things like RELATED RELTYPE=X into a subclass relationship between X and RELATED which allows generic RDF machinery to process it.
3. An extensive rework in which the logic of rules was largely exposed in RDFS or something stronger would of course be great.

Appendix: Node types

Appendix: rdf:Properties - from "parameters"

Appendix: Calendar component Properties

See spec 4.8

The columns E, T etc indicate whether the subject of the property is permitted to be an event, todo, journal, freebusy, alarm or timezone component.

Examples

@@@

References

There must be a much better list of resources for hacking calendar files of various formats - but until I find it here are some random things I found.

• The iCalendar RFC: RFC2445
• Jetstream: Java classes in Apache's Jetstream which represent the iCalendar properties.
• Open source handheld synchronisation software at openhandheld.org
• PalmOs documentation; file formats (pdf copy)
• Dan Connolly's design research notebook on this