- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 21 Feb 2006 18:05:10 -0600
- To: public-swbp-wg@w3.org
I sent this to the DAML-time editors a while back... is America/Chicago a daml-time time standard, or just CDT/CST? Fri, 18 Feb 2005 09:22:25 -0600 http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0009 It's noted as an outstanding issue in the RDF Calendar Note. http://www.w3.org/TR/rdfcal/#L21805 I get the impression this WG is looking at a derivative of DAML-time... http://www.isi.edu/~pan/SWBP/time-ontology-note/time-ontology-note.html so I'd like it considered here... [[ I have been working on an RDF schema for iCalendar data for several years now; I have tried several different designs for modelling time zones, and I'm not quite comfortable with any of them. This week I re-discovered the DAML time work; in particular, this bit... [[ We have been refering to time _zones_, but in fact it is more convenient to work in terms of what we might call the "time standard" that is used in a time zone. That is, it is better to work with *PST* as a legal entity than with the *PST* zone as a geographical region. A time standard is a way of computing the time, relative to a world-wide system of computing time. For each time standard, there is a zone, or geographical region, and a time of the year in which it is used for describing local times. Where and when a time standard is used have to be axiomatized, and this involves interrelating a time ontology and a geographical ontology. These relations can be quite complex. Only the entities like *PST* and *EDT*, the time standards, are part of the _time_ ontology. ]] -- A DAML Ontology of Time Jerry R. Hobbs November 2002 http://www.cs.rochester.edu/~ferguson/daml/daml-time-nov2002.txt My question is: does "Chicago time", which changes between CST and CDT, fit this notion of time standard? The reason I ask is... I maintain some timezone data in RDF... http://www.w3.org/2002/12/cal/#tzd And there is renewed interest in a timezone registry... "TC-TIMEZONE was formed as a result of work being done in CalDAV showing the need for a formal time zone registry" -- Report on Roundtable II/Interop II -- 11-13 January 2005 http://www.calconnect.org/roundtable2.html The calconnect folks are working on iCalendar, an IETF Proposed Standard. The iCalendar specification for Timezones is http://www.w3.org/2002/12/cal/rfc2445#sec4.6.5 The RDF data I maintain are derived from an iCalendar formatted version of the tzinfo database that governs timezone calculations on lots of computers... "The public-domain time zone database contains code and data that represent the history of local time for many representative locations around the globe. ... This database (often called tz or zoneinfo) is used by several implementations, including the GNUC Library used in GNU/Linux, FreeBSD, NetBSD, OpenBSD, Cygwin ..." -- http://www.twinsun.com/tz/tz-link.htm The sources of that database are filled with fascinating trivia about timezone laws and such. The brilliant compromise they use is... Each location in the database represents a national region where all clocks keeping local time have agreed since 1970. Interestingly, both daml-time and this page about the tzinfo database note the special case of Indiana... Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, America/New_York represents most of the US eastern time zone; America/Indianapolis represents most of Indiana, which uses eastern time without daylight saving time (DST) ... The location in the database that corresponds to where I live is called "America/Chicago". Here's a turtle/n3 syntax view of (the gist of) the RDF view of America/Chicago, i.e. http://www.w3.org/2002/12/cal/tzd/America/Chicago Chi:tz a :Vtimezone; x:licLocation "America/Chicago"; :daylight [ :dtstart [ :dateTime "1970-04-05T02:00:00" ]; :rrule [ :byday "1SU"; :bymonth "4"; :freq "YEARLY"; :interval "1" ]; :tzname "CDT"; :tzoffsetfrom "-0600"; :tzoffsetto "-0500" ]; :standard [ :dtstart [ :dateTime "1970-10-25T02:00:00" ]; :rrule [ :byday "-1SU"; :bymonth "10"; :freq "YEARLY"; :interval "1" ]; :tzname "CST"; :tzoffsetfrom "-0500"; :tzoffsetto "-0600" ]; :tzid "/softwarestudio.org/Olson_20011030_5/America/Chicago" . The question is whether Chicago:tz fits the daml-time notion of time standard. Here's some example data from my itinerary for my next trip, to show how we use Chi:tz as a property to relate times to strings... http://www.w3.org/2005/03dc-bos/bos-tp-aa bo:_g0 a :Vevent, k:fromLocation <http://www.daml.org/cgi-bin/airport?MCI>; k:toLocation <http://www.daml.org/cgi-bin/airport?ORD>; t:arrivalTime "16:27"; t:departureTime "15:00"; t:flightNumber "1094"; :dtend [ Chi:tz "2005-02-26T16:27:00" ]; :dtstart [ Chi:tz "2005-02-26T15:00:00" ]; :summary "#1094 to ORD on AMERICAN AIRLINES" . The itinerary data is generated from a recent design, but the timezone data were generated from an older design. I'm not sure if they line up... I hope to re-generate the timezone data to be sure. I think I prefer to treat timezones as RDF datatypes, ala... bo:_g0 a :Vevent, :dtend "2005-02-26T16:27:00"^^Chi:tz. For those familiar with logic but who have not been dragged thru RDF datatypes, they're pretty much like function terms: dtend(g0, Chi:tz("2005-02-26T16:27:00")) hmmm... maybe I have that backwards... maybe it's (E x) dtend(g0, x) & Chi:tz(x) = "2005-02-26T16:27:00" Which reminds me... I'm also looking at re-generating the timezone RDF data or perhaps just changing the iCalendar/RDF schema in order to accommodate a recent request from TimBL to be more explicit about some constraints in order to support a diff/sync architecture we're working on... Please put IFP and FP decls into the TZD and iCal ontologies http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0002.html He's basically asking to add ical:Vtimezone rdfs:subClassOf owl:InverseFunctionalProperty. to the iCalendar schema, and I'm thinking about whether that makes sense. Tim and I were talking about what happens at 2am on Sundays in the spring and fall and whether we need some sort of "if a local time maps to 2 UTC times, pick the first one" rule to avoid an inconsistency. I'm trying to absorb the dam-time ontology by transcribing it to N3 so that I can actually use it with my data and schemas... http://www.w3.org/2000/10/swap/util/time.n3 v 1.1 2005/02/18 03:05:12 I have only worked thru a few sections so far; I'm not sure when I'll get down to the timezone section. So I thought I'd bundle up what I learned so far and send this question, in case I don't get back to it on my own. ]] -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Wednesday, 22 February 2006 00:05:20 UTC