Finish fixing links

_pages/build/local.md

@@ -22,6 +22,6 @@ docker run --pull=always --rm --workdir /workspace -v "$(pwd):/workspace" \
  ```shell
 docker run --rm --pull=always -v "$(pwd):/register" -p 9090:9090 ghcr.io/ogcincubator/bblocks-viewer
 ```
-You can now experiment with the source material - or proceed to [create your own building blocks](/bblocks-docs/create).
+You can now experiment with the source material - or proceed to [create your own building blocks](../create).
 
 (create a fork if you want to update the the repository so you can submit pull requests. The local build outputs will be ignored automatically on updates.)

_pages/create/index.md

@@ -8,7 +8,7 @@ permalink: /create
 2. Fork an existing repository to update or add new building blocks, and generate a Pull Request to submit to the register owner
 2. Copy any building block repository and edit `bblocks-config.yaml` and the `_sources/*` to create a new register
 
-In all cases follow the [local build process](/bblocks-docs/build/local) to test before committing to an online repository.
+In all cases follow the [local build process](../build/local) to test before committing to an online repository.
 
 ## Quick how-to create
 
@@ -26,16 +26,16 @@ In all cases follow the [local build process](/bblocks-docs/build/local) to test
      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.).
 4. Set a `name` for the repository inside `bblocks-config.yaml`.
-5. Configure any necessary [imports](create/imports) inside `bblocks-config.yaml`.
+5. Configure any necessary [imports](imports) inside `bblocks-config.yaml`.
 6. Set the [additional register metadata properties](#additional-register-metadata-properties) in `bblocks-config.yaml`.
 7. 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**.
-8. Update the [building block's files](create/structure).
-   1. [Add documentation](create/documentation) to your Building Block.
-   2. See [defining a schema](create/schema) for information how test an existing schema.
-   3. See [adding JSON-LD context](create/json-ld-context) for information how to "uplift" a schema - linking to a model using JSON-LD.
-   4. See [validation](create/validation) for information how to define powerful constraints for schemas and semantic models.
-   5. See [transforms](create/transforms) for information how to define and test transformations.
+8. Update the [building block's files](structure).
+   1. [Add documentation](documentation) to your Building Block.
+   2. See [defining a schema](schema) for information how test an existing schema.
+   3. See [adding JSON-LD context](json-ld-context) for information how to "uplift" a schema - linking to a model using JSON-LD.
+   4. See [validation](validation) for information how to define powerful constraints for schemas and semantic models.
+   5. See [transforms](transforms) for information how to define and test transformations.
 9. Replace the README.md file with documentation about the new building block(s).
 10. Enable GitHub pages in the repository settings, setting "Source" (under "Build and deployment")
     to "GitHub Actions".

_pages/create/metadata.md

@@ -4,4 +4,4 @@ permalink: /create/metadata
 ---
 Building block metadata provides context information about the item in the building blocks register. It is based on [ISO 19135](https://www.iso.org/standard/54721.html), the standard for item registration of geographic information, from which it extracted its six mandatory items (flagged with *). The ISO schema is extended with other properties (in green), which account for things such as the visual representation in the register, item validation or relation with other building blocks.
 
-[![building block](/bblocks-docs/assets/bblock.png)](/bblocks-docs/assets/bblock.png)
+[![building block](../assets/bblock.png)](../assets/bblock.png)

_pages/create/rdf-only.md

@@ -5,8 +5,8 @@ permalink: /create/rdf-only
 Building Blocks can be defined that use RDF only. An RDF building block can:
 
 1. Define RDF (TTL) examples how to use the Semantic model
-2. Apply SHACL Rules to [validate examples](TESTING.md#SHACL)
-3. [Perform transforms](create/transforms) and validate results
+2. Apply SHACL Rules to [validate examples](validation#shacl-validation)
+3. [Perform transforms](transforms) and validate results
 
 Test cases and examples as either TTL or JSONLD will undergo syntax and SHACL validation.
 

_pages/create/schema.md

@@ -39,7 +39,7 @@ this is done in a two-step process:
 
 2. use the `bblocks:://{id}` syntax as href in schema $ref elements. 
 
-    This means your building block will inherit all json-ld contexts and SHACL rules from the referenced building block automatically and apply during [testing](create/validation).
+    This means your building block will inherit all json-ld contexts and SHACL rules from the referenced building block automatically and apply during [testing](../create/validation).
 
 
 # Profiling JSON Schemas

_pages/create/structure.md

@@ -5,7 +5,7 @@ permalink: /create/structure
 
 The following image summarizes the general usage of a building block:
 
-[![Usage](/bblocks-docs/assets/usage.png)](/bblocks-docs/assets/usage.png)
+[![Usage](../assets/usage.png)](../assets/usage.png)
 
 ## Building Block sources
 

_pages/index.markdown

@@ -4,12 +4,13 @@ permalink: /
 ---
 This is the documentation for OGC Building Blocks, a specification component packaging approach that can be used to **add documentation** to existing specification components, or to assemble specifications cost-effectively using a test-driven approach.
 
-![](/bblocks-docs/assets/bblocks-qr.png)
-Building Blocks may be various [types](/bblocks-docs/overview/types) - however the emphasis is semantically annotated schemas for use in OGC API definitions. 
+![](../assets/bblocks-qr.png)
+
+Building Blocks may be various [types](overview/types) - however the emphasis is semantically annotated schemas for use in OGC API definitions. 
 
 A key application is the [register of OGC Specification Building blocks](https://opengeospatial.github.io/bblocks/register/)
 
 This packaging supports testing of examples, and validation using rules inherited from other Building Blocks that are re-used (by aggregation or profiling) to create compatible specifications for specific applications.
 
-OGC BuildingBlocks can be organised into [registers](/bblocks-docs/overview/registers) for convenience, each repository creating a local register that can be aggregated into another application domain register.
+OGC BuildingBlocks can be organised into [registers](overview/registers) for convenience, each repository creating a local register that can be aggregated into another application domain register.
 

_pages/overview/profiles.md

@@ -51,7 +51,7 @@ Built-in support is provided for automatic validation of the following forms:
 - JSON schema (for JSON examples) for **structure**
 - SHACL (Shapes Constraint Language for RDF) for **content** and **logical consistency**
 
-In addition [custom validators](create/validation) can be added to the validation workflow. 
+In addition [custom validators](../create/validation) can be added to the validation workflow. 
 
 Using a JSON-LD context "semantic uplift" of JSON to RDF supports use of SHACL and other forms of validators to 
 

_pages/use/finding.md

@@ -7,7 +7,7 @@ Whilst components described as Building Blocks may be referenced by individual s
 
 The OGC Building Block Framework provides two improved approaches:
 
-1. [Registers](/bblocks-docs/overview/registers)
+1. [Registers](../overview/registers)
 1. [RAINBOW (OGC Knowledge Graph)]() 
 
 # Well-known Building Blocks registers

_pages/use/reusing-schemas.md

@@ -5,8 +5,8 @@ permalink: /use/reusing-schemas
 
 Building Blocks can be reused in several ways:
 
-- if creating a JSON schema based BuildingBlock then use the $ref: bblocks://{block id} to make a JSON schema reference to any building block in the import list [see imports](/bblocks-docs/create/imports)
-- for other [types of Building Blocks](/bblocks-docs/overview/types) declare as an entry in the dependsOn element of a `block.json` metadata file
+- if creating a JSON schema based BuildingBlock then use the $ref: bblocks://{block id} to make a JSON schema reference to any building block in the import list [see imports](../create/imports)
+- for other [types of Building Blocks](../overview/types) declare as an entry in the dependsOn element of a `block.json` metadata file
 - cut and paste "ready to use" forms from the `build/` directory of any building block repository into a some other form of application (not a reusable Building Block itself)
 - directly reference the artefacts in the `build` directory using the URL pattern specified in the building block
   description (noting this may be affected by changes if a building block is moved from one register to another - bblocks:// references will still work if imports approach is used.)