Improve how-to and remove slate build

USAGE.md

@@ -11,12 +11,21 @@ Building Blocks can be reused by either:
 
 ## How-to
 
-1. Fork (or click on "Use this template" on GitHub) this repository.
-2. For each new building block, replace or create a copy of the `my-building-block` inside `_sources`.
-   Note: **the name of the new directory will be part of the building block identifier**.
-3. Set a `name` for the repository inside `bblocks-config.yaml`.
-4. Configure any necessary [imports](#setting-up-imports) inside `bblocks-config.yaml`.
-5. Set the `identifier-prefix` provided by OGC in `bblocks-config.yaml`.
+1. Click on "Use this template" on GitHub (do not fork this repository, or you will have to manually enable the
+   workflows).
+2. Set the `identifier-prefix` provided by OGC in `bblocks-config.yaml`:
+   * The first component of the prefix should represent the entity defining or maintaining this building block
+     collection. If this is an OGC-related project, you may use `ogc.` here.
+   * The rest of the prefix components should be chosen according to the nature of the collection. For example, if
+     this repository only contained schemas for *OGC API X*, a possible prefix could be `ogc.apis.api-x.schemas.`.
+   * Bear in mind that the path of the building blocks inside `_sources` will be used in their identifiers (see below).
+   * **Identifiers should be as stable as possible**, even when under development. This makes it easier to promote
+     building blocks to production (i.e., being adopted by the OGC as official), and avoids having to manually/update
+     references (in dependency declarations, schemas, etc.).
+3. For each new building block, replace or create a copy of the `mySchema` or `myFeature` inside `_sources`.
+   Note: **the path to and name of the new directory will be part of the building block identifier**.
+4. Set a `name` for the repository inside `bblocks-config.yaml`.
+5. Configure any necessary [imports](#setting-up-imports) inside `bblocks-config.yaml`.
 6. Set the [additional register metadata properties]() in `bblocks-config.yaml`.
 7. Update the [building block's files](#building-block-structure).
    1. See [Using a published schema](SCHEMAS.md) for information how test an existing schema.
@@ -26,7 +35,7 @@ Building Blocks can be reused by either:
    5. See [SHACL Rules](TESTING.md) for information how to define powerful constraints for semantic models.
    6. See [Transforms](TXFORMS.md) for information how to define and test transformations.
 8. Replace the README.md file with documentation about the new building block(s).
-9. Optional: Enable GitHub pages in the repository settings, setting "Source" (under "Build and deployment")
+9. Enable GitHub pages in the repository settings, setting "Source" (under "Build and deployment")
    to "GitHub Actions".
 
 Note: building blocks subdirectories can be grouped inside other directories, like so:
@@ -255,11 +264,6 @@ The outputs can be generated locally by running the following:
 # Process building blocks
 docker run --pull=always --rm --workdir /workspace -v "$(pwd):/workspace" \
   ghcr.io/opengeospatial/bblocks-postprocess  --clean true --base-url http://localhost:9090/register/
-# Optional - build Slate docs
-docker run --pull=always --rm \
-  -v "$(pwd)/build-local/generateddocs/slate:/srv/slate/source" \
-  -v "$(pwd)/build-local/generateddocs/slate-build:/srv/slate/build" \
-  dockerogc/slate build
 ```
 
 **Notes**: