We propose to reformulate metadata templates such that they represent changes that occur within the RTS.

Each metadata template represents a change in the RTS, where a change is typically something that happens to a template.  We currently recognize three major changes that happen in an RTS: insertion of a template into the RTS (essentially creation), invalidation of an existing template, and re-validation of a template (that was previously invalidated).  We describe these changes below.  Also, assignment of an instance unique identifier (IUI) is something that happens in the RTS.  Currently, these changes are captured in A templates.  At this time, we do not propose to change how IUI assignments are captured as A templates.

The original formulation of metadata templates has a parameter, the "error or insertion" code (E), whose semantics are mixed.  If you are inserting a template for whatever reason, the E code is set to the value I for "insertion".  If you are correcting an error, then the E parameter codifies what type of error exists in the RTS that makes the template false (even if the error originates with another template.  For example, a duplicate IUI assignment in an A template causes a PtoU template to be incorrect, but in inserting a metadata template to correct the PtoU template, you assign the E parameter the value U5).

Note that we never change or update any parameter in a template or metadata template in an RTS.  To correct errors, we insert new metadata templates.  This practice enables us to view the state of the RTS as it was at any time in the past.

The Proposal

We propose to remove the E parameter from metadata template specification, and replace it with two parameters: the CT parameter for change type and the EC parameter for error code.  

The CT parameter

The CT parameter may take 3 values, defined as follows.  It is a required field in the metadata template.

A template may be invalidated then revalidated and subsequently invalidated again and etc. any number of times through the history of the RTS.  There will be a new metadata template for each insertion, invalidation, and revalidation.

The original metadata template specification did not envision the possibility that assertions that templates are in error might themselves be made in error.  And thus there was no mechanism to restore templates mistakenly asserted to be in error.  Thus the "change view" has improved the flexibility of RT.

One disadvantage to this approach is that to query "good" data in the RTS, the query must check disjunctively for the values I and R in the CT parameter.  Alternatively, we could add a flag to the templates themselves that determines whether they are valid.  This flag would be set to true upon insertion and revalidation, and to false upon invalidation.  The disadvantage to that approach is keeping the flag in synchronization with the information in the metadata templates in the RTS.

The EC parameter

The EC parameter takes the same values as the original E parameter except for the value I (insertion).  It is not a required field in the case of template insertion or revalidation.  It would be required for any metadata template with an CT parameter with value X.

The C parameter

The C (change reason) parameter continues to exist as before.  However, we replace error correction (XM) with error recognition (XR) as an allowed value.  

Consider an incorrect PtoU template asserting that a particular chair is an instance of Table.  The error was in asserting this PtoU template, not in inserting it into the RTS.  Thus, the error was made on the part of the entity designated by iui_a (in the PtoU template).  Now either this entity (1) really believed that the chair was a table for some reason or (2) made a mistake in picking out a reference to the type Chair (e.g., said "table" when she meant to say "chair" or selected "table" from the dropdown list when she meant to select "chair").

Now, if the entity correcting the error is the same entity as the iui_a of the template with the error, then there is the possibility of both change in belief (really believed it was a table when she made the PtoU assertion) and recognition of error (never believed it was a table but just picked the wrong reference somehow).

If the entity correcting the error is a different entity, the same two possibilities exist: the entity may have shared the incorrect belief or it may just have recognized the error (and not have believed it was a table).

We cannot assume either.  The remaining question is whether it is worth making the distinction?  It would certainly be helpful in the grand scheme of things to capture both, so we could differentiate erroneous beliefs from errors in recording those beliefs, so that we could study them.

The allowed values for C are therefore the following:

Implications for Remainder of Metadata Template

Possible Combinations of Parameter Values