Fix typos in doc.

doc/user_guide/docs/content_model_intro.md

@@ -33,11 +33,11 @@ that describe all the semantic and behavioral aspects of a content type.
 
 ## Type inheritance
 
-Content types are hierarchical, starting with a single common archtype, called
+Content types are hierarchical, starting with a single common archetype, called
 "Anything", which is refined into broad categories, and further into more
 specific categories.
 
-![Screenshot of a portion of a Pocket Archive presentation page, with the tpe
+![Screenshot of a portion of a Pocket Archive presentation page, with the type
 hierarchy visible in the "Classification"
 section.](./assets/pkar_screenshot_classification.png)
 
@@ -65,7 +65,7 @@ We can add more properties to the Postcard type, e.g. an `inscription` property
 that contains text inscribed on the object. We can also add `has_recto` and
 `has_verso` relationships with **Bricks** representing the two faces of the
 postcard. Finally, we can re-define the `has_file` property to restrict the
-relationship to a sub-tye of `File`, e.g. `StillImage`. All these properties
+relationship to a sub-type of `File`, e.g. `StillImage`. All these properties
 are only available to the Postcard type and its sub-types (if any are defined).
 
 If we later decide that all artifacts need a new property, e.g. `description`,
@@ -99,7 +99,7 @@ contains data related to the subject, content, author, taxonomy, etc. of the
 intellectual work.
 
 File is a digital capture or document related to an artifact. The file is
-accompanied by a **metadata** resource, which is automatically generated fom
+accompanied by a **metadata** resource, which is automatically generated from
 the metadata that the archivist enters in the laundry list. These metadata
 should be exclusively about the file itself, e.g. time of creation, file
 size, file type, etc, as well as how the file relates to the artifact (e.g.
@@ -182,7 +182,7 @@ setting the `content_type` property to one of the available type codenames.
 There is no need to define a specific content type for every object in the
 archive. Only if enough resources sharing similar characteristics start
 populating the archive, and there is a need to set them apart from other
-rsources, a new type may be created.
+resources, a new type may be created.
 
 If one-off items are acquired, it is mostly fine to classify as the most
 fitting type at hand. For example, if a Book and a Manuscript types are defined

doc/user_guide/docs/install.md

@@ -34,7 +34,6 @@ the commands below will be replaced by a one-line command. Until then...
 ```bash
 # Note: tested on Archlinux. Other distros (especially Alpine) may need tweaks.
 eval $(luarocks path)
-luarocks install --local debugger  # Not in dependencies file but temporarily required
 git clone --recurse-submodules https://git.knowledgetx.com/scossu/volksdata_lua.git
 cd volksdata_lua
 luarocks build --local

doc/user_guide/docs/submission.md

@@ -54,7 +54,7 @@ A [working SIP
 example](https://git.knowledgetx.com/scossu/pocket_archive/src/master/test/sample_submission)
 including files and a laundry list, used for testing, is available as a quick
 reference (note: the CSV file is currently displayed as a raw file. To view it
-as a spreadsheet, download it and open it with Libreoffice or another
+as a spreadsheet, download it and open it with LibreOffice or another
 spreadsheet editor). Other examples are illustrated further down in this
 document.
 
@@ -63,7 +63,7 @@ is successfully archived, it can be deleted. The full SIP can be regenerated by
 the archive and retrieved at a later time.
 
 The original files in the archivist's workstation can be optionally kept and/or
-copied to local storage. This is stongly recommended, at least until Pocket
+copied to local storage. This is strongly recommended, at least until Pocket
 Archive reaches a stable status and can be exclusively relied on for long-term
 preservation. More copies means more chances to recover data from corruption or
 loss, but it also means higher storage costs.
@@ -104,7 +104,7 @@ This creates a collection, `my_collection`, with two members, `artifact1` and
 containing `file3.mpg`.
 
 Ordering of the files or folder in a SIP is defined in the laundry list, as we
-will see further down, so using file namings to force a certain order is not
+will see further down, so using file names to force a certain order is not
 necessary (however it can provide a good starting point for large lists of
 files or folders under a parent).
 
@@ -371,7 +371,7 @@ guide for more information about sub-types.
 
 Types provided by Pocket Archive may have similar names but different uses. For
 example, the `still_image` type, a sub-type of `artifact`, designates a visual
-object, e.g. a photograh. `still_image_file` may be the capture (e.g. scan) of
+object, e.g. a photograph. `still_image_file` may be the capture (e.g. scan) of
 that object, but also the capture of a `text` artifact if it is the scan of a
 book page.
 
@@ -393,7 +393,7 @@ The ID is automatically generated and system-controlled. It cannot be changed.
 A submission can also have a name, which is optional and user-defined. The
 submission name is determined by the file name used for the laundry list. E.g.
 `pkar_submission-my_new_collection.csv` will use `my_new_collection`, i.e. the
-text between `pkar_submission-` and `.csv`, as the submission name. Submisson
+text between `pkar_submission-` and `.csv`, as the submission name. Submission
 names are not required to be unique. Of course, the laundry list file names
 must be unique in the drop box they are deposited to.
 
@@ -423,7 +423,7 @@ As mentioned before, explicitly adding IDs in a laundry list simplifies later
 editing and management. However, this is one of the most tedious parts of a
 laundry list creation.
 
-Fortuntately, such repetitive and error-prone tasks can be easily automated
+Fortunately, such repetitive and error-prone tasks can be easily automated
 with tools provided by most spreadsheet applications. A macro (a mini-program
 that runs in an application) for LibreOffice Calc is [provided
 here](https://git.knowledgetx.com/scossu/pocket_archive/src/master/src/util/libreoffice_idgen.bas)
@@ -432,16 +432,18 @@ table.
 
 ## Deleting resources
 
-Although some archivists argue against deleting *anything* from an archive,
-Pocket Archive acknowledge that in real life things may actually need to be
+Although some archivists advise against deleting *anything* from an archive,
+Pocket Archive acknowledges that in real life things may actually need to be
 removed. The cause may be a duplicate, or something that was not supposed to
 be archived, etc. In any case, the resource-conservative alignment of Pocket
-Archive supports deleting resources immediately and irreversibly.
+Archive supports deleting resources immediately and irreversibly. Versioning
+and "soft" deletion, which keep prior states of resources including deleted
+ones, is not supported.
 
 A resource can be deleted via the `pkar remove` CLI method, or by uploading a
 special file to the drop box, named `pkar_remove*` (asterisk means zero or more
 characters—note that the file name does not need an extension). The delete file
-must be a list of arhchival IDs, in the short **URI** form (`par:<ID>`), one
+must be a list of archival IDs, in the short **URI** form (`par:<ID>`), one
 per line.
 
 If `pkar_watch`, the process watching the drop box, was started with the `-r`