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.

id

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:

cdate

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.

tcdate

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.

mdate

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.

tmdate

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.

ddate

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.

invitation

The invitation field contains the Invitation id used to create or modify the Edit.

domain

The domain is a string that groups all the entities of a venue. Its value is set automatically and cannot be modified.

signatures

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.

readers

The readers field is an array with Group ids that indicates who can retrieve the Edit or see the Edit in the UI.

nonreaders

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.

writers

The writers field is an array with Group ids that indicates who can modify the Edit.

content

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.

replacement

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 .

tauthor

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.

Specific Invitation Edit Fields

invitations

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.

invitation

The invitation field contains the object that will be used during to create or modify the Invitation that will be saved to the database.

Specific Group Edit Fields

invitation

The invitation field contains the Invitation id used to create or modify the Edit.

group

The group field contains the Group object that will be used during to create or modify the Group that will be saved to the database.

Specific Note Edit Fields

invitation

The invitation field contains the Invitation id used to create or modify the Edit.

note

The note field contains the object that will be used during 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 is used:

Creating Notes

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.

Adding Fields

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:

Replacing Field Values

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:

Removing Fields

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.

Destructive Changes

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:

Replacement

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.