ViRR Scope
Revision as of 11:31, 16 June 2009 by Kleinfercher (talk | contribs) (→Project Phase: deleted ISBD as this will be part of R3.0)
|
Planning[edit]
The solution ViRR will be planned and developed in several phases, each of them with different focus.
Each phase will be divided into several implementation steps (releases), to allow gradual but ongoing specification and development.
Details about each release can be found below.
Specification and functional prototypes for each release will be available on the Wiki.
Please note that phases and respective releases might be adapted during development life cycle.
FIRST PHASE - Publication of the digital collection[edit]
Release 1[edit]
R 1.0
- Ingestion (no user interface)
- scans --> derive from file structure a basic skeleton of toc
- bibliographic metadata: MAB mapping to MODS
- structural metadata: eSciDoc container
- derive basic keywords from bibliographic metadata
- Browsing and Display (basic)
- alphabetical sorted browsing tree (multi-volume works, parts and pages)
- display of basic bibliographic metadata (name of book, page)
- display of scans in detailed view
R 1.5
- Original picture size in new window
- Link to DFG Viewer
- Only 1 book for a start (ingestion will be continued successively)
Related Links
- Functional Prototype for R1 (requires login)
Release 2[edit]
R2.0
- New GUI for bibliographic Metadata (on booklevel, volume level, multivolume level)
- Edit bibliographic MD
- Browsing by physical structure/scans
- URL for each image
R2.1
- Editing
- create logical pagination
- enrich toc skeleton with information on structural elements (i.e. chapters)
- relate pages and structural elements (e.g. page 1-5 = chapter 1)
- add metadata about the chapters, e.g. keywords
- Browsing and Display (enhancement)
- display of all information collected during the editing process
- linking between the structural elements and the corresponding scans
- Ingestion all pages of the 2 books
- Simple User Management
- Log on / log of
- Editor role
Related Links
- Functional Prototype for R2.1 (requires login)
Release 2.5 (Pilot Release)[edit]
Scheduled for end of June
- Minor changes in ToC Editor and Browsing page, based on feedback from last meeting (07.05.09)
- Rework of hompage content (by institute)
- Rework of the start browsing page
- Will include Oertel 1-8 and Schauroth 1-3
Automated Ingestion[edit]
(Independent from Releases, depending on efforts for automatic JPEG generation. Latest: September 2009, possibly earlier)
- Extend ingest procedure to automatically generate JPEGs incl. parameter setting for JPEG generation (no crop)
- Will not include cropping of black frames (was done manually by Denise so far, which would be a huge effort for all images)
- Ingest all volumes from collection Virr
- Ingest TIFFs from gwdg
Release 3.0 (Productive Release)[edit]
Scheduled for end of September
- Potential critical improvements after testing phase
- Bookmarkable pages/nice URLs
- Google-enabling
- Help (context-sensitive, tool-tips)
- Disclaimer (institute)
- Copyright/usage info (institute)
- Display Metadata in ISBD style (find detail specification here).
Related Links
- Functional Prototype (will follow)
Project Phase[edit]
- Browsing and Display (detailed)
- systematic browsing tree as alternative entrance to the collection (see order in the systematical list of the digitalized works)
- integration of Digilib functionalities (minimum: zoom in, zoom out)
- dynamic generation and integration of "identification stamp" ("Herkunftsnachweis") on the images (whole image, selected part of image) --> new Digilib requirement
- View Scans as thumbnail (multiple scans on one page)
- View actual and following page
- Search
- simple search (one search field "any field")
- advanced search (several special search fields, e.g. one for title, one for author)
- paginator for search list (--> GUI)
- Ingestion
- Ingestion of one MAB data set during edit bibliographic metadata
- Scans and/or bibliographic metadata from OPAC
- Export
- image selection
- downloading of selected images(in separate jpgs)
- downloading of selected images(in one pdf with a cover page)
- downloading selected part of an image
- downloading of METS-xml
- export of some bibliographic metadata for the opac of the institute (In a txt file)
- aim: to integrate the persistent id in library catalog
- integration of "Herkunftsnachweis" in pdf compilation (one page with Herkunftsnachweis should be included). (see DFG best practice)
- Export of books, basket as pdf
- Edit
- Validation before release (unpaginated pages, not assigned pages etc.)
- Other
- Integrate Normdata (Author, Subject=SWD)
- Icon Class (depends on availability)
- Basket function
Further requirements[edit]
- "Genre specific entry mask" for different types of structural elements
- OAI-interface
- New action: download METS/MODS xml (together with export func in project phase)
- Nice Urls
SECOND PHASE - Virtual research environment[edit]
Following is a list of requirements ...detailed release planning will come at a later stage.
- Display keywords as list (cf. Index in a book)
- Persistent Identifier (PID)
- Album management (analog to Faces), but perhaps without the publishing functionality
- Workflow for edition process of collection, incl. metadata, images, annotations, external sources (upload, editing, annotating, scientific review etc.)
- User Management to support workflow
- Fulltext transcription online (offline client at later stage) - in METS
- Ingestion/Upload of additional books (digital images + bibliographic metadata) - local resources, BBAW-DTA
- Adding and editing of bibliographic and descriptive metadata
- Adding annotations / comments
- Adding relations
- Integration of external resources (Deutsches Rechtswoerterbuch/Heidelberg)
- Creation and maintenance of synonyms
- Offering metadata to the ZVDD(zentrales Verzeichnis digitalisierter Drucke) and other virtual libraries - OAI interface for the exchange of metadata
- Sitemap protocol for crawlers
- Integration of research literature for download (bibliographic lists? articles?)
- Linking to other digital archives / OPACs /research projects
- Delivery of one complete dataset for the DNB for long term archiving
- Collection description (requ. DFG)
ToDos (Discussion):
- Structural analyzes of the data of the Deutsche Rechtswörterbuch
- Analyzes of the requirements of the ZVDD
- Text editor for the creation of transcriptions is needed
Expectations[edit]
Expectations MPIeR[edit]
- The content of the collection ViRR will be digitally preserved and persistently identified.
- The data of the collection ViRR will be published open access.
- ViRR will be an open collection, so the import of further digitized work will be possible after the solution is in production.
- The ViRR solution has to be configurable so that the institute will be able to use it independently for further digitization projects.
- The solution, services and framework are continuously maintained and further developed by a central unit.
- The ViRR project has to follow the DFG Praxisregeln. The paper covers following aspects:
- selection of works
- digitization techniques
- digital preservation
- metadata (METS and TEI for structure metadata, should)
- re-use and integration with portals (OAI-PMH, must)
- persistent identification (URNs and/or DOIs, should)
- accessibility of metadata & digitized works (open access, must)
- required functionalities for representation
Expectations MPDL[edit]
- ViRR will be a service based on the eSciDoc infrastructure for handling scanned books.
- ViRR will be delivered as an open source self-contained solution, which can be installed and run with predefined standard set-up.
- The MPDL will use the ViRR solution as showcase for demonstrating possible research data scenarios based on the infrastructure. The institute's staff will support respective outreach activities by reporting on their experiences.
- The MPDL has access to the root account for administration purposes.
- The data of ViRR will be hosted at the MPDL (and/or its partners like the GWDG), who are also responsible for the server administration. Details will be fixed in a service level agreement.