Using Rule to Control the Paper-Review Process

Rule-based representation [6] is a kind of knowledge representation, used to express cause-effect relations and reasoning logic. In the proposed paper-review system, this representation was used to represent process control logic, anonymity principle, and authentication rules to facilitate modification for frequently changeable requirements of research groups.

By the observation of existing paper-review system, rules used in paper systems could be classified into Process Control Rules, Authentication Rules, and Data Verification Rules based on the purpose of rules.

(a) Process Control Rules

Process control rules determine the paper-review process, which can be modified by editors.

A process control rule may have preconditions, which were classified into four types: (i) Configuration Satisfied: the rule could be fired if a specific setting was in the action frame; (ii) Role Satisfied: the rule could be fired for specific roles; (iii) Paper State Satisfied: the rule could be fired if the targeted paper was in specific paper states; (iv) Important Date Before: the rule could be fired in specific dates. For example, the resubmission deadline may be a month later when the paper state was

“revise”. The important date could be a real date, such as the paper submission deadline was 2010/09/30; (v) Action Satisfied: the rule could be fired after some actions performed and generated the fact in the FC-tuple of action frame (see Definition 2).

If the preconditions were satisfied, four kinds of actions could be triggered: the action allowing the execution of specific actions; the action setting specific paper states; the action setting the anonymity under specific action; and the action sending messages by E-mail. The structure of process control rules was shown in Figure 3.4.

Example 3.2: Process Control Rule

If the end-user’s role was Reviewer, and there was any Reviewer Review action frame which the Reviewer slot (See Figure 3.3(b)) pointed to this end-user then she/he could review paper.

14 Figure 3.4: The Structure of Process Control Rules

(b) Authentication Rules

Files in a paper-review process had various accessing permissions for roles.

For example, a paper under reviewing could only be accessed by a reviewer and an editor. In the system, authentication rules, defined by editors, could control these accessing principles. As shown in Figure 3.5, preconditions of an authentication rule had three types: (i) Role Satisfied: the access was permitted for specific roles; (ii) Paper State Satisfied: the access of a paper was permitted if the paper was in specific states (the State slot in Figure 3.3(a) Paper Frame). The permitted actions were accessing, downloading, modifying, or removing a specific resource.

Example 3.3: Authentication Rule

If the end-user’s role was Editor, or the State slot of Paper frame was Public then this end-user could access this Paper frame.

Figure 3.5: The Structure of Authentication Rules

(c) Data Verification Rules

The user-generated data, such as information of a new paper or a new account were required to be verified to prevent wrong inputs. Thus, data verification rules, as shown in Figure 3.6, were defined to verify user-generated data in resource frames’

slots. The preconditions of these rules had four types: (i) Not Empty: the input was allowed if a specific value was not empty; (ii) Is Valid Date: the input date was allowed if it had a correct format or in the valid duration; (iii) Is Valid Email: the input

15

E-mail was allowed if the E-mail’s format is correct; (iv) Value in […]: the input data was allowed if it was in a range which defined by user; (v) Resource Exist: the input data was allowed if the referred resources were exist. If the input data was valid, these rules could allow user to generate paper, generate a message, or add a new account.

Otherwise, data verification rules could reject inputs and give tips to users.

Example 3.4: Data Verification Rule

If the end-user’s role was Editor, or the State slot of Paper frame was Public then this end-user could access this Paper frame.

Figure 3.6: The Structure of Data Verification Rules

In the end of this chapter, this thesis introduced an example of a scenario with the author submitted paper. The scenario was shown in Figure 3.7.

Figure 3.7: The scenario with author submitting paper in a paper-review system

When the author started to submit paper, inference engine got the configuration in New Submit Paper frame (action frame) and the structure of Paper frame (resource frame). Author provided the information of paper such as Title, Abstract, Category, etc. (see Figure 3.3(a) Paper frame).

When author submitted, inference engine inference the data verification rules defined in Paper frame to check if the content of new Paper frame was valid. If not, rejected this submission and tipped to author, otherwise, generate new instance of Paper frame (data verification rule).

After frame was generated, inference engine inferred the new state of the paper,

16

and mails needed to be sent through the process control rules. In this example, the paper state might be set as “wait-for-review”, a mail sent to author for keeping track of his paper after submitting, another mail sent to editor as a notification after the paper state set as “wait-for-review”. After submitted, the author could access this paper, but another end-user was not editor or an author of the paper could not (authentication rules).

Through the user logging in and submitting scenario, this thesis presented a typical example of rules inference (verify papernew paper statenotify editor). Of course, different research group might have different frames/rules setting. They could generate another process of submitting paper by modifying the frames/rules.

17

Chapter 4 Roles Setting with Role-Based Access Control