Edits are used to create Invitations, Groups and Notes. Therefore, there are three kinds of Edits: Invitation Edits, Group Edits and Note Edits. Once an Edit is created, it goes through the process of inference to create the corresponding entity. Consequently, Edits contain the history of changes of the entity that they create. Adding, removing or modifying an existing Edit will change the resulting entity.
Edits can only have certain fields and have a specific format. Some of these fields are the same as other objects and some are specific to the Edit object.
This is a unique value that identifies the Edit. The id of an Edit is generated automatically. It is a random 10 character long string that can contain any of the following values:
The Creation Date or cdate is a unix timestamp in milliseconds that can be set either in the past or in the future. It usually represents when the Edit was created.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Edit is created. Unlike the cdate, its value cannot be set or modified by the user and it is not displayed in the UI.
The Modification Date or mdate shows when the Edit was last modified. The mdate value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The True Modification Date or tmdate indicates the date in unix timestamp in milliseconds when the Edit is modified. Unlike the mdate, its value cannot be set or modified by the user and it is not displayed in the UI.
The Deletion Date or ddate is used to soft delete an Edit. This means that Edits with a ddate value can be restored but will appear as deleted. The ddate value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The invitation field contains the Invitation id used to create or modify the Edit.
The domain is a string that groups all the entities of a venue. Its value is set automatically and cannot be modified.
The signatures field indicates who created the Edit. Even though the field is an array of strings, only one item can be present in the signatures field. Users can sign with different ids depending on their permissions.
The readers field is an array with Group ids that indicates who can retrieve the Edit or see the Edit in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Edit or see the Edit in the UI. This field is useful in case we want to use a group id in the readers field that contains a member that we want to exclude from the readers. In this case, we can specify the Group id of that user in the nonreaders field.
The writers field is an array with Group ids that indicates who can modify the Edit.
The content field has arbitrary fields that can be named as anything with some restrictions. The fields can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters.
The fields inside content must contain a value field and optionally a readers field. For example:
In the example above, readers of the Edit will see that the value of title is "Title". However, only members of "OpenReview.net/2023/Conference" will be able to see the value of venueid.
The replacement field is a boolean value that indicates whether the history of changes of the entity that is being edited should restart from the Edit that is being created or modified. In other words, if the value of replacement is true, then, the previous Edits for that particular entity are ignored during inference.
The tauthor field contains the identity of the user that created the Edge. This property is only present when the user is writer of the Edge.
The invitations field contains the Invitation id used to create or modify the Edit. Even though the name of the field is in plural, the field contains a string. This is to avoid name collision with the invitation field.
The invitation field contains the Invitation object that will be used during inference to create or modify the Invitation that will be saved to the database.
The invitation field contains the Invitation id used to create or modify the Edit.
The group field contains the Group object that will be used during inference to create or modify the Group that will be saved to the database.
The invitation field contains the Invitation id used to create or modify the Edit.
The note field contains the Note object that will be used during inference to create or modify the Note that will be saved to the database.
The process of inference combines Edits to create an entity before saving it to the database. In other words, entities such as Invitations, Groups or Notes cannot be created directly, they need to be created through Edits and the process of inference.
Edits are sorted in a fixed chronological order using the tcdate field during inference. Since the tcdate value can never be modified, Edits can never change their position in the history of changes. However, the history of changes can be modified by destructively changing an Edit. This is only possible if the user has writer permissions on the Edit.
The process of inference can add, remove and replace fields as long as the Invitation used to create the Edit allows it. To illustrate this, we will focus on inference used to create Notes, however, the same rules apply to Invitations and Groups.
For the following examples, assume that the following Invitation is used:
Suppose the following Note Edit is created:
Since this is the first an only Edit the resulting Note will only contain the fields and values inside the note field of the Edit.
You may have noticed the fields id, invitations and domain that were not included in the Edit but still appear after the inference runs. These fields are set automatically and cannot be manually modified. The invitations field shows all the different Invitations that have contributed to the modification of the Note. The field domain shows the venue that the Note belongs to and it is present in every single object created.
Let's say that we now want to add the field abstract to the Note. We can create a new Note Edit:
Notice that we now pass the field note.id to the Edit. This indicates what Note we want to modify. The resulting Note will then contain the abstract field:
Values can be overwritten by passing the same field with a new value. For example, if we want to update the abstract field that we just added, we can create the following Note Edit
The resulting Note will look like this:
In order to remove a field from a Note, we can pass the object { delete: true } as value to the field.
The resulting Note will look like this:
The resulting Note will look exactly the same as the first Note that was created from the first Edit. The difference is that we can see the history of changes by querying the Edits associated to the Note.
Edits can be modified directly and alter the history of changes. This can achieved by passing the id of the Edit that we want to modify like so:
The field replacement can be used when we want to restart the history of changes. In other words, Edits created before the one that contains replacement: true will be ignored during inference. The ignored Edits will still exist but will not be considered for the resulting values of the entity. Consider the following Edit:
The resulting Note looks like this:
As you can see, the Edit containing the replacement: true is considered to be the first Edit during inference. If a subsequent Edit contains replacement: true then that Edit will considered to be the first Edit and the previous Edits will be ignored.