W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > December 2002

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

From: Graham Klyne <GK@ninebynine.org>
Date: Sun, 22 Dec 2002 10:42:54 +0000
Message-Id: <>
To: Dan Connolly <connolly@w3.org>
Cc: Charles McCathieNevile <charles@w3.org>, www-rdf-calendar@w3.org

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 

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" ] .
     { 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" ] .
     { ex:bar ex:dayAfter ex:foo . }


[1] http://www.w3.org/TR/rdf-mt/#entail

Graham Klyne
Received on Sunday, 22 December 2002 05:47:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:11 UTC