Subject: Re: Fuzzy Logic

From: "Frank Dawson/CAM/Lotus" <[email-masked]>
Date: Mon, 23 Aug 1999 09:51:16 -0400

Greg:
You raise two types of examples:

1. Priority rating of event "A" over event "B".

2. Scheduling event "C" on Monday versus Friday.

The current iCalendar proposed standard provides for case #1. You can set
the PRIORITY property for a calendar component, such that one component has
a higher priority than another.

Case #2 involves not just calendar information/representation, but also
scheduling semantics, for say, a meeting invitation. Currently, the iTIP
proposed standard provides for negotiation of a meeting date/time via the
COUNTER/DECLINECOUNTER methods.

The current negotiation methods mimics existing practice in LAN-based
calendaring and scheduling systems. Scheduling meetings over the Internet
can introduce new conditions that may indeed necessitate studying other
approaches to scheduling workflow.

My pattern recognition knowledge is twenty years old, so it is somewhat out
of date. However, back then the use of "fuzzy" logic implied values other
than "1" and "0" for decision tables. For example, for the question "Is the
pixel inside the polygon?", the values could be "TRUE", "FALSE" or "MAYBE".

With "fuzzy" scheduling, I was applying the term to refer to the
specification of DTSTART and DTEND (for a VEVENT) and DTSTART and DUE (for
a VTODO) properties with either a value or a parameter value that lent
similar "fuzziness". For example, you might specify an event start time
with the additional parameters for "meeting buffer" for travel arrival and
departure of participants, "schedule range" for providing participants a
priori knowledge of permissible alternative meeting times. This might look
like:

   DTSTART;TZID=US/Eastern;SCHBUF=PT0H30M00S;SCHRANGE=19990920T083000/19990924T133000:

    19990920T083000
   DTEND;TZID=US/Eastern;SCHBUF=PT0H30M00S;SCHRANGE=19990920T093000/19990924T143000:

    19990920T093000
   PRIORITY:1
   STATUS:TENTATIVE

For a scheduled one-hour, Monday, September 30th 8:30 AM US/Eastern time
zone meeting that would allow a 30 minute buffer before the actual start
for participant travel and a 30 minute buffer at the end of the meeting for
participant departure. In addition, for a participant wishing to propose a
counter date/time, the Organizer is indicating that any date/time up to
1:30 PM US/Eastern, on Friday, September 24th would be acceptable for the
new start of the meeting and likewise, any corresponding one-hour date/time
up to 2:00 PM US/Eastern, on Friday, September 24th would be acceptable for
the new end of the meeting. The status for the meeting is still TENTATIVE,
pending a later reconfirmation from the Organizer.

While this functionality precisely specifies a set of DTSTART, DTEND,
PRIORITY and STATUS values, it also introduces a level of "fuzziness" to
the meeting invitation. This "fuzziness" is not based on the lack of
concrete values or ambiguity in the VEVENT definition, but rather is
indicated using parameter values that convey "fuzzy" semantics in the form
of flexibility in scheduling of the event. That is, the meeting definition
has precise specification, but includes additional information that a
participant can use to "intelligently" propose a counter proposal for the
meeting start/end date/times.

The last thing that we need to introduce into calendaring and scheduling is
ambiguity in property values. Rather, we need to convey the flexibility
that an event, to-do or journal entry may have with respect to its
confirmed scheduling.

-- Frank

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 24 Aug 1999 16:11:37 +0200

Frank

I am sure that this is not the time for a fuzzy discussion about fuzzy
logic.  I was just picking up on your comment.

Earl Cox has asked for some more background on our work and I have sent him
some URLs.  He says he would like to make some comments to the list which I
for one would welcome, in the event the experimental WG gets in to
operation, I am sure these would be of value.

I do not believe one should call our request for scheduling times an attempt
to introduce ambiguity into property values.

Greg

>  Frank Dawson wrote: