August created a highly specialized Metadata Repository and WEB Entry System for NASA.

NASA's Application

NASA's Mission to Planet Earth stores an incredible amount of data and files about the Earth's atmosphere and surface as seen and analyzed from space.  NASA will sell these files on the open market via the WEB.  A prospective buyer will have to enter qualifications to help find what types of files are available, and then purchase.  The qualifications will be compared with the vast stored metadata to find the best matches.  Hence, the metadata had to be somehow entered so it could be available for WEB query.

Each satellite created image and data file is the product of hundreds to thousands of pieces of Metadata.  There are multiple satellites, each satellite has multiple different possible instrument platforms, each platform can have multiple different instruments, each instrument can have a number of different options, settings, and parameters.  Then there are hundreds of processing options.

August's Task

When August was initially contracted, NASA had a MS Word document that defined the data hierarchy, objects and attributes.  Hundreds of pages.  Every time a change to the MS Word document was made, no one was able to know just what had been changed.  So it was nearly impossible to know how to change the database schema and access methods to be in sync with the document.

August suggested the metadata document be made completely electronically.  Then it could be imported into a set of programs that could analyze the differences, make reports, and re-configure the user interface to match.

The Metadata declaration was via an industry standard data migration and interchange grammar, which was then extended to meet NASA's need.  The WEB system after inputting all the parameters could be instructed to output all the information in Object Definition Language (ODL) format.  This is a standard interchange format which allows two dissimilar systems to be able to communicate in a common language..

The various Metadata entry screens were then built "on-the-fly" by reading the declaration grammar. The grammar defined the object hierarchy, components and relationships between objects.  The attributes were defined, as to type, description and cardinality.  It allowed "REPEATS x TIMES", much like COBOL.  Objects were nested inside objects.  So the system only needed to read the data declaration grammar to know exactly what screens needed what entry fields.

August then created a custom Repository for this data.  This repository was portable between different systems, and could be run on Unix or Windows.

Click here to see what a "typical" entry form looked like.  It's a bit complicated, as you will see.

Each "object" could be defined separately and used as a "template"  Templates could be nested, so you could save time be creating quite complex templates that might be 90% of what was needed for a number of similar data entry runs.

An example of unusual behavior, is that a groups of objects could be "optional".   That is, the group of parameters that defined that group could be entered or not.  However, if one of the parameters was input, then several of the other parameters immediately became mandatory.  That is, if the group was to have data, then some of the parameters were mandatory.  If nothing was entered into the group, then nothing was mandatory.

The object was to make a highly complex set of operations a user friendly as possible.  At first this objective seemed at odds.  But the results exceeded expectations.

One of the difficulties of a "prototype" system they were experimenting with, was that it had about 100 different
screens and menus.  No one could remember which screens had which parameters and which menus were needed
to get down to those screens.

If a user decided he needed to add multiples of objects, the form automatically redrew itself, showing the new additional objects that had been specified.  This meant a screen could be 10 pages long, but a single "add object" click could double or triple the size, because an object might contain 7 levels of nested subjects.

Successful Project

So August created a rather novel approach.  Rather than make a system with hundreds of screens and dozens of menus, it created one large data entry screen.  If a user needed to find where a certain parameter was on the form so he could enter it, he merely used the browser's "search in page" function, that is built into the browser.  For example, suppose the entry form he was working on was 30 pages long.  He could do a "in page search" and find his attribute in a second or two.  This approach was so easy  to use, and no navigation between forms was needed.

Since all the data was on the screen at one time, it made it easier for the user to visually inspect the data for correctness.   Of course the entry system did all the mandatory and value range checking, because this data was also specified in the metadata declaration grammar, so the entry system had access to it.

This is an example how August is able to take what appears to be a difficult system and make it easier for the users and for subsequent administration and total life cycle support.