NEPOMUK Calendar Ontology

This document arose from the work of the Task-Force ontologies within the NEPOMUK project. This document is a DRAFT made available by the Nepomuk Consortium for discussion only. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.

This document is a part in a set of seven documents, which together comprise the complete specification of the Nepomuk Information Element Ontology Framework. These are: NIE, NFO, NCO, NMO, NCAL, NEXIF, NID3.

Added

Modified

• ncal:created
• ncal:description

Deprecated

1. Introduction

Nepomuk Calendar Ontology (NCAL) has been designed to describe various entries usually found in calendars. These include events, tasks (todo's) and journal entries. It is an adaptation of the well known iCalendar specification published in 2002 as RFC 2445 [RFC2445]. This section begins with an outline of the previous attempts in adapting RFC 2445 to RDF. It gives an account of the issues with existing ICAL ontologies that make them unusable within Nepomuk. Following subsections describe the process adopted for the creation of NCAL and it's result - the classes and properties of the ontology. Proposed solutions to problems found in existing ICAL ontologies are presented. At the end, a list of known limitations of NCAL is given, followed by ideas for future work on improving NCAL.

The following sections make use of the vocabulary specified in RFC 2445. The reader is advised to get acquainted with it before continuing reading. A nice outline of the structure of iCalendar specification can be found in [TIMBLICAL].

1.1 Previous work

The need for a common vocabulary for describing calendaring information in RDF has been recognized early within the W3C RDF Interest Group. Organized activity has been started on 9th of October 2002 at the SWAD-Europe Workshop on the Semantic web and Calendaring in Bristol, UK. The report from this workshop [SWAD37] mentions earlier attempts by Tim Berners-Lee ([TIMBLICAL]), Arick and Miller ([HYBRIDICAL]) and Dan Connoly ([ANOTHERICAL],[PALMICAL]).

Work continued through a series of meetings. Numerous discussions were held using the www-rdf-calendar@w3.org mailing list. The archive is available at here and the #rdfig channel on the Freenode IRC network. Logs of these discussions are available here.

After three years of research the group has produced two ontologies in OWL and a W3C Interest Group Note ([ICALNOTE]) describing the design decisions that have been made. The first ontology, hosted under http://www.w3.org/2002/12/cal/ical is more popular, semantic web enthusiasts try to publish their calendars with this vocabulary, even though the creators themselves have abandoned it in favour of a newer one, hosted under http://www.w3.org/2002/12/cal/icaltzd. The main difference between these two lies in treatment of timezones. Many entities in the iCalendar data model contain various dates and times. They are usually accompanied by a timezone that should serve as a context to interpret them. The older ontology represents this fact with a 'tzid' property more in-line with the original representation. The newer one uses a controversial approach of representing the timezones as datatypes for literals.

In the rest of this section the older ontology will be referred to as ICAL ontology, whereas the newer one will be called the ICALTZD ontology to avoid confusion. TZD stands for ``TimeZones as Datatypes''. Whenever concrete properties from the ICAL ontology are referred, they will be given with the 'ical' prefix (e.g. ical:attendee). ICALTZD properties will use the 'icaltzd' prefix (e.g. icaltzd:component).

2. Drawbacks of the ICALTZD ontology

ICALTZD ontology is newer and better developed. Therefore it was chosen to serve as a the model for NCAL. Numerous drawbacks have been identified in it though. This section gives an account of them. It is intended to provide justification for the decision not to use ICALTZD directly.

Most of the deficiencies of ICALTZD have been caused by the automatic process of its creation. It is automatically generated from the text of the RFC itself using a combination of a python script and an XSLT transformation. (Refer to [ICALNOTE] for details). This process overlooks many details that cannot be extracted with a simple analysis of the structure of the document. They would require deeper understanding of the text itself, which is certainly beyond the capabilities of such simple tools. Following subsections explain four kinds of problems encountered when trying to use ICALTZD within Nepomuk: underspecification, bugs, superfluous elements and pieces of design that certainly cannot be considered errors in themselves but are nevertheless against the guidelines for NIE.

2.1 Underspecification

ICALTZD is underspecified. There are many places, where certain structural information is not explicitly stated within the ontology. The user needs to be aware of the 'conventions' adopted by the authors.

2.1.1 Property values and parameters

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:

• Possible parameters (according to the RFC 2445). Information if those parameters are allowed in the RDF representation or not, which is the case if the model has been simplified.
• Information if a property points to a literal value (in which case all parameters specified in RFC 2445 are discarded) or to an untyped blank node.
• URI of the property.
• URI of a property used to link the intermediary blank node with the actual value of the property.

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.

2.1.2 Domains of calendar properties

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.

2.1.3 Missing Entity Types

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.

2.1.4 No limited vocabulary

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.

2.1.5 Vague semantics of the component property

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.

2.2 Errors

Two problems have been identified when working with the ICALTZD ontology. The first one concerns the domain of the icaltzd:rrule property. It is defined as an anonymous owl union class.

<rdf:Description rdf:ID="rrule">
 <rdfs:domain>
 <owl:Class rdf:nodeID="DomainOf_rrule">
 ....
 </owl:Class>
 <rdfs:domain>
 ...
</rdf:Description>

We see that the nodeID construct has been used. This means an identifier of a blank node. This might not have been the intention of the author though since two other properties icaltzd:recurrenceId and icaltzd:exdate refer to it, but they do it wrong.

<rdf:Description rdf:ID="recurrenceId">
 <rdfs:domain>
 <owl:Class rdf:about="#DomainOf_rrule"/>
 </rdfs:domain>
</rdf:Description>

This construct refers to an URI, not to a blank node. The W3C RDF validator interprets the first example as:

subject: http://www.w3.org/2002/12/cal/icaltzd#rrule
predicate: http://www.w3.org/2000/01/rdf-schema#domain
object: genid:UDomainOf_rrule

Whereas the second example is interpreted as:

subject: http://www.w3.org/2002/12/cal/icaltzd#recurrenceId
predicate: http://www.w3.org/2000/01/rdf-schema#domain
object: http://www.w3.org/2002/12/cal/icaltzd#DomainOf_rrule

Which is clearly not the same.

The second problem with ICALTZD are multiply defined ID's. The W3C RDF Validator finds 53 redefinitions of a previously defined identifiers. This fact has caused problems when working with the RIO 1.0 RDF Parser. It could potentially cause problems with other tools, even though semantically it makes no difference if a statement occurs once or multiple times within an RDF document.

There are also repetitions in OWL unions that describe the domains of properties.

2.3 Ranges of datatype properties

An attempt has been made to model the datatypes of literals that serve as property values. A set of datatypes has been defined. These include icaltzd: Value_DATE-TIME, icaltzd: Value_CAL-ADDRESS, icaltzd: Value_PERIOD, icaltzd: Value_RECUR etc. They have been defined as rdfs: Datatype but there are no additional characteristics of them. In most cases they can safely be expressed with either xml schema datatypes or special-purpose classes. It is worth noting that the datatype for dates and times is defined twice: as icaltzd: Value_DATE-TIME and icaltzd: dateTime.

2.4 Design decisions unacceptable in Nepomuk

2.4.1 OWL

The most important fact, that inhibits the usability of ICALTZD within Nepomuk is that it is expressed in OWL. This violates the guideline expressed here. 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.

2.4.2 Timezones as datatypes

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:

• It relies on the timezone database provided by the authors.Available here. This database was created by converting the well-known Olson timezone database to RDF. This assumption works as long as the timezone identifiers used in in iCalendar files can easily be translated into URIs from that database. This is often the case, but there are no constraints specified in the RFC 2445 to reinforce that claim. The timezone identifiers are plain strings. The specification states that they should refer to timezone definitions that within the same file. RFC 2445 doesn't mention any centralised timezone database. There are perfectly correct iCalendar files that use timezone identifiers that cannot be easily (that is by simple string operations) mapped to those from the Olson database.
• Instances of icaltzd:Vtimezone gathered in the timezone database are not instances of rdfs:Datatype. Using them as datatypes is dubious from the semantic point of view.
• This approach makes it impossible to specify the datatype in the ontology itself. The user must learn to use this convention from other sources.

2.5 Alignment with contact ontology

Tight integration between ontologies has been identified as one of the core requirements for NIE (see here). ICALTZD makes no references to any specific ontology that would make it possible to link calendar events with actual contact information about attendees and organizers.

3. NCAL Development process

Issues outlined in the previous section led to a decision to create a new calendaring ontology for Nepomuk. The main goal was to solve the problems described above while retaining compatibility with Nepomuk guidelines.

Development of NCAL began with the ICALTZD ontology. A Java program has been written that transformed it into RDFS and performed some basic transformations. These transformations included:

• Solving the problem with the domain of rrule property. See
here
• Adding the TimezoneObservance class and including it in domains of appropriated properties.
• Removing the cardinality restrictions from class definitions.
• Converting the owl unions to appropriate superclasses and adding the rdfs:subClassOf links.
• Changing OWL classes and properties into RDFS classes and properties.
• Converting all property ranges to XML Schema datatypes
• Creating the RecurrenceRule class, adding it as a range of icaltzd:rrule and icaltzd:exrule properties. Setting the domain of all recurrence rule parameters appropriately.
• Setting the domain of all four Vcalendar properties correctly.

It became clear that some properties require special classes as their ranges. They would provide explicit hooks to attach the property parameters. In order to get an overview of the needs the definitions of properties in RFC 2445 have been examined carefully. A table has been created with basic information about each property. It had following columns:

• Name of the property.
• Domain of the property.
• Default type of the property value.
• Additional possible types of the property value (does the property accept the VALUE parameter).
• Does the value accept the timezone identifier parameter?
• Other parameters (apart from VALUE and TZID).
• Possible values. (If the property has a limited set of possible values).
• Multiplicity. Whenever the RFC mentioned the fact that a property can be specified multiple times (or only once), or that it can have many comma-separated values - this fact was recorded.
• Other important information.

This table quickly visualised the actual relations between properties and parameters. It enabled us to divide the ical properties into six groups. For each group an approach to represent it in RDF has been chosen.

• Properties that accept the ALTREP and LANGUAGE parameters. It has been decided that creating a separate class just to have means to express the alternate representation would not be an elegant solution. Therefore for each property that can accept the ALTREP parameter (i.e. COMMENT, DESCRIPTION, LOCATION, RESOURCES, SUMMARY and CONTACT) a new 'altRep' property has been introduced (i.e. ncal:commentAltRep, ncal:descriptionAltRep, etc.). The LANGUAGE parameter has been removed from the ontology altogether. The user can express the same with language literals available in RDF.
• Properties that accept no parameters, but have a limited set of values. This included CLASS, STATUS, TRANSP and ACTION. For each a separate class has been introduced. For each of those classes a set of instances has been created to represent the possible values of each property.
• Properties that don't accept and don't have any restrictions on the set of possible values. This was the simplest case. The ranges of those properties have been set to an appropriate XML Schema datatype. (Apart from RRULE and EXRULE, which refer to a RecurrenceRule).
• Properties that refer to a Universal Coordinated Time point. (COMPLETED, CREATED, DTSTAMP, LAST-MODIFIED). Their ranges have been set to the dateTime datatype defined in the XML Schema Definition.
• Properties that refer to a time point in a concrete timezone (DTEND, DUE, DTSTART, EXDATE, RDATE). The problem of representing the timezone has been solved with the NcalDateTime class. Its properties enable it to be used whenever a DATE-TIME or DATE value is needed. It also provides three ways to express the timezone - a reference to a ncal:Timezone instance or a simple string.
• Properties that require separate solutions. These included RECURRENCE-ID, TRIGGER, FREEBUSY, ATTENDEE, ORGANIZER, ATTACH, GEO, RELATED-TO. For each of those a separate class has been created and added to the range of the property and to the domain of appropriate parameters.

4. Differences between NCAL and ICALTZD

The overall structure of NCAL is in most respects similar to ICALTZD, which is thoroughly described in [ICALNOTE]. NCAL only tries to clarify certain underspecified points, as outlined in the sections above. Following paragraphs describe two important changes that break the continuity with ICALTZD.

4.1 Timezones

As already mentioned, NCAL introduces the NcalDateTime class (see ncal:NcalDateTime). It's purpose is to provide a more elegant way to link the time values with their timezones. It can also represent plain dates, which models the fact that four properties have two possible value types: date and date-time. It allows for a clean link between the time value and the timezone (expressed with the ncal:ncalTimezone). Since RFC states that each icalendar document MUST contain exact definitions of all timezones used, it can safely be assumed that all time values can refer to those definitions.

4.2 Alignment with NCO

According to the guidelines for NIE (see sec. here), it is desirable to promote integration between ontologies. That's why ranges of two properties (namely: ncal:attendee and ncal:organizer have been equiped with links to the nco:Contact class from the Nepomuk Contact Ontology. This will facilitate integration between addressbooks and calendars.

4.3 Union Classes

ICALTZD used OWL unions to define domains of many properties. They don't have their equivalents in NRL, so another solution has been adopted. Each union is now represented as a separate class with whose name has been generated by concatenating the names of classes that comprise the union. (such as UnionOfEventFreebusy).

The reader may now feel the urge to give more "meaningful" (semantic) names to the union classes. It is difficult. The semantic meaning of a union class is defined by the properties that have it as a domain, and it was not possible for us to find a name for the Union classes based on the properies, as they are too diverse.

5. Known limitations of NCAL

Nepomuk Calendaring Ontology doesn't capture the whole complexity of the data model defined by RFC 2445. Following limitations have been identified.

• Usually in places where a limited set of values is referred to, one of those values is considered default. NCAL doesn't distinguish between default and non-default values.
• If a parameter or a property has multiple sets of acceptable values depending on the context - this information is lost. For example the STATUS property can have different values depending on whether it has been applied to a Event, a Todo or a Journal instance. NCAL makes no such distinctions. All possible values are represented as instances of the same class.
• Sets of acceptable parameters can also differ between various classes in the domain of a property (e.g. attendee of an alarm cannot have any parameters). NCAL doesn't capture this.
• No cardinality constraints have been specified, neither direct (properties MUST be specified) nor conditional (properties that cannot be specified simultaneously)
• Extension tokens have been altogether ignored

6. Future versions

A major revision of NCAL is expected when the RFC 2445 is obsoleted by a new document currently in preparation in the Working Group for Calendaring and Scheduling Standards Simplification (CALSIFY) within the Internet Engineering Task Force.

7. Examples

Example files that show how to use the expressive power of the ontology will be published here in near future.

References

[ICALNOTE]

Rdf calendar - an application of the resource description framework to icalendar datal, Dan Connolly and Libby Miller, W3C Interest Group Note 29 September 2005 http://www.w3.org/TR/rdfcal/

[HYBRIDICAL]

Hybrid ical rdf schema, Michael Arick and Libby Miller http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf

[TIMBLICAL]

A quick look at icalendar, Tim Berners-Lee http://www.w3.org/2000/01/foo

[ANOTHERICAL]

Another icalendar model, Dan Connoly http://www.w3.org/2000/10/swap/pim/ical.rdf

[PALMICAL]

Palm datebook, Dan Connoly http://www.w3.org/2000/08/palm56/datebook

[RFC2445]

Internet calendaring and scheduling core objects specification, Frank Dawson and Derik Stenerson http://www.ietf.org/rfc/rfc2445.txt

[SWAD37]

Swad-europe deliverable 3.7: Developer workshop report 2 - semantic web calendaring, Libby Miller http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/

[NRLSPEC]

Nepomuk Representational Language (NRL) Vocabulary Specification., Nepomuk Task-Force Ontologies, http://www.semanticdesktop.org/ontologies/nrl