1 / 14

Introduction

Introduction. This seminar is intended to give people an overall view of the capabilities of the Scientific Programme Management System (SPMS), to explain what has to be done by the administrators, to describe the operating environment and to show what the users will see.

shermanh
Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction • This seminar is intended to give people an overall view of the capabilities of the Scientific Programme Management System (SPMS), to explain what has to be done by the administrators, to describe the operating environment and to show what the users will see. • In general the presentations will describe what should be happening, even if there are still some developments to come. • Discussion of the technical details will take place later in the week in the sessions devoted to the SPMS.

  2. Brief History of SPMS • The meta data associated with contributions to a conference is a valuable resource and the quality of the final products critically depends on it. The data should therefore be of the highest quality and it should be handled in a secure manner • Oracle has been used in proceedings production since the first web publication of EPAC in 1996, when it was only used for making web indexes. In 1999 Oracle was used during the editing and proceedings production processes at PAC and from 2001 onwards it was used extensively by both PAC and EPAC • In this context, the team meeting in Nov 02 at Berkeley (LBNL) was basically a workshop aimed at producing a specification for a database system which would facilitate management of the scientific programme and proceedings production and thus the SPMS was born. • Data defined and gathered from the earliest stages of the conference organisation is used in proceedings production and therefore the management system must be able to handle all the activities from very early stages. This will be seen from the following talks which roughly follow the conference organisation process chronologically.

  3. Objectives of SPMS • Protect us from the authors • Provide a turnkey tool for the collaboration • Initially we wanted to cover the following functionality • Author/Institute database • Automated Emailing • Author interface • Abstract submission • Brochure production • Registration • Paper submission • File management • Meta data management • Paper processing management • Wrapper production • Statistical analysis

  4. More Functionality Since the initial specification more functionality has been added • Refereeing module • Poster police • Submission and publication of talks • Scripts to prepare the files for publication • Author index, Table of Contents • Banner and Page numbering • Deriving keywords • Filling hidden fields • Quality checks

  5. Implementation • It was agreed at the TM in LBNL that the implementation should be staged and in particular the registration module would not be done for the first release. • Out target was to have the first release fully operational for EPAC’04, which was the case. • At the same time several other conferences in 2004 used the system in stand-alone mode (no link to the repository). • The registration module was first used at PAC’05 and is currently undergoing further development.

  6. Main Features of SPMS • A central repository of authors and institutes. • The SPMS is freely available to everyone under a GPL but access to the central repository is restricted to JACoW collaboration conferences. • Each conference has its own database. • Each conference has its own file server and web server. • All interfaces are web-based forms • administrator interfaces for central repository and conference databases. • User interfaces to central repository and conference databases. • Editor interfaces for paper processing.

  7. Basic Architecture

  8. Repository System User DatabaseMachine Web Server User interacts throughweb forms starting from a log-into JACoW Repository The web form speaks to oraweb.cern.ch the Oracle web server Oracle is installed on the CERN central computers and the repository database is set up here

  9. Conference System The conference webserver is able to access the file server viacgi scripts which takecare of the file transfers User File Server Web Server RepositoryDatabaseMachine DatabaseMachine User interacts throughweb forms after log-into conference DB The web form speaks to the Conference Oracle web server Oracle is installed on the conference computer and the conference database is set up in here

  10. Administrator Roles • Data – repository and conference data • Setting parameters, maintaining data • Oracle – repository and conference databases • Installing Oracle, installing the database and maintaining them • Tuning the system, modifying code • Web servers – Oracle or standard • Installing the server and ensuring security etc • Installing upload/download scripts • File Server • Allocating space, implementing backup • Security issues

  11. How does one start ? • Obtain the package and install it on the conference system • Set up access to the repository (done by me at CERN) • Customise the conference installation • Then you are ready to start defining the programme.

  12. How does it Work ? • All of the code apart from the scripts is stored in the database and is delivered to a new conference manager on a CD, ready to go. • The code comprises many packages e.g. profile • The code itself generates the web pages (e.g. profile.html) which you see, so each page is generated when you ask for it – unlike normal web pages which are often just static data, like the programme of this workshop. • The Oracle web server makes the connection between your web form (page) and the Oracle database. • The packages manipulate the data which is stored in tables in the database.

  13. Profiles and Accounts • A user’s profile contains his name and email address and points to one or more affiliations – in this way a user may have one or more profiles (e.g. moves from one institute to another, on detachment, sabbaticals etc.) • The affiliation data cannot be changed by a user – he must select from a list or request the creation of a new one. • When a user takes possession of his profile he has to create an account (username and password) and this is what he/she should always to interact with the SPMS. • An author can create ‘light’ profiles for his co-authors but more of that later.

  14. The Agreement Each conference wishing to use the full SPMS system (i.e. with access to the repository data) or wishing to use JACoW software licenses has to sign the following declaration: • As organisers of the xxx conference we undertake that • The data supplied and collected with the SPMS system will under no circumstances be used for any other purpose than in connection with the organisation of the conference in question (e.g. non-conference announcements to the whole repository are strictly forbidden). • The data will not be provided to any external body for any purpose and especially not for any commercial activities. • The data will be destroyed following the publication of the conference proceedings. • Software installed using JACoW licenses will be un-installed immediately after the conference.

More Related