D6.1

From Soteria
Jump to: navigation, search


Lead Beneficiary: ROB

Beneficiaries involved: ROB and all other institutes as users.

Due Date: Month 3 (Feb 2009)

Contents

Goal

The main objective is to create an online reference documentation repository where the SOTERIA community, and the space weather community in general, can share documents.

Progress so far

We have reached an agreement with the people (Stijn Calders) from http://www.spaceweather.eu/ to develop and host for us the community wide document repository. A beta version has been presented at the Consortium meeting in Lapland for feedback: http://soteria-space.eu/meetings/lapland230309/material/talks/dhuys.pdf The software is in an advanced state of development. We aim at a public release by May 15.

Timeline

(note that the reference date in the proposal for this deliverable was Feb 1)

09/01/2009 Requirements definition
23/01/2009 Analysis & software design
01/03/2009 Proof-of-concept (working basic implementation, including minor and major bugs)
15/03/2009 Testing of the system and upload of first documents
20/03/2009 Beta release presentation to SOTERIA consortium
01/04/2009 Patching the bugs and deployment
01/05/2009 Finalisation, internal release, final tests
15/05/2009 Finalisation, internal release, final tests

Analysis of the requirements

  1. the repository will store reference documents
    1. the storage should be safe (back-up etc). SC discussed it with the IT department at BISA, and there’s a daily backup of all files and databases on the webserver of Spaceweather.eu.
    2. reference documents implies that no versioning should be foreseen. Only finished documents should be stored. Refinement: it should be possible to delete documents or to replace files.
    3. all types of content should be allowed (science papers, technical descriptions, images, reports, etc). No technical implications.
    4. all types of formats should be allowed (for the time being we restrict to documents consisting of 1 file only, optionally tar group of documents)
  2. the repository will allow users to upload documents
    1. the size limit per individual document should be sufficiently high (a book of 100s of pages with 10s of pictures should be possible). he maximum size of one file should be 50MB. We guess that the total size of all files is less than 1GB in the first phase of the project.
    2. in order to avoid abuse, only registered users should be able to upload
    3. when uploading documents, the user should fill in required and optional metadata keywords
      1. the required keywords should include original filename, author(s), institute(s), production date, title and a few drop-down menu of topics. These fields are marked as mandatory (not null) in the database: title, author, file and topic list. All other fields are optional. Topics are non-hierarchical, but they are grouped. Production date: time of insertion in the database. Also the userid of the person who uploaded the document should be included in the database.
      2. the optional keywords should include a full abstract. The abstract is in ASCII format.
      3. optional and required keywords should be configurable. It’s possible to define store optional keywords in the database and to do a basic search on them (exact match).
  3. the repository will allow everybody to download the documents
    1. in contrast to upload (see 2.3), download should be open to everybody, also non-registered users.
    2. individual documents should have a stable url that can be used elsewhere. On a short period this is okay, but it can be a problem when we want to rename the website, upgrade the content management system, … So SC can’t promise to fulfill this requirement.
    3. a scrollable overview of the documents contained in the repository should be online. The organization of this overview is TBD. Sorting on each field of the overview will be supported.
  4. the repository will allow searching the metadata
    1. a simple google-like search interface should allow to retrieve documents (maybe it could be google itself?). Google index service has some problems, so SC advises to use Full-Text Search.
    2. all words in the required and optional metadata should be searchable. In the first version, it shall only be supported in advanced search. Advanced search isn’t able to run a full text search on the abstract and title.


Author’s names should be in this format: CALDERS, S. There should be a basic interface for uploading a lot of documents at once. The order of authors is very important in scientific papers. It should be remained in the database. Uploading bibtex(-like) files is not a priority. After upload, there’s a timestamp added to the filename to avoid collisions, e.g. SOTERIA.pdf becomes SOTERIA-20090206134906.pdf

Retrieved from "http://soteria-space.eu/newwiki/index.php/D6.1"
Personal tools