The usage of keys (keywords / TAGs / subjects / index terms) is a great and productive thing. But beyond of more than 20...30 keys the application is more and more shilly-shally. And the number of possible combinations, alternatives and variations is growing rapidly.
In order to keep an overview, a key-management is required, that makes the whole key-usage clear. This is increasingly so as more controlled the key usage should be (subject => index term => category system*).
The inEx-explorer offers with the keyPage-System within the scope of the HTML-export an alternative or additional possibility besides the keyManager^ - and with a better transparency compared toward its present level of development (state: version 1.06).
The keyPages are a "solid-state" solution, independent of InterNet connections and server support, lokal usable and also for publishing. An example of this is the experimental inEx-Blog^, where at present a categorical key-system is under development, and may a source for inspirations.
To create keyPages, check the option keySys at the Options-Dialog^ panel "Macros". By a dialog box the position of the keySys-folder will be asked, when a first production is started. This folder must be at the level of the production folder or at a higher part of the path.
By a first production the template file __ix_keytemplate.html will be created. This file can be edited to make additions at the top and/or the end.
At the end of a production, the keySystem can be finalised. The Finalisation updates at all keyPages the complete key overview and the page-local links (register-links), and puts out all now longer referenced qoutes (validate). If there were more than one (source) pages are produced, only at the end one finalisation is needed.
Status of the keySys-Version
With version 1.06.1 the following part (1) is rated as mature, the part (2) as still beta.
1) If the keySystem created completely new (after "Delete keyPages", see main menu "Tools"), there shouldn't be any problems.
2) If source pages are produced again after changes, keyPages might have problems. This assessment based on the complexity of possible situations. In practical application, no more problems appear so far, but will stay to be tested.
The option keyTags, to add TAG-button at the produced pages without a key-system and without links, is not implemented so far.
- Option tagsAtTop: Position of the TAG-line - true = above the item - false = following the item text
- Option tagsPosAuto: less then five TAGs following the text, else above the item
Image: Original item of the production list
: TAG-buttons a) following the text, b) with option tagsPosAuto
The production was realised with Option autoBold
The look of the TAG-buttons can be changed by the CSS declaration (.tag, .tag2) in the template file^, the colour, without colour, bold, italic, etc.
At top of a keyPage - below a maybe added title in the keyPage template - the complete overview of all keys is shown, updated by the finalization. The quotes are present in two different parts, first the alpha-numerical, top-down sorted part, and then the second part, sorted by key-lines (key sorted).
: Top part of a keyPage,
complete overview of all keys (see
The second part contains 2-key and 3-key links and targets (register-links). Useful for quick access, but also to get a quick overview about the used combinations and hierachies for the key-management of conceptual categories.
: Part of the keyPage "mc_blues" shows
the 2-key and 3-key page register (see
Tips and Tricks
As shown in the image above, I use Wikipedia items to create a kind of keyword register without(!) expanding the whole keySystem. And in addition, that increases the information density in each special case by the instant option for deeper research. Wikipedia items (as links or doublets) as childs in a list works like keyword quotations to the list item.
The clarity of the complete key overview can be improved by the use of special expressions for special groups of keys. At the already noted above experimental blog, I use the prefix "nc_" (name space country) for country keys ("nc_usa", ...) and "md_" for keys of media kinds ("md_video", ...). More examples can be found at my private Music Anthologie "theHyperBox.de"^.
What kind of indexation will be chosen depends on the respective task. At the beginning of a indexation, a lot of cases should be handled first, to get a feeling of the specific "space" of the area. With the inEx-explorer it is simple to optimize the "keySystem" over time. Especially with Occam as spiritual companion.
.17.0518 pre-updated ("The keyPage System")