Meta-data about data creation, modification, etc. It may apply to objects but also parts of the object (e.g. assignments).
Meta-data only apply to successful operations. That is obvious for create, but it also applies to modify. For obvious reasons there are no metadata about delete. We keep no metadata about reading. That would be a huge performance hit.
Meta-data only describe the last operation of its kind. E.g. there is a record of last modification, last approval, etc. There is no history. The last operation overwrites data about the previous operation.
These data are informational only. They should not be used for security purposes (use auditing subsystem for that). But presence of metadata simplifies system administration and may provide some basic information "at the glance" which may be later confirmed by the audit logs.
Meta-data are also supposed to be searchable. Therefore they may be used to quickly find "candidate" objects for a closer examination.
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| requestTimestamp |
property dateTime |
[0,1] | The timestamp of operation request. |
| requestorRef |
reference ObjectReferenceType |
[0,1] | Reference to the user that requested the operation. |
| createTimestamp |
property dateTime |
[0,1] | The timestamp of data creation. |
| creatorRef |
reference ObjectReferenceType |
[0,1] | Reference to the user that created the data. |
| createApproverRef |
reference ObjectReferenceType |
[0,-1] | Reference to the user that approved the creation of the data (if there was such a user). |
| createApprovalTimestamp |
property dateTime |
[0,1] | The timestamp of last modification approval. |
| createChannel |
property anyURI |
[0,1] | Channel in which the object was created. |
| modifyTimestamp |
property dateTime |
[0,1] | The timestamp of last data modification. |
| modifierRef |
reference ObjectReferenceType |
[0,1] | Reference to the user that modified the data. |
| modifyApproverRef |
reference ObjectReferenceType |
[0,-1] | Reference to the user that approved the last modification of the data (if there was such a user). |
| modifyApprovalTimestamp |
property dateTime |
[0,1] | The timestamp of last modification approval. |
| modifyChannel |
property anyURI |
[0,1] | Channel in which the object was last modified. |
Flags: RAM,runtime,oper
Multiplicity: [0,1]
The timestamp of operation request. It is set once and should never be changed.
In case of "background" processes to create object (e.g. create with approval)
this should be the timestamp when the process started. I.e. the timestamp when
the operation was requested.
Flags: RAM,oper
Multiplicity: [0,1]
Flags: RAM,runtime,oper,I
Multiplicity: [0,1]
The timestamp of data creation. It is set once and should never be changed.
In case of "background" processes to create object (e.g. create with approval)
this should be the timestamp when the process ended. I.e. the timestamp when
the operation was executed.
Flags: RAM,oper
Multiplicity: [0,1]
Flags: RAM,oper
Multiplicity: [0,-1]
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Flags: RAM,runtime,oper,I
Multiplicity: [0,1]
Flags: RAM,runtime,oper,I
Multiplicity: [0,1]
Flags: RAM,oper
Multiplicity: [0,1]
Flags: RAM,oper
Multiplicity: [0,-1]
Reference to the user that approved the last modification of the data (if there was such a user).
This is multi-value reference therefore multiple approvers may be recorded. Howerver the order and
hierarchy of the approvers is lost.
Even though this is multi-value reference it will get overwritten after each approval.
The multiple values are used only if all the approvers are known at the same time,
e.g. if multi-level approval is evaluated at the same time. But generaly this refers
only to the last approval event.
Flags: RAM,runtime,oper
Multiplicity: [0,1]
Flags: RAM,runtime,oper,I
Multiplicity: [0,1]