Scope Definition – Publication Management Release Q1 2007

1. Scope Definition – Publication Management Release Q1 2007 December 2006 Version 3

2. Purpose of this document • Describe the functional scope of Q1 • Describe the maxims in defining the scope of Q1 • Describe some details in specification relevant for Q1 • Main target groups of the document: • eSciDoc project MPG, SMC and FIZ • Pilots

3. Background • Service-oriented architecture approach • Identify useful functional components (submission, search, browse/display) • Break down available specification to small, coherent sets of use cases • Align scope of Q1 with long-term release planning of services/components • Consider Laurent Romarys ideas for „scientist release“ whereever suitable • Feasibility Meeting on 30 oct (MPG, SMC, FIZ, LR) • Define scope and get started … • Consider expectations BMBF (focus on eScience infrastructure) • Consider expectations pilots (focus on admin - functionalities) • Consider expectations Romary, scientists (focus on re-use/easy use functionalities)

4. Results of PM functional team • Adapted policy changes for PubMan (Laurent Romary): • All Metadata are visible to public • Changed: no visibility level for metadata on collection level • Affiliation tree can have multiple roots • Changed: affiliation concept, removed <affiliationtype> • Scope/content of PM not limited to MPG publications, but „any content of relevance for a MPG scientists“ (i.e. includes publications affiliated only to external organisation) • Defined and adapted 12 uses cases and data model relevant for components • Submission • Browse/display • Search • Finished functional requirements for MDS • Finished wireframe for relevant use cases • Basic elements of GUI design as navigation and content sections • Conceptual, no detailled design

5. What to expect from Q1 – maxims for scope definition • First release of components will be • Touchstone (Prüfstein) for functional specification, design, preliminary architecture and user interfaces • Reduced functionality, properly designed and implemented (no prototype) • Infrastructural showcase • Target group • mainly project intern (MPG, SMC, FIZ) • Interested partners from scientific and librarian communities • BMBF, wissenschaftlicher Beirat (focus on architecture) • Aim • Serve as first example for ongoing development of SOA approach • Starting point for focussed further developments • Provide tangible, concrete modules for user discussion (vs. abstract documentation) • detect bugs/shortcomings in functional specification • check integration functional components and framework

6. Overview functional scope Q1 • Simple search • Manual submission of items • Basic browse and display • one interface language (english) • Additional language considered in design for help and error messages • one sample collection (hardcoded) • MPG= responsible affiliation • two sample users (both role depositors) • Incl. sample rules for validation point „submit“ • One sample affiliation structure (hardcoded) • One root (MPG), 5 institutes, with 2 sub-sub-affiliations each • Incl. Sample affiliation with 2 parents (project X) • Help • Basic help available on left navigation bar • Additional context sensitive help for each section • Sample text

7. Overview functional scope Q1 - Submission • Submission: • After submission, item is immediately released without QA workflow • All metadata relevant for a genre are displayed • Access level for files either „public“ or „private“ • Authority files • Basic fundament: link between object <organisation> and metadata of item (organisational description) • Validation • Basic validation rules defined for sample collection, for validation point submission • These rules have to be fulfilled when an item is submitted. • => validation rules serve as example for collection-specific validation rules, for a certain validation point. point submission. • Mandatory elements as specified in MDS have to be filled each time an item is saved by user (genre, at least one creator, title)

8. Overview functional scope Q1 - Affiliations • Affiliations: • Sample affiliations hardcoded by FIZ • One root defined (MPG), with 5 subunits (institutes) and two sub-subunits each • One common subsubunit • Choosing the organisation of an creator during editing of item: • User can choose the organisation from the list of available sample affiliations. When choosing one affiliation from the list, a link is created and the organisation metadata are pre-filled with the appropiate values • The values can be modified afterwards • The modification of metadata copied from an chosen affiliation does not have any implication on the browsing tree of the affiliations • The finally entered affiliation is stored within the item

9. Overview functional scope Q1 – Browse/Display • Browse/Display of items • Itemlist • With display type „list item view“ • Sorting by one selectable criteria (e.g. sort by date or sort by title or …) • Default sorting by „most recent date“ • includes all possible date types in the metadata (created, last modified, published etc.) • Includes option for ascending-descending • Icon/symbol for items with files attached in shortlist of items • Single item view • With display type „full“ (all Metadata provided, cite as <PID of item>, cite this file as <PID of file>) • Includes action buttons edit, submit, delete • Includes browsing back/forward to previous/next items or go back to shortlist • Browse by affiliations • Tree-structure display • Either view items of selected affilition or • view substructure • Information of affiliation is displayed in header when user chooses to view items

10. Overview functional scope Q1 - Search • Simple search • one search field, with option to include search in files • Coverage of search (under discussion with FIZ) • Only metadata records which are attached to the last item version in status „released“ will be searched (all released MD are visible) • No search for pending items via simple search • Pending items are listed in user workspace • In case files are included in search, ALL files will be searched, independently from access level • Search in files inlcudes all content types except correspondence and CTA • No automatic truncation, but user can decide whether to use wildcards • No support for transformation rules required for „Umlaute-Suche“