Dear Matthew, Avril, Doug, Rich, Leo, and Simon, (01)
I accidentally hit "send" before I finished. And upon rereading
what I had written, I realize that Matthew had written "modal realism"
but I had read it as "model realism". (02)
But that's a useful Freudian slip. If we could do a global change
of "possible world" to "model", we would use a term that is familiar
to engineers, and it would eliminate a huge amount of metaphysical
confusion. (03)
In fact, Hintikka had used the term 'model set' to specify what
Kripke called a possible world. Kripke made some important
contributions beyond Hintikka. But if he had used the term 'model'
instead of 'possible world', he would have saved a lot of dead trees. (04)
JFS
>> I would really like to see a quotation from some report at Shell
>> that supports the claim "just how I found the word being used there". (05)
> MW: That is really quite insulting. (06)
I am very sorry. I did not consider that suggestion insulting. I
would never trust my own memory about fine distinctions between what
I and my colleagues had assumed. In fact, I always quote people
verbatim when there is any possibility of misinterpretation. (07)
> Attached is a diagram from training material used to make sure the
> language was being used in the same way to disambiguate terms like
> strategy, plan, mission, vision, objectives and policy. (08)
At the level of detail in that diagram, there's nothing I disagree with.
The term 'possible world' is the source of the disagreement. (09)
JFS
>> When you get to the lowest level details,
>> there is almost no difference between an imperative command (action
>> type) and a precondition-postcondition declaration. You can have
>> a one-to-one correspondence. (010)
> MW: But they are not the same. (011)
True. But the one-to-one correspondence means that you can replace
any action type with its pre and post conditions (or vice-versa)
without making any difference in the sequence of execution or the
results achieved. You can associate a time-stamp with a condition
just as easily as an action type. (012)
Having that flexibility is valuable. Some kinds of actions are much
easier to describe one way or the other. Tying your shoe string is
much easier to specify by the conditions than by a procedure. (013)
AS
> The necessarily inaccessible Lewis' modal realist worlds are fine
> examples of something that the principle of economical
> understandability PEU can clear-cut away, without robbing anything
> away from the intellects. This is because one can get by exactly as
> well or even better without them; if one can get by as well without
> them, then they are not required, and what is not required is an
> unwanted weight (014)
I agree. But sometimes it is useful to consider the realization
of a specification. Calling it a model gives you that option,
but it avoids the metaphysical baggage of possible worlds. (015)
JFS
>>> But I disagree that "a plan is a set of actions". Whether you're
>>> using a 4D analysis or 3+1D is irrelevant to the definition of 'plan'. (016)
MW
>> Well I spent 30 years working for Shell, an organization that lived
>> and thrived by creating plans and then executing them.
>> My usage is just how I found the word being used there. (017)
DF
> I would suggest that even at Shell, a plan is a structured set of action
> templates, not a set of fully pre-described actions. (018)
Yes. And for any physical actions, the instances always contain
an immense amount of irrelevant detail that the types omit. (019)
RC
> The idea of a plan drawing (a la architects) is SO DIFFERENT in
> meaning as to be only lexically similar...
> There is no similarity in meaning, and no commonality, between
> an engineering/architecture plan drawing and a project plan... (020)
The drawings or other specification of the goal to be achieved are
the single most essential part of a plan. Without that, nothing
else matters. A *project plan*, as the adjective shows, is a special
case of a plan that specifies a *project* for achieving that goal. (021)
For an example where the overhead of a project plan is not advisable,
see the comic book on "The Adventures of Task Force Tim": (022)
http://www.jfsowa.com/computer/tftim.htm (023)
And please note that the goal is *not* identical to the final result.
For any physical project, the goal always has far less detail than
the result. It is a type, of which any instance can be considered
a successful completion. (024)
Leo
> In the AI planning community, typically there are 3 phases of "planning"
> 1) planning...
> 2) scheduling
> 3) execution. (025)
That's a good specialization of the meaning of 'plan'. But even in AI,
there are many variations. A robot, for example, doesn't use a
project plan when it must respond within seconds. (026)
Leo
> You might look at Dan Nau's slides on automated planning:
> http://www.cs.umd.edu/~nau/planning/slides/. His first chapter
> takes you through multiple definitions of plan. (027)
Yes, and he does exactly what I recommended: start with a survey
of definitions from a good dictionary. Then he specialized some
senses for his examples. (028)
Furthermore, the AI work emphasizes the pre & post conditions as
the means for deriving the specific action types. (029)
SES
> One thing covered in the book are some of the work that is being
> done to deal with durations where the process can't cleanly be
> separated into those the phases, as the outcome of an action
> may be non-deterministic, etc. (030)
Yes. That's another reason why it's important to be flexible
in the definition of 'plan'. Any plan that deals with the real
world must always accommodate "Murphy's Law" -- something is
bound to go wrong and require an ad hoc fix. (031)
John (032)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (033)
|