From 5673a0410b56f895931dd8df809437c300710947 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torbj=C3=B8rn=20Pedersen?= <113333557+torbjornbp@users.noreply.github.com> Date: Wed, 9 Oct 2024 17:38:12 +0200 Subject: [PATCH] fix spelling --- .../intellectual-sip-scope/index.md | 11 ++++++----- .../internal-sip-policy/premis-architecture/index.md | 4 ++-- .../internal-sip-policy/representation-types/index.md | 2 +- .../internal-sip-policy/systems-architecture/index.md | 4 +--- 4 files changed, 10 insertions(+), 11 deletions(-) diff --git a/content/docs/sip-specification/internal-sip-policy/intellectual-sip-scope/index.md b/content/docs/sip-specification/internal-sip-policy/intellectual-sip-scope/index.md index 7f748de..c84982b 100644 --- a/content/docs/sip-specification/internal-sip-policy/intellectual-sip-scope/index.md +++ b/content/docs/sip-specification/internal-sip-policy/intellectual-sip-scope/index.md @@ -17,15 +17,15 @@ To understand the complexity in our organizational architecture better we first ## Intellectual entities in the metadata management systems Intellectual entities (IE) is a concept we find in the various metadata systems outside the digital preservation environment. -In these systems we tend to operate with a lot of different IEs, usually organized in some sort of hierarchy. +In these systems, we tend to operate with a lot of different IEs, usually organized in some sort of hierarchy. -In use-case examples of PREMIS and E-ARK, it is usually the highest level entity from these hierarchies, that is referred to as the IE and used to define *intellectual scope of packages/SIPs*, ie. a *work* or *expression*. +In use-case examples of PREMIS and E-ARK, it is usually the highest level entity from these hierarchies, that is referred to as the IE and used to define *intellectual scope of packages/SIPs*, i.e. a *work* or *expression*. However, we have to define scope differently, using an entity that sits at a lower level of description: - SIP scope is defined by the metadata management system IE that holds the UID linking the IE to the SIP. This is a necessity for keeping all components of our [system architecture](/system-architecture) in sync. -The UID sits at specifically defined IEs in our metadata mangement systems. +The UID sits at specifically defined IEs in our metadata management systems. ## Hierarchies and flatness A change in architecture could open for using a different key UID placed at a different location of these metadata hierarchies. @@ -33,7 +33,7 @@ However, we believe it is impractical to do so as it introduces multiple issues Intellectual scope defined by abstract high-level entities introduce different challenges with: - Vast package sizes (dozens of terabytes) -- Huge amount of representations within SIPs +- Huge number of representations within SIPs - Content description metadata changes leading to restructuring of stored data - Preservation of unidentified digital objects having no relationships to IEs holding the key UID - Increased complexity in keeping our three system domains in sync @@ -65,7 +65,8 @@ In our systems the essential UID that holds all our systems together sits or ref Our more complex metadata management systems (e.g. Axiell Collections), are advanced asset management systems and describe the actual data object in technical detail using a *carrier* IE. The URN identifies the carrier IE, and in extension the SIP. -Our MARC based metadata management systems (e.g. Alma), use the URN to *link* to the SIP and it's primary representation, while not actually describing the data object in the metadata management system. The URN identifies the SIP, but no the record holding it. +Our MARC-based metadata management systems (e.g. Alma), use the URN to *link* to the SIP and it's primary representation, while not actually describing the data object in the metadata management system. +The URN identifies the SIP, but not the record holding the URN. Using the smallest size of description has multiple positive side effects: - Package size is kept small diff --git a/content/docs/sip-specification/internal-sip-policy/premis-architecture/index.md b/content/docs/sip-specification/internal-sip-policy/premis-architecture/index.md index 7ac9758..0e4c44b 100644 --- a/content/docs/sip-specification/internal-sip-policy/premis-architecture/index.md +++ b/content/docs/sip-specification/internal-sip-policy/premis-architecture/index.md @@ -64,7 +64,7 @@ If a user needs to find an intellectual entity or their related digital objects, The metadata management systems handle the UIDs that link an intellectual entity to a SIP/AIP in the DPS. ### Digital Preservation Services (DPS) -The DPS currently manage **files**[^2]. +The DPS currently manages **files**[^2]. These files are *organized* by intellectual entities and representations. Files are ingested to the DPS through the delivery of SIPs, which again mirror intellectual entities found in the Metadata management systems. @@ -82,7 +82,7 @@ The public access services manage and provide access to *access representations* The data and metadata here is a subset of what is found in the metadata management systems and the DPS. The public access services transform harvested metadata into a flattened structure of intellectual entities with a single representation each. -The intellectual entities found online, does not necessarily mirror a single intellectual entity found in the metadata management systems. +The intellectual entities found online, do not necessarily mirror a single intellectual entity found in the metadata management systems. ## Architecture We can draw up another idealized architecture diagram, using PREMIS entities, to illustrate the responsibilities of the different system domains: diff --git a/content/docs/sip-specification/internal-sip-policy/representation-types/index.md b/content/docs/sip-specification/internal-sip-policy/representation-types/index.md index 522fd6b..847f2a3 100644 --- a/content/docs/sip-specification/internal-sip-policy/representation-types/index.md +++ b/content/docs/sip-specification/internal-sip-policy/representation-types/index.md @@ -2,7 +2,7 @@ title: Representation types summary: This post discusses high-level metadata and data handling at the National Library of Norway date: 2024-09-30 -tags: [Systems architecture, PREMIS, Intellectual entities, representations] +tags: [System architecture, PREMIS, Intellectual entities, representations] authors: - name: Torbjørn Bakken Pedersen image: https://avatars.githubusercontent.com/u/113333557?v=4 diff --git a/content/docs/sip-specification/internal-sip-policy/systems-architecture/index.md b/content/docs/sip-specification/internal-sip-policy/systems-architecture/index.md index f3b09c6..c2adfcc 100644 --- a/content/docs/sip-specification/internal-sip-policy/systems-architecture/index.md +++ b/content/docs/sip-specification/internal-sip-policy/systems-architecture/index.md @@ -2,7 +2,7 @@ title: System domain architecture summary: This post discusses high-level metadata and data handling at the National Library of Norway date: 2024-09-30 -tags: [Systems architecture] +tags: [System architecture] authors: - name: Torbjørn Bakken Pedersen image: https://avatars.githubusercontent.com/u/113333557?v=4 @@ -78,5 +78,3 @@ Our DPS is currently not exposed to the public. Any public access to preserved data goes through other internal services built on top of the DPS. The DPS does not preserve access copies that can be automatically derived from preservation files. Such copies are managed in the public access services. - -