Business rules, triggered by the PC chair, dynamically change the site view currently active for a ... Designing a data-intensive Web site in WebML amounts to specifying its characteristics in terms ... Composition units are defined on top of the.
Designing multi-role, collaborative Web sites with WebML: a conference management system case study Stefano Ceri, Piero Fraternali, Maristella Matera, Andrea Maurino Dipartimento di Elettronica e Informazione Politecnico di Milano [ceri, fraterna, matera, maurino]@elet.polimi.it
1 Introduction This report describes the design and implementation in WebML of the Conference Management System case study (CMS, from now on), proposed by the organizers of the IWWOST 2001 Workshop. WebML is a visual language for modelling data intensive Web sites, conceived to facilitate the implementation of a novel generation of CASE tools capable of automating the most repetitive tasks of site construction [4]. The fundamental aspects of WebML modelling and design are: 1. The separation of the distinct concerns of site specification: information structure, page composition, navigation, and presentation. 2. The provision of novel visual metaphors for expressing the composition of pages in terms of content units, defined over the objects of the structure schema. 3. The support of advanced features, like derived data, user modelling and personalisation, data entry and update operations, multi-device output. 4. The extensive use of XML and XSL in all aspects of site design and deployment. The highlights of the WebML implementation of the CMS case study can be summarised as follows: 1. A rich structure schema is provided, which captures the fundamental objects of the domain of discourse, as well as the main user roles. 2. Several site views are defined on such structure schema, i.e., hypertext modules offering a different set of pages and functions tailored to the needs of a specific category of users (e.g., authors or PC members). 3. Business rules, triggered by the PC chair, dynamically change the site view currently active for a given class of users, implementing the evolution of the site functions required by the workflow of conference management.
2 The Web Modelling Language Designing a data-intensive Web site in WebML amounts to specifying its characteristics in terms of various orthogonal abstractions, each captured by a distinct model. • The Structural Model describes the conceptual data organization; it is compatible with the Entity-Relationship model. A prominent application of structure modeling is User and Group Modeling, which specifies the information about users and users’ communities maintained in the site to foster personalization. • The Derivation Model enables the extension of the structural model with redundant data, to adapt it to different requirements. • The Hypertext Model enables the definition of the pages and links of the actual hypertext(s), which constitute the application. It is further sub-divided into: o The Composition Model, which concerns the definition of pages and their internal organization in terms of elementary interconnected content units. o The Navigation Model, which describes the links between pages and content units, which should be provided to facilitate information location and browsing. • The Presentation Model enables the expression of default rules for rendering pages in the markup language of choice (e.g., HTML or WML). Presentation rules are coded using XSL style sheets. WebML hypertexts are packaged into modularization constructs called site views. Each site view represents a different application designed to meet a well-defined set of requirements (e.g., the access with a specific device or the interests of a specific user group). The structure, composition, navigation, and presentation models enable the description of readonly web sites. They can be extended to cope with the specification of write access, through the addition of update operations, which can be incorporated into the hypertext model. They are invoked as a side effect of navigation and permit one to specify commonly found interaction patterns as data entry, personal data management, and shopping carts.
2.1 Structure Model The WebML Structural model is a suitable adaptation of conceptual models for data design, as already in use in other disciplines, such as database design, software engineering, and knowledge representation. It is compatible with the Entity-Relationship data model, used in conceptual database design, and with UML class diagrams, used in object-oriented modeling. The fundamental elements of structural models are entities, defined as containers of data elements, and relationships, defined as semantic connections between entities. Entities have named properties, called attributes, with an associated type. Entities can be organized in generalization hierarchies and relationships can be restricted by means of cardinality constraints.
2.2 Derivation Model Derivation is the process of adding redundant information to the structure schema, in order to augment its expressiveness and define different views and groupings of the same data. Derivation is formally expressed by queries in a conceptual language named WebML-OQL, which apply to the elements of the structural schema and construct additional concepts, whose content is intentionally defined instead of being extensionally stored. Every element of the structural model can be derived by means of a query (entities, attributes, and relationships). An important application is the definition of derived entities, which introduces sets of related objects, called collections in some other Hypermedia design methods. By grouping objects with common properties into derived entities, it is possible to provide meaningful access indexes to the site content.
2
2.3 Composition Model Composition modeling specifies which pages compose the hypertext, and which content units make up a page. The pages of the Web site are the containers of information actually delivered to the reader. Units are atomic content elements used to publish the information described in the structure model. Six types of units can be used to compose pages: data, multi-data, index, filter, scroller and direct units. Data units are used to publish the information of a single object (e.g., a paper), whereas the remaining types of units represent alternative ways to browse a set of objects (e.g., the set of papers of a conference track). Composition units are defined on top of the structure schema of the site; the designer dictates the underlying entity or relationship on which the content of each unit is based. The visual notation of the composition units is reported in Appendix A. The typical schema of a WebML page is a graph of units, where data units showing the information content of an entity alternate to the other types of units, which enable various forms of interconnection between related objects. Data units, even if associated to a single entity, may include information from any object defined in the structure schema via derivation. The mapping of entities to data units is one-to-many: the same entity can be associated to different data units, each showing a different mix of features. Therefore, data units define "virtual views" of structural concept, adaptable to specific user requirements or access constraints. Index, multidata, scroller, and filter units are typically used to specify access structures over the site's content, and to cluster several related pieces of information in a page. These units can be defined over 1:N relationships, in which case they permit alternative forms of navigation from one object to a set of related objects. The same units can also be defined over entities, in which case they are used for selecting and accessing one instance of an entity. Finally, direct units are defined over 1:1 relationships, to connect one object to the single object associated to it by a 1:1 relationship.
2.4 Navigation Model The purpose of navigation modeling is to specify links. Links can be defined between the units inside a single page, between units placed in different pages, and between pages. A link may serve the following purposes: 1. Moving the focus of presentation from one page to another one. 2. Passing information from a unit or page to another unit or page. 3. Producing some side-effects (e.g., the execution of an update operation). The information carried along a link is called navigation context, or simply context. Links that carry context information are called contextual links, whereas links that have no associated context information are called non-contextual links (these may serve only purpose n. 1 and/or n. 3). Context information is typically necessary to ensure the computability of a unit's content. For example, a data unit may be defined showing the details of an author, and it may be connected to a second unit showing an index of submitted papers. To compute the list of papers of a specific author, context information (e.g., the author's OID) must be transferred along the link connecting the data unit to the index unit. Composition and navigation models are tightly integrated, because features in one model may affect the other model (e.g., to show a set of related units in a page, proper links must be established). Collectively, they form the hypertext model, which completely defines the information content, and topology of connections of a WebML site.
2.5 Packaging Hypertext Specifications into Site Views Composition, and navigation completely define a hypertext and may be associated to default rendition rules for producing a set of pages in some markup language (e.g., HTML). An 3
application may be published in more than one way, to serve different requirements (e.g., the access with different devices and/or alternative user requirements). Each application perspective is packaged in a modularization construct called site view, which collects a set of pages, units, and links designed for a coherent purpose.
2.6 Modelling the User In order to support personalization, the WebML structure model includes the predefined entities Group and User [3]. Groups describe sets of users with common characteristics, whereas users denote individuals. As for the normal entities, User and Group may be internally sub-structured into attributes and multi-valued components, classified by means of inheritance, semantically related to other entities, and used for writing derivation queries. Typically, user or group data (e.g., the most frequently or recently visited objects) are progressively collected and modified during the Web site evolution as the result of user's actions and choices. WebML assumes that users always belong to at least one group, possibly the default one (called everyone). Each group is associated to a single site view, whereas the same site view may serve different groups. If a user belongs to more than one group, a default group must be indicated, which is used to select the site view to display when the user accesses the site. Switching from a site view to another one requires the (implicit or explicit) re-classification of the user. This can be done dynamically, via explicit or implicit login and logout operations.
2.7 Introducing Write Access and Update Operations In addition to the specification of read-only Web sites, where the user interaction is limited to information browsing, WebML also supports applications requiring write access to the information hosted in a site (e.g., the filling of a shopping trolley or the update of the users' personal information). WebML extends the composition, navigation, and presentation models with additional primitives for expressing data entry forms, built-in update operations and their activation, and the integration of a WebML site with arbitrary external procedures. WebML also offers data entry units, for collecting input values into fields, and operations units for invoking generic external operations implemented by externally available Web services, or for managing and updating built-in content (e.g., creating, deleting or modifying an instance of an entity, or adding or dropping a relationship between two instances) [2]. The visual notation of operation units is reported in Appendix A. More detailed information about the semantics of units, links, and pages in WebML can be found at http://webml.org and in [1].
3 Case Study Specification: a Conference Management System on the Web The Conference Management System (CMS) is aimed at offering support for the process of paper submission, evaluation and selection for publishing within a conference.
3.1 Conference Management Actors Different groups of users may perform activities through the CMS: • The Program Committee Chair (PC Chair) is in charge of managing the whole conference, and establishing the Program Committee, by designating PC members. •
PC Members are in charge of reviewing papers assigned to them by the PC Chair. They also take part to the final discussion about paper acceptance.
•
Reviewers may be designated by PC members for the evaluation of some papers. 4
•
Authors can submit one or more papers.
In order to access the system, all the users, but the PC Chair, must be registered.
3.2 Conference Management Life-Cycle A number of phases can be distinguished in the conference life cycle. Each phase is characterized by a number of activities to be performed by the user groups: 1. Conference set-up: only the Program Chair has access to the system. S/He “creates” the conference, by entering the general information, defining the conference tracks and subjects, and establishing the Program Committee (PC) - s/he pre-registers the PC Members. 2. Paper submission: authors can register to the conference site and submit one or more papers. They can then also modify the paper data. When the submission is closed, authors are not allowed to access the site. During the same phase, PC Members can express their preferences for the conference tracks and subjects. During this phase, the PC members can express their interest about the submitted papers. 3. Paper bidding: PC Members can express their preference for those papers that are submitted to their preferred tracks and have at least one topic matching their preferred subjects. PC Members can also declare conflicts. 4. Paper assignment: taking into account the interests expressed by the PC members about tracks, subjects and conflict papers, the PC Chair assigns papers to the PC members for reviewing. 5. Paper review: once the review process has been opened, the PC members may register other reviewers, and assign them papers for evaluation. Then, the PC members and any reviewer can enter a review for a paper, and are able to modify it, until they declare that the review is “final”. During this phase, any PC member is able to see the other reviews for the papers s/he must review, but only after s/he has entered her/his own review. 6. Final discussion: the PC member can access the entire set of reviews for preparing to the final discussion at the PC meeting. 7. Acceptance notification: the Program Chair declares papers accepted or rejected. The paper acceptance is notified to authors through an email message. Non-registered users and registered users logging into the conference site are routed to a page including the final conference program. The evolution of the conference life cycle is explicitly commanded by the PC chair, whose site view comprises suitable commands for advancing the state of the conference.
4 Structure Modelling The WebML design process starts with the definition of the structure schema, which specifies data organization. In particular, a skeleton is initially defined, which includes basic information objects, able to capture the most relevant concepts of the application domain.
4.1 Identifying the Basic Information Objects As shown in Figure 1, a number of basic information objects and relationships emerge from the case study specifications. The different roles associated to the different user groups and the individual users belonging to each group are respectively represented by the two WebML entities Group and User (note that these entities are added by default to all WebML projects).
5
User_Group User_Preference User_Review
User_Submits_Paper
Explicit_Conflict
User_Track
User_Subject
User_Reviews_Papers
Paper_Track Paper_Preference
Paper_Coauthor
Paper_Subject
Figure 1: The basic relationships in the initial structure schema skeleton. The conference to be managed is described by means of the entity Conference, storing general information about the conference, and two further entities, Track and Subject, which respectively represent the conference tracks and subjects. The papers are represented by the entity Paper, which stores data entered by the author when submitting the paper, as well as derived data about the review results for that paper (for example the maximum, minimum and average grade assigned by reviewers). Moreover, the entity Coauthor allows representing further authors (if any) different from the contact author, who is the only author required to register to the conference site. The entity Preference represents the marks assigned by all the PC members to the submitted papers, which express their level of interest about a paper. The paper reviews, authored and submitted by reviewers, are represented through the entity Review. Figure 2 also shows the attributes that characterize each entity; the data dictionary reported in Appendix B gives more details about the attribute semantics.
6
Figure 2. Structure schema with details about the entity attributes.
4.2 Identifying Relationships The entity User is central to the schema, being connected through several relationships to almost all the other entities. In particular: • The relationship User _Group expresses that each user can belong to one or more groups. The group a user belongs to determines the site views a user can access. •
The relationships User_Track and User_Subject express that a PC Member can declare her/his interest about one or more tracks, and one or more subjects.
•
The relationship Explicit_Conflict, defined between User and Paper, connects each PC member with those papers (if any) for which s/he has raised a conflict of interest.
•
The relationship User_Submits_Paper, defined between User and Paper, connects each author to one or more papers that s/he has submitted
•
The relationship User_Reviews_Paper, defined between User and Paper, connects each PC member or reviewer to one or more papers that s/he has been assigned with.
•
The relationship User_Review connects each PC Member or reviewer to one or more review s/he has submitted.
•
The relationship User_Preference associates each PC Member to the grades s/he has expressed for the different papers.
Other relationships depart from the entity Paper: •
The relationships Paper_Track and Paper_Subject respectively associate each paper to a single track and to one or more subjects.
•
The relationship Paper_Review associates each paper to one ore more (maximum three) reviews, submitted for that papers by PC members ad/or reviewers
7
•
The relationship Paper_Preferences associates each paper to the preference grades expressed for that paper by the PC members.
• The relationship Paper_Coauthor associates each paper to its co-authors (if any). Moreover: • The relationships Conference_Track and Conference_Subject respectively associate the conference with its tracks and subjects.
5 Hypertext Modelling After defining the structural schema, the design process proceeds with the definition of the site views to be associated to the different user groups.
5.1 Identifying User Roles The CMS users taking part to the conference management play the following roles: 1. The Program Chair is responsible for: i) creating the conference, i.e., entering into the system general information, such as name, venue, start and end date, and conference important dates for paper submission, paper review, and acceptance notification; ii) defining the conference tracks and subjects; iii) creating the program committee, by pre-registering the PC members; iv) assigning papers to reviewers based on PC Members’ preferences about tracks and subjects; v) defining the final list of accepted and rejected papers, on the basis of the paper reviews and the discussion with the PC Members. 2. The PC Members are responsible for: i) expressing interest in conference tracks and subjects; ii) expressing their interest in those submitted papers that match the preferred tracks and subject, after the submission procedure has finished; iii) reviewing a set of assigned papers; iv) indicating another person, external to the Program Committee, as a reviewer of a paper. PC members must be pre-registered by the PC Chair (they can subsequently modify their personal profile). 3. The Reviewers are responsible for reviewing one or more papers. Reviewers must be pre-registered by the PC Chair or by any other PC Member. They are not required to express preferences about conference tracks or subjects. 4. The Authors are responsible for submitting one or more papers. They must self-register to the system before submitting any paper. 5. Non-registered users (belonging to the Everyone group) are those users who have no special role in the conference (e.g., prospect authors, casual readers, etc.).
5.2 Identifying Site Views In each conference phase, depending on the role they are required to play, users will have access to different site views, explained in the following (refer to Table 1 for a summary of the relationship between site views, user roles, and conference phases): 1. The PC Chair site view is used by the PC Chair throughout the conference lifecycle. It allows her/him to tackle the different activities (conference set-up, paper assignment, final discussion about the paper acceptance or rejection), and to manage the access rights of users groups to the different site views. 2. The Everyone-login site view enables users to login as PC chair, PC members, reviewers or authors. After logging in, each user is routed to the proper site view, based on the group s/he belongs to and the current phase of the conference lifecycle. 3. The Everyone-register site view enables non-registered users to register as authors. 4. The Login suspended site view contains static information (e.g., a warning) and is presented to registered users (PC members, authors, reviewers) when their role is disabled (e.g., to PC 8
members when the conference activities have been completed, to reviewers before the opening of the review process, to authors after the submission phase has been closed). 5. The Author-submission open site view allows registered authors to submit one or more papers. 6. The PC members-choose subjects & tracks site view allows PC Members to express their preferences about the conference tracks and subjects. 7. The PC Members-bid site view allows PC Members to declare their interests or conflicts of interest about the submitted papers, before the review process is opened. 8. The PC Member-insert review site view allows PC members to enter their reviews, and to designate further reviewers. 9. The Reviewer-insert review site view allows reviewers to enter their reviews. 10. The PC Member-final discussion site view allows PC Member to have a look to the review results, so that to take part to the final discussion about paper acceptance or rejection. 11. The Everyone-conference program site view is presented to all users (non-registered, authors, external reviewers, and PC members) after the conclusion of the review process. It contains the final program of the conference. Conference phase/user role
PC chair
PC Member
1. Conference set-up
PC chair SV
2. Paper submission
PC chair SV
PCM-choose subjects & tracks
3. Bidding
PC chair SV
4. Paper assignment
--
Author
--
Reviewer (non PC member)
Non registered user
--
Everyone login
Authorsubmission open
--
Everyone register
PCM-bid
Everyonelogin suspended
--
Everyone – login
PC chair SV
Login suspended
Login suspended
--
Everyone – login
5. Paper Review
PC chair SV
PCM-insert review
Authorsubmission close
Reviewer-insert review
Everyone – login
6. Final discussion
PC chair SV
PCM-final discussion
Authorsubmission close
Login suspended
Everyone – login
7. Acceptance notification
PC chair SV
Login suspended
Login suspended
Login suspended
Everyoneconference program
Table 1: Overview of site views, user roles, and conference phases. In the following, the composition and navigation for one of the listed site views (the PC chair site view) will be described.
5.2.1 The PC Chair Site View The PC chair site view contains six main areas, corresponding to related groups of pages: 1. Conference set-up area; 2. PC member registration; 3. Review assignment; 4. Paper acceptance and rejection; 9
5. Final statistics control; 6. Management of conference lifecycle.
5.2.1.1 Conference set-up
Figure 3. The pages of the conference set-up area within the PC chair site view. Figure 3 shows the group of pages within the PC Chair site view, which allows the PC chair to set up the conference. The Setup conference page is a static page not including any WebML unit, where instructions for the PC chair will be manually inserted and displayed. This page is set as landmark page (as indicated by the “L” symbol placed in the bottom right corner of the page). This means that any page within the PC Chair site view will include a non-contextual link to that page. From the Setup conference page, several non-contextual links lead to the other pages offering functions for creating and editing a conference. Page Create Conference includes an entry unit, New conference, for inputting data about the conference to be created. The Create Conference unit linked to the entry unit executes the creation of the Conference instance. Page Modify Conference allows the PC Chair to modify the conference data. Through the Modify Conference entry unit, s/he can insert new data; the ModifyConference operation unit executes the update operation. Conference subject and tracks are created in the Create subjects and tracks page, where two distinct chains, including an entry unit, a create unit, and a connect unit, allow entering data for creating a new Track or a new Subject, and associating the new instances to the conference. The Modify and delete subjects and tracks page allows the PC Chair to modify or delete the subjects and tracks previously created. The page includes an index of the subjects and tracks; for each index item, two links respectively activate a modify and delete operation.
10
5.2.1.2 PC member registration
Figure 4. The page for managing PC Members. The PC chair can create and register new PC members into the site, using page Manage PC members (see Figure 4). In this page, the group “PC member” is located1 and displayed in data unit PC Member Group. From this unit a link leads to the index of existing PC members (PC Members), from which a data unit (PC Member) is used to display the details of the selected PC member. Two operations (Modify PC Member and Delete PC Member) and an entry unit (Modify PC Member) permits the PC chair to delete and modify the details of the currently selected PC member. Finally, a second entry unit (New PC Member) permits one to insert a new PC member and connect it to the PC member group.
5.2.1.3 Review assignment A number of pages are introduced in the PC chair site view to let her/him assign papers to be reviewed to PC members, based on their declaration of interest in tracks and subjects. Two distinct perspectives are supported by such pages, assignment by paper and by PC member. In the former, papers are listed and the PC chair can select the PC members that are the most preferable candidates to review them. In the latter, PC members are listed and the PC chair can select the papers that most comply with their interest. In addition, the PC chair can explicitly declare conflicts of interest between papers and reviewers. Page Detect conflict of interests (see figure 5.a) allows the PC chair to explicitly declare some conflicts of interest. For each paper, the page shows the paper’s author and co-authors and the 1
The use of index PCMembersGroup is necessary to locate the instance of the derived entity PCMemberGroup, which contains a single instance (the group of all PC members). In a future version of WebML, it will be possible to declare singleton entities (i.e., with a single instance) and the use of an index to locate the required instance will be unnecessary.
11
To the Assign reviewer page To the Assign paper page
a)
b) Figure 5. The group of pages for assigning reviews to PC Members.
12
list of candidate reviewers (Candidate Reviewers index unit). The content of such index is computed by a WebML derived relationship between entity Paper and entity User2, which calculates those PC members and reviewers who expressed interest for the paper subjects and track and have a different affiliation with respect to the paper author and co-authors. However, if the PC chair detects a conflict between the paper and one candidate reviewer, s/he can eliminate the candidate from the list of reviewers, by following a link that populates the relationship Explicit Conflict, between the reviewer and the paper. The new relationship instance expresses the existence of the conflict. After this operation, the reviewer will not be shown anymore in the list of candidate reviewers for that paper. In order to assign papers to be reviewed to PC Members, the PC Chair accesses the two pages Assign Review (paper-based) or Assign Review (PC member-based), which are shown in Figure 5.a. Page Assign Review (paper-based) summarizes the current situation for all papers. It includes the index of all submitted papers (Papers index unit). Selecting one paper, one gets all the details about it (Paper data unit), its author (Author data unit), the list of co-authors (Coauthors index unit), and the list of the reviewers the paper has been already assigned to (Assigned Reviewers index unit). The PC Chair can also revoke one of the reviewers, by following a link departing from the index, which activates a disconnect operation (Disconnect Reviewer from Paper), dropping the relationship between the selected reviewer and the current paper. To manage a specific paper, the PC chair follows a link to the direct unit ToPaper, which leads to a new page (Assign reviewer) devoted to the selection of reviewers. In this page (Figure 5.b), a central data unit (Paper) displays the paper details and is surrounded by several units showing the various features of the paper (subjects, track, author, co-authors). The page contains two separate indexes of reviewers: the former (Candidate PC members interested to the paper) is constructed on the grades expressed by the PC members. Thus, all reviewers that have expressed the wish to review the paper are listed, in decreasing order of grade. The PC chair can select from the top of the index a reviewer that will most like to have the paper assigned (note that the index of reviewers displays also the number of reviews already assigned to each reviewer, so that the PC chair can check PC members having less reviews than the estimate number). The latter index (All candidate PC Members) lists all the reviewers that have no conflict with the current paper, which allows the PC chair to assign reviews also to those papers for which no one has bid. Page Assign Review (reviewer-based) and Assign paper are constructed in a similar manner, changing the perspective from papers to reviewers. So the PC chair can switch back and forth from one perspective to the other, obtaining a complete and well balanced assignment of reviewers to papers.
2
Derived relationships (as well as derived entities and attributes) are inserted in the structure schema by means of a wizard, called WebML derivation wizard, which hides the syntax of WebML-OQL.
13
5.2.1.4 Paper acceptance and rejection
Figure 6: Pages for the final evaluation of papers. Two pages support the PC chair when expressing the final evaluation of papers. Page See paper Status (Figure 6) contains the index of all conference tracks, from which it is possible to access three indexes (accepted, rejected and undecided papers). The indexes are constructed on top of derived entities, which partition all papers based on the value of their attribute FinalStatus. From the index of undecided papers, it is possible to access the page Undecided Paper Details, where the reviews of the paper and the reviewer’s details are shown, so that the PC chair can modify the final status of the paper, determining its acceptance or rejection.
14
5.2.1.5 Final statistics control
Figure 7: Pages showing the final statistics. The pages in the final statistics control area permit the PC chair to browse the evaluated papers in three different ways: by subject (page View final statistics (subject-based)), by track (page View final statistics (track-based)), by reviewer (page View final statistics (reviewer-based)).
5.2.1.6 Access rights management
Figure 8: Page Manage Access Rights for changing the status of the conference. Finally, the PC chair site view includes a page (Manage access rights) for declaring that a phase of the conference lifecycle is closed and the subsequent phase is open. This update is done simply by modifying the status of the conference. A relational trigger, installed in the underlying database, automatically reacts to such update, and changes the site view attached to the involved groups (stored in the value siteviewID of entity Group). As a result, the next login by a user of the involved groups leads to the home page of the new site view, as dictated in Table 1.
15
6 Derivation and Proactive Behaviours Some forms of derivation and some triggers have been applied to the initial structural skeleton, so that to enhance its expressiveness and cope with some advanced requirements. The definition of declarative business rules is the process of creating new structural objects starting from existing ones. Instances of such entities are not stored into the database; rather they are calculated at run time. In WebML the designer can specify these rules using an OQL-like syntax called WebML-OQL. A derivation wizard also offers a visual interaction paradigm for the rule construction. Within the CMS case study, derivation has been adopted for implementing some advanced features. In particular, one interesting case is when, during the review assignment within the PC Chair site view, given a PC Member, it is necessary to compute the “candidate” papers, i.e., those papers that have been indicated as preferred by the PC member, and that do not show any conflicts with the PC member herself. In order to satisfy this requirement, a derived entity, PC Member User, has been created – it is a sub-entity of User that represents PC member users only. Then, a derived relationship between PC Member User and Paper, PCMemberUser_NonConflictualPaper, has been created. Given a PC member, it computes those submitted papers, which do not show any conflict with her/him. Two types of conflicts can be detected through the defined derivation: implicit conflicts, arising when a PC member works in the same organization as one of the authors or coauthors of the paper; explicit conflicts, that are explicitly indicated by a PC member or by the PC chair. In summary, the derived relationship expresses the following conditions: • The PC member doesn’t work in the same organization of the paper author; • The PC member doesn’t work in the same organization of any of the paper coauthors; • The PC member does not show any explicit conflict with the paper; • The PC member has not been already designated as a reviewer for the paper. The where clause, written in WebML-OQL, for expressing the relationship PCMemberUser_NonConflictualPaper is the following: Self to Paper (as M2U) WHERE Self.affiliation M2U.User_Submits_Paper.affiliation Self.affiliation NOT IN ( M2U.Paper_Coauthor.Affiliation ) AND Self.Oid NOT IN (M2U.Explicit_Conflict.UserOid) AND Self.Oid NOT IN (Self.M2U.User_Reviewer_Papers.UserOid)
AND
In this query, Self is the PCMemberUser entity, M2U is the new relationship, to be populated by the query; the other relationships are those already described in Section 4. Finally, in order to select those non-conflictual papers that have been indicated as preferred by the PC Member, a new relationship, User_NonConflictualPreference, has been derived from the existing relationship User_Preference. This has been obtained through a clause expressing that the PaperOid of the Preference table be in the derived relationship PCMemberUser_NonConflictualPaper. The CMS case study also requires describing different users behaviours, in correspondence of different conference status. This specification has been translated through WebML into a number of site views (one for each couple (user, status of conference)). To make a group “transit” from a site-view to another one, we have introduced a relational trigger that is activated when the status of the conference changes. For instance, when the submission phase is closed, Authors cannot modify their papers; also, users cannot register as new authors. These access restrictions are obtained by associating to the author group the site view called login suspended. 16
Another feature of the trigger is the automatic creation of the list of possible interesting papers for the PC members. In the submission phase, authors submit their works and assign them to a track and to a set of subjects. In the meantime, the PC members express their interest about tracks and subjects. At the end of this phase the PC Chair changes the conference status and the trigger assigns to PC members a list of papers, which are assigned to a track, or a set of subjects preferred by the PC member. By default the grade of interest for these papers is 0, but the PC member can modify this grade or s/he can raise an explicit conflict of interest about a specified paper.
7 Implementation The CMS Web site has been implemented using the WebML tool suite (http://webml.org), which automatically translates the WebML specifications into a set of JSP 1.1 page templates, running on any JSP-enabled web server. Presentation of pages is dealt with by constructing a simple XSL style sheet, which is uniformly applied to all pages to produce the desired look & feel. Individual pages can be retouched using a commercial HTML editor, for optimised graphic rendition. The following table summarises the application dimensions: Number of site views Number of JSP pages Number of relational tables Approximate dimension of generated JSP code (Kbytes) Number of relational views for derived data Number of JSP page templates manually retouched Number of SQL views manually retouched
11 148 16 950 56 2 6
Table 2: Dimensions of the site implementation. As an example of the site navigation, in the following we show a sequence of HTML pages by means of which the PC chair sets up the conference:
The Log in page allows the PC Chair to specify user name and password and enter the system. As indicated in the bottom area of the window, at this time, no conferences have been created yet.
17
All the pages within the PC Chair site view include a landmark navigation bar, for moving to the pages where different management activities can be accomplished. By selecting the Setup Conference item, a sub-menu appears (the one highlighted by the dotted rectangle), that allows the PC Chair to invoke functions for: i) creating the conference; ii) modifying the conference; iii) creating subjects and tracks; iv) modifying and deleting subjects and tracks. As shown in the figure, a short text indicating the basic steps for setting up the conference is also displayed.
The Create conference page allows the PC Chair to enter data about the conference to be managed.
The Modify conference data page allows the PC Chair to modify the conference information, by entering new data.
The Create subjects and tracks page allows the PC Chair to create conference subjects and tracks. As new instances are created, they are shown in the index placed at the bottom of the page.
18
The Modify and delete subjects and tracks page, allows the PC Chair to delete or modify one of the conference subjects and tracks. The PC Chair can select a subject or a track from the two indexes in the top of the page. Then, s/he can delete the selected item by clicking on the delete button, or can modify it by inserting the new data into the entry form, and clicking the Submit button.
8 Conclusions WebML is a formal language with an accompanying visual notation for expressing complex data-intensive Web sites at the conceptual level. WebML specifications are automatically translated by the WebML CASE tools into a running Web site implemented in JSP 1.1 on top of relational data stores. WebML has permitted designers to completely capture the requirements of the CMS application, which has led to the design of several user roles and site views, each representing a set of functions performed against the information objects managed by the site. A simple relational trigger, reacting to the modification of the conference status by the PC chair, ensures the change of site view for the relevant user groups, thus modelling the workflow of a real conference management system.
Acknowledgements We are very grateful to the WebML team, and in particular to Fabio Surini, for the valuable support offered for the case study implementation.
References [1] [2]
[3] [4]
Aldo Bongio, Stefano Ceri, Piero Fraternali, Andrea Maurino: Modeling Data Entry and Operations in WebML. Proc. WebDB 2000: 201-214, Lecture Notes in Computer Science, Vol. 1997, Springer 3540-41826-1 Angela Bonifati, Stefano Ceri, Piero Fraternali, Andrea Maurino: Building Multi-device, ContentCentric Applications Using WebML and the W3I3 Tool Suite. ER 2000 Workshops:4-75, Lecture Notes in Computer Science, Vol. 1921, Springer, 2000, ISBN 3-540-41073-2 Stefano Ceri, Piero Fraternali, Andrea Maurino, Stefano Paraboschi: One-to-One Personalization of Data-Intensive Web Sites. WebDB (Informal Proceedings) 1999: 1-6 Stefano Ceri, Piero Fraternali, Aldo Bongio: Web Modeling Language (WebML): a modeling language for designing Web sites. Proc. of WWW9, and Computer Networks, 33(1-6): 137-157 (2000)
19
Appendix A: The WebML Visual Notation A.1 Composition Units VISUAL NOTATION
UNIT NAME
DESCRIPTION
Data
It shows data about a single entity instance.
Multi-data
It shows data about several entity instances.
Index
It shows a list of properties (also called descriptive keys) of a given set of entity instances. A user click on an index entry causes one instance to be selected.
Scroller
It provides commands for scrolling one-by-one the elements of a list of entity instances (e.g., the first, last, previous, next). Scrolling commands cause one instance of the list to be selected.
Filter
It shows a form with several fields associated to the properties of an entity. Values entered by users form a search predicate, which selects.
Direct
It selects one entity instance semantically related to another one by means of a one-to-one or many-to-one relationship.
A.2 Operation Units UNIT NAME Data Entry Unit
Create Unit
VISUAL NOTATION
DESCRIPTION It is used for collecting input values into fields, which are then fed as parameters to operations.
It creates a new instance of an entity.
Delete Unit
It deletes an instance of an entity.
Modify Unit
It modifies an instance of an entity.
Connect Unit
It creates a new instance for a relationship.
20
Disconnect Unit
Generic Operation
It drops an instance of relationship.
It invokes a generic operation, possibly implemented by externally available Web services.
21
Appendix B: The Data Dictionary Group
Enables the management authenticated users
GroupName SiteviewID
Name of the group Program Chair, PC Member, Reviewer, Author). An identifier representing the site view currently associated to a group. In the transition between different phases of the conference management, the PC Chair can enable or inhibit the access to a site view by a group (e.g., when the review process has to be opened, while the paper submission has to be closed). A numerical identifier.
GroupID
of
roles
for
groups
of
User
Represents single authenticated users
UserName Password Email Affiliation Name Surname
Name used by the user when logging in. Password used by the user when logging in. User’s email address. User’s affiliation (organization and department). User first name. User surname.
Conference
Represents the information about the conference to be managed (conference dates, venue, important deadlines, conference current status)
Name Location Start Date End Date
Conference Name. Conference Venue. First day of conference. Last day of conference.
Submission Deadline Review Deadline Acceptance Notification Date Conference Status
Deadline for the paper submission. Deadline for the review submission. Deadline for the notification to authors of paper acceptance or rejection. A string indicating the current conference status. Each status implies enabling (or disabling) the access of some user groups to specific site views. The possible values for this attribute are “Submission Open”, “PC Member Interest Declaration about Tracks and Subjects Open”, “Author Submission Closed and PC Member Interest Declaration about Papers Open”, “Paper Assignment Open”, “Review Open”, “Review Closed”, “Final Discussion Closed”.
Track
Represents the Conference Tracks
Name Description
Name of the Track. Short description.
Subject
Represents the Conference Subjects
Name
Name of the subject.
Paper
Stores data describing the paper (entered by the author when submitting the paper), as well as data about the review results (mainly derived from the entity Review)
Title
Paper title (max 256 Characters). To be inserted by authors during paper submission. A short abstract (max 1000 characters). To be inserted by authors during paper submission. Local path for the file to be uploaded. The path can be entered manually, or can be loaded by selecting the file in a window for browsing the file system. A derived attribute indicating the number of reviews already submitted for the paper. A string (accepted/rejected), indicating the final decision about the paper acceptance. A derived attribute, indicating the maximum Final Grade assigned to the paper. A derived attribute, indicating the minimum Final Grade assigned to the paper. A derived attribute, indicating the average of all the grades assigned to the paper. A derived attribute, indicating the difference between MaxGrade and MinGrade.
Abstract FileLocalPath NoOfSubmittedReviews FinalStatus MaxGrade MinGrade AvgGrade Deviation
22
OverboundDev PaperID NoOfReviewers
A derived Boolean attribute. It is true when the deviation value is grater than 2. A paper reference number, to be communicated back to the author when s/he submits the paper. A derived attribute, indicating the number of reviewers the paper has been already assigned to.
Coauthor
For each paper, it stores data about the coauthors, i.e., those authors (if any) different from the author registered as contact author.
Name Surname Email Affiliation
Coauthor Name. Coauthor Surname. Coauthor’s email address. User’s affiliation (organization and department).
Preference
Represents the preferences expressed by each PC member for all the submitted papers
Mark User Name PaperID
The PC Member level of interest for a given paper. The name of the user that has expressed the preference. An identifier for the paper for which the user has expressed her/his interest.
Review
Stores the paper reviews
Paper Title Reviewer Name Comment To Program Commitee Comment To Author
The title of the paper imported from the entity Paper. The name of the reviewer, imported from the entity User. A short text (maximum 1000 characters), representing a reviewer comment to be read by the Program Committee only. A short text (maximum 1000 characters), representing a reviewer comment to be sent to the paper author, together with the other evaluation items (see the following attributes). A Boolean value. When set to true by the reviewer, it indicates that the review status is final. An integer between 1 and 5 (1=very low, 2=low, 3=medium, 4=high, 5=very high), to be entered by the reviewer, which expresses the overall evaluation about the paper acceptance or rejection. A value (1=very low, 2=low, 3=medium, 4=high, 5=very high) to be entered by the reviewer, which indicates the paper relevance w.r.t. the conference themes. A value (1=very low, 2=low, 3=medium, 4=high, 5=very high) to be entered by the reviewer, which expresses the paper presentation quality. A value (1=very low, 2=low, 3=medium, 4=high, 5=very high) to be entered by the reviewer, which expresses the paper originality. A value (1=very low, 2=low, 3=medium, 4=high, 5=very high) to be entered by the reviewer, which expresses the paper originality. A value (1=very low, 2=low, 3=medium, 4=high, 5=very high) to be entered by the reviewer, which expresses the reviewer’s level of confidence with the paper topic. A Boolean value to be entered by the reviewer, which expresses if the paper is worth to be nominated for the best paper award. An attribute imported from the entity Paper, which univocally identifies the paper.
Final Status Final Grade
Relevance Presentation Quality Originality Technical Depth Reviewer Confidence
Best Award Paper ID
23
