The Conference Review System with WSDM

1. The Conference Review System with WSDM Olga De Troyer Sven Casteleyn WISE Vrije Universiteit Brussel

2. The approach of WSDM Audience-driven rather than data-driven • Starting point: requirements of the different users/audiences • Next:model the requirements step by step • Later on: map requirements on available data © Prof. Dr. Olga De Troyer 2001

3. The approach of WSDM (2) • Explicit Conceptual Designphase • Different presentations possible • Design not biased by current implementation limitations (e.g. HTML) • Conceptual Design (schema) may be available to • the users • search engines © Prof. Dr. Olga De Troyer 2001

4. Audience Modeling Conceptual Design Implementation Design Implementation WSDM Overview Mission Statement Specification © Prof. Dr. Olga De Troyer 2001

5. Mission statement: • purpose • target audience • subject Mission Statement Specification Mission Statement Specification © Prof. Dr. Olga De Troyer 2001

6. Mission Statement - CRS Example • Purpose • To support the paper selection process • Target Audience • Authors, PC-program Committee • Subjects • papers for the conference Conference Review System (CRS) example “To support the overall selection process (submission by authors, evaluation and selection by the Program Committee) of papers for a conference” © Prof. Dr. Olga De Troyer 2001

7. Audience Modeling WSDM Overview Mission Statement Specification © Prof. Dr. Olga De Troyer 2001

8. Audience Modeling Audience Class Hierarchy Audience Classification Audience Characterization Audience Modeling • Audience Class • Users similar in terms of their information- and functional requirements. • Audience classes need not be disjoint © Prof. Dr. Olga De Troyer 2001

9. How? Audience Classification - CRS Example CRS example Target Audience:Authors, PC-program Committee Audience classes • Author • PC-Chair • PC-Member • Reviewer © Prof. Dr. Olga De Troyer 2001

10. Paper Selection PC-Chair PC-Members Entering Review Notification of Author Assignment of Papers Authors Paper Submission Reviewers Identifying Audience Classes • Step 1:Consider the activities of the organization related to the purpose of web site © Prof. Dr. Olga De Troyer 2001

11. Identifying Audience Classes (2) • Step 2 : For each activity 2.1 Identify people involved 2.2 Restrict them to target audience 2.3 Divide them into audience classes based on different information or functional requirements © Prof. Dr. Olga De Troyer 2001

12. Identifying Audience Classes step 2 - CRS (1) Requirements • Authors Functional requirements: • Submit paper info and upload file • Change submission until submission deadline • Pre-register Co-author Information requirements: • Information about the author’s submissions © Prof. Dr. Olga De Troyer 2001

13. Identifying Audience Classes step 2 - CRS (2) • PC Chair Functional requirements • Create conference • Update Conference information • Pre-register PC Members • Pre-register reviewers • Indicate conflict of interest for papers • Open list of submitted papers for PC Members when submission deadline has been reached • Assign papers to PC Members (based on preferred papers and preferred tracks and subjects) • Inform PC-Members about papers assigned to them • Change track or topic of a submitted paper • Open virtual PC meeting • Mark paper as accepted, not accepted or undecided until all papers are either accepted or not accepted • Close virtual PC meeting © Prof. Dr. Olga De Troyer 2001

14. Identifying Audience Classes step 2 - CRS (3) • PC Chair (2) Information requirements • All available information on the conference • All available information on papers • All available information on authors • All available information on PC-members • All available information on reviews • During PC meeting: statistics about the reviews Navigation requirements • Easy navigation from an author to his papers; from a paper to its reviews; from a review to the PC-member and reviewer; from a paper to its authors; from a review to the paper © Prof. Dr. Olga De Troyer 2001

15. Identifying Audience Classes step 2 - CRS (4) • PC Members Functional requirements • Indicate preferences for tracks and subjects • Pre-register reviewer • Indicate interest in and conflict with proposed papers when list of papers is available • Re-assign paper to reviewer • Download papers assigned to him • Submit review • Change review if not final and until review deadline • Advice PC chair during PC meeting Information requirements • Easy navigation from an author to his papers; from a paper to its reviews; from a review to the PC-member and reviewer; from a paper to its authors; from a review to the paper © Prof. Dr. Olga De Troyer 2001

16. Identifying Audience Classes step 2 - CRS (5) • PC Members (2) Information requirements • List of papers • Own reviews • State of reviews of papers PC Member is reviewing himself, after he submitted his own • During PC meeting: all reviews and statistics © Prof. Dr. Olga De Troyer 2001

17. Identifying Audience Classes step 2 - CRS (6) • Reviewers Functional requirements • Download papers assigned to him • Submit review • Change review if not final and until review deadline © Prof. Dr. Olga De Troyer 2001

18. Identifying Sub Audience Classes • Sub-audience class • The members have all the requirements of the super audience class + additional requirements CRS example • Requirements of Reviewers is subset of requirements of PC-Members • PC-Member sub-audience class of Reviewer © Prof. Dr. Olga De Troyer 2001

19. Identifying Audience Classes (3) • Step 2 :For each activity 2.1 Identify people involved 2.2 Restrict them to target audience 2.3 Divide in audience classes based on different information or functional requirements 2.4 Decompose activity if possible 2.5 Repeat until no new audience classes or no further decomposition © Prof. Dr. Olga De Troyer 2001

20. CRS example • Visitor Information requirements • General information about the conference The Audience Class Hierarchy • Top of the audience class hierarchy is always the class Visitor • Visitor groups together all requirements common to all audience classes © Prof. Dr. Olga De Troyer 2001

21. The Audience Class hierarchy - CRS example Visitor Author PC Chair Reviewer PC Member © Prof. Dr. Olga De Troyer 2001

22. CRS - Example • Registered UsersSecurity requirements • Logging in • Pre-Registered UsersSecurity requirements • Logging in • Not-Registered UsersSecurity requirements • Register The Security Class Hierarchy • A different Class Hierarchy to model the security aspects • The Security Class Hierarchy © Prof. Dr. Olga De Troyer 2001

23. The Security Class Hierarchy- CRS example Visitor Not-Registered User Registered User Pre-Registered User © Prof. Dr. Olga De Troyer 2001

24. Confirm Registration Registered User OR Pre-Registered User Registered User OR Pre-Registered User Registered User OR Not-Registered User Author Reviewer PC-Member Author Register Registered User Registered User Registered User Pre-Registered User Not-Registered User Relationships between the classes © Prof. Dr. Olga De Troyer 2001

25. Audience Class Hierarchy Audience Modeling Audience Classification Audience Characterization • Audience Class • Description • Requirements: • Information • Functional • Usability Audience Modeling - Output © Prof. Dr. Olga De Troyer 2001

26. Audience Class Hierarchy Audience Modeling Audience Classification • Audience Class • Description • Requirements: • Information • Functional • Usability • Characteristics Audience Modeling - Output Audience Characterization © Prof. Dr. Olga De Troyer 2001

27. Audience Characterization - CRS Example Audience Class Visitors: • Characteristics • Older than 20; • Have reasonable experience with web sites; • Are able to communicate in English; • Professionals. © Prof. Dr. Olga De Troyer 2001

28. English Speaking Dutch Speaking Students Audience Class Variants • Differences in usability requirements or in characteristics within one audience class:Audience Class Variants © Prof. Dr. Olga De Troyer 2001

29. The conceptual The conceptual “How” “What” Next Step: Conceptual Design Mission Statement Specification Audience Modeling Conceptual Design Information Modeling Functional Modeling Navigational Design © Prof. Dr. Olga De Troyer 2001

30. Conceptual Design • Information Modeling • For data intensive web sites • What kind of information • Functional Modeling • For application type of web sites • What functionality • Navigation Design • How to navigate through the information and the functionality © Prof. Dr. Olga De Troyer 2001

31. Information Modeling Audience Class Author: • Information requirements • Information about the author’s submissions Information Chunk C1 ER, OMT, ORM, ... © Prof. Dr. Olga De Troyer 2001

32. Using Information Chunks • Step1: Elaborate the information requirements into elementary information requirements. • Step 2: For each elementary information requirement make an Information Chunk. © Prof. Dr. Olga De Troyer 2001

33. Elaborate Information Modeling - CRS Example For each paper submitted by the author either as main author or as co-author allow to give: • Paper-id, title, abstract, main author (name) and co-authors (names), track and if available the subjects, and file (url) containing the paper. “Information about the author’s submissions” © Prof. Dr. Olga De Troyer 2001

34. Make Elementary requirements Information Modeling - CRS Example (2) For each paper submitted by the author either as main author or as co-author allow to give: • Paper-id, title, abstract, main author (name) and co-authors (names), track and if available the subjects, and file (url) containing the paper. 1.Give paper-id and title of all papers submitted by the author as main author or as co-author and allow the user to select a paper. 2. For a paper give: Paper-id, title, abstract, main author (name) and co-authors (names), track and if available the subjects, and file (url) containing the paper. © Prof. Dr. Olga De Troyer 2001

35. identifier PersonName Person with of Non Lexical Object Type roles Lexical Object Type a mandatory role Object Role Model (ORM) - Notation • Object Role Modeling (ORM) • Object Types (OT) • Binary relationships composed of (two) roles © Prof. Dr. Olga De Troyer 2001

36. PersonName ‘Casteleyn’ Person *p Paper {*p} PersonName ‘Casteleyn’ Person *p with of PersonName ‘Casteleyn’ with *p Person of ‘Casteleyn’ Object Role Model (ORM) - Extra Notations • Referents for instances • Relations between instances © Prof. Dr. Olga De Troyer 2001

37. Paper !!{*p} Paper !{*p} Object Role Model (ORM) - Extra Notations • Selecting instances • One Instance: ! • More Instances: !! © Prof. Dr. Olga De Troyer 2001

38. Information Chunk - CRS Example (1) © Prof. Dr. Olga De Troyer 2001

39. Information Chunk - CRS Example (2) © Prof. Dr. Olga De Troyer 2001

40. Functional Modeling Audience Class Author: • Functional requirements • Submit paper info and upload file Functional Chunk C1 © Prof. Dr. Olga De Troyer 2001

41. Using Functional Chunks Similar to Information Modeling • Step1: Elaborate the functional requirements into elementary requirements. • Step 2: For each elementary requirement make a Functional Chunk. © Prof. Dr. Olga De Troyer 2001

42. Elaborate Functional Modeling - CRS Example Submit New Paper • Register New Paper • Add co-author • Submit Paper info and upload file “Submit paper info and upload file” © Prof. Dr. Olga De Troyer 2001

43. Functional Modeling - CRS Example (2) • Make Elementary • 1.Register New Paper • The user enters the title of the paper. The system will generate and return a new paper id for this paper and assign the author as main author for this paper. • 2. Submit Paper Info and File • The user enters the abstract, track, subjects and indicate the file that need to be uploaded. The system will automatically record the date of the submission and the date of the last modification. • 3.Add Co-author • The user enters the name of a co-author of a given paper. The system will pre-register this co-author by generating and returning a new username and password for this author. The author will be added as co-author for the given paper. © Prof. Dr. Olga De Troyer 2001

44. ORM - Extra Notations (2) • ?and??for interactive input • = for assigning values, e.g. *t = ? • ® for updating values, e.g. *t ® ? • ® Øfor removing information, e.g. *{p}® Ø • ==for testing equality of values • is to test membership of an Object Type • exist to test on the existence of an instance • NEW to generate a new OT instance • REMOVE to remove an OT instance • If, for each, and, or, not, union, minus, … as usual © Prof. Dr. Olga De Troyer 2001

45. Functional Chunk - CRS Example (1) © Prof. Dr. Olga De Troyer 2001

46. Functional Chunk - CRS Example (2) © Prof. Dr. Olga De Troyer 2001

47. Linking the Information Chunks Information Chunk C1 Business Information Model © Prof. Dr. Olga De Troyer 2001

48. Business Information Model (1) © Prof. Dr. Olga De Troyer 2001

49. Business Information Model (2) © Prof. Dr. Olga De Troyer 2001

50. Business Information Model (3) © Prof. Dr. Olga De Troyer 2001