RE: SUO: ontology as science
I was out with a bad back for the last two weeks, so I
missed some of the discussion and skimmed over other parts.
It seems to me that we are still missing a key ingredient
necessary for successful standardization.
John F. Sowa wrote:
> Rich,
>
> I don`t believe that we disagree. The method of processing
> contexts must certainly be dynamic, but at any instant of time,
> you can represent the current state of the dynamic stack by
> a graph with a nest of contexts.
Agreed; we share the same conceptual imagery of what
a context looks like AFTER it has already been chosen.
My concern is with the choices that map one to one
onto the context stack. Those choices are much less
clear to me.
> In particular, the contexts in conceptual graphs are designed
> to represent the contexts of dynamically changing discourse
> structures in natural languages or the dynamically changing
> frames of a motion picture (which consists of a sequence of
> static "snapshots").
>
> JFS>> I am almost finished with a paper I was writing on Laws,
> >> Facts, and Contexts, which is at the following URL:
> >>
> >> http://www.jfsowa.com/pubs/laws.htm
> >>
I think of the graph as you think of CGs - a (relatively)
static structure that is only incrementally modified by the
disambiguation processes operating on the context stack.
[snip]
> One very important property shared by NLs and by CGs is that
> every step of the dynamic process can be expressed as a well
> formed statement in either NLs or CGs. As new information
> comes in, the current statement might change, but it can also
> be described by another statement in NL or CGs.
>
> Everything you are describing below is fine with me, but I
> don`t know what the abbreviation OOD means.
OOD is "Object oriented design", a programmerese term for
organizing programs into classes, properties, threads,
and the other contexts that we're discussing. This is the
source of "context"s that is most intuitive to me due to
my experience.
One major lesson from the software engineering era was the
need for communicating design of a large system to all
appropriate members of the development team. When a project
gets very large, every context needs to be documented and
the documentation maintained. At one time, DoD Std 2167
was defined to try to get a handle on a standard method
for documenting contexts as CPCs - computer program components -
which could be scalloped into any number of context layers.
OOD was the next step of putting the designs into a standard
object oriented language, but progress faltered there due
to the mismatch between compilable objects and conceptual
objects.
[snip]
> What does that have to do with natural
> language or context or dynamic interpretation of either?
>
> John
Here in SUO/SUMO/CG/CYC land, we're discussing the same
issues. I think the lessons learned on large projects should
be incorporated into the thinking here, but I don't see
anyone else chiming in on it.
The point is that there is so much discussion on the logic
of ontology, on the flow of contexts, and on the selection
of "good" ontologies without assistance from the needs of
communicating an ontology (in my terms, a set of contexts)
into the proper conceptual machinery of people who have to
read and write fragments of the ontology.
For example, the discussions recently on 3D versus 4D versus
temporal logic versus agendae of events. The point ought
to be made that every one of those representations involves
a distinct context, and every one is valid in its own context
for its own purposes. None of them should be disallowed,
required, or dictated as necessary. Many applications will
require a distinct subset of these concepts, but most will
not need any of these things.
The IFF approach has some nice sounding goals, and this is the
only approach so far that seems to deal with contexts at all.
I think we should pay more attention to midwifing the IFF or
declaring it stillborn as appropriate, then get on with the
major issues of context selection.
JMHO,
Rich