Many processes (scientific, industrial, medical, etc) can be modelled as the movement of information between agents, agents being hardware, software or human entities which can acquire, store, forward, originate, or modify information. It seemed to me that the project might benefit from an attempt to represent our software/hardware design using this model.
I therefore proceeded to define a schema for representing this information flow in the context of a hardware/software system using our Memes tables for the definition of information units. The structural features of the Memes/Mbundles tables enable us to indicate economically that a cluster of memes travel together, thus reducing the amount of data entry needed to describe the complete system.
The Agents table:
agentid int,
aname varchar(20),
atype char(1),
author varchar(20),
lang char(5),
uri varchar(255),
rev char(10),
ref char(12),
rank char(12)
is intended to describe named (aname) agents of various types (atype); in the case of software agents (which is our main concern) we wish to preserve knowledge of the author and language of the agent, its current revision (from CVS or other code control systems) (rev), and a reference (ref) to a particular document section if desired. The URI, as in the Memes table, gives us the flexibility to attach arbitrarily complex additional information to the agent definition. The rank field is a hook left for a feature not yet implemented.
At present only a few types of agents are recognized:
P Person
H Hardware
D Daemon
C Command
T User Tool
We see no need at this point to become more specific.
The flow of Memes between agents is represented by a table Mpaths (Meme Paths):
mpid int,
mid int,
sendr int,
rcvr int,
ctrlr int,
medid char(3),
timid char(2),
formid char(3),
elaps int,
pcontext char(20),
pcomment varchar(255)
Each entry in this table represents an edge in a digraph (directed graph), between two nodes (agents). The meme whose ID is mid travels from the agent sendr (an agentid) to the agent rcvr (another agentid). This transfer has several additional attributes: the medium of exchange, the timing of the exchange, the format of the meme data, and the elapsed time for the exchange to complete. The pcontext and pcomment fields exist to permit the designers to establish families of Meme Paths (for example, those for DEIMOS might be quite different from those for HIRES, though both might use some of the same software or hardware agents since both instruments are built by the same institution) and to attach brief annotations to the paths.
The timid is the ID of a Timing for the transfer. Some information moves on demand; some is transmitted every N milliseconds to anyone who is listening; some is acquired by a cron job or other repeating event; some is available only at startup, shutdown, end of exposure, etc. We would like to know what kind of timing is involved in each transfer. We would also like to know who controls that timing. If the transfer is on demand, who demands it? If the transfer is via a cron job, who establishes the crontab entry? This agent is the controller (ctrlr).
Possible media:
DF Disk File
RD Raw Disk
KE User Key Entry
TCP TCP Connection
UDP UDP Packets
SQL Database Query
X11 X11 Display Server
RS Serial Connection
SM Shared Memory
MT MagTape
PAP Paper Output
FD Floppy Diskette
Possible formats so far:
TX ASCII plain text
HT HTML
LT LaTeX
BD binary data
SD screen display
KV keyword/value data
SC source code
IM image data
DB database table
FT FITS table
DX DXF Mill File
PS PostScript
SQL SQL source
C C source
FOR FORTRAN source
Possible timings so far:
OD On Demand
CJ Cron Job
FI Fixed Interval
SE Start of Exposure
EE End of Exposure
SD Shutdown
SU Startup
A simple example:
Meme definitions (the Memes table bundle) might originate by a human agent, by the medium of Key Entry, typing them into the SQL database (a software agent of the Daemon type) in the format of SQL (insert) commands. This would occur On Demand, the controlling agent being the same human agent.
The definitions might then be acquired from the SQL server, in the form of SQL (select) commands, by a software agent (of the User Tool type) called sbh. This would occur On Demand, the controlling agent being a generic human agent called Tool User.
Lastly, Tool User would acquire the information in the form of C source, in the medium of a Disk File, from the agent sbh. Tool User would be the end of the line.
This would be a three-agent, three-edge path. This very simple example illustrates the most basic application of the schema; however, there is nothing to prevent bundles from splitting (some memes being diverted to one destination and some to another), data paths from teeing (information ending up at multiple destinations from a single source), or feedback loops from being established. Fairly complex information flows can be described by this simple schema.
There are several ways to use such a database. The most obvious is the generation of flow diagrams (a customary inclusion with CDR documents and delivered manual sets). The dot program (part of the graphviz package from Lucent) is quite adequate for our current needs. A simple filter reads the Agents/Memes/Mflow and related tables and generates dot language files which dot processes into clean digraphs in a number of output formats (PostScript is the format we prefer, but FrameMaker MIF, HPGL, and others are supported).
We could also use such a database to calculate total end-to-end elapsed time figures for latency estimates; to establish chains of responsibility to trace backwards when a meme appears to be incorrect or corrupt in the final output (FITS headers or other end products); to determine what information is handled by a specific agent, so as to estimate the impacts of modifying or shutting down that agent; and so forth. As with the basic Memes database, our theory is that one good online model of our information can be used for many productive purposes by many different project members.