A knowledge base is a container for a set of managed data assets that may change over time based on the actions of an authority. These data assets contain the knowledge of the knowledge base. Structuring the knowledge base as a set of data assets allows each asset to be individually managed, tracked, versioned validates, approved and accepted. This approach carries forward units of management like “files” and “ontologies” so that knowledge is in manageably sized chunks. Anything that is “said” in the knowledge base is said with respect to such a data asset. The knowledge base makes no assumption about the granularity of data assets – they may be as big as an enterprise DBMS or as small as a single business rule. To capture the common concept of a data asset container (or folder) for data assets, a hierarchy of Data asset containers may be used – this is a synonym for a folder in a file system. Use of folders is, however, optional.
Anything that affects the knowledge base begins with a transaction. A transaction is performed by some authority (human or automated performer) that makes (states) a set of coordinated Data asset changes. Note that any speech act (such as a transaction) may state other propositions, including other speech acts Authority and authorization is the subject of another ontology. A data asset change records the authority that stated the changes being proposed that move the asset from one data asset version to the next (prior_version to later_version), based on this change.
Assuming there are no errors or conflicts the data asset change and subsequent transaction is marked as a successful act or a failed act. Note: Structure for reasons for failure still to be developed.
Structured data assets augment generic data asset management by understanding the changes that take place within the asset. For example, in a time ontology it would be recorded that the concept of “timezone” was added. Each such change is a proposition about the structured data asset, stated as part of a speech act.
Consider that we start with a transaction that states a structured data change about a structured data asset. That change will take the structured data asset from one structured data version to the next. The structured data change is a proposition group that states a set of changes about the asset. That set of changes may:
Through these changes every triple in the resulting version should be able to be tracked back to a specific change made as part of a speech act.
As EKB will manage different representations and mappings of data assets when the structure of those assets is understood based on rules about synchronizing those assets. Structured data may have three different representations in the EKB, each of which is considered a separate asset: 1) The “raw” file in some external format. 2) An isomorphic representation of the same information expressed in RDF, but retaining the source files meta model and terminology. 3) A shared concept representation where representations of shared concepts have been normalized.
These different representations of the same information are maintained as separate but synchronized data assets. The mappings between these assets are expressed as synchronization rules and the resulting changes to the assets “data synchronization changes”, based on the following ontology:
A “Shared Concept Synchronization Rule” changes the semantic representation but preserves meaning by mapping the isomorphic model to and from a “shared concept” model. The shared concept model will have those concepts that are defined in the EKB mapped to their normalized counterparts (the shared concepts). Note that subtypes of a shared concept mapping rule may “narrow down” the situation within the shared concept model that is mapped.
Both the isomorphic and shared concept synchronization rules specify what the EKB should do, not what actually happened. When an asset with a synchronization rule is changed is will trigger the synchronization rule to perform the mapping and thus make a change to the mapped asset. Each version of a mapped asset will trigger a corresponding version of each asset it is mapped to. The mapping may be done based on either the changes or a wholesale mapping of the asset.
A “Structured Synchronization Change” records the specific effect of a data synchronization rule that is a result of some other change to a data asset. So when one asset changes it triggers a rule which creates a data synchronization change, resulting in a new version of the synchronized asset. A data synchronization change references a data synchronization rule as its “reason”. This results in a “forward chaining” effect on the synchronized assets.