The NEPOMUK Calendaring
Ontology intends to provide vocabulary for describing calendaring data
(events, tasks, journal entries) which is an important part of the body
of information usually stored on a desktop. It is an adaptation of the
ICALTZD ontology created by the W3C RDF Calendar Task
Force of the
Semantic Web Interest Group in the Semantic Web Activity.
This document describes the reasons behind the adaptation, the changes
performed, as well as an overview of the classes and properties of the
NCAL ontology.
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].
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Nepomuk Calendaring
Ontology doesn't capture the whole complexity of the data
model defined by RFC 2445. Following limitations have been identified.
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.
