different calendars Re: ical schema based on 1 test case: mtg.ics

This is still rambly thinking-out-loud.

The short summary is that I think dates are just events, whose occurrence can
be calculated relative to other events of "type date", and which occur at
geographic locations.

For some classes of dates, such as UTC from now until we change the rules,
these things can be believed for any location - for tohers, such as the Hejri
calendar I am using as my example, this apparently varies from place to
place. But "local time" is normally important - and local time in Melbourne
and Brisbane is the same for certain dates, and different for others, because
Australia does not have universal summer time. Since real people tend not to
live by UTC, (nor swatch's "beat" time - another attempt to have a
time-zone-free system,) solving this problem still seems useful for other
than historical interest.

cheers

Chaals

The long and so far a bit inconclusive ramble that got me there...

What I know about the Hijri (Islamic) lunar calendar

Well; in summary still not a lot. I have a program that can generate tables
to convert to the gregorian calendar, but it is a non-trivial exercise.

Features of the calendar: The length of months can vary. They are based on
the first sighting of the new moon, whch makes them dependent on place (with
the added complication that like the christian calendar for many centuries
different people followed different advice on when this was, so dates vary by
plus or minus one in actual usage).

The days (like in the Jewish calendar) run from sunset to sunset and not
midnight to midnight as in the gregorian calendar. This means that noon will
be on the same day, whereas 10pm on that day in the Gregorian calendar will
be 10pm the next day of the Hijri calendar in places where the sun has set by
then.

I don't think the location dependence is a big problem - we already have to
deal with synchronising time zones according to places.

I suspect that it wasn't always the case that gregorian calendars ran
midnight to midnight either, but I don't know enough to find out when this
measure was adopted. In any case, usage should mean that it doesn't cause a
problem for historical data if we know the difference between the eve of a
given day and the night of a given day.

So what I would like to do is generate a series of RDF date properties for a
given location (probably Greenwich, which means I'll start them with the
adoption of the Gregorian Calendar in England in 1752?) of the form
http://namespaces.example.com/greenwich/Gregorian/2003/01/14 and
http://namespaces.example.com/greenwich/HijriYallop/1453/01/14 which have the
sunset time, and pointers to the coresponding date at noon as W3C Date/Time
format.

This makes me think that it would be good to have a foreachURI proprty again,
so that foreachURI http://namespaces.example.com/greenwich/ I can provide
geographic information (latitude, longitude, etc)

What this is good for...

Well, it means that I have a set of explicit properties I can use for days,
and a simple rule (get the sunset time and check the desired time against it)
for converting from one calendar to the other at a given location.

Not all applications are time sensitive - sometimes I will have things
expressed as being in a given month (such as "Marco Polo arrived at the court
of Kublai Khan in september), other times they will be exactly the days
within a given month (There's not much point inviting a muslim for lunch in
Ramadan of any year - although I still need some way of specifying a range of
years that is better than using a regexp in my namespace), but not dependent
on location, and other times they will be a particular time tied to location
for disambiguation (the "Toro Toro Toro" order was given at 6:42 am Hawaiian
local time on 7 December 1941, or more prosaically there will be a
videoconference commencing at 12noon Boston time on 2002/11/14, or the
celebration of Eid el-fatr starts in Melbourne on 1 Shawwal 1426 (this is
like saying New year's day is 1 January) which at noon is the same day as 27
November 2004).

In my final example, the fact that I can get the information that 1 Shawwal
is (at noon) 27 November, and that the time of sunset is listed, means I can
get the gregorian date more widely used in Melbourne. (Tet is another
important day in Melbourne, in yet another calendar that is widely used for a
few things).

First thing that makes me think is that I should actualy be giving the
information in terms of events - 1 shawwal 2003 in Melbourne is an event
starting at 9:45 Melbourne time on 26 November, and finishing at 9:46pm
Melbourne time on 27 November, and vice versa. Which in turn lets me define
dates once per calendar, and then describe the event times as properties of
the place property of the date, since it is rare I think to worry about the
place but not the date, whereas it is normal to do it the other way around.

On Sun, 22 Dec 2002, Graham Klyne wrote:

>At 12:36 PM 12/21/02 -0600, Dan Connolly wrote:
>
>>On Fri, 2002-12-20 at 23:28, Charles McCathieNevile wrote:
>> > On 20 Dec 2002, Dan Connolly wrote:
>> >
>> > >
>> > >Following from our discussion today about the new workspace
>> > >  http://www.w3.org/2002/12/cal/
>> > [snip]
>>
>>[...]
>>
>> > The Gregorian calendar was adopted at different times in
>> > different places.
>>
>>OK, yes, the gregorian calendar sucks. But as they
>>say, it sucks less than everything else. That is: there's
>>an IETF RFC and a bunch of running code that groks
>>the gregorian calendar. The understanding shared
>>by the iCalendar spec readers/writers/implementors/users
>>is what I think we're modelling in
>>   http://www.w3.org/2002/12/cal/ical
>>
>>That schema is grounded in real data coming from
>>real tools, plus a little bit of checking that
>>it conforms to the spec.
>>
>>Hmm... time for a dc:description, I suppose.
>>
>>I'm sorta interested in other calendars, but
>>that's another subject; i.e. I'll change
>>the subject line before going into that stuff...
>
>I started on this thread being fully in accord with your (DanC's) position.
>
>But I think the debate here is important, because it's a decision that I
>believe we have to make now, and can't put off until later, because of the
>way that RDF semantics works.
>
>Suppose we decide that for the time being that we'll assume only Gregorian
>calendars.  And later, some application comes along which genuinely uses
>(say) the Japanese year, which from my experience is widely used by people
>in Japan (if not by software).  Now we're stuck:  we cannot use the rest of
>the schema with a calendarScale="Japanese" tag because that leads us into
>non-monotonic logic.  Specificaly, the model theory [1] subgraph lemma is
>broken, because:
>
>    ex:foo a ical:vCalendar
>      ical:calendarScale "Japanese" ;
>         ical:veventProp [ a ical:Vevent ;
>                           :
>                         ] .
>
>no longer entails the intended interpretation of:
>
>    ex:foo a ical:vCalendar
>         ical:veventProp [ a ical:Vevent ;
>                           :
>                         ] .
>
>[[[Looking at the schema http://www.w3.org/2002/12/cal/ical I couldn't see
>what property links Vcalendar to Vevent, so I made on up based on Libby's
>work.  Also, is it intended that over time we'll replace the ss: properties
>by corresponding assertions of rdfs: properties?]]]
>
>Looking ahead, there may be other assumptions that we want to make in our
>calendar data (e.g. for some scientific data, is it relative to UTC or GMT?).
>
>So, does this work:
>
>ical:calendarScale is a mandatory property for any ical:Vcalendar object,
>whose value is a *resource*, and said resource MAY (in time) have
>properties that encode various assumptions about how the time is
>measured.  For the time being, we define just one URI that corresponds to
>the Gregorian calendar as grokked by current software, and try to document
>(briefly) the calendar scale assumptions that are implied/assumed by that
>software.
>
>Then, if at some future time, we find there is a real software that has
>requirements that are not consistent with the working assumptions of the
>existing software, a new resource URI can be allocated, yet still allow the
>rest of the schema work to be reused (so far as the assumptions
>match).   So, for example, to support Japanese calendars (if I understand
>correctly), a new calendarScale resource would be introduced for each
>Emperor relative to whose reign years are stated.
>
>...
>
>A consequence of this approach would be that any calendar-based inferences
>would have to be stated with explicit reference to the calendar scale
>assumed; e.g.
>
>     { ex:foo a ical:Vcalendar ;
>           ical:veventProp [ a ical:Vevent ;
>                             ical:dtstart "20021230" ] .
>       ex:bar a ical:Vcalendar ;
>           ical:veventProp [ a ical:Vevent ;
>                             ical:dtstart "20030101" ] .
>     }
>     log:implies
>     { ex:bar ex:dayAfter ex:foo . }
>
>(for an intuited meaning of "ex:dayAfter") would not necessarily be a
>universally valid rule.  It would need to be stated as (say):
>
>     { ex:foo a ical:Vcalendar ;
>         ical:calendarScale ical_scale:Gregorian ;
>         ical:veventProp [ a ical:Vevent ;
>                           ical:dtstart "20021230" ] .
>       ex:bar a ical:Vcalendar ;
>         ical:calendarScale ical_scale:Gregorian ;
>         ical:veventProp [ a ical:Vevent ;
>                           ical:dtstart "20030101" ] .
>     }
>     log:implies
>     { ex:bar ex:dayAfter ex:foo . }
>
>#g
>--
>
>[1] http://www.w3.org/TR/rdf-mt/#entail
>
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>
>

-- 
Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409 134 136
SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): +33 4 92 38 78 22
 Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France

Received on Tuesday, 21 January 2003 03:39:21 UTC