It is anticipated that Portable Web Publications (PWP) for the Open Web Platform will need to be archived.
[pwp-archival-services] This document describes
archival use cases and requirements of potential interest to those developing the vision and requirements for PWPs.
Status of This Document
This document is merely a W3C-internal
document. It has no official standing
of any kind and does not represent consensus of the W3C Membership.
There are multiple definitions of "digital preservation," but among the more useful starting point definitions are the
[definitions-of-digital-preservation]
posted several years ago by the American Library Association's Association for Library Collections and Technical
Services. These include: "Digital preservation combines policies, strategies and actions to ensure access to reformatted and
born digital content regardless of the challenges of media failure and technological change. The goal of digital preservation
is the accurate rendering of authenticated content over time." Various workflows and approaches (i.e., use cases) have
been developed over time to create services that strive to meet this definition of digital preservation.
Captured here are some of these use cases and parts of use cases that provide context and articulate the requirements and expectations
typical of archival services that are likely to archive PWPs. To add a use case, please copy and populate the template
and insert as next new section below. The use cases are for now unordered. The template provided is adapted from the IG's Use Case Template.
[dpub-use-case-template]
2. Use Cases
2.1
Initial harvest of a PWP by an archiving service
Description
An archiving service wants to harvest a PWP.
Requirement(s)
The archiving service must have a way to discover the locations of all the components of the PWP.
All components of the PWP must be dereferenceable by the archiving service.
An archiving service needs to update an Archival Information Package (i.e., a previously harvested PWP)
because a new version of a component of the PWP has been published.
Requirement(s)
The archiving service must have a way to discover that an updated component of the PWP with an unchanged URI has been published.
The mechanism for enabling the archiving of a new version of a single component of the PWP should also scale up to multiple or all new components of the PWP.
The magnitude of the change to the component (e.g., correcting a spelling error versus major editorial revisions) should not otherwise matter.
Created By
Nicholas Taylor
Status
NEW
2.3
A new PWP component is published
Description
An archiving service needs to update an Archival Information Package (i.e., a previously harvested PWP)
because a new component of the PWP has been published.
Requirement(s)
The archival service must have a way to discover that a new component of the PWP has been published.
The mechanism for enabling the archiving of a new component should also scale up to multiple new components of the PWP.
Parsing of harvested bibliographic metadata is the responsibility of the archiving service.
Created By
Nicholas Taylor
Status
NEW
2.5
A Retraction Notice of a PWP or PWP Component is Issued (but the original PWP Remains)
Description
An archival service needs to harvest the retraction notice and update the Archival Information Package for
the original PWP to include / link to the Retraction Notice. (Need to clarify likely action here and if archives
in practice use more than one approach, may need more use cases.)
Requirement(s)
List of requirements drawn from the above Description.
Stakeholder(s)
Always use a consistent and preferably predefined value: ARCHIVING-SERVICES, LIBRARIES, PUBLISHERS-ALL, PUBLISHERS-STEM, USERS-ALL, USERS-A11Y, RETAILERS, IMPLEMENTERS.
New values can be added to this space as they are needed.
An archival service needs to update an Archival Information Package (i.e., a previously harvested PWP)
because it or one of its components has been taken down by the publisher.
Requirement(s)
List of requirements drawn from the above Description.
Stakeholder(s)
Always use a consistent and preferably predefined value: ARCHIVING-SERVICES, LIBRARIES, PUBLISHERS-ALL, PUBLISHERS-STEM, USERS-ALL, USERS-A11Y, RETAILERS, IMPLEMENTERS.
New values can be added to this space as they are needed.
Relations/dependencies
Optional, links to other use cases.
Relevant W3C group(s)/specification(s)
Where the target WG/spec is obvious, specify it.
External relevant group(s)/specification(s)
Where there are external groups/specifications that address on this problem in whole or part.
Comments
Any additional info (clarifications, etc.).
Created By
Ayla Stein
Status
NEW
2.7
An Archived PWP needs to be validated periodically while in archive in order to know when format migration is required.
Description
An archival service needs to validate that a previously harvested PWP and all of its components
are still viable in order to determine when format migration is required.
Requirement(s)
List of requirements drawn from the above Description.
Stakeholder(s)
Always use a consistent and preferably predefined value: ARCHIVING-SERVICES, LIBRARIES, PUBLISHERS-ALL, PUBLISHERS-STEM, USERS-ALL, USERS-A11Y, RETAILERS, IMPLEMENTERS.
New values can be added to this space as they are needed.
Relations/dependencies
Optional, links to other use cases.
Relevant W3C group(s)/specification(s)
Where the target WG/spec is obvious, specify it.
External relevant group(s)/specification(s)
Where there are external groups/specifications that address on this problem in whole or part.