CCAT: OBJ/EVENT/PROC:Deadlines and STATE
fritz@rodin.wustl.edu (Fritz Lehmann)
Date: Mon, 10 Oct 94 20:40:19 CDT
From: fritz@rodin.wustl.edu (Fritz Lehmann)
Message-id: <9410110140.AA17909@rodin.wustl.edu>
To: abrewer@Glue.umd.edu, cg@cs.umn.edu, srkb@cs.umbc.edu
Subject: CCAT: OBJ/EVENT/PROC:Deadlines and STATE
Cc: M.J.Johnson@qmw.ac.uk, anquetil@IRO.UMontreal.CA,
beancar@cucis.cis.columbia.edu, bill@violin.att.com,
billrich@vnet.ibm.com, brayman@zuben.ca.boeing.com,
buteau_brandon@prc.com, cassidy@micra.com, cbwillis@netcom.com,
cyre@vtvm1.cc.vt.edu, dick@Glue.umd.edu, doudna@aol.com,
doug@csi.uottawa.ca, fletcher.mcleancsd@xerox.com,
fritz@rodin.wustl.edu, ged@cs.rmit.edu.au, gerbe-o@immedia.ca,
grau@falcon.depaul.edu, kivs@bgcict.bitnet, kremer@cpsc.ucalgary.ca,
kschoi@cs.kaist.ac.kr, lukose@peirce.une.edu.au, moulin@ift.ulaval.ca,
oh@vax2.cstp.umkc.edu, peterman@informatik.uni-hamburg.de,
phayes@cs.uiuc.edu, roger@ci.deere.com, s.griffin@mcs.surrey.ac.uk,
shmyaeng@mailbox.syr.edu, sowa@turing.pacss.binghamton.edu,
thompson@zuben.boeing.com, wei@oucsace.cs.ohiou.edu, willems@cs.vu.nl
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk
Allen E. Brewer <abrewer@wam.umd.edu> wrote on the definition of a
STATE (in the sense of STATE-OF-AFFAIRS) as follows:
>Subject: RE: TIME and STATE
>Fritz wrote -- begin quote-----
>What I was trying to get at is that a _change_of_time_ does not
>change the state. Something else, other than the passage of time, is
>needed for a change in state.
>[. . .]
>-----end quote-----
>QUESTION 1
>In a contracting environment, specifically under the Federal Acquisition
>Regulations, it is possible for time to cause a change in contractual state,
>depending upon how certain clauses and combinations of clauses are
>interpreted.
>-----begin FAR quote---- 48 CFR Ch. 1 Part 52.249-8 [extract]
>DEFAULT (FIXED-PRICE SUPPLY AND SERVICE) (APR 1984)
> (a)(2) The Government's right to terminate this contract under
>subdivisions (1)(ii) and (1)(iii) above, may be exercised if the
>Contractor does not cure such failure within 10 days (or more
>if authorized in writing by the Contracting Officer) after receipt of
>the notice from the Contracting Officer specifying the failure.
>-----end quote-----
>[Details omitted]
>In this case the state of the contract changes by action of the
>cure notice and may again change based upon:
>a) action of the contractor
>b) action of the Contracting Officer
>c) passage of time
>Thus if nothing else occurs, where a contractor is given a 10 day "Cure
>Notice" under the above cited clause, the state of the contract automatically
>changes. A termination causes a new Contracting Officer to be appointed,
>and a number of other issues are initiated by the "running of the clock."
>How does this fit into the thinking on time representation, and states,
>where a contract is in State-1 pending one or more of a number of
>possible circumstances which cause transition to State-2, State-3,...
>where one of the states is triggered by passage of time, and the
>passage of time is relative to an event (receipt by the contractor)
>whose time is not necessarily deterministic when the contract
>enters State-1 ?
Well, this certainly makes my earlier statement seem false, and it
raises several interesting and subtle issues. A Petri Net representation of
the contract state would have state-transitions triggered simply by the
passage of a deadline. I think the CCAT/TIME ontology should indeed be able
to handle deadlines correctly. To me, the question is, at what level of
ontology do such deadlines "exist"?
It's interesting to transfer a problem like this from one domain to
another. The original Cyre-Hayes discussion was on states in digital timing
diagrams. What is a "deadline" in such a world? I see states lasting quite
a while in digital systems. If the digital system is "clocked", however,
this means that the persisting state is really only a partial description;
any continuing "state" is actually disregarding part of the total available
state, namely the changing clock pulses. Even if clock pulses are detected,
a deadline condition will not occur unless something is actually counting
the elapsed clock-pulses, and not unless there is furthermore a _test_ of
the count against a known value to set a "flag condition".
Now take this apparatus for deadlines and lift it back up from the
world of digital timing to the world of government contracts. First, the
mere passage of time has no effect unless the system is aware of it; this is
normally unstated because it is assumed in a legal system that the passage
of time is universally known by everybody (or at least that it reasonably
should be known). Then, what are the "clock" and the "counter"? I think it
turns out that literally the "clock" is the official atomic standard clock,
and the "counter" is the international standard system of dates and times.
(It is noteworthy that Pat Hayes' proposed base ontology for CCAT/TIME
includes clocks.) Then, the "test" and the "flag" condition: this involves
the people in the legal system and their representation of time and
obligation. (In CCAT this involves the REPRESENTATION/SEMIOSIS subgroup.)
Assume the government is a "composite person" with information and
obligations. The government's obligation to honor the contract depends on
numerous conditions (legally defined); its representation of the contract
state (which will causally govern physical human behavior of government
agents) depends on the information known to it. The government is always
capable of answering the question of what date it is; it has available a
"test" and "flag condition" for DATE/TIME (specifically, one or more persons
in government keep track of the date and time). Thus the actual "state" of
the whole information known to the government does not persist in time (for
more than a second, anyway). So long as DATE/TIME information is available
to the government, the issue of "whether a certain deadline has passed" is
part of its state.
The upshot of this seems to be that you and I may both have been right
about STATE: At a primitive level the mere passage of time does not alter
STATE, but if a system has access to a clock/calendar then it technically is
in a different STATE with every passing clock tick, and no state that
includes this information persists more than one tick. The STATE that you
describe for a government contract is not the _whole_ STATE but "the STATE
'modulo' irrelevant differences" where 'modulo' means disregarding certain
distinctions within an equivalence-class. For example, second-to-second
changes in STATE don't matter to contractual obligation, except at the
boundary points (usually midnight) of a legal contract period. If so, the
CCAT ontology should make this fact explicit.
>QUESTION 2
>There are any number of circumstances in contract schedules where a date
>is specified as EVENT + time_period, where the event might be completion
>of, or delivery of, or acceptance of, a product, service, etc. Retrospectively
>it is possible after the specific event has occurred to compute a time period
>from that point in time, however, in the case of delivery schedules which
>are based upon a sequence of receipts, and where the contractor is at risk
>for additional performance prior to acceptance of prior performance and
>where typically acceptance does not occur simultaneously with receipt,
>the delays caused by the contractor waiting for acceptance before proceeding
>with a program will generally not fit within the scope of "excusable delays"
>and might result under some circumstances in creating an opportunity for
>the Contracting Officer to terminate the contract for default for failing to
>perform in accordance with the schedule.
>In this case, the contractor must be able to reason about the risks associated
>with incurring cost prior to acceptance, and the risks of termination for
>default if performance is delayed until acceptance is received to identify
>critical time points for: (1) entering into discussions with the Contracting
>Officer for changes in the delivery schedule; or (2) for accepting the risk
>of performance without receipt of acceptance for prior work. How would
>this case fit into the time representation issues under discussion?
I don't think this example places any special burden on a time
ontology. An "ordinary time-line" can be used in the decision-making of the
contractor. The decision depends on the priorities of the contractor (such
as risk versus reward) and the bargaining strength of the parties (if the
contractor's position were stronger, the government would not push it around
this way and deem sensible risk-aversive delays "inexcusable"). This has
nothing especially to do with time.
>Admittedly these are fairly mundane examples, but they are genuine
>concerns in building a system which can provide assistance in contract
>administration by reasoning about the possible states of a contract,
>during the life of a contracting action and represent issues which
>are faced by contractors frequently.
>Allen Brewer
>abrewer@wam.umd.edu
Not too mundane for CCAT! Your first question isn't mundane at
all, since it raises subtle and important issues, and if it were mundane
it would still be appropriate for CCAT because the very thing we are
trying to do is represent common-sense (mundane) knowledge that is often
obvious to people but unknown to computers. Yours is really an ideal
type of question because it brings in an important idea from a practical
field that the deep ontologists may have forgotten to consider.
Yours truly, Fritz Lehmann
GRANDAI Software, 4282 Sandburg Way, Irvine, CA 92715, U.S.A.
Tel:(714)-733-0566 Fax:(714)-733-0506 fritz@rodin.wustl.edu
=============================================================