[om-list] pattern conversions

[Tom and other Packers]

Chris

    Just to make sure we're on the same page, is this what you're think of?:

    We should write a very high level knowledge-processing program that
would take as input three parameters: (1) a command in its native language
such as "Translate document A from format A into format B", and (2,3) two
other constructs in that same language, namely the descriptions of the two
file formats.  These format descriptions would probably be found in its
general knowledge base, as referenced within the first parameter, the
command; or they could be passed in full as actual arguments, if we didn't
want to save them in the general knowledge base for multiple potential uses.
It would have one output: document B (in format B).

    Would this not be very cool?  We could have many file formats specified,
and be able to use them in reading and writing input and output files.  And
we use this same translater to help itself every time a file format or
language was specified in a known format, such as Backus-Naar (sp?).  It
would translate the file discription into its native language, and then use
it to translate one file into another.  This could be very, very powerful.

    There would be no more hard-coding of formats, which have been a very
bad feature for our Thoughtform programs.  Every time we might want to
change our TSF file format we would need to change all of those implicit
file format reading and writing instructions, which is such a daunting task
that we have only changed the TSF file format once, and most of our
utilities have not even attempted to become compatible with this second
format.  There are so many things I would like to add to our file format,
but right now it's not practical to consider adding these features, even
though they would help our studies tremendously.  These things include
abstract, project-specific knowledge, such as multiple, overlapping and
hierarchical classifications of the waveform epochs.  We could design some
very sophisticated knowledge processing algorithms if we had this
information to work with.

    Back to translation.  Another big use of this power would be in
integrating a lot of various documents, into one homogeneous document, the
first step in semantically integrating a whole lot of information into our
OM information base.

    Another use would be the tremendous power in formatting output, such as
displaying a querry result.  We could print the information we are looking
for in any format we have specifications for, to be sent to this or that
organisation in whatever format they prefer using.

    Next I'll send the letter I sent to Curtis about the other problems I
have with our TF paradigm.

ciao,
tomp

----- Original Message -----
From: "Chris Angell" <christoph at middle.net>
To: <om-list at onemodel.org>
Sent: Saturday, September 01, 2001 5:17 PM
Subject: [om-list] pattern conversions


Hey all,

I thought I'd better at least at a thought or two every once in awhile, so
here it goes.  The language paper was interesting, and helped clear up a few
things I'm working on right now, mainly in picking a language to do a
project
in.  It's been quite frustrating dealing with different data formats, and
interfaces, and languages.  Nothing seems to want to work together.
Therefore I'm quite desirous to create something to get to all work
together.
 So this is what I've been thinking lately (though this has probably already
been said, and may not tie in with om):  I would like a general (global)
format to represent the many different formats and devices I have to work
with.  I think om fits the job perfectly with a knowledge relational space
to
work in.  It would then be simple(simpler) to create a pattern  search
algorithm and take om patterns then convert them to any format necessary.
The translation app (specification) would only have to be done once,, once
the relationship specification between om and any other format is written it
would serve the purpose of being able to translate both ways.  Such a
translation device (format) would be excellent (well, for solving my
problems in my personal projects)    But in moving anything or out of om
space could go beyond just translating docs, but serve as API wrappers, so
you can simply buffer any external API and translate between om patterns and
the API, device drivers for one thing, load in a hardware specification and
automatically have a way of interfacing to the device.  This would desirably
be AI augmented so that it can watch for patterns in the different
translations and giving minimal information be able to create a translation.
Even nicer would to be able to have the AI read the manufacture docs or
format docs and generate an interpretation format based on that.  Is this
possible?  (Any one remember web bots?  They seemed to have died a rather
abrupt death back in 98) As of the moment I don't quite know how to take
this
forward.

-Chris

_______________________________________________
om-list mailing list
om-list at onemodel.org
http://www.pairlist.net/mailman/listinfo/om-list