RE: relationship to iCalendar

Libby,

I was just reading your comments about recording/archiving event
descriptions, and a possible solution occured to me (well this is only a
partial solution - more might need to be done to make it work)

A. - I believe you can mark Calobjects as RELATED-TO each other, this is
designed to allow vEvents, vToDos, and vJournals to be related to each
other.

B. - One possible use of a vJournal would be to use it to record a "history"
of a given vEvent - for many purposes this might be perfectly suited -
though what I am not sure about it how well this would support breaking out
and tagging specific times to specific individual's attendance.

This brings up another alternative - use RELATED-TO vEvents to record
"attendance" - i.e. set primary vEvent for the meeting, with attendees - but
set a "related-to" vEvent for a person who left the meeting early (and set
that event's time(s) accordingly.

Just a thought - this would not require a great deal of complexity in terms
of the data structure - but would require that RELATED-TO be employed in
some clear and useful manner by CUA used to view and explore archival
information - I suspect many current CUA only use the RELATED-TO for
associating vTODOS and vJOURNALS and may be less useful in associating
vEvents together.

Shannon

-----Original Message-----
From: www-rdf-calendar-request@w3.org
[mailto:www-rdf-calendar-request@w3.org]On Behalf Of Libby Miller
Sent: Monday, August 13, 2001 10:25 AM
To: Martijn van Beers
Cc: www-rdf-calendar
Subject: Re: relationship to iCalendar



Hi Martijn,

>
> Hrm. what's wrong with sticking close to iCalendar? I'm working on
> Net::ICal, a perl implementation of rfc2445, and I was thinking
> of making it capable of outputting rdf as specified by your schema,
> so we can use xsl to convert it to html/other xml formats. But
> if you're going to move away from iCalendar, I'd have to come up
> with my own xml format.

We fully intend that documents written in rdf-cal format (or whatever we
decide to call it) will be mappable to iCalendar format and
vice-versa.

In terms of differences, what's most likely to happen is that there will
be several different parts to the rdf-cal schema, with different
namespaces, representing various parts of the iCalendar rfc 2445. So
this is a trivial way in which they will differ. I am also wondering
whether on close inspection some of the names used in iCalendar rfc 2445
map well on to the classes and proprties they need to become in
RDF. Also the capitalisation of names in iCalendar will probably
change in rdf-cal because the convention in RDF is to give classes a
first capital letter and have properties in lower case. These again are
all fairly trivial.

More fundamental is the difficulty that iCalendar may not give us all
that we may want from descriptions of events. For example, in iCalendar
you have a VEVENT which has DTSTART and a DTEND. Now it maybe that if
the VEVENT is a meeting, libby has to leave early. This implies that she
was an ATTENDEE at the meeting for only part of the time of the duration
of the meeting. We can't express this in iCalendar as it stands, but I
think it's an important aspect of archiving event descriptions. It's
also something SKIcal have been looking into. See a preliminary (and
partial) rdf calendar issues list at

http://ilrt.org/discovery/2001/07/cal-issues/

But this is an addition, and so should not affect translation to and
from the iCalendar format. It is possible that we will find other
similar issues as we work through examples for each property and class.

>
> Another question, why are <ical:VEVENT>s wrapped in a <ical::VEVENT-PROP>?
> From the example data you have
> (http://ilrt.org/discovery/2001/06/content/swws2001-07-30.rdf) it looks
> like it's just a gratuitous extra tag.

This is part of the way RDF works. The striped syntax for RDF means that
you have to have class - property - class - property. ical:CALENDAR is a
class and ical:VEVENT is a class so you need a property in
between.  Perhaps I could have given it a better name though.

cheers,

Libby

Received on Friday, 17 August 2001 15:49:05 UTC