Re: [dpub-arch] ideas for PWP use cases related to archival services

On 5/3/16 3:13 PM, Timothy Cole wrote:
> > The last few Archival Task Force calls have generated a few ideas for
> PWP use cases related to archival services. Several of these ideas >
are listed below. Please keep in mind that these are only preliminary >
(i.e., not fully baked – in various stages of development), and in >
some cases what we have now can only be thought of as a placeholder. >
In some instances the use case ideas listed below may overlap; in >
other instances the initial idea may conflate multiple use cases. > > >
> Please respond to this email with suggestions for additional >
archival-related use case ideas, as well as with feedback on the > ideas
listed here that will help get us going on Thursday. >
I am noting after each use case the requirement(s) I think it's
suggesting. My questions are whether or not I've captured the
requirements correctly, and what might be missing?

> > > We will spend most of Thursday's Archival Task Force call refining >
and making these ideas more granular as needed, and developing >
additional use case ideas.  Some of the following have already been >
added preliminarily to our Archival Use Cases page, >
http://w3c.github.io/dpub-pwp-arch/Archival-UCR.html. Here's an >
initial list of archival-related PWP ideas to get us going Thursday >
(more ideas welcome): > > > > ·         Initial Capture of a PWP by an
Archiving Service: An > archival service wants to harvest (spider) and
save a PWP, and > expects to find in the manifest the enumeration of
what it will need > to capture to make sure it has all the pieces of the
PWP that need to > be archived, even if these pieces reside on separate
servers. (What > does this mean for the design of the PWP manifest?)
In terms of requirements, this provides input into what's required in a
manifest. Also, that a PWP does need to be made available as a single,
discrete file.

> > ·         A new Version of a PWP Component is Published, requiring >
partial re-harvesting: An archival 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. > (This may in
fact be multiple use cases, see below.) >
I think this is multiple use cases, split at least in part the way you
have it below.

> > > ·         A Revision of a PWP (or PWP Component?) is Published, >
requiring re-harvesting: 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 revised, e.g., a > spelling
error corrected. >
Requirement: some kind of signaling service that will let the archive
know that the files must be updated?

> > > ·         A Retraction Notice of a PWP or PWP Component is Issued:
An > archival service needs to harvest the retraction notice and replace
/ > update /  add to the Archival Information Package for the PWP as >
originally harvested to reflect the Retraction Notice issuance. >
Requirement: some kind of signaling service that will let the archive
know that the files must be changed, plus metadata that indicates the
retraction date/cause?

> > > ·         A PWP or PWP Component is Taken Down: 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. >
What happens if the take down notice comes to the archive and not the
publisher?

> > > ·         Determining when format migration of a PWP is required. 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. >
Definitely needed, but not sure how this translates in to requirements
for the PWP. It's more an operational item for the archive.

> > > ·         Adding metadata to a PWP to support archiving: A service >
wishes to augment the metadata of a PWP being harvested for archiving >
with additional metadata deemed essential for long-term archiving. >
Requirement: the PWP needs to allow additional metadata to be added by a
third party

> > > ·         Migrating metadata format: An archiving service needs to >
migrate the metadata associated with a PWP to a scheme that will >
better make sure the metadata  (as distinct from the content of the >
PWP in this case) can be read and understood in the future. >

Is this another purely operational item that doesn't touch on
requirements for the PWP?
-Heather