View source for Cyc Administrator Handbook/Upgrading

<includeonly>
=== [[Cyc Administrator Handbook/Upgrading|Upgrading]] ===
</includeonly>
<noinclude>
==== Prev: [[Cyc Administrator Handbook/Monitoring Activity|Monitoring Activity]] Home:[[Cyc Administrator Handbook]] Next: [[Cyc Administrator Handbook/Support Components|Support Components]] ====
{{:Cyc Administrator Handbook/Header}}

=== Porting Over Knowledge ===
 When Cycorp releases new version of the Cyc server, these releases usually include updated versions of the knowledge base as well.
 For customers who use the Cyc server for knowledge retrieval over, this poses little or no challenge.
 For customers engaged in active development of their own represented knowledge, this requires that the knowledge developed in the old system be transferred to the new knowledge base and tested for efficacy.
 The transfer of knowledge developed in one KB to another KB is usually referred to as porting that knowledge over. Several strategies exist, dependent on the authoring strategies use.

* Reloading of the authored Knowledge, which comes in two flavors
** Reloading the KE files
** Reloading the transcript files
* Generating and loading an HL partition

=== Generating and loading an EL Partition ===
 The following discussion will refer to the previous release’s knowledge base as the branch KB, that is the point where customer development branched off from Cycorp’s development.
 The end state of that customer development will be called the tip KB.
 The set of modifications that transform the branch KB into the tip KB will be called the change set.
 The newly released knowledge base will be referred to as the target KB.
 The application of the change set to the target KB to produce an updated tip KB will be called re-basing.
 
 Using this terminology, the task of porting over knowledge is to identify the change set from the branch and the tip KB for the purpose of applying that set of modifications to the target KB.
 
 Thus, with every release, the previous target KB becomes the new branch KB for the purposes of the knowledge port entailed with the upgrade.
 
 At the end of a successful re-base, it is recommended to dump new units files that reflect the final state of the new tip KB; see the section on unit file dumping for more details.

=== Reloading Authored Knowledge ===
 In some cases, usually when the amount of knowledge development that was done by the customers is small, the change set may already known and instantiated in a set of files using the KE knowledge authoring format or as transcripts.
 
 In this situation re-basing merely involves loading the KE and transcript files in the appropriate order into the target KB.

=== Using HL Partitions ===
{{to be completed}}

=== Using EL Partitions ===
 EL partitions are best used when porting over knowledge that includes deletions, which HL partitions do not support well, and has a complex or even incomplete audit trail.
 An EL partition is a transcript that is generated by performing a low-level comparison between two knowledge bases where one is the ancestor of the other. For some of the technical details, refer to http://cyc-server:http-port/cycdoc/help/how-to-use-el-partitions.html.
 
 On UN*X installations of the Cyc server, the ${CYC_BASE_DIR}/scripts directory contains a shell script called make-el-partition.sh., which is designed to be run from within the ${CYC_BASE_DIR}. The script takes three arguments:

* the path to the units directory for the KB that is the branch KB
* the path to the units directory for the KB that is the tip KB
* the name of the EL transcript file to produce.

 After the EL partition generation process has completed, the resulting transcript file represents the entirety of the change set. As a transcript file, it can be used to re-base the tip KB as outlined in the section above on re-loading authored knowledge.

=== Using HL Transcripts ===
{{to be completed}}
</noinclude>