RDF calendar schemas - relative times

  Geoff Chappell wrote:

  You could accomplish this also if you had the ability to constrain
event
  start/end times relative to other events start/end times (or to
absolute
  times).

  Have constraints of this nature been discussed at all (or are they
already
  supported in iCal)?

Greg's reply:

The SkiCal group submitted a RELATIVE DATE-TIME property proposal to the
CALSCH WG in '99- and though all basically agreed that this would be of
some value, no action has been taken on this proposal within iCal and
SkiCal people are not even sure we should push the issue

iCal simply doesn't have a mechanism for this.  In iCal you can describe
(using one calendar object) only one event in a machine-readable format.
If you wanted to make known that, for example, "the bar opens 15 minutes
after the game ends" you would insert that text into the DESCRIPTION
field of the calendar object that describes the game. IOW - not really
machine friendly.  And the bar itself could never even publish an object
with "tentative" times of operation, since there is no mechanism for
that either.

The only way to link together multiple events in iCal is to use the
RELATED-TO property - but this merely relates one event (actually the
calendar object pointing to the event) to another - it still does not
let a publisher relate event-times themselves.  

As with many other possible property extensions to iCal this boils down
to a question of scope.  To what extent does the intended scope merit
creating explicit machine-readable values?

Since you can always take any information you please and insert it into
the DESCRIPTION, the question will always be: what is the utility value
of creating explicitly machine-readable property tags?  Who (or what
agents) will make use of this facility?

From my horizon it is a question of strategy.  I believe that we could
be progressing towards a network of universal synchronization between
people, systems and things, but we are so early even imagining this
amazing development that we must proceed soberly and pragmatically -
incrementally if you so will.

The issue will always be - how do you provide for the needs of fine
grained particulars (perhaps important to some) with out encumbering the
utility of the system as a whole.

Of course I am not saying anything new here, this is the old
minimalist-generalist, 90/10 problem inherent in all
system/ontology/schema design. I phrased it this way in Berlin: 

Let's say you have 500,000 painters who only use five colours, but
amongst those you have 50 painters who use 50 colours.  How do you
provide for those 50 without burdening the other 499,950.  If you take
the general expediency of this community as the measure of utility, even
the trivial annoyance for the 499,500 of having to answer "no" to a
question: "Do you want to use more than five colours" might outweigh the
benefit to the 50 of having that option.               

Yes, I believe that even without getting philosophical about the
advantage to the community of actually having the possibility to use 50
colours, there are solutions to this problem, but one must always be
careful that specificities do not inadvertently capsize the boatload of
generalities that are the basis for development. 

Greg

Received on Tuesday, 5 June 2001 07:23:35 UTC