Common use of Target of Evaluation Clause in Contracts

Target of Evaluation. The BlogForever platform is the target of our evaluation, but this system is not a single component. For the purposes of WP5, the parts of the BlogForever system to be evaluated are: (a) The crawler software: also called the "weblog spider component", under development by CyberWatcher at time of writing. This spider will be responsible for weblog data extraction, manipulation and transfer to the digital repository. The evaluation must determine how well the spider is able to harvest blogs. (b) The digital repository web application component: this will include the public delivery platform, through which renditions of harvested blogs can be viewed; and evaluation of the functionality of the repository - more precisely, those specific parts of the functionality already defined in 4.1 [1] for the repository in conjunction with the spider. Additionally, the following elements are considered to be general attributes and characteristics which the completed BlogForever platform will aim to offer. They are: ✓ Digital preservation ✓ Data migration ✓ Quality assurance checking ✓ Collection curation ✓ Additional national laws restrictions These elements will also be evaluated by WP5. It is recognised that elements may have certain dependencies on other features that the repository already has, or will develop later. Evaluation of these elements will likewise be phased in a managed fashion as these features are successfully implemented. • Repository support for file formats found in blogs • The support of METS and PREMIS metadata schema • The ability of the repository to migrate file formats, or perform encapsulation of blogs, or emulate blog functionality • The ability of the repository to run standard ingest procedures automatically (e.g. file format verification, checksums, virus scanning) • The overall capability to identify and maintain significant properties of blogs over time, and automate this process as far as possible • Repository databases for managing and storing content and metadata • Format support in the repository, e.g. the ability to export data as XML or CSV • Metadata management, including metadata for blogs, conformance with the OAI-PMH protocol and the Dublin Core schema • The repository supplying tools for data quality and integrity checking of the data itself • Well-maintained user profiles; ranking; tagging; and other metadata created by active users of the service. This will enable them to find good quality relevant posts. • The ability to detect and remove duplicates • The ability to detect and remove spam content • Features that define important content and can filter out unimportant content • The ability to define permanent URIs and metadata for purposes of referencing and citation Curators, be the libraries or other memory institutions seeking to build and manage collections of blogs, will need privileged access to the system and the ability to perform certain actions. The dependencies of collection curation are: • BlogForever's ability to search and retrieve records • A functioning mechanism to sort them into meaningful collections • The ability to add, remove or edit metadata • A useable, reliable and secure front-end provided to curators for this purpose The requirement for the observation of additional national laws reflects a very specific requirement. BlogForever will not produce software with a blanket assurance that its use will not break the copyright law of the country in which it is deployed. The project intends to give the administrators the possibility of configuring the platform so that users can restrict access to the content, either the whole archive or part of it. It then becomes the responsibility of those who install the software to respect the law. The dependency here is: • The BlogForever platform can be configured so that it respects additional laws of organisations in the country in which the archive is running T5.2 thus faces the job of mapping further the generic requirements of D4.1 [1] to specific BlogForever features. The current WP4 mapping document is a "living" "working" document subject to changes according to the WP4 developers' planning of iterative implementation. This has been agreed as a method that makes it easier in the future to justify features and corresponding requirements changes as they are needed within T5.2. Table 2 - Example of initial details for T5.2 further mapping of T4.1 generic requirements Features UNDEFINED Interpretation Long term digital preservation of the archived content, validation of files, checksums, functional preservation, identifying, safeguarding and preserving archival records and ensuring that these are accessible and understandable. Sophisticated electronic records management systems will therefore include not only functions necessary for document management, but also features supporting these longer-term perspectives. These include: the association of contextual and structural data within a document; the construction and management of audit trails; document version control; support for disposition scheduling; and scheduling; and maintenance of the relationships between records in files, file series, and the corporate filing plan. DR21 is regarded as a generic requirement that cannot be directly mapped to specific features. This generic requirement on long term digital preservation will have to be re-analyzed and broken down to map against specific features, as part of T5.2. One possible deliverable which may assist is Deliverable 3.1.C Examination of OAIS compliance, submitted by UL within WP3 subtasks in March 2012. This document describes a repository workflow for digital preservation and has identified 17 potential features of this workflow. Early tests CERN's proposal is to create specific features which will map to this generic requirement for digital preservation. There will be no need to create new entries in the features list for things that are already covered in other features. The plan is to map the DR21 requirement to every existing feature that satisfies part of the requirement, and then continue to add new features for the missing elements. It is worth noting that some of the features of digital preservation are related to a service and not to a piece of software (like those to do with hardware, for example). Later tests