We have a need for a query engine; for the moment let's call it "Query". I described it as two different functions, but as I think about it I think it might be just one. It's purpose is to enable a user to select from a small database the items he or she wants to learn more about. Keeping it simple, its right argument is the database. The left argument are some clues to help the user get started.
The rows of the right argument matrix are equivalent to "items"; let's say they are case studies, or books, or people.
The columns of the right argument are "fields".
RaceMatters.org already has the following fields: 1) Filename, 2) Type, 3) Date, 4) Size, 5) Relevance, 6) Program, 7) Innovation, 8) Provenness, 9) Inspiration, 10) Warning, 11) Author, 12) Publication, 13) Geography, 14) URL, 15) Title, 16) Copyright, 17) Valuetype, 18) Images, and 19) Processkeys.
ProCash has 366 unique input possibilities (many of which can be used repetitively). These will be the basis for developing fields or columns.
Each of the 366 input possibilities has already been coded as follows: 1) numeric identifier for the input array (row of INPNMS), 2) applicable dimension of the input array (0 if vector, 1 for rows, 2 for columns), 3) data: element, row, or column, 4) group assignment (documentation COA ref # for context sensitive help), 5) input type for validity checking (per 8100 64), 6) importance of documentation, warning to user on input complexity, 7) frequency of use: case studies or in judgement of system designer, 8) sequence for listing (or sorting).
Additional fields could indicate which of the 366 inputs are used (boolean for complex arrays, the value for any input which is an element of a vector).
Landev has a structure identical to ProCash, but it only has 201 input possibilities (though many may be used repetitively).
The user should be able to make various sorts of queries. The form that the user is watching will continually report how many items qualify so far. Continuing work by the user will increase or decrease the number of items which qualify (as the user provides words or expressions to expand or contract the list). If a small number of items qualify, they can be presented in a control on the form. If the number of items currently qualifying is large, the user may need to click on a button to see them.
While this may seem trivial, this form should be able to work on a literal matrix. You might think of this as a database with only one field, but from the standpoint of creating the right argument, there will be times when a literal matrix is a preferred format.