Joe's GUID dreams vs. a Shoebox

[Ulf Wiger]

On Fri, 14 Feb 2003, Jay Nelson wrote:

>Marked up documents with GUIDs can be neatly organized and
>referenced if you are a little bit meticulous about
>creating things.  I tend to get started on a lot of things,
>but never really polish them enough to be fully organized.

I think this is a pretty common problem.

I will briefly describe the system I worked on eons ago -- a
prototype resource management system for State Troopers and
Disaster Response teams in the U.S.

(A somewhat corny term used in these circles is "Situational
Awareness")

I had two different prototypes:

SA*FE (Situational Awareness Front-End)
-----
This was basically a shallow object database, where all
objects ended up in the main object table, tagged with a
GUID, date-time, latitude-longitude, object type, etc.:

                +--------+
                | Object |
                +--------+
                    |
     +-----------+--+-------------+
     |           |                |
  +--------+ +--------+      +--------+
  | Type A | | Type B | ...  | Type X |
  +--------+ +--------+      +--------+

(the sub-tables could be a collection of tables per type;
this was managed by the access interface for each object
type.)

The system had a GUI, where one could register different
maps. Objects could then be placed on the map using
drag-and-drop, or move around on the map based on e.g. GPS
coordinates coming in through a serial feed etc.

There was also a link table, where any object could be
associated with any other object. Each object had a generic
link list, and to associate two objects, you grabbed one
object and dropped it onto the link list of the other
object. Using container objects like "task force",
"investigation", etc. we could assemble a team, throw in
people, cars, material, etc. and then drag the whole task
force onto a map. The general idea of e.g. having an
"investigation" container was that you could follow the
links to associated events, documents, etc., and these could
in their turn be linked to other investigations, and so on.

SA*MS (Situational Awareness Messaging System)
-----
This was a flexible messaging backbone designed to glue
different systems together and feed the front-end systems
with relevant information, as things happened. Status flags
information source, and priority were obvious information
elements. Fault-tolerance, responsiveness, flexibility,
distribution were obvious requirements. It was when trying
to design this that I came across Erlang.

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes