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

Each metadata template represents an event in the RTS, where an event is typically something that happens to a template.  We currently recognize three major things that happen to a template: insertion into the RTS, invalidation, and re-validation.  We describe these events below.  Also, assignment of an instance unique identifier (IUI) is something that happens in the RTS.  Currently, these events 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 EV parameter for event type and the EC parameter for error code.  

The EV parameter

The EV 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 "event 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 EC 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 a template insertion or revalidation.  It would be required for any metadata template with an EV parameter with value X.

The CR parameter

The CR (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 study erroneous beliefs from errors in recording those beliefs.