From 8df7f39f17c9eaecbd852f10d5867e89684a7b98 Mon Sep 17 00:00:00 2001 From: Rosalyn Metz Date: Tue, 28 May 2019 13:05:57 -0400 Subject: [PATCH 1/5] Fixes #186 --- draft/spec/index.html | 89 ++++++++++++++++++++++++++++--------------- 1 file changed, 58 insertions(+), 31 deletions(-) diff --git a/draft/spec/index.html b/draft/spec/index.html index e3acda8d..e8f1ac7c 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -172,47 +172,74 @@

Introduction

of digital objects in a structured, transparent, and predictable manner. It is designed to promote long-term access and management of digital objects within digital repositories.

-

- This normative specification describes the nature of an OCFL Object (the "object-at-rest") and the arrangement - of OCFL Objects under an OCFL Storage Root. A set of recommendations for how OCFL Objects should be acted upon - (the "object-in-motion") can be found in the [[OCFL-Implementation-Notes]]. The OCFL editorial group recommends - reading both the specification and the implementation notes in order to understand the full scope of the OCFL. -

-

- This specification is designed to operate on storage systems that employ a hierarchical metaphor for - presenting data to users. On traditional disk-based storage this may take the form of files and directories, - and this is the terminology we use in this specification since it is widely known. However, it may equally - apply to object stores, where namespaces, containers, and objects present a similar organization hierarchy to - users. -

Need

- The OCFL initiative arose from a need to have well-defined application-independent file management within - digital repositories. + The OCFL initiative began as a discussion amongst digital repository practitioners to identify well-defined, + common, and application-independent file management for a digital repository's persisted objects and + represents a specification of the community’s collective recommendations addressing five primary + requirements: completeness, parsability, versioning, robustness, and storage diversity.

+

Completeness

- A general observation is that the contents of a digital repository — that is, the digital files and - metadata that an institution might wish to manage — are largely stable. Once content has been - accessioned, it is unlikely to change significantly over its lifetime. This is in contrast to the software - applications that manage these contents, which are ephemeral, requiring constant updating and replacement. - Thus, transitions between application-specific methods of file management to support software upgrades and - replacement cycles can be seen as unnecessary and risky change which affects the long-term stable objects - in support of the short-term, ephemeral software. + The OCFL recommends storing metadata and the content it describes together so the OCFL object can be fully + understood in the absence of original software. OCFL does not make recommendations about what constitutes an + object, nor does it assume what type of metadata is needed to fully understand the object recognizing those + decisions may differ from one repository to another. However, it is recommended that when making this + decision, implementers consider what is necessary to rebuild the objects from the files stored.

+

Parsability

- By providing a specification for the file and directory layout on disk or in an object store, the OCFL is an - attempt at reducing, or even eliminating, the need for these transitions. As an application-independent - specification, conforming applications will natively "understand" the underlying file structure without - needing to first transition these contents to their own format. -

+ One goal of the OCFL is to ensure objects remain fixed over time. This can be difficult as software and + infrastructure change and content is migrated. To combat this challenge, the OCFL ensures that both humans + and machines can understand the layout and corresponding inventory regardless of the software or + infrastructure used. This allows for humans to read the layout and corresponding inventory and understand it + without the use of machines. Additionally, if software were to become obsolete, the OCFL could easily be + understood by a light weight application, even without the full feature repository that might have been used + in the past. +

+

Versioning

- While digital repository content changes relatively slowly, it is necessary to be able to track changes to - digital objects. Within the file and directory layout specification, the OCFL provides a simple structure to - efficiently capture versions of object contents so that all previous states of an object may be recovered - and examined. + Another need expressed by the community was the need to update and change objects, either the content itself + of the metadata associated with the object. The OCFL relies heavily on the prior art in the [[Moab]] Design + for Digital Object Versioning which utilizes forward deltas to track the history of the object. Utilizing + this schema allows implementers of the OCFL to easily recreate past versions of an OCFL object. Like with + determining what constitutes an OCFL object, the OCFL remains silent on when versioning should occur + recognizing again that this may differe from implementation to implementation. +

+

Robustness

+

+ The OCFL also fills the need for robustness against errors, corruption, and migration. The versioning schema + ensures an OCFL object is robust enough to allow for the discovery of human errors. The fixity checking built + into OCFL via content addressable storage allows implementers to identify file corruption that might happen + outside of normal human interactions. Finally, the OCFL allows for methods that ease complications related to + migrating content from one technology to another. +

+

Storage diversity

+

+ Finally, the community expressed a need to store content on a wide variety of storage technologies currently + available on the market. With that in mind, the OCFL was written with an eye toward various storage + infrastructures including cloud object stores.

+
+

Note

+

+ This normative specification describes the nature of an OCFL Object (the "object-at-rest") and the + arrangement of OCFL Objects under an OCFL Storage Root. A set of recommendations for how OCFL Objects should + be acted upon (the "object-in-motion") can be found in the [[OCFL-Implementation-Notes]]. The OCFL editorial + group recommends reading both the specification and the implementation notes in order to understand the full + scope of the OCFL. +

+

+ This specification is designed to operate on storage systems that employ a hierarchical metaphor for + presenting data to users. On traditional disk-based storage this may take the form of files and directories, + and this is the terminology we use in this specification since it is widely known. However, it may equally + apply to object stores, where namespaces, containers, and objects present a similar organization hierarchy to + users. +

+
+
From a5fac4deee006f2d4940933bbcd3f2c607c1a621 Mon Sep 17 00:00:00 2001 From: Rosalyn Metz Date: Tue, 28 May 2019 14:39:58 -0400 Subject: [PATCH 2/5] addresses @zimeon's requested changes --- draft/spec/index.html | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/draft/spec/index.html b/draft/spec/index.html index e8f1ac7c..27867fd9 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -183,25 +183,25 @@

Need

Completeness

The OCFL recommends storing metadata and the content it describes together so the OCFL object can be fully - understood in the absence of original software. OCFL does not make recommendations about what constitutes an - object, nor does it assume what type of metadata is needed to fully understand the object recognizing those - decisions may differ from one repository to another. However, it is recommended that when making this + understood in the absence of original software. The OCFL does not make recommendations about what constitutes + an object, nor does it assume what type of metadata is needed to fully understand the object, recognizing + those decisions may differ from one repository to another. However, it is recommended that when making this decision, implementers consider what is necessary to rebuild the objects from the files stored.

Parsability

One goal of the OCFL is to ensure objects remain fixed over time. This can be difficult as software and - infrastructure change and content is migrated. To combat this challenge, the OCFL ensures that both humans + infrastructure change, and content is migrated. To combat this challenge, the OCFL ensures that both humans and machines can understand the layout and corresponding inventory regardless of the software or - infrastructure used. This allows for humans to read the layout and corresponding inventory and understand it - without the use of machines. Additionally, if software were to become obsolete, the OCFL could easily be - understood by a light weight application, even without the full feature repository that might have been used - in the past. + infrastructure used. This allows for humans to read the layout and corresponding inventory, and understand it + without the use of machines. Additionally, if existing software were to become obsolete, the OCFL could + easily be understood by a light weight application, even without the full feature repository that might have + been used in the past.

Versioning

Another need expressed by the community was the need to update and change objects, either the content itself - of the metadata associated with the object. The OCFL relies heavily on the prior art in the [[Moab]] Design + or the metadata associated with the object. The OCFL relies heavily on the prior art in the [[Moab]] Design for Digital Object Versioning which utilizes forward deltas to track the history of the object. Utilizing this schema allows implementers of the OCFL to easily recreate past versions of an OCFL object. Like with determining what constitutes an OCFL object, the OCFL remains silent on when versioning should occur @@ -212,8 +212,8 @@

Robustness

The OCFL also fills the need for robustness against errors, corruption, and migration. The versioning schema ensures an OCFL object is robust enough to allow for the discovery of human errors. The fixity checking built into OCFL via content addressable storage allows implementers to identify file corruption that might happen - outside of normal human interactions. Finally, the OCFL allows for methods that ease complications related to - migrating content from one technology to another. + outside of normal human interactions. The OCFL allows eases content migrations by providing a technology + agnostic method for verifying OCFL objects have remained fixed.

Storage diversity

From 537e2987fd1e49208b1449cc5347bc0f56589b82 Mon Sep 17 00:00:00 2001 From: Rosalyn Metz Date: Wed, 29 May 2019 09:30:14 -0400 Subject: [PATCH 3/5] addresses final requested change --- draft/spec/index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft/spec/index.html b/draft/spec/index.html index 27867fd9..a06e8179 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -212,8 +212,7 @@

Robustness

The OCFL also fills the need for robustness against errors, corruption, and migration. The versioning schema ensures an OCFL object is robust enough to allow for the discovery of human errors. The fixity checking built into OCFL via content addressable storage allows implementers to identify file corruption that might happen - outside of normal human interactions. The OCFL allows eases content migrations by providing a technology - agnostic method for verifying OCFL objects have remained fixed. + outside of normal human interactions. The OCFL eases content migrations by providing a technology agnostic method for verifying OCFL objects have remained fixed.

Storage diversity

From fc67f8066e01a0f0d32688e4fbefc09507d349d5 Mon Sep 17 00:00:00 2001 From: Rosalyn Metz Date: Wed, 29 May 2019 09:30:51 -0400 Subject: [PATCH 4/5] line length --- draft/spec/index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft/spec/index.html b/draft/spec/index.html index a06e8179..f3133ef5 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -212,7 +212,8 @@

Robustness

The OCFL also fills the need for robustness against errors, corruption, and migration. The versioning schema ensures an OCFL object is robust enough to allow for the discovery of human errors. The fixity checking built into OCFL via content addressable storage allows implementers to identify file corruption that might happen - outside of normal human interactions. The OCFL eases content migrations by providing a technology agnostic method for verifying OCFL objects have remained fixed. + outside of normal human interactions. The OCFL eases content migrations by providing a technology agnostic + method for verifying OCFL objects have remained fixed.

Storage diversity

From c25efc1cbf554ff0356734f090a1f136b60f5f41 Mon Sep 17 00:00:00 2001 From: Rosalyn Metz Date: Wed, 29 May 2019 11:26:34 -0400 Subject: [PATCH 5/5] addresses changes by @awoods --- draft/spec/index.html | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/draft/spec/index.html b/draft/spec/index.html index f3133ef5..6e7f250b 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -204,22 +204,22 @@

Versioning

or the metadata associated with the object. The OCFL relies heavily on the prior art in the [[Moab]] Design for Digital Object Versioning which utilizes forward deltas to track the history of the object. Utilizing this schema allows implementers of the OCFL to easily recreate past versions of an OCFL object. Like with - determining what constitutes an OCFL object, the OCFL remains silent on when versioning should occur - recognizing again that this may differe from implementation to implementation. + objects, the OCFL remains silent on when versioning should occur recognizing this may differ from + implementation to implementation.

Robustness

The OCFL also fills the need for robustness against errors, corruption, and migration. The versioning schema ensures an OCFL object is robust enough to allow for the discovery of human errors. The fixity checking built - into OCFL via content addressable storage allows implementers to identify file corruption that might happen - outside of normal human interactions. The OCFL eases content migrations by providing a technology agnostic - method for verifying OCFL objects have remained fixed. + into the OCFL via content addressable storage allows implementers to identify file corruption that might + happen outside of normal human interactions. The OCFL eases content migrations by providing a technology + agnostic method for verifying OCFL objects have remained fixed.

Storage diversity

- Finally, the community expressed a need to store content on a wide variety of storage technologies currently - available on the market. With that in mind, the OCFL was written with an eye toward various storage - infrastructures including cloud object stores. + Finally, the community expressed a need to store content on a wide variety of storage technologies. With that + in mind, the OCFL was written with an eye toward various storage infrastructures including cloud object + stores.