-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for adding Disposal Scheduling Information in Information Packages #29
Comments
Needs approval from the DILCIS Board. |
I'm blocked at the moment waiting for a strategic decision on this topic. Either way I believe this should be something to be added to the CSIP and then inherited by the SIP. |
I'll put this up on the agenda for Wednesday. |
The discussion on the meeting today: (Local implementations and extensions that can be made needs to be described, guidleine and also CSIP) |
Ok. I'm moving this to unplanned then. |
The Swedish Customs have sponsored the development of this feature in RODA. The implementation has not required any change on the SIP, but the selection of disposal schedules and the calculation of the retention period can be based on descriptive metadata that is conveyed in the SIP. This selection of disposal schedule and/or retention period start based on metadata fields is defined by configuration in a new Disposal Policy page in RODA. So, generally, we might not require a strict definition of how disposal schedule and retention period start is conveyed in the SIP, but guidelines on how this should be done using standard descriptive metadata schemas might be welcomed. |
That sounds a lot like a new CITS... :-) |
The Role of Disposal Scheduling Information in Information PackagesDisposal scheduling is an essential pillar of effective records management. It not only ensures compliance with legal, regulatory, and organisational policies but also supports operational efficiency by enabling structured and accountable management of records throughout their lifecycle. In MoReq 2010, disposal schedules play a vital role in managing records within an organisation's Electronic Records Management System (ERMS). These schedules define retention periods, specify disposition actions (e.g., secure destruction, transfer to an archive), and account for exceptions. This ensures records are handled in a compliant, controlled manner while optimising storage use and operational workflows. By contrast, the OAIS (Open Archival Information System) model focuses on the long-term preservation and accessibility of digital objects. While it does not govern detailed lifecycle management in the records' originating environment, OAIS depends on receiving records enriched with contextual information to ensure their authenticity, integrity, and usability over time. One key piece of this information is the disposal scheduling metadata, which provides critical insight into the records' intended lifecycle, legal obligations, and retention logic. For records with longer active lifecycles (e.g., beyond 7 years), the risk of technological obsolescence becomes increasingly significant. Formats, software, and storage media evolve rapidly, jeopardising access to records managed in traditional ERMS systems. To mitigate this risk, organisations are advised—and often compelled—to transfer such records to OAIS before the end of their active lifecycle. OAIS systems are purpose-built for long-term digital preservation, offering tools to combat obsolescence through format migration, monitoring, and secure storage practices. This early transfer to an OAIS introduces a critical intersection between MoReq and OAIS systems. Disposal scheduling metadata serves as the bridge, ensuring that records transitioning from operational management to long-term preservation retain their compliance framework and contextual relevance. Without this metadata, the integrity of the lifecycle management process is compromised, increasing the risk of mismanagement, data loss, or non-compliance with legal mandates. Maintaining detailed and consistent disposal scheduling information across both systems is not merely practical, it is essential. Disposal scheduling metadata enables OAIS systems to manage preserved records with full awareness of their historical, legal, or operational value. To operationalise this continuity, disposal scheduling information should be included in E-ARK SIPs during the transfer of records from ERMS to OAIS. Additionally, this information should persist within E-ARK AIPs to support ongoing archival management and the application of disposal rules for archived records that do not warrant permanent preservation. Given the importance of disposal scheduling information in bridging operational and archival records management, this feature request proposes that such information be incorporated into E-ARK Information Packages. Before drafting a technical proposal, we invite the DILCIS Board to review and provide feedback on this change request. If endorsed, a detailed technical implementation plan will follow, outlining how disposal scheduling information can be effectively accommodated in both SIPs and AIPs to support robust lifecycle management across MoReq and OAIS environments. |
I agree that it would make sense to include the disposal schedule and that it should be included in the SIP and AIP. Apart from MoReq 2010 there are many other ISO standards, policies, and frameworks which are relevant. Apart from any documentation which is provided, it would be interesting to consider PREMIS as it includes metadata elements that can record events such as "disposal" or "transfer to archive." While it is not made specifically for that purpose it could be interesting because this would make the disposal schedule machine-readable and actionable. |
This seems a sensible proposal to me. |
Proposed element: Preservation status
Status for retention, disposal or preservation.
Element type: String. Allowed values: S, DI, PA, UN
Proposed element: Preservation date.
Date after which disposal of AIP shall occur if PreservationStatus="DI". That is preservation shall only occur up to and including this date, i.e. package shall be retained to this date. E.g. ”2020-01-01” means that the AIP shall be destroyed (directly) after this date (or retained to this date depending on ones viewpoint.). Element type: YYYY-MM-DD. Shall be given if PreservationStatus="DI". Otherwise it is optional.
Proposed element: Preservation reference.
Law or other regulation that determines preservation, disposal or retention. E.g. "RA-FS 2030:12". Element type: Free text. Min 1 character. Max 255 characters
Proposed element: Classification.
Security classification of information in package.
Elements type: String. Allowed values: P, BS, HS, EJ KLASSAT. "EJ KLASSAT" is default.
Values could be extended to support different organisations requirements.
Proposed element: Keywords.
A list of keywords used for searching. E.g. "TMJ, BB, varumärkesintrång, värde2variabel" or "TMJ BB varumärkesintrång värde2variabel". Element type: Free text. Max 20 words separated by (space) or (comma). Max 2047 characters.
The text was updated successfully, but these errors were encountered: