Technical Documents

Increase your system's agility with the KML Importer Wizard

Change Management

Authority provides built-in support for rule versioning and change management. Every version of model and content information managed in a knowledge base, including rules, modules and concepts is maintained within a knowledge base, including original versions and each intermediate version. For each piece of model or content information, there exists a current version or the last version which was deleted. In addition, each piece of model or content information has a state in the workflow of managing knowledge, such as draft, pending review, approved for production, etc.

In addition to built-in versioning and workflow within a knowledge base, Authority supports interchange for sharing and updating content across multiple knowledge bases. Authority allows selective export and import of models and content between knowledge bases using XML. The XML exported and imported by Authority conforms to the Knowledge Management Language Schema (KML).

Using KML interchange, distinct knowledge bases can share all or parts of their models (e.g., an upper ontology) or content (e.g., modules of rules shared across multiple applications). KML interchange also allows fixes found in QA or patches made in production to be efficiently retrofitted into upstream knowledge bases during the application development process.

Export, Import and Merge

Importing KML exported from another knowledge base (or created externally) is supported by merge functionality that allows specific elements (i.e. a module or concept) or bulk content to be accepted into the importing knowledge base. When accepted, an update either adds new content or changes existing content. In addition, accepted updates may delete existing content. All are subject to Authority's comprehensive permission and versioning within the importing knowledge base.

The benefits of this sharing are:

• Ability to have parallel work in separate knowledgebase that can be captured, saved, and shared.
• Packaging and collaboration of rules among separate knowledge workers or environments.
• Share knowledge and leverage knowledge bases as libraries, whether departmentally, organizationally or industry-wide.

In addition, the import with merge is enabled with a conflict resolution feature where users will be given an option to resolve conflicts directly or set preferences to solve automatically.

With regard to merging, Authority will:

• identify imported additions from the merged knowledgebase (e.g., constructs that are not found in the knowledge base).
• Identify imported constructs are already in the knowledge base. Users will be given an option to resolve conflicts directly or set preferences to solve automatically.
• Identify any items that may have been deleted (e.g. not found among the imported constructs).

KML Importer Wizard - High Level Overview

Via use of Haley's Knowledge Markup Language (KML), HaleyAuthority supports importing and exporting (including merging) of concepts, relations, dictionary entries, phrasings, procedures, templates, modules, statements, and other knowledge base constructs via XML files in accordance with a documented XML schema definition (i.e., Haley's Knowledge Management Language XSD).

The KML Importer is a plug-in that takes a KML file and updates the knowledge base based on the contents of the knowledge base and the KML file. After identifying the additions, changes, and deletions that need to be resolved, the importer allows user interaction in order to identify how to resolve the differences.

The KML Import Wizard is crucial in the development life cycle and in supporting a shared model across multiple knowledge bases. When importing an XML file, the KML Import Wizard will ask about which constructs to add or update from the source and delete from the destination. The KML Import Wizard primarily leverages GUIDs, generated by HaleyAuthority, to identify when objects are the same, but is also aware of primary key constraints that indicate that two objects must be the same even if they do not share the same GUID, e.g., there can only be one noun named "person".

The following constructs can be identified:

• a dictionary entry, which is either an abbreviation, acronym, adjective, adverb, conjunction, determiner, preposition, noun, or verb
• a dictionary entry relationship
• a custom field and a custom value
• a concept, a relation, an instance, an is-a-kind-of relationship, and a fact
• a phrasing
• a data type, a procedure, a template, an attribute, and a library

Although phrasings are distinct from the concepts, instances, and relations that they are attached to, a user does not consider them as separate constructs. Thus, the importer treats them as one unit.

Best practices for managing the life cycle of a knowledge base

The KML Import plug-in can be used to support the life cycle of a knowledgebase across different versions of an application as follows:

• Create a knowledge base.
• In traditional source control systems, branching is used to introduce a new code line. Essentially, branching copies one or more files. If the knowledge base is maintained in Access, then the source control's branching mechanism suffices by copying the Access file. If the knowledge base is stored in something other than a file-based database, then HaleyAuthority's copy knowledge base mechanism is required.
• Merging is used to integrate changes from one line into another. HaleyAuthority provides an export/import mechanism to accomplish the merge as follows:
• export the source knowledge base as an XML file, and
• import the XML file into the destination knowledge base using the KML Import Wizard.

Best practices for supporting a shared model across multiple knowledge bases

The KML Import plug-in can be used to support a shared model across multiple knowledgebases, as follows:

• Create a knowledge base using HaleyAuthority for the shared ontology and develop the initial ontology.
• To create a new knowledge base that leverages a shared ontology, create a new knowledge base, export the shared knowledge base to an XML file, and import the XML file using the KML Import Wizard, accepting all of the new constructs using HaleyAuthority.
• To update a knowledge base with changes from the shared ontology, export the shared knowledge base to an XML file, and import the XML file into the knowledge base using the KML Import Wizard using HaleyAuthority

• To update the shared ontology with changes made from another knowledge base, export the knowledge base to an XML file, and import the XML file into shared ontology using the HaleyAuthority's KML Import Wizard.

  Identifying constructs could be added, updated, or deleted

  The KML importer can to determine whether

  • a construct needs to be added to the destination
  • a construct in the destination needs to be updated from the source
  • a construct needs to be deleted from the destination

  in order to bring the source and destination into conformance. If a construct in the source does not correspond to a construct in the destination, then the construct in the source will be added because

  • the construct was added to the source without being added to the destination, or
  • the construct was deleted from the destination

  If a construct in the source corresponds to a construct in the destination then the construct in the destination will be updated from the construct in the source or the construct in the destination can remain unchanged because

  • the construct was modified in the source and/or destination

  If no construct in the source corresponds to a construct in the destination, then the construct in the destination could be deleted because

  • the construct was added to the destination, but was not added in the source, or
  • the construct was deleted from the source, but was not deleted in the destination

Determining whether to add, update or delete

Since a user may wish to augment the destination with constructs from the source, to remove constructs from the destination that are not in the source, and/or to update constructs in the destination from the source, the importer will establish preferences at the beginning of the import process to determine whether or not additions, deletions, and/or updates should be considered. Furthermore, if updates are to be considered, then the importer may be configured to favor the source, the destination, or the most recent version.

With regard to updates, the wizard will prefer updating a construct in the destination from a construct in the source:

• only if the construct in the source could be updated from a construct in the destination
• unless the constructs are identical
• if the source is preferred over the destination
• if the construct in the source was modified after the construct in the destination
• unless the destination is preferred over the source

Likewise, the wizard will prefer retaining a construct in the destination that corresponds to a construct in the destination:

• only if the construct in the source could be updated from a construct in the destination
• unless the constructs are identical
• if the destination is preferred over the source
• if the construct in the destination was modified after the construct in the source
• unless the source is preferred over the destination

Preferences are merely used to establish defaults and user interaction should typically be used to make the final decisions.



Displaying objects

In order for interaction to be effective, the objects in question are identified for the user with sufficient detail for comparison and selection to take place. A rendering into text for each object shows all the properties of the object. For example, in addition to its simple properties, a concept shows its generalizations, specializations, phrasings and instances.