Re: Semantic Layers (Was Interpretation of RDF reification)

Hans,

I'm glad that you liked the article.

 > When I read that architecture article I thought:  Wow,
 > I'd like to have that FMF! But at the same time I realized
 > that it would be too complex for "normal" IT persons working
 > in the industry. Grand designs are thoroughly mistrusted in
 > our industry.

Au contraire.  The design is extremely simple from the
developer's point of view.  Each module can be as big or
small as you like, and all it does is to respond to input
messages and generate output messages.  The message format
contains six fields:

  1. Message id.

  2. Sender id.

  3. Recipient id (if blank, the message is posted to a
     Linda Blackboard, where it can be associatively
     retrieved by any module that knows what to do with
     messages that match the patterns it's looking for).

  4. Speech act, which specifies why this message is being
     sent.

  5. Language identifier, so that any recipient can determine
     how to read it or where to send it for translation.

  6. Message in whatever language is specified in #5 for
     whatever purpose is specified in #4.

That's all.  The real power comes from the collection of
modules that are made available.  And for ease of development,
we have a GUI that allows developers to build new modules as
combinations of existing modules or to construct a complete
system (which may be stand alone or a module or both) -- and
you can even have a complete FMF system nested inside any
module.  They can be nested as many levels deep as you like.

And you can even take any existing system and put a wrapper
around it to make it look like an FMF module.  We have already
done that for some relational DBMSs so that any module can
send them SQL queries and updates and get responses from them.
We also have modules that translate RDF and OWL to Common Logic
for communication with modules that process CLIF or CGIF.

Eventually, we are planning to make the FMF platform available
as open source software and to make a business out of building
and selling modules.  Think Lego blocks for computer systems.
We give people a starter kit and make money after they're
addicted -- somewhat like the tobacco companies.

 > ... we really have to do our utmost to hide the complexities
 > of our OWL implementation for "normal" users and IT persons,
 > and still make it maintainable and extendible.

A couple of points:  We have modules for converting Common Logic
to and from CLCE (Common Logic Controlled English):

    http://www.jfsowa.com/clce/specs.htm

So we can let any human monitor the activities of the agents by
reading their messages in CLCE (at least for those messages that
are written in a dialect that can be translated to CLCE or other
humanly readable format).  And the human can communicate with the
FMF modules by sending them messages -- i.e., by using a module
that translates the human GUI or text input to FMF messages.

Modules can run on any operating system, even on cell phones.
You can even take a tiny little sensor and make it a module
that generates messages about temperature, humidity, or whatever
RFID tags happen to be in the vicinity.

Summary:  The FMF can be extended or updated at any time just by
adding new modules or putting wrappers around any kind of hardware
or software.  Instead of embedding "device drivers" into the OS,
you just put a wrapper around any kind of device, and it becomes
a module.  If you don't know what kinds of printers are connected
to the system, you just send a message with a blank recipient id,
and ask "Can anybody print this message?"  But don't tell Microsoft,
because the FMF makes the operating system irrelevant.

John

Received on Thursday, 30 March 2006 01:39:45 UTC