Re: More Work on iCalendar RDF Schema

Thanks for responding Alan, Shannon. 

So let me try to formulate the issue to clarify things in my mind.

Sometimes (but not always) we want to be able to assign a timezone
identifier to a date-time. For this reason, in those circumstances
date-times need to be objects, not strings.

However, in many cases a string format for dates such as the W3C DTF
would give sufficient accuracy. Recurring events which span timezone
changes between daylight savings time and standard time are an example
case which would require more information than a UTC offset can give.

In the iCalendar rfc 2445 it is possible to have floating time values
(no time zone) and UTC time values (one specific timezone). There may 
be a case for having simple and complex time values.

This issue seems to  be very similar to the problems faced by dublin
core in RDF. There seems to be a conflict between modelling requirements
(date-times may have properties such as timezone and common name)
and simpicity (date-times can sometimes be adequately represented as a
string). This issue is an important one once we consider the
requirements of the RSS community, for example, who have a much more
document-orientated view of the world. However, the DC people have
opted for an object with an rdf:value arc coming off it (see the paper
'Expressing Qualified Dublin Core in rdf' 
http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/)

However, this problem could I think be resolved if in RDF literals were
allowed to be the subjects of RDf statements, because then we could
subclass a literal for date-time, and preserve the simplicity
 while keeping the structure. Aaron - does that sound right?

This is currently an RDF issue under consideration by RDF Core

http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects

I'm wondering if this is part of a larger issue about representing xml
datatypes in RDF.

[does a little research]

Dan connolly in Using XML Schema Datatypes in RDF and DAML+OIL
(http;//www.w3.org/2001/01/ct24) also uses the rdf:value construct for
datatypes in general in RDF/DAML.
XML date-time uses ISO 8601 representations of time, and includes the
possibility of UTC offset. 

I think I'm beginning to see a way through. My strong feeling is that
date-times need to be typed objects, and not just strings. This is
backed up by the DAML version of xml datatypes in RDF by Dan C.
However, unlike iCalendar rfc 2445, xml datatypes use UTC offsets for
timezones. Maybe what we could do is use objects for date-times but
allow UTC offsets to conform to xml datatypes. This would mean a
difference between icalendar in RDF and icalendar RFC 2445 though; and
I'm sure there are good reasons for the decision not to allow UTC offset
as part of the string (although it does appear as a property of a
date-time...). I've yet to finish going through the Calsch mailing list
archives - please forgive my ignorance.

So this may seem like the worst of both worlds, since you get an object
and not a simple string, but without the precision of a timezone
definition object. But for many people it would be sufficient and it
conforms with standard RDF practice and xml datatypes.

what do you reckon?

(apologies for the length of this message)

libby

> 
> The problem isn't that seconds aren't included, it's more that an
> offset isn't a complete enough description of a timezone.
> 
> To give one example, the iCalendar VTIMEZONE includes daylight/standard
> information. If I create an iCalendar recurring event that recurs every
> day at a 12 noon EST, and has occurrences that fall on either side of a
> daylight/standard shift, the UTC time-of-day of the occurrences on each
> side of the shift will be different (some will be 5 hours behind UTC,
> some will be 4).
> 
> Maybe iCalendar goes a bit over the top to ensure that timezone
> information is unambiguous, in that it requires a VTIMEZONE to
> be supplied within each object if the corresponding timezone is
> used in that object (Globally unique Time Zone IDs are still being
> discussed).
> 
> Also iCalendar allows floating times, which have no timezone (but are
> not UTC- they mean a given time of day in the recipient's timezone).
> 
> --Alan
> 
> 
> 
> 
>

Received on Friday, 22 June 2001 14:03:34 UTC