fix spelling

content/docs/sip-specification/internal-sip-policy/intellectual-sip-scope/index.md

@@ -17,23 +17,23 @@ 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.
 However, we believe it is impractical to do so as it introduces multiple issues related that prohibits scale across our systems.
 
 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

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:

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

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.
-
-