RE: More Work on iCalendar RDF Schema

Another point,

Remember that iCalendar is intended to do two related but different tasks.

One - encode calendar data for machine-to-machine use - i.e. to facilitate
scheduling programs (by making it possible to calculate and publish
FREEANDBUSY information in an interoperable manner. In the case of TIMEZONES
this means encoding in a way that a MACHINE can calculate the CORRECT times
in relationship to each other - i.e. offsets, and some form of rule of which
offset to use (for Daylight savings) are sufficient.

Two - encode calendar data for HUMAN use. In the case of timezones this
means of course behave correctly in regards to displaying times - but it
also means behaving as the USER expects in terms of displaying the NAMES and
descriptions of TIMEZONES that relate to objects on their calendar.

Thus there is a requirement to encode the "Common Name" that is associated
with a particular timezone - and with the particular mode that the timezone
is in (i.e. Central Daylight Savings Time) - furthermore frequently users
prefer a variety of names and forms of referring to timezones - some prefer
CST, some prefer Chicago, some "US, Chicago", some "Canada, Montreal".  The
point is that by making timezones into objects it is possible to encapsulate
significantly more information than if they are attached to directly to the
TIME field.

Thus iCalendar specifically avoids having TIMEZONE as part of a TIME field,
though it does accommodate one special case of Z (or Zulu time) which
represents UTC time.

Hope this helps,

Shannon

-----Original Message-----
From: www-rdf-calendar-request@w3.org
[mailto:www-rdf-calendar-request@w3.org]On Behalf Of Libby Miller
Sent: Friday, June 22, 2001 5:39 AM
To: Libby Miller
Cc: Aaron Swartz; Michael Arick; RDF Calendar
Subject: Re: More Work on iCalendar RDF Schema



ah, re times, I get you, the W3C DTF has timezones tacked on as part of
the string. I guess we could go this way. The icalendar people were
concerned with the accuracy of the timezone information I think,
particularlly for cases where there was no standard name for the
timezone. But you may be right that we don't need this degree of
accuracy, in which case the W3C format would probably do. This would
simplify things.

cheers

libby


see http://www.w3.org/TR/NOTE-datetime


On Fri, 22 Jun 2001, Libby Miller wrote:

>
> hi Aaron. Many thanks for having a look at this.
>
> I should perhaps clarify at least what my intentions were in writing the
> iCalendar in RDF. In particular I wanted to stay as faithful to
> iCalendar as I possibly could, even if this meant that I ignored
> potentially better ways of doing it. I figured that once we had a
> relatively clear iCalendar model in RDF, this could form the basis of
> further work to perhaps separate out different parts into diffeent
> namespaces, or possibly make simplifications, or hook into different
> existing schemas. So as far as RDF calendar taskforce goes, we shouldn't
> see something like the hybrid calendar as the end of the work but just
> an attempt at a solid basis for the start. A next step is to start
> comparing other similar schemas using examples.
>
> >
> > Why THEANNOYINGNAMES? I have difficulty distinguishing between
> > Classes and properties, and there is no good reason for keeping
> > them in ALLCAPS.
> >
>
> This is down to me - Micheal used lower case caps/no caps for classes
> and properties as is more usual. I started off doing that too. However
> the iCalendar rfc is such a complex document that I wanted to minimise
> the number of mistakes that crept in in transcribing it to RDF. For that
> reason it is better to be consistent with the iCalendar usage of
> capitals even though it's not vrey aesthetically pleasing. We can always
> change this later.
>
>
> > Why the funky dates? Can't we just use W3CDTF like everyone else?
> >
>
> This is consistent with the iCalendar RFC usage. I didn't want to
> arbitrarily change anything at this point.
>
>
> > Why duplicate ical:DESCRIPTION and dc:description ?
> >
>
> Michael's reply to this is a good one.
>
> > As a test, I tried transcribing
> > http://ilrt.org/discovery/2001/06/content/track2.rdf into N3
> > with the simplifications I propose above. Look at how much
> > simpler it is:
> >
>
> Aaron, it's confusing to compare one example in XML and another in N3,
> since N3 looks much less complex anyway. One complexifying factor with
> the example I made are the timezone objects (which I'm not sure I have
> right). One thing that could be done here is a fairly authoritative
> conversion of some of the data at www.dateandtime.com (say) into RDF, so
> people would not have to define their own timezones, but could just
> refer to previously defined ones.
>
> I don't see that your idea is so much simpler. It seems that dates are
> now strings rather than objects (my N3 isn't so great). This is ruled
> out if we want to use Timezones. Otherwise changing ical:description to
> dc:description isn't such a big change. Have I missed something else...?
>
> thanks again Aaron - I'm very grateful for your hard work.
>
> Libby
>
>
> > @prefix util: <http://ilrt.org/discovery/2001/06/schemas/ical-util#> .
> > @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> > @prefix dc: <http://purl.org/dc/elements/1.1/> .
> > @prefix event: <http://test.example.com/events/> .
> > @prefix speaker: <http://test.example.com/speakers/> .
> > @prefix : <http://ilrt.org/discovery/2001/06/schemas/ical-
> > full/hybrid.rdf#> .
> >
> > [ a :VCalendar ;
> > 	dc:description "2" ;
> > 	:vEventProp event:137 .
> > ] .
> >
> > event:137  a :VEvent ;
> > 	:dtStart "20010525T141500" ;
> > 	:dtEnd "20010525T141500" ;
> > 	:description "The State of XML" ;
> > 	util:presentation [ a foaf:Document
> > 		dc:creator speaker:40  ;
> > 		dc:title "The State of XML" ;
> > 		dc:description "This talk surveys the current state of
> > XML - from standards and standards-makers through to XML's role
> > in the architecture of the next generation of computer systems.
> > XML's influence is being felt ever more broadly: not only on the
> > Web and in business, but also in more unexpected places such as
> > operating systems and embedded devices. Aided by an energetic,
> > creative and sometimes controversial community, the state of XML
> > is looking better than ever." ] .
> >
> > speaker:40 a foaf:Person, :CalAddress .
> >
> > --
> > [ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]
> >
>
>

Received on Friday, 22 June 2001 12:59:41 UTC