Procedural and spatial knowledge and data are important; so important in fact that effective abstractions and tools have been developed to represent and manipulate them. There is a lack, however, of practical tools for the kinds of knowledge on which this thesis focuses.
 This does intend to imply that CODE4 is organized like a brain (or vice-versa!). The analogy is merely that both contain identifiable units of knowledge.
 Of course, machine learning is one of the techniques that can be used to assist knowledge management. This thesis focuses on situations where humans do most of the inferencing, rather than machines. The goal is to facilitate human reasoning processes.
 The metrics are intended to represent a distinct contribution of this research. They are both evaluated in their own right and assist in the evaluation of other features.
 The word property in CODE2 was used differently than in CODE4. In the prior system the idea of property and statement was conflated. The word concept also had a more restricted meaning - similar to CODE4's main subjects.
 Property occurrences correspond to the statements in CODE4.
 The developers of Cyc abandoned graph drawing after networks became too complex, however they apparently did not invest much time in finding ways of limiting the graphs so as to reduce their complexity.
 This meaning of `concept' has a narrower meaning than in this thesis, where concepts also include the `individuals' of description logic languages. Concepts in the latter correspond to types in this thesis.
 The primitive concepts of this thesis refer to something quite different: concepts on which knowledge engine computations depend and must therefore have `handles' to. The primitive concepts of KL-ONE derivatives correspond roughly to concepts in this thesis that are not dependent concepts.
 The defined concepts of KL-ONE derivatives correspond roughly to dependent concepts in this thesis, although the latter term has a somewhat wider meaning. See the glossary for more details.
 Preliminary steps have been taken to do this as a side-branch of this research: Technology to support this is discussed in section 3.13.
 As opposed to relying on the computer to do the processing as is the case in most AI-based tools.
 At implementation time there is a justification for saying that concepts are qualitatively different from classes; classes can then be considered as actual software components containing code and other information. At analysis time, however, what the software engineer specifies as a class is really a conceptual entity that might be implemented as a class.
 Classes correspond to types in this research.
 Or inside a brain or collective consciousness or perhaps some other KR system.
 To prevent confusion, the word `class' is used here as a near-synonym for `type'. This is done because the discussion is at the meta-level, i.e. it is conceptualizing concepts. Confusing sentences like `types are a type of concept' are replaced by sentences like `types are a class of concept' - the word class is thus used only at the meta-level.
 To many people, the word `thing' connotes an object, however English speakers use the word something to refer to anything: e.g. actions: `We must do something' or properties `Something bothered me about that man'.
 Although statements, terms and metaconcepts are created during knowledge base development, these are implicitly added rather than explicitly. For example, a term is added when a concept is named. A metaconcept is implicitly added when any other concept is added etc. These subtleties will become clearer later in the chapter.
 Discussed in section 3.6.
 Discussed in section 3.8.
 Using informal values, as discussed in section 3.6.
 It might be argued that the only users willing to use CODE4 were those that could do their work without mathematical rigour. However, many users would not have been able to use CODE4 if it required mathematical rigour, but they very much appreciated the organizing mechanisms provided by CODE4. CODE4 thus fills a significant niche that is largely empty.
 In this, CODE4 differs from many other knowledge representation systems, e.g. Cyc.
 Concept A would be indirectly declared disjoint from concept B if, for example one of concept A's superconcepts were declared disjoint from concept B.
 This is at odds with the normal English meaning of `concept': e.g. every intelligent Canadian has in their brain a concept of Canada, which is not a type or set.
 A useful extension would be to add an ability to declare that extensions of a set of subconcepts completely cover the superconcepts, i.e. that a categorization is exhaustive.
 Using a typed logic similar to Z (Spivey 1989), where <type> x means that x is of type <type>.
 The quantificational patterns listed are sufficient for almost all knowledge representation. The only exception is when the value should be universally quantified. Currently this must be expressed using an annotation in a facet.
 The discussion here refers to user concepts. Properties, statements etc. are also instances, but this is not standard among KRs in general.
 Another error very commonly made by users is confusing the subconcept relation with the parts relation. Since the normal knowledge-base building methodology involves specifying the inheritance hierarchy before adding any relations, users often specify things to be subconcepts that should be parts. At present CODE4 provides no solution to this problem, but see section 7.3.1 for possible future work.
 i.e. insisting that instances cannot have instances, or that there be only one inheritance rule.
 The concepts are understandable, but this does not prevent important errors from being made.
 An employable thing would be defined to be a thing that can have a job. The user would have to use modality, discussed in section 3.6.2 to specify this.
 Cyc and KM are among the systems that organize slots into hierarchies, however CODE4 adds additional features such as: 1) the derivation of the statement hierarchy; 2) introduction involving strict subhierarchies; 3) the single most-general-subject, and 4) the importance of the property hierarchy in the user interface (chapter 4).
 If this approach is taken often, the tendancy is to create knowledge bases with too many concepts whose sole purpose is to be a most general subject. This can be combatted in the above example by adding friends as a property of living thing, but giving it the modality of `typically not'. This modality would be overridden in the case of those living things that really are sociable.
 "Intension" is often used thus in AI; see (Lacey 1976, p98) for a philosophical discussion of the term.
 Properties are mental (or computational) and descriptive entities. In CODE4 they are not considered to be intrinsic to the real-world entity being described. For example, each user is likely to characterise cars using a different set of properties; furthermore, it is trivially easy to `invent' new properties to describe some latent aspect of a thing, or some obscure relation that one has just noticed. While some definitional properties might be a necessary part of a concept (in a mind or knowledge base), this does not limit a user's ability to endlessly invent other properties for a thing.
 Of course, the hierarchies contain different concepts, but they appear to be in the same relation to each other.
 This problem arises out of the fact that in CODE4 the name of a concept does not identify it uniquely.
 i.e. facets whose subjects are facets.
 They form the arcs in outline and graphical mediating representations discussed in chapter 4.
 Statistics about feature usage are given in chapter 6.
 A term is a kind of concept; a name is a string used to identify a concept (associated with a term); a label is what is displayed on the screen to identify a concept.
 For user instances and types respectively. Properties, statements and terms have their own rules in this regard. When there are multiple parents, the generated labels combine their names.
 The astute reader might notice the following: Since all concepts except the top concept have superconcepts, and since superconcept is a metaconcept property, then one might expect most metaconcepts to be physically created to store superconcept information. Although the system acts as if this is true, in fact properties such as superconcept are primitively managed by optimized mechanisms (see section 3.9) so physical metaconcepts are only created when values of non-primitive properties are to be stored.
 A temporary empty concept is merely a placeholder for a virtual concept.
 These two `tops' do not impose an ontological committment on CODE4 users. The concepts are merely collecting places; users are not forced to do anything with them.
 In older knowledge bases, the terms `statement within self' or `statement in this KB' are used, but users found this confusing so it was changed.
 i.e. non-primitive properties.
 Technologies such as hypertext and personal productivity software, whose strength is in their user interface, are not listed. None of the techniques apply to them.
 In fact some other physical representation could be substituted leaving all the other manifestations unchanged - it would only be necessary to ensure the new representation used the same API.
 CODE4 does provide a number of formats whereby aspects of the knowledge can be printed for publication or study.
 This is analogous to changing whether a cartographical map shows major roads, all roads, railroads, topographical contours, or any combination of these.
 If a property is not inherited by a concept, but is inherited by its metaconcept, then the arcs are defined in this way.
 If no concept is selected in the inheritance hierarchy, then the top-right subwindow becomes a property hierarchy.
 A near-hierarchy is a hierarchy with the possibility of a node being an immediate child of itself.
 These concepts may not yet have anything said about them, so they may not strictly-speaking be called subjects. However, a major purpose of the matrix mediating representation is to allow users to turn them into true subjects by specifying values of statements.
 Knowledge maps for user language mediating representations lack masks.
 Called the `selection criteria' in the system for historical reasons.
 In object oriented terms, a method whose receiver can be any concept.
 Not yet available in the matrix mediating representation.
 Whenever a `>` symbol is the first character typed, the `fast go to' command is invoked instead of the rename comand. To actually give a concept a term beginning with `>` the user would have to type the name directly into the name field at the top of the outline and graphical mediating representions. Normally, users can rename concepts by typing anywhere in the mediating representation.
 Currently only partially implemented. This can also be invoked for any command by holding down the shift key when requesting that command.
 A major area of research in the knowledge acquisition community involves encoding problem solving methods in knowledge bases.
 The branching factor is 2 for a perfect binary tree, 3 for a perfect ternary tree etc.
 i.e. excluding the top concept, which cannot have parents.
 This section should not be confused with an evaluation of how the metrics fared in actual use. Some discussion of the latter type is found in section 6.2.
 There were other users in addition to the participants. These did not actively particpate (filling out questionnaires, being interviewed etc.) because they were busy, their work was confidential etc.
 According to pairwise t-tests.