- From: Greg FitzPatrick <greg.fitzpatrick@metamatrix.se>
- Date: Tue, 5 Jun 2001 13:26:00 +0200
- To: "'www-rdf-calendar'" <www-rdf-calendar@w3.org>
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