Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: Re: ontology as science




o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

Richard Cooper wrote:
> 
> Thanks Jon, I would like to see any material capable of
> simplifying context, scope or other similar structuring.
> 
> Since you're still writing your dissertation, that
> probably means you're looking at things from a very
> theoretical viewpoint.  I know I did, and I kept it
> for several years after my dissertation was completed.
> It would be helpful if you wrote, for each paragraph
> of theoretical work, a subsequent paragraph explaining
> the same thing in conversational mode.

It's really a capstone (tombstone?) thing, where I've gone back to
try and synthesize old projects from Math and Quant Psych days
that I did get to finish up the first 3 or 4 times around --
In Systems Engineering, so it's okay to be "pragmatic".

Here's an old version of the Introduction:

http://members.door.net/arisbe/menu/library/aboutcsp/awbrey/inquiry.htm

See especially the following Subsections:

1.3.4.11  Review & Prospect
1.3.4.12  Objective Plans & Levels
1.3.4.13  Formalization of OF:  Objective Levels
1.3.4.14  Application of OF:  Generic Level
1.3.4.15  Application of OF:  Motive Leve
1.3.4.16  The Integration of Frameworks

"OF" is for "Objective Framework" -- But read it in the sense of "Objective Lens".

I'm told this is a real crapola as HTML.  Can send Word Doc, if you want it.
And as I already said, this whole segment is badly overdue for a re-write.

Jon Awbrey

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

> Any such contribution is appreciated.
> 
> Thanks,
> Rich
> 
> Jon Awbrey wrote:
> > o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> >
> > Rich,
> >
> > There's a part of my onoing dissertation draft
> > that is designed to handle this sort of issue.
> > It's a bit too repetitively written because I
> > actually came at what is pretty much the same
> > structure from 3 different directions without
> > noticing the convergence until the last moment.
> > We followers of Peirce, of course, have no ideas
> > that we can call our own, and this one is really
> > just another variation on dominant Peircean themes,
> > in particular, the idea that sign relations are the
> > adequate, necessary, and sufficient contexts for all
> > practical accounts of semiotic processes, including
> > as special cases:  computation, dialogue, inference,
> > information, inquiry, logic, reasoning, and thought.
> >
> > I will maybe see about putting some excerpts on the Ontology List,
> > if I can stand to do that without having to re-write the whole mess.
> >
> > Jon Awbrey
> >
> > o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> >
> > Richard Cooper wrote:
> > >
> > > John F. Sowa wrote:
> > >
> > > [snip]
> > > > Cyc supports contextual differences with microtheories, and
> > > > we need a similar modular mechanism in any proposed SUO.
> > > >
> > > > John Sowa
> > >
> > > I've read the Cyc stuff about microtheories, but it isn't
> > > exactly a piece of tutorial elegance.  IOW I don't understand
> > > the motivation behind it, the broad points of implementation,
> > > or the alternative choices that could have been made instead.
> > >
> > > Certainly context is specific to a conversation, or a problem
> > > to be solved, or a lesson to be taught.  But isn't context
> > > also decomposed into other (sub)contexts pretty much like
> > > OOD handles scopes?  The present OOD methodologies don't deal
> > > well with scopes, using the dot notation to reach any object
> > > from any other object.  This isn't a very good solution
> > > because many separately designed units have to have access
> > > to nearly all the other units in a large program.  Polymorphism
> > > is a start at improvement, but only just barely.
> > >
> > > It would be nice if there were a more formal way to represent
> > > contexts, nestings, decompositions, and so forth.
> > >
> > > In XML, the namespaces are no better than in OOD.  I know of
> > > no existing solution to this problem, but it lies at the heart
> > > of the exponential nature of software testing and debugging.
> > > A change in one unit can cause zillions of changes in other
> > > units because references from the other units are not very
> > > transparent to the design of the changing unit.
> > >
> > > Does anyone have a better solution they're willing to share?
> > >
> > > Thanks,
> > > Rich
> >
> > o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o