The Web Information System of the National Institute for Astrophysics: different actors contributing to disseminate information
T he Web Information System of the National Institute for Astrophysics www.inaf.it
Who, what, how and …why? <ul><li>Caterina Boccato and Serena Pastore: Web managers and developers; </li></ul><ul><li>in this presentation we are going to describe our experimentation in applying a Content Management System (CMS) to the realization, from scratch, of the new information system of the National Institute of Astrophysics – INAF; </li></ul><ul><li>telling you about the problems, needs, and the requirements we have encountered and the resolution we have adopted; </li></ul><ul><li>because we would like to share our experience with others who want to use and apply a CMS. </li></ul>
<ul><li>The National Institute for Astrophysics, INAF, was constituted in July 2000. </li></ul>The background INAF is the central administration institute that promotes and coordinates in Italy the research activities in Astrophysics through its network of 19 facilities <ul><li>12 astronomical observatories </li></ul><ul><li>3 research institutes </li></ul>
From the First Web Site to the New Information System The old Web site was realized with a minimal effort for what regards the content architecture and the layout design. Problems > the lack of an editorial office Needs > to have urgently a virtual place where INAF staff throughout Italy could find information about what and how the new central administration was operating A precise choice for the new web site: to concentrate all the efforts mainly on the quality and on the amount of the information that would be published on the web
Towards the CMS What we would like to have > a Web information system able to ensure an efficient flow of information both from the Head Quarter to the peripheral institutes and vice versa. What we needed > a web-based information system able to disseminate information over the different categories of users (internal staff and external users) together with several tools to promote the external image of the Institute. BUT we have to stress again here the fact that INAF, in this phase of its life, couldn’t sustain the constitution of a big editorial office able to realize and manage such a web information system.
The choice <ul><li>The new-born Communication and Image Office, established in 2005, undertook to project such a web system focussing on two standpoints: </li></ul><ul><li>there are people acting on information that need to be published, </li></ul><ul><li>there are final users, accessing the system, whose needs should be evaluated. </li></ul><ul><li>From these considerations the idea to use a Web Content Management System (CMS) came naturally. </li></ul><ul><li>A CMS easily acquires , organizes and manages contents in a collaborative way, resolving the problems related to the lack of an editorial office, giving people with no particular technical knowledge the possibility to add information to the system , assuring a high level of security with a rigorous web publishing process . </li></ul>
Requirements <ul><li>The choice of a web CMS in our scenario was tied to the following requirements: </li></ul><ul><li>a web publishing system which COULD, at the same time, overcome the problem of the lack of an editorial office and let web developers free from the web server management. </li></ul><ul><li>the necessity to dynamically handle the creation or the acquisition of the information coming form different sources through the web; </li></ul><ul><li>the necessity to keep the final presentation of all the information separated from data and logic in order to have a layout consistency and uniformity; </li></ul><ul><li>to find an integrated framework able to provide add-on services required by a web information system such as collaborative web software, advanced searching systems, News systems and web feeds. </li></ul>
Zope/Plone CMS <ul><li>The solution proposed was to adopt the Zope/Plone framework: it implements an integrated infrastructure composed by: </li></ul><ul><li>an open source application server ( Zope ): actually the whole platform is handled behind the HTTP Apache web server to take advantage beyond its performance capabilities of its several features (i.e. caching, possibility to handle web applications written with other program language or paradigms); </li></ul><ul><li>a CMS web application ( Plone ) that provide all of the necessary tools to integrate data and content securely and efficiently into a web information system. </li></ul><ul><li>In practice Zope offers: a through-the-web management , integrated access control, content management, built-in search tools, powerful data sharing and a security model. </li></ul><ul><li>www.zope.org </li></ul>
Stream of information The first step : to understand and to set out the “stream of information” that is how information is generated and how and when it becomes ready to be published in a web environment The web content architecture which would reflect the organizational structure of the Institute. INAF besides the Presidency, the administrative and the scientific councils, is divided into two big department, i. e. the Research Structures Department and the Research Projects Department, each one of them is divided itself into 2 organizational units and 3 or 4 services. In addition to these there are also 7 Presidency direct collaboration offices.
Content architecture We have assigned each web content area to the people responsible for that particular department, office, service or organizational units. Common users, whether belonging to the Institute or not, would never know the organizational structure of the institute and would never search the information following this scheme . This content architecture was made in fact only to apply in the better way the Plone CMS web publishing process because it allows us to give particular permission to a content author only in a the restricted web area in which he/she has the duty to edit his/her information of public interest.
The web publishing system <ul><li>A rigorous web publishing process has to allow different categories of people, belonging to the Institute, to act on specific content by: </li></ul><ul><li>adding, </li></ul><ul><li>modifying, </li></ul><ul><li>reviewing </li></ul><ul><li>and finally publishing digital information in different format. </li></ul><ul><li>It has also to apply a workflow in order to achieve a better dissemination of information. </li></ul><ul><li>A main part of our work has been the adaptation of the Zope/Plone platform to implement a precise process that every author, and consequently the digital information that he/she puts on the web system, should follow before publishing the final content. </li></ul>
Customization From a technological point of view Zope/Plone gives the availability of a mechanism that allows the three main content actors (creator, editor and reviewer) to manage information according to their specific role on specific areas, but following a web publishing process that requires the customization of membership, workflow, access and security system of the platform.
Anonymous and authenticated users The system distinguishes two kind of user categories that access resources: Anonymous : all users accessing public information; Authenticated : users that effectively interact with the system and are authorized to manage web content. The authenticated user is authorized to access specific resources, or to do specific actions, on the system giving a username and a password, different for each role assigned to that user
Security <ul><li>Zope security is based on three fundamental concepts: </li></ul><ul><li>roles, </li></ul><ul><li>Permissions, </li></ul><ul><li>security policies that link the previous two. </li></ul><ul><li>Roles define classes of users, they are divided into global and local ones, the former are globally applied, the latter are applied only in specific portion of the system. </li></ul><ul><li>permissions define WHICH actions are permitted on each object, </li></ul><ul><li>security policies associate the roles with the permissions. </li></ul>This model allows to simplify users management and to reach a higher level of flexibility without affecting the security and the stability of the system.
Customization of roles <ul><li>Plone initially presents 3 types of roles besides the anonymous: </li></ul><ul><li>“ owner ” that represents who owns a specific object; </li></ul><ul><li>“ member ” that defines the authenticated users; </li></ul><ul><li>“ reviewer ” that has the possibility to decide whether a content has to be published or rejected. </li></ul>For the customization and the adaptation of the system to our goals we added other roles in order to define different categories of users. For example the “ redattore ” (editor) role allows a privileged user to publish all the information, while the “ segreteria ” (secretary) role groups people that carry out administrative roles, and usually they merely put information in the exact area of the web system assigned to each of them
The workflow The automation of the whole publishing system is realized by a workflow applied to each content that should be published. The workflow controls the logic in content processing through the systems with a sequence of interactions that should take place to complete the publishing task and that involve different people.
Lifecycle of a generic content in the publishing process: possible states and transitions <ul><li>There are 3 states that can be associated to the content and there are several transitions to provide the changes between these states. </li></ul><ul><li>a content object (i. e. a document or a web pages or a general file) when created is in a “private state” that means that only the user who created it, the owner, can view and change it. </li></ul><ul><li>when a content object is ready to be published, the user makes use of the “change state” action in order to “show” the content while he puts it in the “visible state” that is reachable only knowing its location (by URL). </li></ul><ul><li>a content object could also be submitted in order that such information will be reviewed by people responsible for it. The submission puts it in the “pending state” , and we associated to this transition an action that automatically advises who is the reference head of this section. This person may advise or not a review, but his role gives him the opportunity to its users either to reject or to publish the submission. In the former case the content object is moved again to the visible state and a mail is sent to the creator in order to advise him of the rejection with the motivation of such an action as comments. In the latter possibility, the content is put in the “visible state” and the information is visible to all users. An action that changes the ownership of all published objects is added to this transition again. </li></ul><ul><li>In fact with this trick we avoid that the creator may change, delete or modify the published information. Every changes should follow again the whole process . </li></ul>