RFC 2445 specifies a generic model where each calendar property can be adorned with any number of parameters. Some properties (e.g. UID) don't accept any parameters. These can easily be modelled in RDF. Their ranges can be set to appropriate XML Schema datatypes. Other properties (e.g. Attendee) accept a number of parameters. They cannot be easily modelled in RDF because literals cannot serve as subjects of RDF triples. An intermediary node is necessary.

Using intermediary nodes to express property values poses two problems. The first one being the type of that node. ICALTZD uses untyped blank nodes for this purpose. This is against the recomendations for using property domains and ranges within Nepomuk Representational Language (See [ NRLSPEC] sec. 2.3.1). The Closed-World assumption adopted in NRL implies that domains and ranges are constrains that must be met. Untyped resources cannot be related in NRL.

Whenever such intermediary blank nodes are used as property values, the ICALTZD ontology doesn't specify the ranges of those properties at all. (e.g. in icaltzd:attach, icaltzd:dtend, icaltzd:dtstart, icaltzd:due, icaltzd:duration, icaltzd:exdate, icaltzd:exdate, icaltzd:rdate, icaltzd:recurrenceId, icaltzd:trigger, icaltzd:tzurl, icaltzd:url). It is worth noting that in some cases the ICALTZD ontology simplifies the model defined in RFC 2445 and discards some parameters. This happens for instance in 8 properties that use parameters for alternate representation (ALTREP) and language (LANGUAGE) namely: icaltzd:comment, icaltzd:description, icaltzd:location, icaltzd:resources, icaltzd:summary and icaltzd:contact. These simplifications are not documented anywhere. They can only be learned by observing the example files provided with the ontology.

An attempt has been made to develop a utility that would convert raw iCalendar files to an RDF representation conforming to the ICALTZD ontology. It was developed as an element of the Aperture Framework. Due to the underspecification of properties the developers had to document the conventions by themselves. Each property has been characterised with following attributes:

The last of those four characteristics is especially important since it constitutes the second of those two problems mentioned above. RFC 2445 allows for a property to have multiple value types. The actual type is indicated by a special parameter (VALUE). It is difficult to model this behavior in a general case. ICALTZD makes no attempt to formalize it and forces to user to learn the conventions expressed in examples.

Property parameters are modelled in ICALTZD as rdf properties with no domains and ranges specified at all. Because of that each parameter can just as well be applied to any property. The same applies to parameters of recurrence rules (RRULE and EXRULE property values). Their usage must be learned from the RFC 2445 or from the example files. The ontology itself contains too little information.

RFC 2445 specifies four properties that apply directly to the central Vcalendar object. These are icaltzd: prodid, icaltzd: calscale, icaltzd: method and icaltzd: version. They don't have their domain specified at all.

As said before many properties that accept parameters deserve to have a special classes as their ranges. From these four deserve to be mentioned separately. They are different from other structured values because they are described with their own vocabulary i.e. not with 'normal' ical parameters as defined in sec. 4.2 of RFC 2445.

RFC 2445 defines the concept of a timezone observance. Each timezone can have two observances - daylight and standard. This models a common practice to use different time in the winter and in the summer. Properties responsible for this in the ICALTZD ontology are icaltzd:daylight and icaltzd:standard. They don't have their ranges specified, even though RFC 2445 treats them as separate subcomponents within the timezone component. They are marked with a separate pair of BEGIN and END constructs. The ontology makes no provision for it being a separate class.

A similar situation occurs with recurrence rules i.e. values of RRULE and EXRULE properties. They define patterns for the repetition of a calendar event. ICALTZD doesn't mention them specifically. They are expressed as untyped blank nodes. Recurrence rule properties are attached to untyped blank nodes.

There are also two properties that don't accept any parameters, but their values are structured. That is a comma separated value of the GEO property, which signifies coordinates of a point, and a semicolon-separated value of the REQUEST-STATUS property.

Many properties and parameters defined in RFC 2445 (e.g. CLASS, STATUS, TRANSP, PARTSTAT, RELTYPE etc.) have a limited set of values. This is not expressed in the ICALTZD ontology. The user needs to learn those acceptable values by him- or herself in order to generate RDF that can be exported to a valid iCalendar file.

ICALTZD defines an icaltzd: component property to link the calendar with the components it contains. It is also used to link the events with their alarms but even though Timezone Observances also have their own BEGIN and END constructs, the icaltzd:component property is not used there. These usage patterns have been extracted from the example files provided by the authors of the ICALTZD ontology. The ontology itself doesn't define any domain or range for the icaltzd:component property.

The most important fact, that inhibits the usability of ICALTZD within Nepomuk is that it is expressed in OWL. This violates the guideline expressed in Use NEPOMUK Representational Language. Even though OWL classes and properties could theoretically be interpreted as RDFS constructs, ICALTZD makes use of OWL unions, which have no equivalent in RDFS.

A second design decision that may be considered controversial is the timezones-as-datatypes idea. Whenever point in time is referenced it is described with a date, time and a timezone. The first two parts can be expressed with a single literal, formatted according to the XML Schema 'dateTime' format. The timezone though is expressed as the datatype of that literal. Example files provided with the ICALTZD ontology contain many entries similar to the following one:

<Vevent
      rdf:about="#D4F0202E-2F2F-11D7-A96C-000393161A98">
      <summary>#rdfig calendar meeting</summary>
      <tstart
      rdf:datatype="http://www.w3.org/2002/12/cal/tzd/Europe/London#tz">
      2003-02-05T17:00:00 </dtstart> <dtend
      rdf:datatype="http://www.w3.org/2002/12/cal/tzd/Europe/London#tz">
      2003-02-05T18:00:00 </dtend> <description>
      Email www-rdf-calendar@w3.org with agenda suggestions.
      </description></Vevent>

As you can see the values dtstart and dtend properties have their timezones expressed as URIs. This approach has following disadvantages: