Dear RDF-Calendaring experts
I am a humble student, new to RDF. I implemented an Ical 2 Rdf converter
as a part of the Aperture Framework (). I
used materials provided by your group namely:
The output of the fromIcal.py script by Dan Connoly
The rdf-ical examples
The RDF Calendaring page in the ESW Wiki
My approach was to implement all components, properties and parameters
defined in the RFC. I disregarded the experimental ones. In cases where
a property wasn't mentioned in the examples I came up with my own
mapping. I tried to document the mapping with a N3-like pseudocode. It
was quite a time-consuming task because for every ical element
(component, property, or parameter) i had to learn by example.
I think it would be beneficial for all future implementors to document
the current state of work on Ical 2 rdf mapping in a more detailed and
more formal way. My idea of documentation, that would accelerate and
facilitate my work would look as follows
* General remarks
- four-level, tree-like structure
(VCalendar -Component -Property -Parameter)
- 'Normal' Components (Vevent, VTodo, VJournal, VTimezone)
vs 'Embedded' Component (Valarm, Daylight, Standard)
- treatment of datatypes (ical - to XSD conversion of dates and
datetimes)
- treatment of properties with multiple comma-separated values
* Components
- general remarks how components are handled,
- algorithm to generate URIS (UID, what if there is no UID)
- special issues with timezones (DanC's Timezone database)
* Properties
- for EVERY property in the RFC specification there should be the
following information:
* possible parameters (according to RFC)
* is it a direct link to a literal (in which case parameters are
ignored, this is the case in the examples) or a blank node is
introduced
* the URI of the link that connects the parent node (component
or iCalendar node) with the value (or the intermediary blank
node)
* for the properties that introduce a blank node the URI of the
link between that node and the value itself (rdf:value or
icaltzd:calAddress as far as I remember)
* default IcalDataType
- treatment of property values, what Ical datatypes map into
XSD datatypes. Treatment of the VALUE parameter
- a few words about the special treatment of TZID parameter
(the timezones-as-datatypes idea)
* Parameters
- all introduce single triples, but if some parameter value
were to be a typed literal - this should also be noted
* recurrence rules
- a special value type, how to handle the recurrence params
(e.g. INTERVAL requires a typed xsd:integer literal)
Much of this information can be deducted from the ontology itself but it
is incomplete. Many properties don't have ranges specified. If it is a
conscious decision (for whatever reasons), it should be written down
elsewhere. The Javadoc for the IcalCrawler class contains a draft of the
documentation of the mapping.
It may be viewed via the webcvs interface at sourceforge
The interesting part begins at line 628. (SPECIFIC BUSINESS METHDS).
I may attach the generated Javadoc if that's not a problem with other
members of this group. I would be grateful for any remarks that would
help me improve it and maybe make it useful to thers.
Source code can be freely downloaded from the sourceforge CVS.
Details under
This class serves a purpose of a Crawler in the Aperture Framework. It
can be also used as a simple converter with the main method provided by
I welcome any comments.
Antoni Mylka
Antoni.Mylka (AT) dfki (DOT) uni-kl.de