Knowtifacts Required for a Composer Application

As I said in my last post, a Composer is basically a document configurator. Two required inputs for any configurator are a parts catalog and instructions for how to select and assemble the parts to meet the current need. To build a Grant Composer, I needed to design those two knowtifacts  -- first, generic versions capable of generating any type of document and second, specific versions suitable for generating grant proposals.

My high level goal for The Shape of Knowledge -- the book, this blog and the Apprentice Systems website -- is to create an environment where people with knowledge can generate useful applications that embody that knowledge without writing computer code. To achieve this, people must be able to document their knowledge in easy-to-use tools like Microsoft Excel. A spreadsheet is perfect for capturing 'square' knowledge like tables. We created our own tool, KnowtShare, for documenting hierarchical triangle-shaped knowledge like decision trees. Between KnowtShare and Excel (Excel can also capture lines/lists and cubes/3D tables) we've been able to document many forms of important knowledge. The knowledge necessary to create a Composer is two tables, so only Excel will be required.

Then our job at Apprentice Systems is to create the Application Generators - - "apperators" - that can consume this documented knowledge and generate simple but useful applications. This method only works because underpinning the whole process is a highly reusable, generally applicable knowledge pattern that provides discipline and acts as a link between the documented knowledge and the app generator. Yes, two tables are all that's required, but the two tables must meet a consistent set of requirements for the Composer Apperator to work. My task is to design the two tables and identify those requirements.

The first table is the Content Table, and it will act as the 'parts catalog' for my configurator. It will be the comprehensive set of questions and answers that the Composer will draw from to generate a grant proposal. There will be multiple columns in this table, representing the various versions of the content.

The second table is the Sequencing Table, and it will act as the instructions for how to select and assemble items from the Content Table. There will also be multiple columns in this table, providing different sequencing instructions for different potential target audiences.

"To meet the current need" -- establishing the context for a particular document -- will determine which columns to use from each of the two tables. When running the Composer the user will select the version of the content and the target audience for that particular document, and the Composer will generate an HTML document that meets those specifications.

This is the general game plan. The next posts will show how this actually works for grant proposal generation.