A series of unconference-style events focused on connecting practitioners and technologists interested in digital curation
Working page for use cases in curation microservices
Background
Penn State Libraries has launched a pilot project focused on developing curation microservices, and this page is for gathering/developing/commenting on use cases for driving such microservices. This page can also include resources that inform our understanding and development of use cases. We welcome contributions from our colleagues engaged in digital curation activities toward getting a firmer sense of how to collect effective use cases.
Scope/definition
What do we mean by a use case, and who are our users in such cases? Our users are internal to our libraries - so, these are curator types (such as metadata librarians, archivists, and digitization/preservation staff) who work with our systems that take in, and make accessible, data and content in digital format - which includes (but is not limited to) digitized text and images, e-records from across campus units, and research data sets. In this context, a use case is a scenario or situation in which they are trying to do something with data and content that effects a particular goal. For example, our e-records manager has been asked to reproduce the digital equivalent of a paper trail to track versions of a course proposal as it went through the appropriate channels for approval, to verify that a certain faculty member made a certain change to the proposal on a certain date. In order to fulfill this use case, there would need to be a microservice for versioning of e-record content - a use case that would also represent (document) the process in a series of steps as referent for code development.
Sample use cases
Note: These use cases are works in progress. A significant next step will be to describe a step-through process for each of them, even as we continue gathering use cases. These step-through processes will be documented here, too, as we create them.
Use Case for an Identity Service
Albert is looking for a way to identify a digital object (for lack of a
better term) in its use context and relate that to the digital object in
its server context.This is based on naming conventions required by our
platforms vs naming conventions for ease of identification in long-term
data storage. Are there specs that could be written not only to link
the two but also verify that they are meant to correspond to one
another?
Use Cases for a Viability Servce
Penn State Libraries has launched a pilot project focused on developing curation microservices, and this page is for gathering/developing/commenting on use cases for driving such microservices. This page can also include resources that inform our understanding and development of use cases. We welcome contributions from our colleagues engaged in digital curation activities toward getting a firmer sense of how to collect effective use cases.
Scope/definition
What do we mean by a use case, and who are our users in such cases? Our users are internal to our libraries - so, these are curator types (such as metadata librarians, archivists, and digitization/preservation staff) who work with our systems that take in, and make accessible, data and content in digital format - which includes (but is not limited to) digitized text and images, e-records from across campus units, and research data sets. In this context, a use case is a scenario or situation in which they are trying to do something with data and content that effects a particular goal. For example, our e-records manager has been asked to reproduce the digital equivalent of a paper trail to track versions of a course proposal as it went through the appropriate channels for approval, to verify that a certain faculty member made a certain change to the proposal on a certain date. In order to fulfill this use case, there would need to be a microservice for versioning of e-record content - a use case that would also represent (document) the process in a series of steps as referent for code development.
Sample use cases
Note: These use cases are works in progress. A significant next step will be to describe a step-through process for each of them, even as we continue gathering use cases. These step-through processes will be documented here, too, as we create them.
Use Case for an Identity Service
Albert is looking for a way to identify a digital object (for lack of a
better term) in its use context and relate that to the digital object in
its server context.This is based on naming conventions required by our
platforms vs naming conventions for ease of identification in long-term
data storage. Are there specs that could be written not only to link
the two but also verify that they are meant to correspond to one
another?
Use Cases for a Viability Servce
- One of the things that Albert has to manage is the migration of CDs
and DVDs to server storage. He tests to verify the data has
transferred properly at the time of transfer, then periodically needs to
test that data to ensure it maintains its viability. Once that is
done, he has to test for viability, to see if the data on those media
have been transferred completely and are readable.
- The Electronic Records Manager keeps track of the following kinds of record types: faculty senate course submissions; Board of Trustees meeting minutes; and newswires. She needs each submission (of the foregoing
record type) checked for acceptable format (and associated size
parameters – JXE, have these been established?) PDF/a for text, Jpeg for
graphics, MP3 for audio, AVI for video, QuickTime for multimedia. These
are the only formats we are committed to supporting/migrating in the
future. In the future, the system should be able to perform
batch-refresh when a specific format is deemed outdated by the Records
Management Advisory Committee.
Use Case for Authenticity and Versioning Services
The head of an academic department is complaining to the Provost that he
did not approve a course that is currently being taught by a newer
professor in his department.
Course proposals must pass through three levels of approval, including
the department head, the academic dean overseeing that department, and
the University Faculty Senate. Course proposals are archived in digital
format, in a storage system which is jointly maintained by Library IT
and the University Archives. The three layers of approval are recorded
through digital signatures.
The Provost asks the University Archivist to retrieve the course
proposal and verify that the department head signed off on it. The
course proposal shows that indeed it went through all appropriate
approvals. The University Archivist must make the case that the
department head's (digital) signature is authentic.