CRIG Scenarios

From DigiRepWiki

[ CRIG Home | CRIG Telcon 29/3/07 | CRIG Scenarios | CrigCasts (Podcasts) | Unconference (Bloomsbury, Dec 6/7) | ReST Workshop (Bloomsbury, Feb 8) | RepoChallenge (Southampton, April 2-4) | DRY Barcamp (Bath, Friday June 6) | Roadshow (July 08) | RepoCamp (LoC 25 July 08 ]

DRAFT scenarios



The following three large-scale scenarios have been created by the JISC Common Repository Interfaces Working Group to expand on the three short scenarios included in the JISC funding circular issued April 2007. These scenarios are broad, focusing on a wide set of interactions, rather than on any one particular aspect of a system. As such, they do not represent an exact description of what the proposed interoperability projects need to address. Instead, they describe examples of the types of scholarly processes that any interoperability demonstrator project would need to recognise and support. Where particular entities, such as repositories, are referenced, this is intended to describe a set of functionality, rather than a particular system or software. Full implementation of any single scenario may not be practical for an interoperability demonstrator project, although projects will need to demonstrate that they take a process-wide view. As noted in the funding circular, “Acceptable scenarios are those that address scholarly communication and (i) would be recognisable and seen as plausible by the actors involved, and (ii) require interoperability between systems beyond a single institution.”

Scenario one - The Scholarly Cycle

SHORT VERSION: The Scholarly Cycle: A researcher discovers and reads papers on her project topic, some of which are accessed from repositories; she reviews some repository-hosted papers and a dataset for journals and workshop, works on her own dataset via a laboratory repository and analysis tools; she starts a new workshop paper, which synchronises with her institutional repository, drawing metadata from other institutional, national and international services as appropriate.

EXTENDED SCENARIO: A researcher reads around a particular research topic using subscription and open access journals, libraries and repositories. She reviews some new papers and a dataset in a national data archive, in the process comparing it with datasets and papers held in other archives and repositories. She then applies an analysis tool to her own dataset, held on a laboratory repository and being updated by a sensor array at remote locations. She identifies an unnoticed pattern, discusses this with colleagues online, and identifies the potential for a workshop paper. She creates the first draft of the paper on her laptop which migrates and synchronises automatically to the institutional repository (along with the blogged discussions) and whose metadata is automatically populated with her and her team’s names, the project name, persistent links to relevant datasets, funders and relevant grant codes. Her project collaborators (based at a range of institutions) have edit rights to the new document, and there is full version roll-back and audit. The whole team is emailed to alert them to the existence of the new document. The paper is flagged for submission to the workshop, it is reviewed in place by the program committee, revised according to the reviewers comments and accepted for publication. Several months after the workshop, citations to the paper start to be collected automatically by the repository from other repositories, secondary literature databases and Google Scholar. The paper and data are included in a teaching resource that is exported to the University's VLE, and a summary of the paper is created for the marketing department to use on the University's web pages. A short interview with the Radio 4 Science Today program ensues; a clip and transcript of the recording are added to the repository as part of the RAE Portfolio as evidence of profile and public engagement.

Scenario two - The all-round academic

SHORT VERSION: The All-Round Academic: An academic holds teaching materials, research papers, committee notes, email threads and so on on his laptop. The institutional repository offers services whereby these are held and managed (datestamped, version controlled, related to each other, etc), by dynamic reference to other institutional, national and international services as appropriate.

EXTENDED SCENARIO: An all-round academic is employed to do research, teaching and administration. His laptop holds a wide range of information: data files of experimental readings extracted from external systems, analyses, discussions with his PhD students, drafts of papers, project proposals, project reports, committee minutes, meeting agendas, email threads, logs of IRC discussions, blog entries and Wiki pages all of which reflect the single or compound objects forming fragments of the researchers' contribution to "scientific communication". The institutional repository, or repositories, offer services whereby these can be captured, described, stored and managed, often automatically. This fine-grained deposit/management process offers a set of services or operations on items, both archived and in-waiting to be archived, so that content and metadata (and more) can be updated or added discretely, and status and current content can be determined through defined user or machine-to-machine interfaces. Management activities include datestamping, version control, metadata creation, classification, capturing relationships between items, and preservation. The repository(ies) uses a series of external services, including the SHERPA RoMEO database, the IE Metadata Schema Registry and format registries to validate, check and describe ingested material and also to identify new material available for ingest or reference. The institutional repository(ies) also employs a range of mechanisms for getting content and metadata into the repository from various sources, largely using existing standards and specifications. These include bulk ingest from legacy expertise databases, dynamic ingest from live Current Research Information Systems (CRIS), external thematic repositories (such as arXiv and PubMedCentral) and external secondary literature databases, and automated deposits from the researchers' desktop.

Scenario three - Complex Objects in Teaching and Admin

SHORT VERSION: Complex Objects in Teaching and Admin: A lecturer creates a reading list for one of his MSc modules and stores it as an item on the teaching repository, which forms a basis for students' learning activity resulting in heavily annotated and amended versions of the reading list being submitted to the learning assessment repository. The examination and quality assurance processes are then managed using linked materials from repositories of teaching, teaching quality administration, and other administrative materials, with appropriate outcomes being made available via the students' eportfolio application.

EXTENDED SCENARIO: A lecturer creates a reading list for one of his MSc modules and stores it as an item on the Teaching repository. Each of his students create duplicates of the reading list on the Student Learning repository and annotate each entry with summaries and notes. They also create a review paper, with citations and internal links to each of the items of the reading list object which are then submitted to the Learning Assessment repository. After marking the submissions, the lecturer attends Exam Board where a master Exam Grid object links each mark to the assessed material, the coursework description and the coursework, module and degree specifications in the Teaching repository. Minutes of previous exam boards, recording past decisions on individual special circumstances are referred to in the Teaching Quality Administration repository. Once agreed, the new Exam Grid object is stored with the minutes of the current meeting as a new entry in the TQA repository, and the marks are released to students (with appropriate authorisation). The marked objects are then imported by the students into their E-Portfolio objects back in the Student Learning Repository.