Computer science educators are involved with SIGCSE Symposia primarily as authors and reviewers. A general description of such activities is available through the paper/reviewing home page.
The following figure provides an overview for the main user-oriented processes.
Authors submit papers to the Symposium. Paper submission can be done either electronically or via hardcopy. For each paper, a form is provided to enter the paper into the database. In the case of electronic submissions, a form also allows the author to review the paper as received. This latter approach is very important, as it implies that authors (not the Program Chair) can be responsible for determining that papers have been received correctly.
In addition to the expected author-based forms, another form is provided for the Program Chair in the case that a paper is received through regular mail but the author has not filled out a hardcopy-submission form.
Finally, after the reviewing process is complete, authors receive notification of the acceptance or rejection of their papers via e-mail. That e-mail also contains copies of referee ratings and comments.
Referees receive notification of which papers to review via e-mail. Referees then view electronic versions of papers through a Web-based interface, and they submit their reviews electronically through another Web-based form.
After the reviewing process is complete, referees receive via e-mail copies of reviews for the papers they reviewed.
Historically, the Program Chair have followed the following rough general schedule, which is a modified version of one written by Bob Noonan, SIGCSE 1999 Program Chair. Information on performing these tasks appears later in this Part.
The following sections describe each of these tasks in some detail.
Most forms and scripts include information about the Symposium's
Updating this information through the various forms and scripts involves both bad news and good news.
The bad news is that HTML documents and forms contain Symposium information in a hard-coded form, as HTML does not allow "include" files for common information. Thus, a Symposium and/or Program Chair will need to review each HTML document, as described below to make needed changes.
The good news is that asp scripts allow "include" files. For example,
More information on specific files may be found in Part III, later in this document.
This section describes the various tables found in the Access database and then outlines how to prepare these tables for a new Symposium.
Paper information is stored in several Access tables:
Referee information is stored in four Access tables:
Additional Symposium information is stored in four tables:
From time to time, a referee asks to be removed from the SIGCSE database. Potentially, this requires removing records from four database tables: Reviewer, ReviewerSubject, PaperRatings, and PaperAssignedSubject. (In most cases, only the first two of these tables are involved, as a referee is unlikely to asked to be removed immediately after completing reviews.)
Script deleteAReviewer.asp performs all these updates. To use this form, begin with the "Delete a Referee" option on the administration form dbAdmin.html. The script then asks for a last name or reviewer number. Supplying this information yields a table entry for checking. Clicking the "Delete" button then performs the operation.
Notes:
When several referees have the same last name, entering a last name displays all matching candidate records, each with its own "Delete" button. Deletions can be made only one referee at a time, using the individual's "Delete" button.
The deletion operation is not reversible once the "Delete" button is clicked for a specified referee. The database is not changed when an individual is displayed; the removal occurs when "Delete" is clicked.
Individualized email messages may be sent to SIGCSE referees, as follows:
NOTE: The dollar sign MUST be in the first position of the new line and the string identifying the type of content must be typed exactly as it appears below. There can be NO SPACES in the string or between the '$' and the string identifier.
At successive points where individualized content is to be inserted, create a new line and again insert an appropriate "flag string" on a line by itself.
The currently available "flag strings" are:
(A sample message text file can be found at "refereeUpdateRequest.txt", in the scripts' directory.)
Notes:
For tracking purposes, a message displays as each email message is sent.
Unfortunately, identifying duplicate entries in the Referee table is a manual process. Sorting the table by last name may help group duplicate entries together, although this may not help when names change or are listed in several ways (e.g., duplicate records may have entries under each last name of a hyphenated name).
On the positive side, referees may be sent current reviewing information, using the $ref-profiile-data option in the letters to referees option for administration. Referees then may use the on-line form refereeRegistration.html to update their own records. This form provides a mechanism for referees to maintain their own data, without the need for intervention by the Program Chair.
Past referees send e-mail to the Program Chair if they do not wish to continue reviewing. For security, it seems best for the Program Chair to delete such referee entries manually. This task may be done using the "Delete a referee" option of the administration form dbAdmin.html.
Inevitably, as e-mail addresses change, some e-mail messages to past referees will bounce. One approach to this problem is use the web to try to locate a corrected e-mail address, change the address in the full database, and the use the letters to referees option -- designating the individual as the only recipient. Alternatively, records of those yielding bounced e-mail messages may be deleted from the database, using the "Delete a referee" option of the administration form dbAdmin.html.
Authors of hardcopy submissions are asked to complete an on-line form, paperSubmissionHardcopy.html, which will enter the paper into the database. In most cases, authors complete this work promptly, and a Program Chair need not interact further with the database when a hardcopy paper is received. (The Program Chair may choose, however, to send an e-mail note confirming receipt of the paper.)
If a hardcopy submission arrives and has not been recorded in the database, this task may be done using form paperSubmissionAdmin.html. (The form also is available through a link from the administration page, dbAdmin.html .) The paperSubmissionAdmin.html form automatically generates an acknowledgement to the author.
Program Chairs are advised to keep hardcopy submissions in paper-number order, until they are distributed to referees later in the process.
Since information on all papers and all potential referees is available in the database, the assignment of referees to papers can be done on-line. The process typically follows two steps:
Both the tentative assignment and the review may be done using forms and scripts accessible from successive options on the administration form dbAdmin.html.
To tentatively assign referees to papers, use the "Assignment of Referees to Papers" option on dbAdmin.html.
SIGCSE 1999 Program Chair, Bob Noonan, and others have suggested that the paper assignment begin with papers from categories with few referees. (There is considerably more flexibility when papers fit into subject categories with many referees.) To start, click on the "View data" option on the assignment page. This displays the number of papers and the number of referees available for each subject area. Clicking on a subject then displays all papers, which have been classified by the author as fitting in that subject area.
Clicking on a specific paper gives some information about the paper, together with a listing of all referees who have indicated some expertise in any of the paper's subject areas. (Some referees have not identified specific subjects of interest, and such undesignated referees appear at the bottom of the display.) The referees appear in increasing order of the number of reviews already assigned to them, so referees with few previously-assigned reviews appear at the top.
In addition to a referee's name, the assignment form displays the referee's institution, state, and number of previously-assigned reviews, together with a flag ("YES", "no") showing if the referee has previously been assigned to the current paper. As one might guess, Button "Add" allows a new referee to be assigned the current paper to review, while Button "Delete" removes the assignment of a current reviewer of a paper.
After assignments have been made or modified, click the "Update" or "Update and Next" button at the top of the page to make the changes in the database.
While various assignment algorithms can work quite well, some common-sense guidelines might include:
Since the assignment form includes both institution and state information, checking the guidelines during the assignment process is easy.
With the reviewing option, one first specifies an initial paper or referee to review. Buttons then allow sequential review by paper or referee (respectively).
Alternatively, to check the breadth of workload for each referee in the database, one could use the "View Database" option from dbAdmin.html, and view the "Reviewer" table. Clicking once on the numRevs will sort the referees in ascending order by the number of reviews assigned to them. Click a second time orders in descending order.
While each Program Chair will make her or his own policy decisions, it seems highly desirable for each referee to have at least 1 or 2 reviews, so no referee feels left out.
Once referees are assigned to papers, the e-mail to referees script may be used to notify referees of their assignments via e-mail. This should handle all notification duties for the on-line papers.
For hardcopy papers, an Access query is available to generate mailing labels for the relevant referees. The labels then may be run on a standard printer. [Additional information on this is forthcoming.]
All reviewing is done on-line, with referees using an on-line reviewer form. Scripts handle the recording of the reviews as they come in.
Some Access queries allow the compilatin of referee statistics and ratings. More information on this subject is forthcoming.
The organization of papers, panels, etc. into sessions is a manual process. Final session descriptions should be entered manually into the DayTime, Session, and SessionPaper tables within the database.
Once the program is entered, script program.asp produces an on-line summary of the program, together with information about individual sessions. Separate links to listings of panels, special sessions, or workshops should be inserted into the script.
Since a draft program is available on-line as soon as it is entered, a Symposium Committee might be asked for scheduling feedback before the program is announced to the community at large.
For papers submitted electronically, notification of authors proceeds in two main steps:
While this work could naturally be combined in one script, the multi-step format allows double checking of papers in each category before formal notifications are sent out.
Acceptance letters should contain information on copyright, style, A/V availability, scheduling, presentation details, the existence of a speakers' breakfast, and the need for the presenting author to register for the Symposium. The e-mail letter should indicate that a snail-mail letter can be sent to the primary author, if that would be helpful professionally.
While snail-mail acceptance letters can be sent to primary authors upon request, these letters are not sent automatically.
Since script program.asp produces on-line versions of the program, the Proceedings Chair may view this material on-line as soon as it is entered.
While session chairs may be selected following many criteria, there may be some advantage in identifying those not otherwise on the program who need some status in order to get travel funds. In this regard, authors of rejected papers may be given some priority.
To record a Session Chair in the database, the individual must be registered as a referee. The person's reviewer ID then should be entered in the Session table, so this assignment is visible in the program.
While transparencies for sessions may be made in several ways, one approach is to utilize the individual session information available on the Web through the program.asp script. While not fancy, the output is fairly reasonable, either as is or magnified slightly with a copier. The resulting transparency should be sent to the registration folks for stuffing into the registration envelopes of Session Chairs and Panel Moderators.
This part describes files created and/or used in the project. Conceptually, these files may be placed in three basic categories:
At a more detailed level, the pages, forms, and scripts fit together as follows:
| Category | Initiating Form/Graphic | Script |
|---|---|---|
| Information Pages | index.html | |
| call.html | ||
| 2001committee.html | ||
| paperInformation.html | ||
| otherConf.html | ||
| forthcoming.html | ||
| documentation.html | ||
| Graphics Files | ACM-logo.gif | |
| symposium2001-logo.gif | ||
| userProcess.gif | ||
| Database, Test Database, and Database Viewing | dbAdmin.html | sigcse2001.mdb |
| sigcse2001tst.mdb | ||
| peek.asp | ||
| peekAndEdit.asp | ||
| peekAndEditNew.asp | ||
| peekAndReview.asp | ||
| peekAndReviewNew.asp | ||
| databasePick.asp | ||
| tabled.asp | ||
| Paper Submission and Security | paperSubmission.html | AspUser.inc |
| AuthorizationFailure.asp | ||
| secure1.asp | ||
| secure2.asp | ||
| updateAuthor.asp | ||
| updateAuthorHardcopy.asp | ||
| updateAuthorAdmin.asp | ||
| vbFileManagerInclude.asp | ||
| Paper Viewing | authorViewing.html | paperView.asp |
| refereeViewing.html | makeFolder.asp | |
| refereeViewingAlt.html | ||
| Referee Registration | refereeRegistration.hmtl | refereeRegistrationNew.asp | refereeRegistrationUpdate.asp | refereeRegistrationAction.asp |
| Assignment of Referees to Papers | dbAdmin.html | RefAssign.asp | SubjectCount.asp | SubjPapers.asp | RefAssignCat.asp | PaperAssign.asp | UpdateReviewAssign.asp |
| Reviewing Assignment of Referees | dbAdmin.html | ReviewRefAssign.asp | CheckReviews.asp | CheckPapersReviewers.asp | CheckReviewerspapers.asp |
| Send Letters to Referees | dbAdmin.html | refMessageSender.asp | #emailRefereeRecruit.asp |
| Submission of Reviews | reviewForm.html | updateReviews.asp |
| View Program Sessions | *program.asp | *sessionPanels.asp | *sessionPapers.asp | *sessionSeminars.asp | *Program_at_a_glance.asp | *programPapers_Authors.asp | *programPapers_Titles.asp |
| Send Notification to Authors | *dbAdmin.html | *sendNotifications.asp | *sendAcceptances.asp | *sendRejections.asp |
# indicates script currently being expanded
* indicates file/script not updated since SIGCSE 2000 and thus not
currently available.
Informational pages provide the SIGCSE community with a wide variety of general material. While details will vary with each Symposium, these are the informational pages found at the main SIGCSE 2001 Symposium site:
These pages, in turn, use the following graphics -- also located in the Symposium's home directory (unless otherwise stated):
HTML forms provide the starting point for performing various functions such as collection of referee information and viewing of submitted papers. These forms are stored in a common, public_html directory, which may be independent from the location of the various scripts. There are six different forms:
The informational pages are found on a main HTML directory. As this data will be downloaded to user's browsers on a wide variety of platforms, this main HTML directly may be placed on any type of server. (In contrast, scripts are written in asp and interact with a Microsoft Access database. This requires the scripts and database to be stored on a Windows platform.)
The various pages provide standard Symposium announcements, and this material may grow as the Symposium gets closer. The starting documents are described below. Normally, the Symposium Chair is responsible for writing and updating these documents, except that the Program Chairs maintains paperInformation.html.
index.html is the main Symposium page, giving general information and links to more detailed pages.
call.html is the on-line Call for Participation. This duplicates the Call in hardcopy form which is distributed at the previous Symposium and mailed in June to all SIGCSE members. The Call contains links to the detailed pages for papers, panels, workshops, special sessions, birds-of-a-feather sessions, faculty posters, SIGCSE's Doctoral Consortium, and ACM's Student Research Competition. For each of these areas, the Call also provides a contact person and e-mail address.
2001committee.html gives the name of all committee members, links to their home pages, and their e-mail addresses. Also, the page contains a link for each activity (e.g., papers, panels, workshops, etc.)
paperInformation.html provides complete paper-submission information, including formatting information and procedures. This page should be maintained by the Program Chair.
otherConf.html provides links to other conferences related to computer science education, including SIGCSE's European and Australian conferences.
forthcoming.html is a default page, used as a link before specific information on a topic is available. For example, when the conference's home page is first created, titles might be desired for the host city. Such titles can link to this "Forthcoming" page, until more details are available.
documentation.html is this document. It is hoped that this material provides reasonably detailed information on processes for papers, reviewing, and administration.
File name: referee-registration.html
This form is for updating information for existing referees and registering information of new referees. Referees who wish to delete their names from the SIGCSE database need to email SIGCSE.The form does the following error checks for the fields when data is being entered:
| Field | Type of Error Checking |
| Last Name | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| First Name | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. | Department | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Institution | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Database Update Category | None |
| Referee Number | The number is positive |
| Referee Password | None |
| Address1 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Address2 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Address3 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| City | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| State/Province | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Zip | None |
| Country | None |
| Phone Number | All characters entered are non-blank, numeric or dashes (-). Also the minimum number of characters entered is 8. |
| All characters entered are non-blank, there are at least 7 characters entered and one of the characters entered is the @ symbol. | |
| Areas of Expertise | None |
The form also checks that the following fields are entered before it submits:
Last Name, First Name, Department, Institution, Update Category, Address1, City, Referee Number and Referee password if the information is for database update, Zip Code and State/Province if country is Canada or US and at least one area of expertise is specified.
During the submission of the form, the form calls refereeupdate.asp
script. All the fields are stored in the Person table except for
the areas of expertise information which are stored in the Reviewer_Subject table.
File name: author-viewing.html
Authors may view either the full or anonymous versions of their papers by
entering the paper number and the password for that paper. The form does
no error checking, but calls the paper-view.asp script. This script
displays a paper only if the password is valid for the given paper number.
If passwords are given for both versions of the paper, then the anonymous
version is displayed in the browser.
3. Referee Viewing Form
File names: referee-viewing.html or referee-viewing-alt.html
Referees may view the anonymous version of a paper by entering the paper's number and password. The form checks that the paper number is a number, and the form removes initial and final white space from both the number and password.
Upon submission of a paper, referee-viewing.html calls the referee-view.asp script, which checks the user has authorization to read the paper. This form also opens a new browser window, for viewing the review-form.html. This allows a referee to read the paper in one browser window while filling out the review form in a second window.
Alternative form referee-viewing-alt.html also calls the referee-view.asp script. However, to allow referees to run their work on a wider range of browsers, this alternative script does not automatically open a second browser window for the review form.
File name: review-form.html
This form is for submission of referees reviews.
The form checks that the following fields are entered before it submits:
Paper Number, Paper Title, Referee Number, Level of Referee's
familiarity with the topic of the paper, at least one topic of the
paper is specified, each category rating and comments for each
category. If the referee does not submit any comments, the form will remind
the referee to fill in the boxes once. Thereafter, the form can be
resubmitted without comments.
During the submission of the forms, the form calls updateReviews.asp
script. Before storing the information the script first checks if the
submitted
review is legitimate i.e. the referee is submitting an assigned
review. This check is done by checking if there is a corresponding referee
and paper number pair in the Paper_Reviewer table. After checking,
all the fields are stored in the Paper_Ratings table except for
the hidden field reviews Received which is stored in the Paper_Reviewer table.
File name: paper-submission.html
This form is for submission of papers. Then author needs to submit their own the co-authors' information as well as the filenames of the full paper and anonymous version of the paper. The form does the following error checks for the fields when data is being entered:
| Field | Type of Error Checking |
| Primary Author Information | |
| Last Name | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| First Name | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or { and there are at least two allowed characters entered. |
| Department | None |
| Institution | None |
| Address1 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or {. |
| Address2 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or {. |
| Address3 | All non-blank characters entered are alphabetic or numbers or one of the following symbols and punctuation marks: / . ' - & } or {. |
| City | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or {. |
| State/Province | All non-blank characters entered are alphabetic or one of the following symbols and punctuation marks: / . ' - & } or {. |
| Zip | None |
| Country | None |
| All characters entered are non-blank, there are at least 7 characters entered and one of the characters entered is the @ symbol. | |
| Co-Authors Information | |
| Last Name | None |
| First Name | None |
| Department | None |
| Institution | None |
| All characters entered are non-blank, there are at least 7 characters entered and one of the characters entered is the @ symbol. | |
| Paper Information | |
| Title | None |
| Filename for the full paper | It must end in .htm or .html |
| Filename for the anonymous version of the paper | It must end in .htm or .html |
The form also checks that the following fields are entered before it submits:
For primary author:
Last Name, First Name, Department, Institution, Address1, City, E-mail
address, Zip Code and State/Province if
country is Canada or US.
At least one Focus of the paper is specified, Title and Type of paper, Filenames for the full
version and anonymous version of the paper.
The form also checks if the Filenames for the figures and other
supplementary material end with .gif or .jpeg.
Relation to scripts is forthcoming.
6. Database Administration Form
File name: db-admin.html
This form organizes several administration tasks by providing a common interface for several scripts. Each database task requires a password, but the form does no error checking.Task: Viewing the Database Each database table may be viewed. Clicking on a field name sorts the table in ascending order by that field; clicking a second time on the field sorts the table in descending order.
The filer option allows one to select specific records from a database table.
The row+ and row- options alter how many records are displayed per page in the browser.
This task is performed by the peek.asp script.
Task: Assigning Passwords to Referees For security, referees can update their records only if they supply the password for their record number. This script assigns passwords to records which are currently blank. Existing passwords are not changed.
This task is performed by the referee-passwords.asp script.
Task: Send Information to Referees about their Database Entry To facilitate database maintenance, e-mail may be sent to each referee in the database with the individual's database information. This allows each referee to review her or his own data and invites the individual to make changes through the referee registration form. By sending information to referees and asking them to make corrections, the Program Chair need not make updates manually.
This sending of e-mail is performed by the email2referees.asp script.
This script sends email to assigned reviewers who have not submitted their reviews. The script extracts email address, paper number, title and password information from ReviewsNotReceived table. ReviewsNotReceived table has to be updated by executing MakeReviewsNotReceivedTable query before sending emails.
This script sends emails to all the primary authors of accepted papers. The script extracts email address and paper title information from Accepted_Paper table. Accepted_Papers table has to be created by executing MakeAcceptedPapersTable query therefore this query has to be executed before sending emails.
*** The above and SendRejection scripts might also be used to send ratings and comments to papers primary authors.
This script sends emails to all the primary authors of rejected papers. The script extracts email address and paper title information from Rejected_Paper table. Rejected_Papers table has to be created by executing MakeAcceptedPapersTable query therefore this query has to be executed before sending emails.
This script is used to store the information from Referees Registration
Form in appropriate tables. For new referees, the script just add an entry
in the tables. In case of an update, the script checks that the personId
and password match before updating the person record.
This script is used to send e-mails to all the referees listed in the original database. The e-mails invite the referees to be referees again for SIGCSE 2000, and ask them to review their information stored in the database. They can update it by filling the Referee Registration Form with their referee number and password, or if they decide not to be referee again, they can send e-mail to the program chair. The script extracts the e-mail address of every referee from the Person table first, and if there is an valid e-mail address for the referee, extracts all of his/her other information also, and includes them in the message.
This script is used to store the information retrieved from Referee Review Form into Paper_Ratings table and Reviewing_Subject table. It first checks if the pair of personId and paperId the referee submitted matches any entry in the Paper_Reviewer table, if not, that means the referee has no authorization to review this paper, and a failure warning page is given back to the referee. If the check passes, go on to retrieve all the ratings and comments, and store them in the appropriate fields in the Paper_Ratings table, and store the categories of the paper to Reviewing_Subject table.
| Fields | Description |
| personId | primary key |
| firstName | first name |
| lastName | last name |
| department | department |
| institution | institution |
| password | for safety, a referee must submit this password in order to update the record |
| addr1 | first line of address |
| addr2 | second line of address |
| addr3 | third line of address |
| city | city |
| state | state |
| zip | zip code |
| country | some of the referees and authors are from foreign country |
| phone | phone number |
| e-mail address | |
| reviewer | to distinguish referees and authors: Yes for referee; blank for author |
| emVerify(Yes/No) | to determine if the e-mail address is valid |
| dbUpdate | New: referee data entered recently Update: referee data changed recently No: referee data stored for some time |
| Fields | Description |
| personId | relates to Person table by this field |
| subjectId | relates to Subject table by this field |
| Fields | Description |
| paperId | identifies paper number number. The number is automatically generated and is unique for each paper. |
| title | the title of the submitted paper. |
| accept | indicates if the paper has been accepted to be presented at the conference. The allowed entries are Yes or No. |
| cameraReady | ???? |
| FullPaperName | the name given to the paper version which includes authors information (full version of the paper) |
| AnonPaperNAme | name given to the anonymous version of the paper |
| submitdate | date the paper was submitted |
| folder | the name of the folder which contains all both versions of the paper |
| fullpass | passord to access the full version of the paper |
| anonpass | passord to access the anonymous version of the paper |
| type | indicates the type of paper submitted. The allowed entries are regular or expository. |
| status | indicates the status of the paper. For the time being the allowed entries are withdrawn or submitted. |
| Fields | Description |
| paperId | indicates the paper number |
| personId | indicates person number for the paper author |
| primary | indicates if the author is the primary author. The allowed entry is yes. |
| Fields | Description |
| paperId | relates to Paper table by this field |
| subjectId | relates to Subject table by this field |
| Fields | Description |
| subjectId | key to relate to other tables |
| subjectDescription | different categories' names |
| Fields | Description |
| personId | |
| numRevs | |
| hasReviews |
| Fields | Description |
| paperId | identifies paper number |
| personId | identifies the paper reviewer number |
| reviewReceived | indicates if the reviewer has submitted the paper review |
| Fields | Description |
| reviewNum | to keep track of different reviews |
| paperId | assign to referee so that they can have access to the paper |
| personId | Referee's personal ID |
| Title | title of the paper |
| Familiarity | referee's familiarity of the topic the paper directs toward |
| Tech | rating on technical contents of the paper |
| Org | rating on organization of the paper |
| Orig | rating on Originality of the paper |
| Sig | rating on significance of the paper |
| overall | rating on overall recommendation of the paper |
| TechComment | comments on technical contents of the paper |
| OrgComment | comments on organization of the paper |
| OrigComment | comments on originality of the paper |
| SigComment | comments on significance of the paper |
| OveComment | comments on overall recommendation of the paper |
| OralPre | suggestion for oral presentation |
| Private | confidential comments to the committee |
| Fields | Description |
| reviewNum | relates to Paper_Ratings table by this field |
| paperId | to identify papers after we calculate the average scores of the same papers |
| subjectId | relates to Subject table by this field |
| Fields | Description |
| paperId | identify the paper not reviewed |
| personId | identify the reviewer who has not submitted a review papers |
| title | identifies paper title |
| anonpass | the password of the anonymous version of the paper |
| firstName | reviewer first name |
| lastName | reviewer last name |
| reviewer email address | |
| Fields | Description |
| paperId | identify the accepted paper |
| title | identifies paper title |
| accept | field which differentiate accepted papers form rejected ones. This table only has records with this field marked Yes. |
| primary | field which distinguished primary authors from co-authors. This table information concerns primary authors only therefore this filled is marked yes for all records in the table. |
| personId | identifies the paper's primary author |
| firstName | primary author's first name |
| lastName | primary author's last name |
| primary author's email address |
| Fields | Description |
| paperId | identify the rejected paper |
| title | identifies paper title |
| accept | field which differentiate accepted papers form rejected ones. This table only has records with this field marked No. |
| primary | field which distinguished primary authors from co-authors. This table information concerns primary authors only therefore this filled is marked yes for all records in the table. |
| personId | identifies the paper's primary author |
| firstName | primary author's first name |
| lastName | primary author's last name |
| primary author's email address | |
| Fields | Description |
| timeId | |
| day | |
| startTime | |
| endTime | |
| date |
| Fields | Description |
| Fields | Description |
The queries in the database can be divided to three groups according to their different functions.
* submitted in all queries implies that the paper is not withdrawn
Check for duplicates of referees or authors
Check for duplicate reviews of papers
Display papers with <3 or <4 reviews
Display all withdrawn papers
Display all submitted papers
Display all submitted papers primary author
Display all authors of all submitted papers
Display the subjects of all submitted papers
Creates Accepted_Papers table
Creates Rejected_Papers table
Creates ReviewsNotReceived table
Display referees confidential comments for all papers
Display primary authors of all regular papers submitted
Display primary authors of all expository papers submitted
Display all authors of all regular papers submitted
Display all authors of all expository papers submitted
Display regular papers submitted
Display expository papers submitted
Display the subjects of each regular paper submitted
Display the subjects of each expository paper submitted
Display review results by score and average of overall score
Display review results by score within categories
Display review results with lowest overall score dropped
Display review results with lowest weighted score dropped
This document is available on the World Wide Web as
It uses the same procedure with the one above, only replace minOfOverall
with minOfWeightedScore.
C. Reports
http://www.cs.grinnell.edu/~sigcse/2000/documentation.html
| created July 9, 1999 | ||
| last revised July 14, 1999 | by | Henry M. Walker (walker@cs.grinnell.edu) |
| with | Weichao Ma (ma@ac.grin.edu) | |
| and | Dorene Mboya (mboya@math.grin.edu) | |