Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Edges are used to connect two entities. They usually represent matching data, like affinity scores, conflicts, custom quotas, etc. The Edge entity contains two main properties: head and tail and optionally a label and weight. Head and tail properties point to other entities in the system like a note, a group or a profile.
Tags are used to tag an entity with a label, a weight or both. They can add information to an entity or be used to locate a group of entities that have the same tag. Tags are also used for stats data. The Tag entity contains two main properties: label and weight. On top of that, tags have a property to indicate what entity they are tagging. For example, if they have the property note, then they are tagging a Note and the value of the field will have the Note id.
Edges 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 Edge object.
This is a unique value that identifies the Edge. The id of an Edge is generated automatically. It is a random 14 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 Edge was created.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Edge 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 Edge 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 Edge 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 Edge. This means that Edges 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 signatures field indicates who created the Edge. 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 Edge or see the Edge in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Edge or see the Edge 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 Edge.
The domain is a string that groups all the entities of a venue. Its value is usually set automatically and cannot be modified.
The head field can contain a Note id or a Group id and connects it to the Note id or Group id defined in the tail field. This field is always mandatory and cannot be empty.
The tail field can contain a Note id or a Group id and connects it to the Note id or Group id defined in the head field. This field is always mandatory and cannot be empty.
The label field contains a string that gives extra information to the Edge. This information can be used to classify Edges and differentiate them from other Edges that have the same Invitation, tail and head values.
The weight field contains a number that defines the weight between two entities defined in head and tail.
The invitation field contains the Invitation id that was used as template to create the Edge.
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.
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZProfiles are an OpenReview object that contains properties. The main three properties that you can expect to interact with are:
id
Type: str
Description: The unique identifier of the profile, usually in the form ~First_Last1.
Purpose: Used as the unique reference to the user across OpenReview (e.g., for assigning roles, authorship, etc.).
state
Type: str
Description: The status of the profile
Active : Profile was moderated and is now active
content
Type: dict
Description: The main body of the profile data. It contains structured information about the user.
Key Subfields:
Tags 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 Tag object.
Active Institutional : Profile contains an approved institutional email domainInactive : User has not completed Profile Registration (profile is not active)
Rejected : User needs to correct information in the profile and resubmit it for moderation
Needs Moderation : Profile is pending moderation
names: List of name entries. Each entry is a dict with keys like first, last.emailsConfirmed: List of verified email addresses.
emails : List of all email addresses
preferredEmail: The primary email to be used for communication.
history: List of affiliations over time, each with institution, position, start, and end.
homepage , gscholar, dblp, github: Social and academic links.
expertise: Manually entered expertise areas.
relations: Manually entered relationships to other users in the OpenReview system.
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 Tag was created.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Tag 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 Tag 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 Tag 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 Tag. This means that Tags 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 signature field indicates who created the Tag. 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 Tag or see the Tag in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Tag or see the Tag 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 Tag.
The domain is a string that groups all the entities of a venue. Its value is usually set automatically and cannot be modified.
The label field contains a string compliant with the invitation definition.
The weight field contains a number compliant with the invitation definition.
The invitation field contains the Invitation id that was used as template to create the Tag.
The tauthor field contains the identity of the user that created the Tag. This property is only present when the user is writer of the Tag.
The note field contains a note id. This field is present when the tag is tagging a Note and its value is used as a pointer.
The profile field contains a profile id. This field is present when the tag is tagging a Profile and its value is used as a pointer.
The group field contains a group id. This field is present when the tag is tagging a Group and its value is used as a pointer.
The invitation field contains a invitation id. This field is present when the tag is tagging an Invitation and its value is used as a pointer.
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZNotes are the main containers of data in OpenReview. Notes are used for submissions and comments such as reviews, meta reviews, decisions and public comments. They require an Invitation to be created and modified.
Groups are used to organize the venue structure and to give permissions to every actor in the system.
For example, the base group of a conference is going to have the venue id as its id. Other groups like the Reviewers group, the Authors group or Area Chairs group will have the venue id as its prefix in their id to indicate what venue they belong to. Users that are members of a group automatically get the group's permissions. Only groups can be members of other groups. For this reason, profile ids and emails are also groups that can be added as members to other groups.
Groups 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 Group object.
This is a unique value that identifies the Group. If its value starts with ~, it will most likely belong to a profile id (some email addresses contain ~ at the beginning): ~Joe_Doe1.Email addresses can also have a group in the system. The email itself will be the id of the group. Other groups used for organization and to assign permissions will usually contain / to indicate the hierarchy within the venue: OpenReview.net/Venue_Organizers.
Groups contain a members field contains other group ids. Members of the group are granted the permissions of the group they belong to.
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 Group was created.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Group 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 Group 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 Group is modified. Unlike the mdate, its value cannot be set or modified by the user and it is not displayed in the UI.
The invitations field contains all the Invitations that were used to create the Group through the process of inference.
The domain is a string that groups all the entities of a venue. Its value is usually set automatically and cannot be modified.
The signatures field indicates who created the Note. 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 Note or see the Note in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Note or see the Note 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 Note.
The content field is a JSON that can contain any field that is specified in the Invitation. The fields in content can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters. The UI will display by default the value of the field after replacing the underscore characters with spaces and uppercasing the first letter of every word in the field. However, the UI can be instructed to render a different text for each field by defining a string inside param/fieldName in the Invitation.
The fields inside content must contain a value field and optionally a readers field. For example:
Notes 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 Note object.
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.
Users can enter data into the system using an invitation. An invitation is roughly a template that indicates required and valid values that will be saved to the database. The invitation contains a list of fields that need to be completed by the user. Everything in the system needs an invitation to be created. Even invitations need an invitation.
The subsections contain information on the types of Invitations, their structure, the fields it can have, and how to define them with different specifiers.
Notes contain a number field that is associated to the first Invitation that is used to create the Note. The number value is added automatically and it is usually used to give a number id to submissions.
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 Note was created.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Note 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 Note 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 Note is modified. Unlike the mdate, its value cannot be set or modified by the user and it is not displayed in the UI.
The Online Date or odate is used to show when the Note first becomes public. The odate value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Publication Date or pdate is used to show when the Note that represents a submission is marked as Accepted. The pdate value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Deletion Date or ddate is used to soft delete an Note. This means that Notes 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 invitations field contains all the Invitations that were used to create the Note through the process of inference.
The domain is a string that groups all the entities of a venue. Its value is usually set automatically and cannot be modified.
The signatures field indicates who created the Note. 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 Note or see the Note in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Note or see the Note 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 Note.
The forum field contains a Note id. When the Note id field is equal to the forum field, it indicates that the Note is a submission. Otherwise, it means that the Note is a comment to the submission. In other words, the forum value indicates the forum the Note belongs to.
The replyto contains a Note id. This field indicates what Note it is replying to. In other words, Notes that contain this field are comments in a forum.
The content field is a JSON that can contain any field that is specified in the Invitation. The fields in content can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters. The UI will display by default the value of the field after replacing the underscore characters with spaces and uppercasing the first letter of every word in the field. However, the UI can be instructed to render a different text for each field by defining a string inside param/fieldName in the Invitation.
The fields inside content must contain a value field and optionally a readers field. For example:
Everyone can query this Note and 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.
{
"id": "or2023",
"invitations": [ "OpenReview.net/2023/Conference/-/Group" ],
"readers": [ "everyone" ],
"writers": [ "~Some_Author1" ],
"signatures": [ "~Some_Author1" ],
"content": {
"somve_value": {
"value": "Title"
},
"another_value": {
"value": "OpenReview.net/2023/Conference",
"readers": [ "OpenReview.net/2023/Conference" ]
}
}
}0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ{
"id": "or2023",
"invitations": [ "OpenReview.net/2023/Conference/-/Submission" ],
"readers": [ "everyone" ],
"writers": [ "~Some_Author1" ],
"signatures": [ "~Some_Author1" ],
"content": {
"title": {
"value": "Title"
},
"venueid": {
"value": "OpenReview.net/2023/Conference",
"readers": [ "OpenReview.net/2023/Conference" ]
}
}
}Invitations 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 Invitation object.
This is a unique value that identifies the Invitation. Its value, which will always contain the string /-/ determines the parent group it belongs to as well as the value that is displayed when creating buttons in the UI. For example, the Invitation id OpenReview.net/Venue_Organizers/-/Submission belongs to the group OpenReview.net/Venue_Organizers and the button displayed in the UI will have the Submission value.
Invitations can be used to create many objects. If you want to restrict the amount of objects created you can set a maxReplies integer value. If this value is not present, then any amount of objects can be created using the Invitation.
Invitations are sometimes used for tasks. Until the integer value minReplies is met by creating object replying to the Invitation, the task will still be marked as pending. The minReplies parameter is only used by the UI.
The Creation Date or cdate is used to activate an Invitation. The value of a cdate is a unix timestamp in milliseconds that can be set either in the past or in the future. If the cdate is set in the future, the Invitation cannot be used until the date set is reached.
The True Creation Date or tcdate indicates the date in unix timestamp in milliseconds when the Invitation 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 Invitation was last modified. The value of a mdate 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 Invitation is modified. Unlike the mdate, its value cannot be set or modified by the user and it is not displayed in the UI.
The Expiration Date or expdate is used to set an expiration date for an Invitation. Once the expiration date is reached, users will not be able to use the Invitation to create new objects, unless the user is a writer of the Invitation. The value of a expdate is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Due Date or duedate is used to set an expiration date for an Invitation in the UI. Its value can be different from the expdate and it is never used to validate if the Invitation can still be used. This property is useful to give users during a deadline room when there are network issues due to heavy traffic. Therefore, the duedate is usually set with a value less than the expdate. The value of a duedate is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Deletion Date or ddate is used to soft delete an Invitation. This means that Invitations with a ddate value can be restored but will appear as deleted. The value of a ddate is a unix timestamp in milliseconds that can be set either in the past or in the future.
The invitations field contains all the Invitations that were used to create the Invitation through the process of inference.
The domain is a string that groups all the entities of a venue. Its value is usually set automatically and cannot be modified.
The signatures field indicates who created the Invitation. 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 Invitation or see the Invitation in the UI.
The nonreaders field is an array with Group ids that indicates who cannot retrieve the Invitation or see the Invitation 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 Invitation.
The invitees field is an array with Group ids that indicates who can use the Invitation to create an object. A user can be a reader of an Invitation but not an invitee.
The noninvitees field is an array with Group ids that indicates who cannot use the Invitation. This field is useful in case we want to use a group id in the invitees field that contains a member that we want to exclude from the invitees. In this case, we can specify the Group id of that user in the noninvitees field.
The preprocess field contains a string with custom javascript or python code that can be used to add extra validation before an object is created.
The process field contains a string with custom javascript or python code that runs after an object is created. This process runs asynchronously and can be used to send emails, for example. Process functions can be executed right after an object is created or with a delay after the object is created.
The dateprocesses field is an array containing different dates and delays. It can be used to run a specific task after an object is created, on a particular date, or as a cronjob.
The web field contains javascript code that runs when the Invitation is loaded in the UI. If the field web is not present, a default UI is shown for the Invitation.
The edit field is a JSON that contains the rules and structure for any edit that is created using this Invitation. Edits can be for Groups, Notes, and Invitations.
The edge field is a JSON that contains the rules and structure for any edge that is created using this Invitation.
The tag field is a JSON that contains the rules and structure for any tag that is created using this Invitation.
The content field is a JSON that can contain any field with any name defined by the user. Please refer to the Speficiers subsection for more information on how to define the field values.
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 UI will display by default the value of the field after replacing the underscore characters with spaces and uppercasing the first letter of every word in the field. However, you can instruct the UI to render a different text for each field by defining a string inside param/fieldName. The field fieldName can be a string with a max length of 1000 characters and no restriction in terms of what characters can be used.
The fields inside content must contain a value field and optionally a readers field. For example:
Everyone can query this Note and 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.
{
"id": "or2023",
"invitations": [ "OpenReview.net/2023/Conference/-/Submission" ],
"readers": [ "everyone" ],
"writers": [ "~Some_Author1" ],
"signatures": [ "~Some_Author1" ],
"content": {
"title": {
"value": "Title"
},
"venueid": {
"value": "OpenReview.net/2023/Conference",
"readers": [ "OpenReview.net/2023/Conference" ]
}
}
}The dollar sign notation is used to copy values from one field whose path is specified inside the dollar sign notation to the one where the dollar sign notation was specified. The path defined in the field is a relative path and can only refer to fields that are passed when the object is posted or to fields that are generated by the backend before it gets saved to the database.
The dollar sign notation is a string has the following format:
Probably the most common and simple example is the one for signatures and Note number. Consider the following simplified Note Edit Invitation:
Then a valid Note Edit replying to this Invitation will look like this:
The final Edit that will be saved to the database after all values have been resolved will look like this:
According to the Note Edit Invitation there are only 2 fields that the user needs to fill up: signatures and the value
titleparamThere are 3 fields that contain the dollar sign notation and 4 values that need to be resolved. Let us start with the one inside edit/readers/1. The value ${2/signatures} means that it will go up twice and then select the value of edit/signatures. Note that the value here is [ "~Test_User1" ]. The array will replace the value where ${2/signatures} would be located in the Note Edit and then flattened. In a similar way, the value inside edit/note/writers/1 will be resolved and flattened. The only difference is that the relative path is different, but they resolve to the same value.
The other example refers to the field number. This field is not defined when the Note Edit is posted, because it is created by the backend. However, the field can be referred to when creating the Note Edit. The number field is the only exception to the rule where all the field values that can be referred to with the dollar sign notation need to be present when the Note Edit is posted. As you can see, when the Note number value is resolved it replaces the value of the dollar sign with the number of the Note.
The dollar sign notation cannot refer to values that are at the root of the Invitation. This is because when an object is created, it only has access to its own fields, not to the fields of the Invitation that allows its creation.
${<integer>/path/to/other/field/value}{
id: "OpenReview.net/Venue_Organizers/-/Submission",
signatures: [ "OpenReview.net/Venue_Organizers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitees: [ "~" ],
readers: [ "everyone" ],
edit : {
signatures: { param: { regex: ".+" } },
readers: [
"OpenReview.net/Venue_Organizers",
"${2/signatures}"
],
writers: [ "OpenReview.net/Venue_Organizers" ],
note: {
signatures: [ "OpenReview.net/Paper${2/number}/Authors" ],
readers: [ "everyone" ],
writers: [
"OpenReview.net/Venue_Organizers",
"${3/signatures}",
"OpenReview.net/Paper${2/number}/Authors"
],
content: {
title: {
value: { param: { type: "string" } }
}
}
}
}
}{
signatures: [ "~Test_User1" ],
note: {
content: {
title: {
value: "This is a title"
}
}
}
}{
signatures: [ "~Test_User1" ],
readers: [
"OpenReview.net/Venue_Organizers",
"~Test_User1"
],
writers: [ "OpenReview.net/Venue_Organizers" ],
note: {
signatures: [ "OpenReview.net/Paper1/Authors" ],
readers: [ "everyone" ],
writers: [
"OpenReview.net/Venue_Organizers",
"~Test_User1",
"OpenReview.net/Paper1/Authors"
],
content: {
title: {
value: "This is a title"
}
}
}
}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 usually 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 .
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 object that will be used during 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 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 object that will be used during to create or modify the Note that will be saved to the database.
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ{
"content": {
"title": {
"value": "Title"
},
"venueid": {
"value": "OpenReview.net/2023/Conference",
"readers": [ "OpenReview.net/2023/Conference" ]
}
}
}The fields of an Invitation vary depending on the object that will be created with it. There are 6 different types of invitations:
Meta Invitations are admin Invitations which are created when the venue is deployed and are available to venue organizers. There is only 1 available per venue and should be used with care and sparingly. Meta Invitations can modify any object in the system that is associated to the venue. Therefore, before using the Meta Invitation, make sure there is no other Invitation that can be used instead. Using an Invitation other than the Meta Invitation is preferred to avoid errors when modifying an object.
Meta Invitations have the structure shown below. They can be identified because of the property edit: true inside the invitation field.
Edge Invitations are used to create Edges and contain the edge field that defines the template for the Edges. This means that when creating an Edge object with the Invitation below, the rules and structure defined inside the edge field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of an Edge Invitation and it is only used to understand its structure.
Tag Invitations are used to create Tags and contain the tag field that defines the template for the Tags. This means that when creating a Tag object with the Invitation below, the rules defined and structure inside the tag field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Tag Invitation and it is only used to understand its structure.
Group Edit Invitations are used to create Group Edits and contain the edit field that defines the template for the Group Edits. This means that when creating a Group Edit object with the Invitation below, the rules and structure defined inside the edit field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Group Edit Invitation and it is only used to understand its structure.
Note Edit Invitations are used to create Note Edits and contain the edit field that defines the template for the Note Edits. This means that when creating a Note Edit object with the Invitation below, the rules and structure defined inside the edit field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Note Edit Invitation and it is only used to understand its structure.
Invitation Edit Invitations are used to create Invitation Edits and contain the edit field that defines the template for the Invitation Edits. This means that when creating an Invitation Edit object with the Invitation below, the rules and structure defined inside the edit field will need to be followed.
Invitations that are used to create Invitation Edits are the most complex ones. Theoretically, they can have any depth, but you will probably hit restrictions if you try to create a very big Invitation.
Do NOT copy the values from this example in your venue. This example is a simplified version of an Invitation Edit Invitation and it is only used to understand its structure.
{
writers: [ "OpenReview.net/Venue_Organizers" ],
readers: [ "OpenReview.net/Venue_Organizers" ],
signatures: [ "OpenReview.net" ],
invitation: {
id: "OpenReview.net/Venue_Organizers/-/Edit",
signatures: [ "OpenReview.net" ],
writers: [ "OpenReview.net" ],
invitees: [ "OpenReview.net/Venue_Organizers" ],
readers: [ "OpenReview.net/Venue_Organizers" ],
edit: true
}
}{
id: "OpenReview.net/Venue_Organizers/-/Bid",
readers: [ "everyone" ],
invitees: [ "OpenReview.net/Reviewers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
signatures: [ "OpenReview.net/Venue_Organizers" ],
edge: {
id: {
param: {
withInvitation: "OpenReview.net/Venue_Organizers/-/Bid",
optional: true
}
},
readers: { param: { regex: "~.*" } },
writers: { param: { regex: "~.*" } },
signatures: { param: { regex: "~.*" } },
head: { param: { type: "note" } },
tail: { param: { type: "profile" } },
label: { param: { regex: ".*" } }
}
}{
id: "OpenReview.net/Venue_Organizers/-/Tag",
signatures: [ "OpenReview.net/Venue_Organizers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitees: [ "~" ],
readers: [ "everyone" ],
tag: {
readers: [ "everyone" ],
signatures: { param: { regex: ".+" } },
writers: { param: { regex: ".+" } },
nonreaders: { param: { regex: ".*", optional: true } },
tag: { param: { minLength: 1, maxLength: 100 } }
}
}{
id: "OpenReview.net/Venue_Organizers/-/Group",
signatures: [ "OpenReview.net/Venue_Organizers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitees: [ "OpenReview.net/Venue_Organizers" ],
readers: [ "OpenReview.net/Venue_Organizers" ],
edit: {
readers: [ "OpenReview.net/Venue_Organizers" ],
signatures: { param: { regex: ".+" } },
writers: { param: { regex: ".*" } },
group: {
id: "OpenReview.net/Reviewers",
readers: [ "OpenReview.net/Venue_Organizers" ],
signatures: { param: { regex: ".+" } },
signatories: { param: { regex: ".+", optional: true } },
writers: { param: { regex: ".*" } },
members: { param: { regex: ".*", optional: true } }
}
}
}{
id: "OpenReview.net/Venue_Organizers/-/Note",
signatures: [ "OpenReview.net/Venue_Organizers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitees: [ "~" ],
readers: [ "everyone" ],
edit: {
readers: [ "everyone" ],
signatures: { param: { regex: ".+" } },
writers: { param: { regex: ".*" } },
note: {
readers: [ "everyone" ],
signatures: { param: { regex: ".+" } },
writers: { param: { regex: ".*" } },
content: {
title: {
value: { param: { regex: ".*" } }
}
}
}
}
}{
id: "OpenReview.net/Venue_Organizers/-/Invitation",
signatures: [ "OpenReview.net/Venue_Organizers" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitees: [ "~" ],
readers: [ "everyone" ],
edit: {
signatures: { param: { regex: ".+" } },
content: {
title: { value: { param: { type: "string", regex: ".*" } } },
duedate: { value: { param: { type: "integer" } } }
},
readers: [ "OpenReview.net/Venue_Organizers", "${2/signatures}" ],
writers: [ "OpenReview.net/Venue_Organizers" ],
invitation: {
id: "OpenReview.net/-/Submission",
signatures: [ "${3/signatures}" ],
readers: [ "~" ],
writers: [ "OpenReview.net/Venue_Organizers", "${3/signatures}" ],
invitees: [ "${3/content/invitees/value}" ],
duedate: "${2/content/duedate/value}",
content: {
optional: { value: { param: { type: "string", optional: true } } }
},
edit: {
signatures: { param: { regex: ".*" } },
readers: [ "OpenReview.net/Venue_Organizers", "${2/signatures}" ],
writers: [ "OpenReview.net/Venue_Organizers", "${2/signatures}" ],
note: {
signatures: [ "${3/signatures}" ],
readers: [ "OpenReview.net/Venue_Organizers", "${3/signatures}" ],
writers: [ "OpenReview.net/Venue_Organizers", "${3/signatures}" ],
content: {
title: {
value: {
param: {
type: "string",
regex: "${8/content/title/value}"
}
}
},
authors: {
value: { param: { type: "string[]", regex: ".*", optional: true } },
readers: [ "OpenReview.net/Venue_Organizers", "${5/signatures}" ]
},
authorids: {
value: { param: { type: "group[]", regex: ".*", optional: true } },
readers: [ "OpenReview.net/Venue_Organizers", "${5/signatures}" ]
}
}
}
}
}
}
}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:
In this case the abstract now inherits the readers of the Note, just like title. The authors and authorids fields are still only visible to a subset of people.
You can completely remove the abstract by now deleting the value field:
The resulting Note now looks like this:
The Note will now 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.
{
id: 'OpenReview.net/Conference/-/Submission',
signatures: [ 'OpenReview.net' ],
writers: [ 'OpenReview.net' ],
invitees: [ '~' ],
readers: [ 'everyone' ],
domain: 'OpenReview.net/Conference'
edit : {
signatures: { param: { regex: '.+' } },
readers: [ 'OpenReview.net/Conference', '${2/signatures}' ],
writers: [ 'OpenReview.net/Conference' ],
replacement: { param: { 'enum': [ true, false ], optional: true } },
note: {
id: {
param: {
withInvitation: 'OpenReview.net/Conference/-/Submission',
optional: true
}
},
signatures: [ '${3/signatures} ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '${3/signatures}' ],
content: {
title: {
value: {
param: {
type: 'string',
optional: true
}
}
},
abstract: {
value: {
param: {
type: 'string',
optional: true,
deletable: true
}
},
readers: {
param: {
regex: '^~.*$|OpenReview\.net\/Conference'
deletable: true
}
}
},
authors: {
value: { param: { type: 'string[]', minLength: 1, optional: true } },
readers: [ 'OpenReview.net/Conference', '${5/signatures}' ]
},
authorids: {
value: { param: { type: 'group[]', regex: '^~.+', optional: true } },
readers: [ 'OpenReview.net/Conference', '${5/signatures}' ]
}
}
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference'
note: {
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
title: {
value: 'Title'
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Title'
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
note: {
id: 'mIcD4PJBaU',
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
abstract: {
value: 'Abstract',
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Title'
},
abstract: {
value: 'Abstract',
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
note: {
id: 'mIcD4PJBaU',
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
abstract: {
value: 'Revised Abstract'
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Title'
},
abstract: {
value: 'Revised Abstract'
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
note: {
id: 'mIcD4PJBaU',
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
abstract: {
readers: { 'delete': true }
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Title'
},
abstract: {
value: 'Revised Abstract'
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
note: {
id: 'mIcD4PJBaU',
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
abstract: {
value: { 'delete': true }
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Title'
},
authors: {
value: [ 'Author One' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
},
authorids: {
value: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ]
}
}
}{
id: 'oORBZnuLKi' // This is the id of the Edit that we want to modify.
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ 'OpenReview.net/Conference' ],
readers: [ 'OpenReview.net/Conference' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
note: {
id: 'mIcD4PJBaU',
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
abstract: {
value: 'A different Abstract'
}
}
}
}{
invitation: 'OpenReview.net/Conference/-/Submission',
signatures: [ '~Author_One1' ],
readers: [ 'OpenReview.net/Conference', '~Author_One1' ],
writers: [ 'OpenReview.net/Conference' ],
domain: 'OpenReview.net/Conference',
replacement: true,
note: {
id: 'mIcD4PJBaU',
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
content: {
title: {
value: 'Replacement Title'
}
}
}
}{
id: 'mIcD4PJBaU'
invitations: [ 'OpenReview.net/Conference/-/Submission' ],
signatures: [ '~Author_One1' ],
readers: [ 'everyone' ],
writers: [ 'OpenReview.net/Conference', '~Author_One1' ],
domain: 'OpenReview.net/Conference',
content: {
title: {
value: 'Replacement Title'
}
}
}There are two types of specifiers: Validation Specifiers and Representation Specifiers.
Both specifiers are defined inside the param field. The Representation Specifiers define how the requested data will be rendered in the UI.
Validation Specifiers define valid values that can be assigned to the fields of the objects (Edits, Edges, Tags) that will be created using the Invitation. Most Validation Specifiers outside content do not require a type field since its type can be inferred from the field name. For instance, the readers field will always be of type group[]. However, other Validation Specifiers need to be defined for the readers field, such as regex.
Validation Specifiers inside the content field will always require a type. This is because content can have any field name and its valid values need to be specified so that the UI can render them and the backend validate them.
In most cases, you can only have one Validation Specifier. The only exceptions are value range specifiers, such as minimum, maximum, minLength and maxLength.
There is no restriction on the amount of Representation Specifiers.
The param should have one of the following specifiers needed to validate the expected value.
const: restricts the value of the field to whatever it's written in const. When const is present, the user does not need to pass the value, since it will be assigned by the Invitation. In the example below, the title value has to be exactly "This is a title".
enum: valid values must be listed in the enum array. The values in enum must be of the same type and should match the type specified in the field type. When the type of enum is string its values can be regexes too. In the example below "This is a title" and "This issss b regex" are valid values for title.
items: valid values must be listed in the items array. Notice that each item is an object that must contain the field value or prefix and optionally the fields optional and description. The values in items must be of the same type and should match the type specified in the field type. In the example below the title field will be an array of strings as indicated by its type.
regex: valid values need to match the specified regex. The type of the field should be string. In the example below, "This asdf title" is a valid value.
range: valid values are within the range [a, b] which means a <= value <= b. The type of the field must be float or integer. In the example below, the values 0, 3, and 10 are valid.
withInvitation: valid values are IDs of entities that have as invitation the value specified in withInvitation.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2022" would be valid.
withVenueid: valid values are IDs of entities that have as venueid the value specified in withVenueid.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2023" would be valid.
withForum: valid values are IDs of entities that have as forum the value specified in withForum.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "com2024" would be valid.
inGroup: valid values are group IDs that are members of the group ID specified in inGroup.
Suppose we have the following group (this is a simplified version of the group):
Given the example below, the value "~Some_Reviewer1" would be valid.
minLength: valid values are strings that have at least the length specified in minLength. In the example below, the values "title" and "long title" are valid.
maxLength: valid values are strings that have at most the length specified in maxLength. In the example below, the values "title" and "abc" are valid.
maxSize: specifies the maximum size that a file can have in megabytes. It must be used with type file. In the example below
extensions: specifies the valid types with the extension of the file. The extensions cannot have dots, which means that files that have the extension tar.gz are not supported.
minimum: valid values are numbers (floats or integers) that have at least the value specified in minimum. In the example below, 1 and 6000 are valid values.
maximum: valid values are numbers (floats or integers) that have at most the value specified in maximum. In the example below, 20.5 and 16.7 are valid values.
type: define the type value that field is going to have.
Allowed types:
string
integer
boolean
date
Square brackets can be appended to each type to expect an array of values, for example:
type can be an optional property in some cases where it is known which type is expected, for example: readers, writers and signatures of a note.
optional: boolean value that indicates if the value is optional or mandatory.
deletable: boolean value that indicates if the value can be deleted.
order: define the order in which the field is going to be rendered in the form.
description: short text to explain the expected value.
input: type of widget to use when requesting data.
file
profile
group
note
False
Field is mandatory and cannot be deleted
True
undefined
Field can be added but not deleted
undefined
True
Field is optional and can be deleted
undefined
undefined
Field is mandatory and cannot be deleted
text
select
checkbox
textarea
radio
default: value that is going to be shown when the widget is initialized.
markdown: boolean value that enables the use of markdown.
scroll: boolean value that specifies whether a textarea input will be scrollable.
True
True
Field is optional and can be deleted
True
False
Field can be added but not deleted
False
True
Undefined
False
"title": {
"value": {
"param": {
"type": "string",
"const": "This is a title"
}
}
}"title": { "value": "This is a title" }"title": {
"value": {
"param": {
"type": "string",
"enum": ["This is a title", "This is{3,5} [a|b] regex"]
}
}
}"title": {
"value": {
"param": {
"type": "string[]",
"items": [
{ "value": "title 1", "description": "This is the first title" },
{ "value": "title 2", "description": "This is the second title" },
],
},
}
}"title": {
"value": {
"param": {
"type": "string",
"regex": "^This .+ title$"
}
}
}"grade": {
"value": {
"param": {
"type": "integer",
"range": [0, 10]
}
}
}{
"id": "or2022",
"invitations": ["OpenReview.net/2022/Conference/-/Submission"],
"readers": ["everyone"],
"writers": ["~Some_Author1"],
"signatures": ["~Some_Author1"],
"content": {
"title": {
"value": "Title"
}
}
}"id": {
"param": {
"withInvitation": "OpenReview.net/2022/Conference/-/Submission"
}
}{
"id": "or2023",
"invitations": ["OpenReview.net/2023/Conference/-/Submission"],
"readers": ["everyone"],
"writers": ["~Some_Author1"],
"signatures": ["~Some_Author1"],
"content": {
"title": {
"value": "Title"
},
"venueid": {
"value": "OpenReview.net/2023/Conference"
}
}
}"id": {
"param": {
"withVenueid": "OpenReview.net/2023/Conference"
}
}{
"id": "com2024",
"invitations": ["OpenReview.net/2024/Conference/-/Submission"],
"readers": ["everyone"],
"writers": ["~Some_Author1"],
"signatures": ["~Some_Author1"],
"forum": "or2024",
"content": {
"title": {
"value": "Title"
}
}
}"id": {
"param": {
"withForum": "or2024"
}
}{
"id": "OpenReview.net/2022/Conference/Reviewers",
"readers": ["OpenReview/2022/Conference"],
"writers": ["OpenReview/2022/Conference"],
"signatures": ["OpenReview/2022/Conference"],
"members": ["~Some_Reviewer1", "~Some_Reviewer2"]
}"tail": {
"param": {
"type": "profile",
"inGroup": "OpenReview.net/2022/Conference/Reviewers"
}
}"some_field": {
"param": {
"type": "string",
"minLength": 5
}
}"some_field": {
"param": {
"type": "string",
"maxLength": 5
}
}"supplemtary_material": {
"param": {
"type": "file",
"maxSize": 5,
"extensions": ["pdf", "zip"]
}
}"some_number": {
"param": {
"type": "integer",
"minimum": 1
}
}"some_number": {
"param": {
"type": "float",
"maximum": 20.5
}
}"invitation": {
"id": "OpenReview.net/2022/Conference/-/Submission",
"signatures": [ "~Super_User1" ],
"readers": [ "~" ],
"writers": [ "groupId" ],
"invitees": [ "~" ],
"edit": {
"signatures": { "param": { "regex": ".*" } },
"readers": [ "groupId" ],
"writers": [ "groupId" ],
"note": {
"signatures": [ "~Super_User1" ],
"readers": [ "groupId" ],
"writers": [ "groupId" ],
"content": {
"title": {
"value": { "param": { "type": "string", "regex": ".*" } }
}
}
}
}
}"keywords": {
"type" "string[]"
}