neon-projectneon-project.org/web-content/images/publications/neon... · 2010. 8. 11. ·...

NeOn-project.org

NeOn: Lifecycle Support for Networked Ontologies

Integrated Project (IST-2005-027595)

Priority: IST-2004-2.4.7 – “Semantic-based knowledge and content systems”

D 11.2.1 Quality Assurance and Risk Contingency Plan

Deliverable Coordinator: Aneta Tumilowicz (OU)

Task Co-ordinating Institution: The Open University (OU)

Other Authors: Martin Dzbor (OU), Jane Whild (OU)

Document Identifier: NEON/2006/11.2.1/v1.0 Date due: August 31, 2006 Class Deliverable: NEON EU-IST-2005-027595 Submission date: August 31, 2006 Project start date: March 1, 2006 Version: V1.0 Project duration: 4 years State: Final Distribution: Public

NeOn Consortium This document is part of a research project funded by the IST Programme of the Commission of the European Communities grant number IST-2005-027595. The following partners are involved in the project:

Open University (OU) – Coordinator Knowledge Media Institute – KMi Berrill Building, Walton Hall Milton Keynes, MK7 6AA United Kingdom Contact person: Martin Dzbor, Enrico Motta E-mail address: {m.dzbor, e.motta} @open.ac.uk

Universität Karlsruhe – TH (UKARL) Institut für Angewandte Informatik und Formale Beschreibungsverfahren – AIFB Englerstrasse 28 D-76128 Karlsruhe, Germany Contact person: Peter Haase E-mail address: [email protected]

Universidad Politécnica de Madrid (UPM) Campus de Montegancedo 28660 Boadilla del Monte Spain Contact person: Asunción Gómez Pérez E-mail address: [email protected]

Software AG (SAG) Uhlandstrasse 12 64297 Darmstadt Germany Contact person: Walter Waterfeld E-mail address: [email protected]

Intelligent Software Components S.A. (ISOCO) Calle de Pedro de Valdivia 10 28006 Madrid Spain Contact person: Richard Benjamins E-mail address: [email protected]

Institut ‘Jožef Stefan’ (JSI) Jamova 39 SI-1000 Ljubljana Slovenia Contact person: Marko Grobelnik E-mail address: [email protected]

Institut National de Recherche en Informatique et en Automatique (INRIA) ZIRST – 655 avenue de l'Europe Montbonnot Saint Martin 38334 Saint-Ismier France Contact person: Jérôme Euzenat E-mail address: [email protected]

University of Sheffield (USFD) Dept. of Computer Science Regent Court 211 Portobello street S14DP Sheffield United Kingdom Contact person: Hamish Cunningham E-mail address: [email protected]

Universität Koblenz-Landau (UNI Ko-LD) Universitätsstrasse 1 56070 Koblenz Germany Contact person: Steffen Staab E-mail address: [email protected]

Consiglio Nazionale delle Ricerche (CNR) Institute of cognitive sciences and technologies Via S. Martino della Battaglia, 44 - 00185 Roma-Lazio, Italy Contact person: Aldo Gangemi E-mail address: [email protected]

Ontoprise GmbH. (ONTO) Amalienbadstr. 36 (Raumfabrik 29) 76227 Karlsruhe Germany Contact person: Jürgen Angele E-mail address: [email protected]

Asociación Española de Comercio Electrónico (AECE) C/Alcalde Barnils, Avenida Diagonal 437 08036 Barcelona Spain Contact person: Gloria Tort E-mail address: [email protected]

Food and Agriculture Organisation of the United Nations (FAO) Viale delle Terme di Caracalla 1 00100 Rome Italy Contact person: Marta Iglesias E-mail address: [email protected]

Atos Origin S.A. (ATOS) Calle de Albarracín, 25 28037 Madrid Spain Contact person: Tomás Pariente E-mail address: [email protected]

D 11.2.1 Quality Assurance and Risk Contingency Plan of 32

Work package participants The following partners have taken an active part in the work leading to the elaboration of this document, even if they might not have directly contributed writing parts of this document:

The Open University

ISOCO

Change Log Version Date Amended by Changes

0.1 20-07-2006 Aneta Tumilowicz Initial draft, outline, data gathering

0.2 26-07-2006 Aneta Tumilowicz Simplified structure, extended content

0.3 08-08-2006 Martin Dzbor Publications, web content, corp.identity, evaluation

0.4 10-08-2006 Jane Whild Extended content, first spell/grammar check

0.5 15-08-2006 Martin Dzbor Backups, web sites, editorial issues

0.6 16-08-2006 Aneta Tumilowicz Text, Table of contents, Tables and Appendices formatting

0.7a 19-08-2006 Jane Whild Adding Legal & licensing issues

1.0 09-10-2006 Aneta Tumilowicz Final QA, change of document’s figures

2006 © Copyright lies with the respective authors and their institutions.

of 32 NeOn Integrated Project EU-IST-027595

Table of Contents

NeOn Consortium ......................................................................................................................... 2 Work package participants............................................................................................................ 3 Change Log .................................................................................................................................. 3 Table of Contents.......................................................................................................................... 4 List of Tables................................................................................................................................. 5 List of Figures ............................................................................................................................... 5 1. Executive Summary .................................................................................................................. 6 2. Quality Assurance Plan............................................................................................................. 6

2.1 Responsibilities for Quality Assurance................................................................................ 6 2.2 Contracts & Management Documentation ........................................................................ 12 2.3 Deliverables ...................................................................................................................... 13 2.4 Publications....................................................................................................................... 13

2.4.1 Types of publications ................................................................................................. 14 2.4.2 Rules of publications .................................................................................................. 15

2.5. Reports to the EC ............................................................................................................ 16 2.5.1 Bi monthly reports ...................................................................................................... 16 2.5.2 Periodic reports .......................................................................................................... 17 2.5.3 Other reports .............................................................................................................. 19

2.6 Documentation procedures and standards ....................................................................... 19 2.6.1 Generic project guidelines.......................................................................................... 19 2.6.2 Document types ......................................................................................................... 20 2.6.3 Document distribution ................................................................................................ 20 2.6.4 Document and file referencing ................................................................................... 21 2.6.5 Document templates .................................................................................................. 21 2.6.6 Software ..................................................................................................................... 21 2.6.7 Bug reporting and fixing ............................................................................................. 22 2.6.8 Back-up and storage policy........................................................................................ 22

2.7 Project identity .................................................................................................................. 23 2.7.1 Legal and licensing issues ......................................................................................... 23

2.8. Information exchange ......................................................................................................24 2.8.1 E-mails and mailing lists............................................................................................. 24 2.8.2 Web sites ................................................................................................................... 25 2.8.3 Document exchange .................................................................................................. 26

3. Risk Contingency in NeOn...................................................................................................... 27


APPENDICES............................................................................................................................. 29 Appendix A.- Risk Contingency Log ....................................................................................... 29 Appendix B. - Assignment of People to Roles in the Consortium ........................................... 30 Appendix C.- Glossary of approved Acronyms used in the Project ........................................ 32

List of Tables

Table 1. Deliverable production schedule----------------------------------------------------------------------13 Table 2. Publication types and responsibilities for quality assurance-----------------------------------14 Table 3. Summary of the process & deadlines for bi-monthly reports ----------------------------------17 Table 4. Outline of the process & deadlines for Periodic Reporting-------------------------------------18 Table 5. Summary of the document label mnemonic -------------------------------------------------------20 Table 6. Summary of the document distribution mnemonic -----------------------------------------------20 Table 7. Principles of referencing documents and files-----------------------------------------------------21 Table 8. List of available templates------------------------------------------------------------------------------21 Table 9. Principles of referencing software deliverables ---------------------------------------------------22 Table 10. Usage of individual elements within NeOn project ---------------------------------------------23 Table 11. Methods of documents exchange ------------------------------------------------------------------26

List of Figures

Figure 1: QA responsibility and risk levels ---------------------------------------------------------------------- 7 Figure 2. Two types of NeOn logo -------------------------------------------------------------------------------15 Figure 3. Relationships of various categories of risks ------------------------------------------------------28



1. Executive Summary

This Quality Assurance and Risk Contingency Plan is the key document in the achievement of total quality and the risk management in the NeOn project. Responsibilities for quality assurance and risk management are shared between all partners and the impact of actions and inactions by each partner is acknowledged and open to challenge in striving for high-quality outcomes.

The Project seeks to attain Total Quality, i.e. where high quality outcomes are achieved in terms of the efficacy and efficiency of working practices, as well as the efficacy and efficiency of software and hardware products, and standards of project deliverables and outputs. This Plan seeks to establish the procedures and standards to be employed in the project, and to allocate responsibility for ensuring that these procedures and standards are followed. The Plan is effective throughout the life of the project but is open to review and revision as necessary.

It sets out the activities that will ensure that overall quality control and risk assessment are carried out effectively, that quality control mechanisms are adequately planned, and that plans are followed, reviewed and updated in light of experience and changing circumstances. This includes the mechanism for proposing and authorizing changes to work packages, deliverables or other agreed plans. The Quality Assurance and Risk Contingency Plan requires that there is evidence of attainment of Total Quality (TQ) in the final version of every deliverable and project output. The Quality Assurance and Risk Contingency Plan is a part of Work Package 11 of the NeOn project.

2. Quality Assurance Plan

2.1 Responsibilities for Quality Assurance

Responsibilities for quality assurance are shared between all partners within the Consortium and the impact of actions and inactions by each partner is acknowledged and open to challenge in striving for high-quality outcomes.

The Project seeks to attain Total Quality, i.e. where high quality outcomes are achieved in terms of the efficacy and efficiency of working practices, as well as the efficacy and efficiency of software and hardware products, and standards of project deliverables and outputs. The table below shows the allocation of responsibilities for ensuring that quality assurance procedures and standards are devised and followed. The table indicates how particular individuals and groups have responsibility for different levels of quality assurance, for example at project, operational or strategic level. The names of individual assigned to the various roles/boards are shown in Appendix B).

Figure 1 below illustrates the quality assurance and risk analysis roles and responsibilities ay each level of the project.


Figure 1: Levels of QA & risk responsibility and level of risk

Title Description

Executive Project

Management Board

Comprises the Project Coordinator, Scientific Co-directors and representatives of core partners. EPMB members were appointed at the kick-off meeting. EPMB ensures the overall scientific coherence, technical quality and exploitability of the NeOn Project. It liaises with the Project Coordinator and key personnel to ensure that the Project is kept on course. In addition to its full members, the Project Administrator and two Scientific/Technology Liaisons participate in the meetings as non-voting observers.

Role

Monitoring and maintaining the coherence and integration of the project.

Reviewing the work plan and the consortium structure.

Resolving technical, administrative or contractual issues.

Coordinating the preparation of all major technical deliverables.

Defining the legal, contractual, ethical, financial and administrative aspects of the consortium.

Defining and implementing the risk and contingency plan.

Promoting gender equality in the project.

Resolving conflict (EPMB may delegate its executive rights to the Project Coordinator for a specific purpose).

Quality Assurance Role:

Ensuring adherence to contractual obligations.

Ensuring that the Quality Assurance and Risk Contingency Plan is delivered and implemented.

Monitoring, reviewing and revising the Quality Assurance and Risk Contingency Plan.



Reviewing and assessing the project at large, incl. the adherence to major project-wide milestones, strengths, weaknesses, arising opportunities and risks.

Monitoring and acting upon the analysis submitted by WP leaders on a quarterly basis.

Monitoring the attainment of Total Quality TQ (i.e. against this plan) at a strategic and project level.

Title Description

Project Coordinator Professor Enrico Motta, Open University

Role

Acting as liaison with FP6, IST Project Officer.

Responsibility for Consortium contractual matters and Progress Reporting.

Receiving and distributing the EC contribution.

Ensuring that the Project Management Board carries out its duties.

Ensuring that the Day to Day Management of the project is carried out.



Ensuring that the Quality Assurance and Risk Contingency Plan is delivered and implemented.

Monitoring, reviewing and revising to the Quality Assurance and Risk Contingency Plan (including deadlines dates, procedures etc).

Monitoring the attainment of TQ at a strategic and project level.

Title Description

Scientific Co-directors

The role of Scientific Co-director is undertaken by The Open University (OU) jointly with University of Karlsruhe (UKARL).

Role

Providing scientific and technological leadership for the duration of the project.

Ensuring that cooperation and communication takes place within and between the workgroups.

Ensuring technical quality and mutual interoperability of methods and techniques developed by the NeOn Consortium.

Making recommendations on the Project Scientific and Technical Roadmaps.

Ensuring the project maintains its objectives and relevance.


Monitoring and acting upon the analysis submitted by WP leaders on a quarterly basis.

Reviewing quality issues reported by the quality assessors (of deliverables). Monitoring activities against work package and task descriptions.

Reviewing and suggesting revision to processes where required.


Monitoring the attainment of TQ at a project level.

Title Description

Project Management Board (GA)

=Project Leaders

The PMB consists of the Project Coordinator and representatives nominated by each partner in the Consortium (i.e. Project Leader). Members of the PMB were appointed at the kick-off meeting. The PMB oversees the operationalization of the strategic and tactical decisions reached by EPMB and recommended by PSB and TMB.

Role

Operationalizing the strategic and tactical decisions as made by the EPMB, the PSM, the TMB and the PEDB.

Providing final resolution of conflicts, unless delegated to the Project Coordinator.

Considering any proposal for amendment to the EC Contract or to the Consortium structure or management.

Designating work package leaders.

Responsibility for monitoring and reporting of activity and expenditure.



Ensuring the quality and timeliness of deliverables.

Monitoring activities against work package and task descriptions.

Reviewing quality issues raised by the EPMB, PSM, TMB, PEB and PA. Monitoring the attainment of TQ at a project level.

Title Description

Project Exploitation

Board

The PEB is comprised of the industrial partners in the consortium, i.e. ISOCO, Software AG, Ontoprise GmbH, AECE, Atos Origin s.a.e, as well as United Nations FAO. The PEB were appointed at the kick-off meeting. The Board will liaise with the Executive Board through a dedicated Exploitation/Dissemination Liaisons who will also be key staff members selected from the core partners. The exploitation is chaired by Software AG.

Role

Ensuring that the work of NeOn is properly and appropriately exploited.

Overseeing and co-coordinating the work in the exploitation and dissemination work packages.

Ensuring that the market is fully addressed by the combination of the industrial partners.

Overseeing the dissemination of the NeOn results into the respective user communities throughout Community countries and beyond, if appropriate.

Exploiting and suggesting exploitation paths for the case studies and the demonstration activities.


Monitoring the quality of market intelligence gathering.

Responsible for the quality of the Exploitation Plan.




Title Description

Scientific Advisory Board

Five leading experts across the world have agreed to sit on the SAB, for a term of one year initially. The advisors are drawn from a range of disciplines, including those relevant to the project, and representing both academia and industry. Members of the Advisory Board will be reimbursed their travel expenses and receive a small annual honorarium.

Role

The Advisory Board will have no executive responsibility, but will meet once a year with the PMB. It will consider reports from these boards, and will make recommendations to these boards, as appropriate. It will be the responsibility of the project coordinator to notify the members of the advisory board of the progress of their formal recommendations.


Reviewing of the Quality Assurance and Risk Contingency Plan.

Reviewing technical quality of methods and techniques proposed by the NeOn Consortium.

Reviewing the quality Project Scientific and Technical Roadmaps.

Reviewing the attainment of TQ at strategic level.

Title Description

Editorial Board The Editorial Board comprises a representative of each type of partner in the project consortium (i.e. academic, commercial and other). The members were appointed at the kick off meeting.

Role

The EB carries out day to day management of activities between the NeOn project and the external world. Its primary responsibilities include planning, coordinating and implementing content for NeOn public web site, NeOn newspapers and various other outreach activities that are strategically agreed by the EPMB and/or PMB.


Maintaining the plan of dissemination and editorial activities and deciding on topics to be published.

Scheduling appropriate content and commissioning site journalists to prepare draft stories.

Coordinating the overall content production and ensuring the content is technically sound, accessible to the appropriate audience and appealing overall (e.g. in terms of design, graphics, etc.).



Title Description

Project Administrator =

Quality Coordinator

The Project Administrator is based at the OU and reports to the Project Coordinator.

Role

The Project Administrator takes care of day-to-day issues of running an Integrated Project. Her primary responsibility is to co-ordinate the timely production of Project deliverables, collate inputs from the Project Leaders to support the Executive Board in its role of an executive body, and to manage financial accounts and budgets for the Project.

Leading WP11.


Responsibility for quality of WP11 operationalization.

Responsibility for delivering the Quality Assurance and Risk Contingency Plan.

Devising and implementing quality assurance procedures.

Ensuring adoption of the Quality Assurance and Risk Contingency Plan.

Maintaining masters of key documentation and ensuring they are stored in the appropriate repositories – e.g. the EC Contract, Consortium Agreement, Annex 1, WP11 Deliverables, Quality Assurance documentation [Document review forms], EPMB & PMB agendas and minutes.

Carrying out Quality Coordination i.e., ensuring that QA procedures are in place for all outputs (e.g. deliverables, reports, public website etc.) and are carried out; conducting final QA checks on an outputs, i.e. ensuring that the correct templates were used, that QA documentation rules are followed, that the content, style, spelling & grammar have all been signed off by Quality Controllers, ensuring documents are submitted in the required format and number of copies to the EC. (The Administration Assistant at the OU supports this activity).

Monitoring the attainment of TQ at a project level.

Title Description

Task Leaders Each task will have a designated leader from the institution managing the specific task. They report to the respective Project Leaders (i.e. PMB member) from their organizations and EPMB.

Role

The Task Leaders have responsibility for producing the task deliverable on time and to the specified quality


Monitoring the attainment of TQ at a task level.



Title Description

Quality Assessors = Reviewers

Appointed by WP leader, this person will be a knowledgeable expert from the outside of the deliverable.

Role

Assessing the reliability of partners’ reports (e.g. in terms of timeliness, schedule adherence, output quality, etc.)


Assessing the deliverable against the stated Quality Criteria.

Documenting the assessment against stated Review Criteria.

Monitoring the attainment of TQ at deliverable level.

Title Description

WP Leaders = Quality

Controllers

Will conduct review of their work package progress on a defined periodic basis, and will report their findings to the PMB and to the Project Administrator in his role as Quality Coordinator. The Quality Controller also acts as internal auditor to self-assess the progress of the work package and tasks, both in qualitative and quantitative terms.

Role

Collate individual outcomes from partners and assessment of internal assessors, and report on the current state of their WP (e.g. ‘% completed’ of these outcomes, etc.).

Will specify quality criteria, which the task deliverable will be benchmarked against. The criteria will be based on the contents of the deliverable, the yardsticks/quantitative measures of progress and risk analysis, and contingency plan columns of the work plan. The specification will be submitted to the Project Coordinator, the Project Leaders and the PMB for ratification. Each task deliverable will be matched against the criteria upon conclusion of that particular task.


Nominating Quality Assessors.

Monitoring the Quality Assessment process and deadlines.

Monitoring the attainment of TQ at a work package level.

2.2 Contracts & Management Documentation The standard contractual documentation related to the Project consists of the EC Contract plus Annexes (including Annex 1), the Consortium Agreement. There may in addition be other contractual documents, for example, software licence agreements, other legal agreements between partners, or between the Consortium and external bodies (e.g. liaison agreements with collaborators).

The original signed paper versions of all documents must be kept according to the institutional rules and regulations of the partner organisations. Electronic masters of contractual documents and version tracking and updating for amendments, will be the responsibility of the Project Administrator. Quality Assurance of amended versions will be the responsibility of initially the PMB and finally, the EPMB.

Maintaining repositories of Key Management Documentation (e.g. EPMB and PMB minutes, correspondence with the EC, will be the responsibility of the Project Administrator. Electronic Masters of Contracts and Management documents will be stored on the Collab site and/or the Management Portal, as appropriate.


2.3 Deliverables The Quality Assurance Plan proposes the following schedule for the production, quality assessment, feedback and revision of the contractual deliverables resulting from technical, managerial or other activities. The production of deliverables will be coordinated by the appropriate Work Package Leader and Task Leader who will appoint a Deliverable Coordinator (i.e. author), and possibly also co-authors. The deliverable will be subject to informal self-assessment during the drafting process, prior to submission for formal quality assurance.

Two months before the deliverable is “due date” the deliverable production schedule begins (see below for a description of the timings in the schedule). At this time the Quality Controller will create a Deliverable Review Form (see the template in Appendix X). This entails entering details of i) the author(s), title of the deliverable and due date into Part I of the Form and ii) specifying a nominated Quality Assessor (Reviewer) and Quality Criteria, against which the deliverable will be assessed, in Part II of the Form. The Quality Assessor will review the deliverable against Quality criteria, enter his/her comment into Part III of the Form and return it to the Author. The Author will make any necessary follow-up actions, record these actions in Part IV of the Form, and return it with the final deliverable to the Quality Controller. The Quality Controller will then carry out a final quality review, signs off Part V of the Form, and send it and the final deliverable to the Quality Coordinator. The Quality Coordinator will carry out the final, general quality assurance checks and will submit the deliverable to the Project Officer and ensure that the deliverable and review form are uploaded to the appropriate repository(ies). The Quality Coordinator will actively track the progress of each deliverable review between review stages to ensure that deadlines are met.

The table below outlines the key dates in the production & quality assurance process for each deliverable. The “due date” in the first column corresponds to the date set either in the contract between the NeOn Consortium and the EC, or in the Annex I to the Contract (or any of its future amendments). Since dates in the Annex or Contract are expressed in terms of months from the beginning of the project, these yardsticks are translated typically to the last working day of the appropriate month. Thus, for instance, if a deliverable is due in M6, it would appear in the table below with the due date set to 31 August 2006. All subsequent deadlines are calculated by either subtracting (–) or adding (+) an appropriate time span to this due date. The table below is an integral part of the deliverable review form, and is thus explicitly available to the authors, WP leaders, etc.

Table 1. Deliverable production schedule

Deadline date Action Responsibility

Due date – 2 months Nominates Reviewer, sets Quality Criteria and creates Deliverable Review Form containing this data

WP Leader =Quality Controller

Due date – 2 weeks Receives the deliverable for review and submit a pre-final version to Quality Assessor

Reviewer = Quality Assessor

Due date Comments sent back to Author Reviewer

Due date + 1 week Author sends the final version to WP Leader for accepting of changes Author

Due date + 4 weeks Final version has to be sent to Project Administrator WP Leader =Quality Controller

Due date + 5 weeks* Submits the deliverable to the EC and uploads it to the NeOn mgt. portal

Project Administrator =Quality Coordinator

2.4 Publications In addition to contractual deliverables we recognize that a major part of the NeOn output (and indeed possibly some contractual deliverables too) will take form of other publications. These include academic outputs such as journal, conference, workshop and other academic/scientific publications, but also electronic material such as demo versions of software, technical manuals, and similarly. The table below details the various types of publications and responsibilities for assuring their quality.



2.4.1 Types of publications The following table contains the key types of publications that are likely to come out of the NeOn project and related work:

Table 2. Publication types and responsibilities for quality assurance

Type Description Responsible Software

Downloads

Software output is one of the core goals in NeOn, and as the project progresses it would become more prominent. A software download is considered to be an electronic file available in various forms (incl. compressed or executable).

Primary the author(s) and then WP leader where the product has been produced

Downloads need to be checked for the completeness, virus safety and stability.

Leader of WP6 or a partner appointed by them

Journals & other print

A journal publication is a standard submission to a reputable journal, magazine, bulletin or similarly that has been peer reviewed and accepted for publication without conditions or with some agreed amendments

As journals are peer reviewed, the key quality assurance in NeOn relates to facilitating the interaction e.g. for an internal pre-review of a submission

An important facet of the project-level presentation in the journal papers includes an appropriate acknowledgement that is printed in a style of a specific journal

Quality Assurance Plan offers variations for acknowledging the role of NeOn in the production

Journal articles are one of the key means for sharing scientific results with the specialists and practitioners

Ongoing status of publications to be monitored by WP10

Conferences & workshops

A conference or workshop publication is a standard submission to a reputable academic or industrial event that has been peer reviewed and accepted for publication without conditions or with some agreed amendments

As the submissions are peer reviewed, the key quality assurance in NeOn relates to facilitating e.g. an internal pre-review of a submission

An important facet of the project-level presentation in the journal papers includes an appropriate acknowledgement that is printed in a style of a specific journal

Quality Assurance Plan offers variations for acknowledging the role of NeOn in the production

Conference papers are another the key means for sharing scientific results with the specialists and practitioners

Ongoing status of publications to be monitored by WP10

Conference papers are typically accompanied by oral presentations; hence presentation style shall preferably reflect the NeOn style and follow logo rules

Templates of presentations prepared by Coordinator

Web-based news, features, etc.

The purpose of the web-based news is to reach out to the external communities (e.g. consultants or academics) and public to disseminate the results from NeOn or to comment on various advances in the fields relevant to NeOn

Editorial & Dissemination Board coordinates this type of publishing and commissions news items from site journalists

It is recognized that web-based ‘publications’ are the key means to communicate with general communities; they main difference from the above

Editorial & Dissemination Board liaises with WP10 leader to ensure appropriate


being its language and overall accessibility copy editing

Other Leaflets and project marketing literature are an important introductory material distributable to a wide audience

Production is a part of WP10, in collaboration with EDB

Leaflets need to be regularly updated, technically sound, visually appealing and accessible to a wide audience

EDB maintains the plan of updates and coordinates actions

Project posters are another important channel and a range of posters needs to reflect different audiences

EDB and Project Coordinator manage the production

All these as well as any other materials (e.g. T-shirts, pens, etc.) need to comply with an overall image of the project and be distributed in an appropriate manner

Production of other artefacts to be approved by EPMB

2.4.2 Rules of publications This section is concerned with a few generic rules covering the production and dissemination of the different types of publications we listed above. In principle, each of the standard publications (i.e. journal articles, conference or workshop papers, or academic posters) shall follow the rules set by the respective publisher and/or conference organizer with respect to the length, style and graphical appearance. In case of leaflets, posters and other publications, specific rules would be agreed case by case. Nevertheless, two generic rules are to be shared by all types of publications:

o Publication must reflect the image NeOn has or intends to acquire in a particular community, which typically means that it would be related to the work carried out in the scope of the project.

o NeOn support in developing or producing a particular publication needs to be explicitly and visibly acknowledged (even if NeOn’s contribution was only partial).

While the first rule needs to be assessed case by case and is to a great extent reliant on the publication author, the second rule will be generalized in the following alternative acknowledgements. The form and style of acknowledgement is likely to reflect the form and style of publication. Hence, in general we distinguish two forms of acknowledging NeOn support or participation: visual (using logos) and textual (using acknowledgement texts).

Two basic forms of NeOn logo exist – on the left is a black version and on the right a white version of the NeOn corporate identity. The Quality Assurance Plan suggests restricting the usage of the left logo to the web sites and other, primarily electronically viewed publications. Alternatively, it shall be used in cases where the native background of a publication is dark. On the other hand, the logo on the right is more appropriate to be used on printed materials (such as reports or posters) and in general on those publications where the background is typically light or white.

Figure 2. Two types of NeOn logo

Logos and other graphical elements form a major part of material accompanying oral presentations. To that extent, a range of MS PowerPoint presentation templates has been created, which suggests appropriate ways of combining the NeOn style with partners’ or other sponsors’ logos, titles, etc.



For the purposes of briefly acknowledging financial, scientific and any other support from NeOn, the Quality Assurance Plan requires (where applicable) the authors of publications to include one of the following agreed forms of acknowledging support (the square brackets contain optional components). Any substantially different wording shall seek approval from the QA Coordinator and/or Project Administrator:

o “This research [person, effort, product development,…] has been [partially] supported by NeOn, an Integrated Project funded by the European Commission.”

o “This research [person, effort, product development,…] has been [partially] supported by NeOn [, Prj_X and Prj_Y]. NeOn is a Framework VI Integrated Project funded by the European Commission under grant no. 027595 [, similarly for other projects].”

o “This research [person, effort, product development,…] has been [partially] supported by NeOn (http://www.neon-project.org), using a grant by the European Commission.”

o “This research [person, effort, product development,…] has been [partially] supported by NeOn, an Integrated Project funded by the European Commission. Further information available from http://www.neon-project.org.”

The main rule applying to the software downloads is to distribute it in a form and shape that does not unnecessarily expose the user’s computer to the virus or any other security hazards. This means that if the software bundle contains an executable, this has to be explicitly checked for known viruses and the result of the anti-virus control shall be made explicit during the installation and/or at the download site.

Furthermore, each software download has to be accompanied by a comprehensible README (or any other form of instructions) detailing: (i) what components are need for a correct operation of the system; (ii) what prerequisite are necessary – if any; (iii) how to carry out the download, installation and setup of the product; and (iv) where more information on the product can be obtained – incl. help lines, public forums, mailing lists, etc.

According to section 2.7.1, software is a form of “Information” and as such will require a statement about responsibilities and liabilities of the NeOn Consortium to third parties. Templates for liability statements will be prepared by the software developers and owners and their organisations. These statements should form an integral part of the software licence.

2.5. Reports to the EC In addition to standard deliverables NeOn is contractually obliged to produce regular reports on its ongoing activities to the Project Officer and the EC. There are several types of these reports – bi-monthly, periodic (annual in our case), and “other”. Reporting activity is carried out under Tasks T11.1 and T11.3 of WP11 and is managed by the Project Administrator. Procedures and responsibilities for reporting and Quality Assurance are described below.

2.5.1 Bi monthly reports Partners contribute to the bi-monthly reporting with brief but concrete summaries of their progress in the WP and tasks they are actively engaged in. To facilitate maximal efficiency and minimize load on multiple processing steps, the bi-monthly reporting uses a common template and custom-built infrastructure of the NeOn Management Portal that has been built using the WebODE infrastructure of UPM (one of the project partners). Each partner is requested to complete one simple section in this portal – reporting on effort spent, together with the justifications for the expenditure.

In addition to this effort reporting and justification, WP leaders have another simple section at their disposal – to report on the overall progress made within a work package, on any obstacles encountered and the status of deliverables. They obviously take in account the details provided by the individual partners in relation to their reported effort.

Both sections of partners’ summaries are uploaded and stored in the management portal, and are aggregated to produce a joint report that is edited by the Project Administrator in collaboration with the Project Coordinator. The inputs from the partners to the bi monthly report will be requested every two months by the Project Administrator. The reporting templates require the partners to complete the following sections:

o Give a brief account of progress in the work package since the last report

o Are there any emerging issues?

o Have there been any deviations from plans and schedules or is any deviation proposed?


o Are there any recommendations or requests to the EPMB/GA?

o Has there been any unanticipated expenditure or underspending, or is any anticipated? Why?

o Looking at the original estimates for effort (in person-months), how far do they reflect the actual effort spent on the work package at this point? Where there are deviations from the estimate, please explain.

o Have all relevant documents, specifications, etc. for the work packages been sent?

The following table highlights the details of the schedule for gathering data necessary for producing a bi-monthly report and also for actually producing a bi-monthly report on time. All weeks in the second column start counting from the next day after the end of the current reporting period; i.e. if we are reporting on period May/June 2006, the partners have to input their information in the first week of month July, etc.

Table 3. Summary of the process & deadlines for bi-monthly reports

Stage Deadline Action Responsibility 1 week 1 Partners enter effort reports PMB

2 week 3 Work Package leaders enter progress reports, following the agreed "gold standard" (in length, detail, style)

WP Leaders

3 week 4 QA check and review by EPMB PA & EPMB

4 week 5 Submission to the Project Officer PA

2.5.2 Periodic reports Periodic reports must be submitted annually to the EC by the Coordinator on behalf of the Consortium 45 calendar days after the end of the reporting period, i.e. the first report will cover the period 1st March 2006 – 28th February 2007 and must be submitted by 14th April 2007. The annual reporting process will involve partners, again, being requested to complete a set of common templates, which will be made available to them within the NeOn Management Portal and, in cases more analytic information is required (such as Form C) appropriate templates will be distributed closer to the time of the period report.

The periodic reports required are:

• The periodic activity report, containing an overview of the activities carried out during the reporting period, describes the progress in relation to the project objectives, the progress towards the milestones and deliverables set for the period, and any problems encountered and corrective actions taken. It also includes a Publishable executive summary and an appendix containing the Plan for using and disseminating the knowledge. This appendix sets out in a detailed and verifiable manner, the terms of use and dissemination of the knowledge arising from the project, which they own, in accordance with their interests. It is an evolving document which should be regularly updated to give a cumulative overview of the project’s undertaken and planned activities.

• The periodic management report includes a detailed justification of the costs incurred and of the resources deployed by each contractor linking them to activities implemented and justifying their necessity, the financial statements (Form C) from each contractor (which may require an Audit certificate) and a summary financial report consolidating the costs of the contractors.

• The periodic report on the distribution of the Community’s contribution records the distribution of funding to each contractor during that period.

• The draft planning for next 18 months – an update of Annex 1 for planned activity during months 13-30 of the project.

Outline of the process & deadlines for Periodic Reporting

(expected dates for the production of the first Periodic Reports are shown in the table below – these dates may be revised as necessary, and will be updated for later reporting periods in subsequent revisions of this Quality Assurance Plan. NB: Easter falls on 6-9th of April in 2007 which may impact on availability of key staff or availability of auditors – therefore partners must plan for this).



Table 4. Outline of the process & deadlines for Periodic Reporting

Deadline Action Responsibility Month 7 (September 2006)

Partners to notify the Project Administrator that either: a) they intend to waive the requirement for an audit certificate under the terms of the EC Contract or b) they have engaged an auditor to deliver an audit certificate to the OU by the 7th April 2007.

Project Administrator & PMB

Month 7 (September 2006)

Circulation of a schedule for drafting and quality assurance of specific reports (including assignment of with responsibilities):

• Plan for Using and Disseminating the Knowledge • Update of Annex 1

• Responses to online questionnaires due in first year (see the section describing other reports)

Quality Assessors for period reports to be nominated by Project Administrator.

Project Administrator (as WP11 Leader)

UKARL

OU

WP10 & WP9

Due Date – 6 weeks (by 2nd March 2007)

Work Package leaders enter progress reports into the management portal (an example "gold standard" (for length, detail, style) will be devised and circulated at that time).

WP Leaders

Due Date – 6 weeks (by 2nd March 2007)

Partners enter effort reports and cost justifications into the management portal.

PMB

Due Date – 4 weeks (by 13th March 2007)

Partners send draft Form C and cost justifications to the Project Administrator.

PMB


Project Administrator collates the Periodic Reports including draft of the summary financial reports etc., and sends to the nominated Quality Assessors.

Project Administrator

Due Date – 3 weeks (by 23rd March 2007)

Draft Periodic Reports circulated to the PMB for comments. Project Administrator and PMB


Final draft of Form C and Audit Certificates to be sent electronically to Project Administrator.

PMB

Due Date – 2 weeks (by 30 March 2007)

Final draft revisions to be made, QA check and review completed by PMB and EPMB.


PMB, EPMB

Due Date – 1 week (by 5th April 2007 or earlier – given that this is Easter week)

Signed Form C and Audit Certificates to arrive with Project Administrator.

PMB

Due Date (by 14th April 2007 for Year 1)

Checking of Form C, final revisions and Audit Certificates and Submission to the Project Officer.



2.5.3 Other reports Other supplementary report may be required under the terms of the EC contract, requested on an ad hoc basis by the Project Officer. Currently required are (this section will be updated in subsequent versions of this Quality Assurance Plan):

The interim science and society reporting questionnaire to be completed on-line by the co-ordinator at the end of the first reporting period only.

The interim reporting on the implementation of the gender action plan this consists of a questionnaire to be completed on-line by the co-ordinator and by each contractor at the end of the first reporting period only.

The interim socio-economic reporting questionnaire to be completed online by each contractor at the end of the first reporting period only.

Final Project Reports In addition to the periodic reports, for the last reporting period, the Consortium is required to submit final reports to the Commission after the end of the project. A plan for producing these final reports will be included in subsequent revisions of this Quality Assurance Plan.

2.6 Documentation procedures and standards In this section we highlight some of the key procedures contributing to assuring quality of interaction, documentation and similarly in the project work. The purpose of these standards is to achieve an easy-to-follow structure, which improves efficiency and effectiveness of both project management and research work.

2.6.1 Generic project guidelines Since NeOn is a project involving multiple partners and large chunks of its outcomes are based on the collaborative work, we start with stating a few simple principles for facilitating seamless and friction-free interaction among partners. Since most of the interaction will take place in a written or oral form, we shall address both of these.

The submission of a written deliverable, deliverable draft or any other draft document (e.g. draft model or definition) should adhere to the following guidelines:

o All files shared among partners and individuals must be scanned for viruses using up-to-date virus scanning software.

o All files should be named according to the agreed convention (see next section); this is particularly important if the purpose of any file is to provide a working version of a particular development or idea, and the author expects others to comment, extend or otherwise contribute to it.

o As far as possible all physical documents that are used in the collaborative work should be (also) based on the deliverable document templates, which are available from the NeOn Collab Space1 (http://www.neon-project.org/ACollab/).

o We strongly recommend not only basing the shared files on a set of templates, but also physically sharing them using the aforementioned NeOn Collab Space, which provides a set of file libraries and folders for a variety of purposes.

o Once the files have been uploaded to a proper section of NeOn Collab Space (either as a new submission or as a revision of a previous one), the submitting partner should send a notification email to the appropriate mailing list (NeOn-all or WP specific). The mail should contain the location and file details, a document development timetable, a list of feedback targets, and a feedback deadline.

1 The Collab Space is password protected; each partner has received a username/login from the coordinating institution (OU).



o In case the interaction does not warrant the formal style of a deliverable templates and its purpose is more to develop ideas, to facilitate brainstorming or similarly, we recommend using the functionality of NeOn Wiki2 (http://www.neon-project.org/wiki).

o Alternatively (or in addition to the text-centric interaction), there is a range of mailing lists to facilitate debate and discussion – both on the level of the project as well as individual work packages.

o In cases the interaction requires immediate communication and/or verbal communication, the coordinating partner (OU) has made available its facility of web-based video conferencing using the FlashMeeting infrastructure (http://flashmeeting.com), which is preferred to the standard telephone conferencing facilities.

2.6.2 Document types The following document types are defined for NeOn project and associated with the following mnemonic labelling system in order to support efficient and effective collaboration:

Table 5. Summary of the document label mnemonic

Mnemonic Ref.

Type Description

DX.y.z Deliverable

This represents a document relating to a specific deliverable as opposed to an aggregate report (‘X’ stands for a specific number of the work package, ‘y’ and ‘z’ identify deliverable and its revision).

DRX.y.z Deliverable review

Review Documents should be named DRX.X.X-P-vX.X (i.e. P = I, II, III, IV or V , corresponding to which Part of the process which has been completed. And vX.X = version number). For example, when Part III of D10.1.1 review is completed, the filename would be DR10.1.1-III-v1.0

MR Management report & documentation

The management of the project anticipates specific procedures for reporting, including Management Reports.

PU Publication All publication from project participants for public use.

2.6.3 Document distribution The following distribution categories for the delivered document types are defined for NeOn project and associated with the following mnemonic labelling system in order to support efficient and effective collaboration:

Table 6. Summary of the document distribution mnemonic

Mnemonic Ref.

Type Description

P Public Open distribution without limitation R Restricted Restricted to the recipients only (as specified), internally in NeOn

& PO C Confidential Internal to NeOn project participants only

2 Because of the sensitive nature of ideas under development, Wiki is also password protected for read and write; each partner has received a username/login from the coordinating institution (OU).


2.6.4 Document and file referencing This section gives suggestions for referencing documents and their versions to ensure traceability and accountability in the preparation of documents. A document reference consists of the following string, whose constituent parts are explained in the following table: NeOn/yyyy/tt /rr

Table 7. Principles of referencing documents and files

Field Type Description yyyy Year of production Year in which a document is produced, delivered – e.g. 2006

tt Type of document DX.y.z, MR, PU (as mentioned in the previous section) rr Revision number This is a revision counter for the document in a form “vM.m”,

where: M is a major revision – e.g. ‘0’ denotes a pre-release draft, ‘1’ may reflect draft under review, ‘2’ after review, etc. and m is a minor revision typically incremented by 1 for each subsequent extension or modification of the document Note: major version numbers shall be used sparsely and shall reflect the situations where the document “has been released” beyond its author/reviewer team – e.g. sent to project coordinator, project officer

2.6.5 Document templates In order to allow a standard form of project presentation, document templates for the following formats are provided in below table.

Table 8. List of available templates

What Where Format(s)

Project logos NeOn Collab Space (see: NeOn General File library Logos, templates)

*.JPG, *.PNG

Deliverable template Deliverable review template

NeOn Collab Space (see: NeOn General File library Logos, templates)

*.DOC (*.DOT)

Bi Monthly report template Annual report template

Template for entering data available after partner’s login to the NeOn Management Portal (see: Progress report Effort, resp. WP Progress)

HTML Form

Presentation template NeOn Collab Space (see: NeOn General File library Logos, templates)

*.PPT (*.POT)

Spreadsheet (e.g. Form C) NeOn Collab Space (see: NeOn General File library Logos, templates)

*.XLS

2.6.6 Software No software package is prescribed. All that is mandated is that any NeOn document to be referenced should:

• be available in electronic form in one of the following formats: minimally .pdf and .doc, but also .ps, , .ppt, .html, or .tex,

• have a cover page that contains the following information (where M = mandatory, O = optional):



Table 9. Principles of referencing software deliverables

Info M/O Value Project acronym M NeOn Full name O Lifecycle Support for Networked Ontologies EC reference M EU-IST-027595 Project logo M As mentioned is section 2.2 Software title M Software distribution / license

O As defined in section 4.3

File name M As defined in sections 4.2 and 4.4 Work package(s) contributing

O WP.x+

Editor O Name Abstract / readme M As appropriate

2.6.7 Bug reporting and fixing The procedures for reporting and managing software bugs are under development and will be included in the subsequent revisions of this Quality Assurance Plan.

2.6.8 Back-up and storage policy Since most of the interaction among NeOn partners as well as preparation of materials for external audiences is conducted via a distributed electronic infrastructure, it is important to ensure that data are safeguarded to the reasonable extent. The following steps were taken to keep electronic communication archived and safe:

supporting infrastructure in NeOn includes several distributed servers – this decision has been taken with cost-effectiveness in mind, and also to reduce the risk of one specific partner or his infrastructure failing, which would simultaneously remove a large part of NeOn infrastructure;

content of NeOn web site, NeOn Wiki and NeOn Collab Space are stored using SQL databases that are part of a hosted solution that KMi (as a coordinating partner) has agreed as a part of its ordinary operation with its web provider;

web hosting solution is provided by Dreamhost.com with regular security updates to the underlying operating system (Linux) and basic data back-up are provided as a part of the package;

in addition to the basic back and security policy, the coordinator will carry out regular snapshots including databases, mailing list archives, and shared documents, and will store these on a geographically separate server, where it could be backed up as a part of internal Open University policy;

in addition to carrying out back-ups Project Administrator will keep a paper and electronic archive of final versions of all Deliverables, key internal reports, bi-monthly, progress and review reports, and also a track history of agendas and minutes from key managerial meetings and other key project events;

the robustness of back-up facilities for software developed for Deliverables is the responsibility of the respective Work package Leader; the Technology Management Board will provide guidance with regard to appropriate precautions needed to safeguard and shared software development work

similarly, while individual work packages and partners may use their own infrastructure for preparing drafts of deliverables and other reports, we strongly advise to regularly share also intermediate and in-progress versions (e.g. using NeOn Wiki and NeOn Collab Space facility), in order to (i) prevent total loss of work and (ii) facilitate good collaborative relationships with other partners


2.7 Project identity As mentioned in the earlier sections, project identity is an important part of assuring consistency of presentation and interaction with a variety of audiences. In this section we summarize a few simple but mandatory restrictions for using various forms contributing to NeOn ‘corporate identity’. In order to keep visual side of the project in a homogeneous and consistent shape, the following rules are defined for NeOn project:

Table 10. Usage of individual elements within NeOn project

Full Name: NeOn – Lifecycle Support for Networked Ontologies

Acronym: NeOn (please note: capital letters are: first “N” and third “O” only!)

Deliverable Software

or or icon

Websites

, and icon

Project Logo:

Written/printed Publications

Other Logos:

Other – IST logo, partner logos for marketing materials

These logos are provided in an archive obtainable from NeOn Collab Space

Font:

NeOn deliverable template and most of the internally designed material (incl. web site) prefers using the Arial, Helvetica font combinations for its better legibility and accessibility to disabled. However, we acknowledge that primarily publications to journals and conferences are subject to their own font guidelines.

*) Logos can be downloaded from NeOn Collab Space – (after login): path: NeOn General File library Logos, templates

**) Please note that partners should observe any other guidelines and/or restrictions that may be in place on the usage of logos and other corporate identity of any partner (include EC). Full official names of NeOn partners are an integral part of the deliverable template, but we advise any authors to check with the appropriate partner regarding using acronyms and/or translations into different languages of the official names.

2.7.1 Legal and licensing issues Material produced within NeOn may include information, software and/or media (individually and collectively the "Information"). The Information is made available by the NeOn Consortium and its partner organizations. Our goal is to keep this information timely and accurate. If errors are brought to our attention, we will try to correct them in line with the recommendations contained in the Quality Assurance Plan.

However, NeOn Consortium may accept no responsibility or liability whatsoever with regard to the Information. This Information is:

not a professional or legal advice (if you need specific advice, you should always consult a suitably qualified professional)

sometimes linked to external sites over which the NeOn Consortium has no control and for which it assumes no responsibility

not necessarily comprehensive, complete, accurate or up to date



It is our goal to minimise disruption caused by technical errors. However some data or information on our site may have been created or structured in files or formats that are not error-free and we cannot guarantee that our service will not be interrupted or otherwise affected by such problems. The NeOn Consortium accepts no responsibility with regard to such problems, or the consequences thereof, incurred as a result of using this site or any linked external sites.

This liability disclaimer is not intended to contravene any requirements laid down in applicable national law nor to exclude liability for matters that may not be excluded under that law.

Different sorts of Information may be subject to different licensing structures, for example, the GNU licence, or Creative Commons “Attribution ShareAlike”, as applicable. Appropriate licence will be decided by the copyright owner in collaboration with the EPMB. In case particular Information, e.g. software, may generate maintainability or upgrade implications, such upgrade implications should form an integral part of the licence. However, it shall not be assumed that any Information has any default upgrade obligations unless specified explicitly in the licence or disclaimer.

Except where otherwise noted, all Information produced by NeOn should be subject to a copyright notice or acknowledgement, for example:

© NeOn: Lifecycle Support for Networked Ontologies (all rights reserved)

2.8. Information exchange The attainment of Total Quality in within the project will rely to a great extent to the project having access to, and utilising, reliable tools and methods for the exchange of information. Described below are the core tools and procedures which are already in use. The efficacy of these will be quality assessed on an ongoing basis by the Project Administrator and Work Package 11 members throughout the life of the Project.

2.8.1 E-mails and mailing lists Several mailing lists (private and unmoderated) have been set up to accommodate a range of interaction opportunities for the project participants. The lists are owned and managed by OU. Each of the lists has the full address around this template: "{List_Name}@lists.neon-project.org". Members could be added to the list either by the central manager (an OU staff member), the respective list manager (e.g. WP leader), or members may subscribe themselves on web pages made available at the NeOn Wiki.

The project-wide mailing lists currently set up are (note that additional emails may be created subject to demand and requirements):

NeOn-All: for everybody associated with NeOn (incl. advisors, external people)

NeOn-PMB: for leaders/key contacts of partner institutions

NeOn-Exec-PMB: for 'core partners' or members of the Executive PMB

NeOn-cBio: for everybody interested in the collaboration between NeOn and cBio /Stanford (incl. external people)

NeOn-Requirements: for everybody interested in developing the methodology / ontology for requirements acquisition, etc. shared by NeOn WP-s

NeOn-Administrative: for administrative contacts of NeOn partners

There are also nine work package specific mailing lists, each following this template: "[email protected]". (domain of X = {1, 2, ..., 9}). WP leaders have received the data (passwords,...) for managing and populating the individual lists. They are responsible for adding and managing the actual membership of the lists. An association of each list, its purpose, formal name and list manager is also available on the Wiki.


2.8.2 Web sites Web presence of the NeOn project is distributed over several dedicated web sites and web spaces that were with particular roles in mind. We acknowledge that the situation of having multiple specialized web sites has inevitable consequences in terms of managing multiple login credentials and get accustomed to different user interaction styles, the distributed design has been the most appropriate way to combine the need of having high quality collaborative infrastructure, which would be as cost effective as possible. This is in line with the recommendations of the EC to use tools and technologies developed using previous funding.

In the following we provide a brief outline of the presence NeOn currently opted to have on the Web and provide to the members of the Consortium to help remote collaboration:

NeOn public web site (http://www.neon-project.org)

Purpose: The primary purpose of the public web site is to act as an outlet to reach out from the NeOn project to the general public and any other audience knowledgeable or interested in the research and technology aspects of the project. In order to achieve a dynamic image of the project the web site has been designed using a mix of static content and dynamic ‘news story’ style announcements, reports on progress, reviews of events or products, etc.

Etiquette: As the intended audience of the NeOn public web site is general public, it is critical to ensure accessibility and readability of any content published through this channel. Therefore the web site is managed centrally by the Editorial Board and the Coordinator who commission regular feature-length stories on topics agreed by the EB from project partners. Also, all partner-submitted news stories or announcements will be subject to approval by the EB.

People responsible: Primarily the Editorial Board in close collaboration with WP10 leader.

Documents input/output: Stories can be submitted to the public web site via a dedicated administrative interface, to which members of partner organizations were given username and password access. On the output, the content of the NeOn public web site will be syndicated using RSS standards, which will be published so that it could be subscribed to and/or used as live bookmarks (e.g. in Firefox).

NeOn management portal (http://www.neon-project.org/management)

Purpose: The primary purpose of the management portal is to collect and store various data related to reporting on progress and effort related to the project, and do it a cost-effective way.

Etiquette: As described earlier in the procedures for bi-monthly and/or periodic reporting, partners are asked to submit information on time and reflecting the ‘gold standard’ given to them at the beginning of the project. Data input shall be realistic, related to the actual, necessary and economic costs of the activities carried out by a partner.

People responsible: Management portal technology and infrastructure is managed by UPM as a part of their contribution to WP10. Project leaders (or people appointed by them) submit information on partners’ effort expenditure together with a brief justification of this claim; WP leaders collate this input and provide an overall progress for their WP; Project Administrator checks, produces and formats the web-based input into a *.DOC report

Documents input/output: Input is done using an online web form, which supports basic formatting directives; the output is by default an *.HTML document, which could be converted into a *.DOC report

NeOn Collab Space (http://www.neon-project.org/ACollab)

Purpose: The primary purpose of the NeOn Collab Space is to act as a repository of shared files and documents that supports their collaborative writing, incl. version control, freeze, etc. The intention of separating this space from the public site or management portal is twofold: (i) to have a track record and version evolution of a particular item, and (ii) to act as a repository of potentially deliverable items (e.g. scientific papers, deliverables, posters) – this is to distinguish ‘a work compiled into a formal file’ from ‘a preliminary brainstorm’.



Etiquette: NeOn Collab Space is based around a folder structure, which is managed by the coordinating partner (OU); there are folders available for each work package and some other project-wide folders – partners shall contact an OU staff member in case they need different or specific structure of the folders in their WP. Furthermore, as Collab Space is document-centric, document labels shall comply with the guidance provided earlier in this plan. While versioning and revisions are managed automatically, it is important to keep an unambiguous referential frame.

People responsible: NeOn Collab Space is managed by the coordinating institution (OU) who maintains it, backs up its database and manages logins for the partners. All members of partner institutions are responsible for uploading appropriate documents.

Documents input/output: Documents uploaded may include any of those formats mentioned earlier in this plan; however, authors shall note that to each document and/or revision there is a short ‘rationale’ section to summarize the content and/or purpose of the upload within 1-2 sentences.

NeOn Wiki (http://www.neon-project.org/wiki)

Purpose: The primary purpose of the NeOn Wiki is to support various less-structured and impromptu interactions within working groups that are centred on the ideas and their capture or development, rather than on any formal document. Hence, NeOn Wiki is, in principle, provided as a remote brainstorming room or as an area for thinking. Due to the nature of Wiki pages, these cannot be presently used as a replacement for any actual deliverable and/or report. Authors are advised to convert or export an agreement reached using Wiki into more standard files and documents.

Etiquette: NeOn Wiki is a standard installation of MediaWiki software enhanced by using semantic module (contributed by UKARL); people shall observe common guidance and advice regarding writing shared web pages – a copy of this guidance notes is available via Help option. Since NeOn Wiki contains ideas that are internal to the project, and as such may be valuable (esp. prior to their publishing) it has been agreed to password protect the core sections of the Wiki – with the exception of generic, introductory pages.

People responsible: NeOn Wiki is managed by the coordinating institution (OU) who maintains it, backs up its database and manages logins for the partners. All members of partner institutions are responsible for writing or amending stories, and also we strongly recommend they use semantic annotations, which enable others to query the Wiki content.

Documents input/output: Wiki content is essentially formed by web pages that are editable by a community; NeOn Wiki provides opportunities to include semantic tags and annotation into standard Wiki pages, and also to use mathematical formulae for more complex formal discussions about theories or methods.

2.8.3 Document exchange Documents will be exchanged using the following methods (in descending order of preference):

Table 11. Methods of documents exchange

Documentation Type Method Meeting documentation (agendas, minutes, etc.) Email, WWW Technical documentation (papers, presentations, etc.) WWW, email Administrative documentation (management reports, etc.) WWW, email, fax Cost Statements courier, post Contract Signatures courier, post


3. Risk Contingency in NeOn Responsibilities for risk management are shared between all partners and the impact of actions and inactions by the Consortium is acknowledged and open to challenge in striving for high-quality outcomes. An analysis was undertaken by EPMB under Task 11.2 of WP11 to identify and assess factors that may jeopardize the successful achievement of the project milestones. The risk analysis also suggests preventive measures to reduce the probability of these factors from occurring and countermeasures for successfully dealing with these constraints when they develop. For major foreseeable risks which were identified, a Risk Contingency Log (Appendix 1) was created. This Log will be reviewed as a standard activity at each EPMB (monthly) and developments on active risks will be updated in the Log. Any new risks that arise will be added to the Log. In addition, the PMB and SAB will annually review and assess the project at large, to identify, strengths, weaknesses, arising opportunities and risks. The results of this review will be fed into later versions of this Quality Assurance and Risk Contingency Plan.

During this initial review, different categories of risks were identified and assessed including RTD risks, management risks, organisational risks and business risks (Figure 1 maps out the relationship of these risks). The EPMB will have responsibility for monitoring these risks based on the information sharing & reports emerging from the work package activity and plenary meetings. As soon as a risk factor becomes “Active” (i.e., when it appears that an impact is likely, then that row in the Risk Contingency Log will be designated a colour corresponding to on of the following: red= high impact, orange = medium impact, or green = low impact. In addition, an EPMB member will be assigned the task of reviewing and creating a proposal for action to reduce and/or manage the risk and/or its consequences. The owner of the risk factor will feedback to the next EPMB meeting and the Log will be updated as appropriate by the Project Administrator. Proposals for action to manage active risks will be presented to the PMB whenever deemed necessary by EPMB.



Figure 3. Relationships of various categories of risks

Examples of the major risks identified in the Risk Contingency Log are:

High-impact risks:

• Technology changes requiring redesign of NeOn architecture/tools; • Tools cannot interoperate within NeOn or with other existing standards; • Application of NeOn technology is not accepted by users and customers; • Adverse changes in conditions of the general market and market for semantic technologies

Medium-impact risks:

• Time for development is underestimated • Partner leaves consortium and its responsibilities need to be re-assigned; • Key staff illness during critical project phase; • Research or software components fail or deliver limited functionality; • Multi-disciplinary nature of the consortium may lead to three disciplines working separately

Low-impact risks:

• Staffing & Recruitment problems. The Risk Contingency Plan will be reviewed as appropriate and remedial actions will be adapted and refined as necessary to address the changing external risks that NeOn encounters during the life of the project.


APPENDICES

Appendix A.- Risk Contingency Log

Exists as an Excel file and an attachment to this document.



Appendix B. - Assignment of People to Roles in the Consortium

Role-Title Name Organisation Executive Project Management Board:

Project Coordinator& Scientific Co-director:

Enrico Motta OU

Scientific Co-director: Rudi Studer UKARL

Asunción Gómez Pérez UPM

Technical Management Board Chair (WP6)

Walter Waterfeld SAG

Richard V. Benjamins iSOCO

Project Administrator & Quality Coordinator:

Jane Whild OU (non voting member)

Evaluation Coordinator: Martin Dzbor OU (non voting member)

Peter Haase UKARL (non voting member)

Project Management Board (aka GA) (also =Project Scientific Board):

Enrico Motta OU

Rudi Studer UKARL

Asunción Gómez Pérez UPM

Walter Waterfeld SAG

Richard V. Benjamins iSOCO

Marko Grobelnik JSI

Jérôme Euzenat INRIA

Hamish Cunningham USFD

Steffen Staab UNI KO-LD

Aldo Gangemi CNR

Jürgen Angele ONTO

Gloria Tort AECE

Johannes Keizer FAO

Aljosa Pasic ATOS

Technical Management Board:

Work Package 6

Project Editorial & Dissemination Board:

Aljosa Pasic ATOS

Johannes Keizer FAO

Martin Dzbor OU

Jane Whild OU


Scientific Advisory Committee:

John Davies, British Telecom UK

Frank van Harmelen Free University Amsterdam, The Netherlands

Mark Greaves Halo Project, US

Mark Musen, Stanford University, US

Nigel Shadbolt University of Southampton, UK

WP Leaders & Quality Controllers (QC) :

WP1 – Peter Haase UKARL

WP2 – Aldo Gangemi CNR

WP3 – Marko Grobelnik JSI

WP4 – Martin Dzbor OU

WP5 – Mari Carmen Suárez-Figueroa

UPM

WP6 – Walter Waterfeld SAG

WP7 – Marta Iglesias FAO

WP8 – Jose Manuel Gomez iSOCO

WP9 – Udo Hafermann SAG

WP10 – Aljosa Pasic ATOS

WP11 – Jane Whild OU



Appendix C.- Glossary of approved Acronyms used in the Project PROJECT BODIES ACRONYMS

AECE Asociación Española de Comercio Electrónico

ATOS Atos Origin, s.a.e.

CNR Consiglio Nazionale delle Ricerche

FAO United Nations Food & Agriculture Organization

INRIA Institut National de Recherche en Informatique et en Automatique

ISOCO Intelligent Software Components, S.A.

JSI Institut ‘Jožef Stefan’

ONTO Ontoprise GmbH

OU The Open University

SAG Software AG

UKARL Universitaet Karlsruhe (TH)

UNI KO-LD Universitaet Koblenz-Landau

UPM Universidad Politecnica de Madrid

USFD University of Sheffield

OTHER ACRONYMS

EB Editorial Board

EC European Commission

ECO Evaluation Coordinator

EPMB Executive Project Management Board

NeOn Lifecycle support for networked ontologies

PA Project Administrator

PC Project Coordinator

PEB Project Exploitation Board

PMB Project Management Board (GA) = Project Leaders

QA Quality Assessors

QC Quality Controllers

QCO Quality Coordinator

REV Reviewers

SCD Scientific Co-directors

TL Task Leaders

TQ Total Quality

WP Work package

WPL Work Package Leaders