...
| Name | Abbreviation | Description |
|---|---|---|
| assignment | A | Captures the assignment of an IUI to a particular (or instance) |
| particular to universal | PtoU | Captures the assertion that a particular, identified by an IUI, is related to a universal by a particular relation. It is typically used for the instance of relation. |
| temporal entity | Te | Captures the assignment of an IUI to a temporal entity, as well as the basic type (interval vs. instant) of the temporal entity. This template is a "shortcut" combination of assignment and particular-to-universal for temporal entities. It and the Ten template help to reduce significantly the number of templates needed to capture temporal entities and their names. |
| temporal entity name | Ten | Captures the name of a temporal entity (e.g. "2013-10" for the month of October in the Gregorian Calendar according to the ISO 8601 standard). Names of other entities are explicitly represented with an A template (assign IUI to name), a PtoP template (relate name to the entity it designates), and a PtoDR template (relate name to its concretized form). |
| particular to particular | PtoP | Captures the assertion that two particulars are related by a particular relation such as part of. |
| particular lacks universal | PtoLackU | Captures the assertion that a particular lacks a specific relation r to any instance of a universal. |
| particular to concept | PtoCo | Captures the annotation of a particular with a concept from a concept-based terminology. It does NOT assert that the particular is an instance of a given type (or universal), is related to other particulars by specific relations, or lacks a relation to any instance of a given universal. |
| particular to digital entity | PtoDE | Captures the relationship between information content entities and their concretization as an encoded string of binary digits. Note that the purist way of doing things would be to assign an IUI to evey unique character string in some set of characters. But since each such unique string can serve as its own identifier, it seems very inefficient. Trying to keep two or more RTSs in synch so that they all have the same IUI for the string "befuddled" would be befuddling indeed. |
| metadata | D | Captures data about templates. More formally, we have reconfigured the metadata template to represent an event that occurs inside the RTS itself. |
...
| Anchor | ||||
|---|---|---|---|---|
|
Per our metadata template reformulation, each metadata template represents some event that occurred in the RTS.
Parameter | Description | Notes |
|---|---|---|
| iuit | The IUI that designates the template undergoing change | All changes are carried out through insertion, invalidation, or revalidation of a template (that is an instance of one of the above types of templates) |
| iuid | The IUI that designates the entity who made the change | |
| td | The time when the change was made | To avoid complexities of using temporal region IUIs here, we simply use an ISO8601 compliant date/time string (e.g., 2013-10-31T14:48:32.234-05:00) |
| CT | The type of change | I = insertion, X = invalidation, R = revalidation |
| C | The reason for the change | CR = change in relevance, CE = change in reality, CB = change in belief, XR = recognition of error |
| EC | The type of error that is being rectified by the change | There is a huge list of change reasons. Some of them are applicable only to A templates, some only to PtoU templates, some only to PtoP templates, etc. |
| S | The IUI(s) of the template(s) that contain corrected information in the event that C = XR | For example, if a duplicate IUI was assigned to a person, then we would invalidate the second (later of the two) assignment template. This parameter would then point to the original, good IUI assignment (whereas the iuit parameter would point to the A template that is being invalidated). |