copy edits 2 from Robbie

CONTRIBUTING.md

@@ -23,7 +23,7 @@ Minor changes such as markup and typo fixes may be submitted directly to this re
 Always write a clear log message for your commits. One-line messages are fine for small changes, but significant changes should look like this:
 
     $ git commit -m "Subject of the commit
-    > 
+    >
     > One ore more paragraph(s) describing what changed and its impact."
 
 A properly formed Git commit subject line should always be able to complete the following sentence: if applied, this commit will "Subject of the commit". For example :
@@ -34,7 +34,6 @@ A properly formed Git commit subject line should always be able to complete the
 
 Git itself uses this approach. When you merge something it will generate a commit message like "Merge branch...", or when reverting "Revert...".
 
-
 ## Contribution License
 
 All contributions to the SWHID standard documents are submitted under the [Community Specification License 1.0](https://github.com/swhid/governance/blob/main/1._Community_Specification_License_1.0.md).
@@ -46,13 +45,12 @@ You understand and agree that this project and the contribution are public and t
 To certify that your contribution complies with the above contribution conditions, a `Signed-off-by` line like the following (replace with your own identity):
 
     Signed-off-by: Author Name [email protected]
-	
+
 must be included in every commit message.
 Changes made through the web interface include this line. If you use the command line, you can do this by passing the `-s` flag to `git commit`.
 
 More information on the decision making process can be found in the [SWHID governance documents](https://github.com/swhid/governance/).
 
-
 [issues]: https://github.com/swhid/specification/issues/
 [pull-requests]: https://github.com/swhid/specification/pulls/
 [swhid-list]: https://groups.google.com/g/swhid-discuss

Chapters/0.Introduction.md

@@ -11,7 +11,7 @@ reproducible, industry needs to improve the traceability of the software supply
 chain, developer communities need tools to cope with the increasing complexity.
 
 A key building block for addressing this issue is a system of *intrinsic*
-identifiers that allows to precisely pinpoint the exact version of any software
+identifiers that allows users to precisely pinpoint the exact version of any software
 artifact, at all levels of granularity, *without relying* on any central registry
 or naming authority.
 
@@ -20,7 +20,7 @@ intrinsic identifiers, originally developed for the Software Heritage
 universal source code archive, available to all stakeholders.
 
 For the sake of clarity, we will use examples drawn directly from the Software
-Heritage archive, but notice that systems for persistent archival of software
+Heritage archive, but notice that systems for the persistent archival of software
 artifacts, as well as resolution of SWHIDs are out of the scope of this
 specification, and the SWHID specification does not require in any way the
 use of Software Heritage.

Chapters/3.Terms_and_definitions.md

@@ -52,9 +52,9 @@ Note that in most cases SHA1 in this specification are computed on objects after
 
 A version control system (VCS), also known as source control or revision control, is a software tool that helps manage different versions of software development artifacts. It keeps track of all changes made to the code, allows multiple developers to work on the same codebase, and provides mechanisms for merging changes, reverting changes, and the branching and merging of code. Examples include Git, Mercurial, and Subversion.
 
-## 3.8 software object, software artifact
+## 3.8 software artifact
 
-A software object, also referred to as a software artifact, represents a distinct entity identifiable by a SWHID. This entity can be as granular as a single line of code within a source file or as expansive as an entire codebase comprising multiple source files. In addition to source files, a software object can also be a binary file resulting from code compilation or multiple binary files linked together to produce an executable file.
+A software artifact, also referred to as a digital artifact and a software object, represents a distinct entity identifiable by a SWHID. This entity can be as granular as a single line of code within a source file or as expansive as an entire codebase comprising multiple source files. In addition to source files, a software object can also be a binary file resulting from code compilation or multiple binary files linked together to produce an executable file.
 
 ## 3.9 metadata
 

Chapters/5.Core_identifiers.md

@@ -70,7 +70,7 @@ The intrinsic identifier of the directory is the SHA1 of the byte sequence obtai
 - a NULL byte,
 - and the previously obtained serialization.
 
-As an example, `swh:1:dir:d198bc9d7a6bcf6db04f476d29314f157507d505` 
+As an example, `swh:1:dir:d198bc9d7a6bcf6db04f476d29314f157507d505`
 is the SWHID computed from
 [a directory containing the source code of the darktable photography application](https://archive.softwareheritage.org/swh:1:dir:d198bc9d7a6bcf6db04f476d29314f157507d505) at
 a given point in time of its development on May 4th 2017.
@@ -151,6 +151,7 @@ As an example, `swh:1:rev:309cf2674ee7a0749978cf8265ab91a60aea0f7d` is the SWHID
 Some revisions get selected by developers as denoting important project milestones known as “releases”. Each release points to the last commit in project history corresponding to that release and carries metadata: release name and version, release message, cryptographic signatures, and so forth. If they're not attached to development history (for instance, if they've been imported from bare archive files), releases can also point directly to a root directory instead of a full revision with metadata.
 
 The metadata fields supported by SWHID are as follows:
+
 - name (arbitrary byte sequence, mandatory): a name identifying the release
 - author (arbitrary byte sequence): generally contains the name and email address of the author of the release.
 - author timestamp (decimal timestamp from the Unix epoch): the date at which the release was authored.
@@ -244,8 +245,8 @@ As an example, `swh:1:snp:c7c108084bc0bf3d81436bf980b46e98bd338453` is the SWHID
 ## Note on compatibility with Git
 
 SWHIDs for contents, directories, revisions, and releases are, at present,
-compatible with the way the current version of [Git](https://git-scm.com/) 
-proceeds for 
+compatible with the way the current version of [Git](https://git-scm.com/)
+proceeds for
 [computing identifiers](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects) for
 its objects. The `<object_id>` part of a SWHID for a content object is the Git
 blob identifier of any file with the same content; for a revision it is the Git
@@ -255,4 +256,3 @@ identifiers, as Git does not have a corresponding object type.
 Git compatibility is practical, but incidental and is not guaranteed to be
 maintained in future versions of this standard, nor for different versions of
 Git.
-

Chapters/6.Qualified_identifiers.md

@@ -55,7 +55,6 @@ For example, `swh:1:cnt:4d99d2d18326621ccdd70f5ea66c2e2ac236ad8b;bytes=154-315`
 designates the same function `generate_input_stream` as in the example above, but
 does not rely on any convention about line numbers.
 
-
 ## 6.2 Context qualifiers
 
 There are four context qualifiers, `origin`, `visit`, `path` and `anchor`.
@@ -72,18 +71,18 @@ been seen in the Git repository at `https://gitorious.org/ocamlp3l/ocamlp3l_cvs.
 
 This qualifier may help to get hold of the full repository where a
 content has been found, but there is no guarantee of success, as an origin
-can change or disappear over time (as is the case in the example above, since 
+can change or disappear over time (as is the case in the example above, since
 gitorious.org was shut down in 2015).
 
 ### 6.2.2 Visit qualifier
 
-This qualifier allows addition of the core SWHID identifier of the *snapshot* 
+This qualifier allows addition of the core SWHID identifier of the *snapshot*
 of the repository where the object has been found or observed.
 
 For example, [`swh:1:cnt:4d99d2d18326621ccdd70f5ea66c2e2ac236ad8b;origin=https://gitorious.org/ocamlp3l/ocamlp3l_cvs.git;visit=swh:1:snp:d7f1b9eb7ccb596c2622c4780febaa02549830f9`](https://archive.softwareheritage.org/swh:1:cnt:4d99d2d18326621ccdd70f5ea66c2e2ac236ad8b;origin=https://gitorious.org/ocamlp3l/ocamlp3l_cvs.git;visit=swh:1:snp:d7f1b9eb7ccb596c2622c4780febaa02549830f9)
 indicates that the content seen previously with the function `generate_input_stream` has
 been seen in the Git repository at `https://gitorious.org/ocamlp3l/ocamlp3l_cvs.git`, when
-its full state had the SWHID core identifier `swh:1:snp:d7f1b9eb7ccb596c2622c4780febaa02549830f9`. 
+its full state had the SWHID core identifier `swh:1:snp:d7f1b9eb7ccb596c2622c4780febaa02549830f9`.
 
 This qualifier is only valid when the `origin` qualifier is also present.
 Otherwise, it MUST be ignored.
@@ -138,7 +137,7 @@ Note that the order of the qualifiers does not matter for comparison purposes.
 We recommend equipping identifiers meant for sharing with as many
 qualifiers as possible. While qualifiers may be listed in any order, it
 is good practice to present them in the following canonical order:
-`origin`, `visit`, `anchor`, `path`, `lines` or `bytes`. 
+`origin`, `visit`, `anchor`, `path`, `lines` or `bytes`.
 
 By adhering to this order, it becomes easier to visually inspect and compare
 SWHIDs, especially when dealing with a large number of identifiers.