diff --git a/_pages/build/local.md b/_pages/build/local.md index 565e959..25b1ce3 100644 --- a/_pages/build/local.md +++ b/_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.) \ No newline at end of file diff --git a/_pages/create/index.md b/_pages/create/index.md index 2625447..e5b3dae 100644 --- a/_pages/create/index.md +++ b/_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". diff --git a/_pages/create/metadata.md b/_pages/create/metadata.md index c57ec16..0e177c3 100644 --- a/_pages/create/metadata.md +++ b/_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) diff --git a/_pages/create/rdf-only.md b/_pages/create/rdf-only.md index 3c0c005..6fbfb12 100644 --- a/_pages/create/rdf-only.md +++ b/_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. diff --git a/_pages/create/schema.md b/_pages/create/schema.md index 5e7fa38..0055af3 100644 --- a/_pages/create/schema.md +++ b/_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 diff --git a/_pages/create/structure.md b/_pages/create/structure.md index d25f4dc..9b161c7 100644 --- a/_pages/create/structure.md +++ b/_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 diff --git a/_pages/index.markdown b/_pages/index.markdown index df91c52..5b49684 100644 --- a/_pages/index.markdown +++ b/_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. diff --git a/_pages/overview/profiles.md b/_pages/overview/profiles.md index 23b374a..d3d5600 100644 --- a/_pages/overview/profiles.md +++ b/_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 diff --git a/_pages/use/finding.md b/_pages/use/finding.md index 215f9b9..3fcbddc 100644 --- a/_pages/use/finding.md +++ b/_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 diff --git a/_pages/use/reusing-schemas.md b/_pages/use/reusing-schemas.md index 614b54e..31e5cc5 100644 --- a/_pages/use/reusing-schemas.md +++ b/_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.)