diff --git a/JSONLD.md b/JSONLD.md deleted file mode 100644 index 7940759..0000000 --- a/JSONLD.md +++ /dev/null @@ -1,21 +0,0 @@ -# JSON-LD (Semantic Uplift) - -Building Blocks defining JSON schemas can be annotated with JSON-LD contexts using either: - - including a file (_context.jsonld_) in the building block directory - - using the property `x-jsonld-context` in the _schema.(yaml/json) for the building block - e.g. `x-jsonld-context: ../../../sosa-ssn.jsonld` - -The JSON LD context: - -1. Maps JSON elements to URIs (which can be URIs of a richer semantic model) -2. Allows validation of complex logical constraints using SHACL Rules to [validate examples](TESTING.md#SHACL) -3. [Perform transforms](TXFORMS.md) to any other RDF model and validate results - -## Modularity support - -JSON-LD contexts are very complex and hard to debug if the schema is at all complex. - -The Building Blocks design allows automatic combination of contexts based on the schema re-use patterns. - -## Context design - -_TBD: document local contexts and use of @base mappings. _ diff --git a/JSONSCHEMA-PROFILING.md b/JSONSCHEMA-PROFILING.md deleted file mode 100644 index 702e9b9..0000000 --- a/JSONSCHEMA-PROFILING.md +++ /dev/null @@ -1,65 +0,0 @@ -# Profiling JSON Schemas - -Profiling JSON schemas is a complex subject. This document is a placeholder for a description of best practices and support tooling. - -## Why is this challenging? - -The JSON Schema specification and tooling landscape is complex. Versions of the OpenAPI Specification (OAS) use different versions of JSON-Schema and tool support varies. - -In particular, reuse mechanisms such as $dynamicRef may not be available. - -## Version-agnostic Building Blocks - -The Building Block post-processing tooling automatically generates OAS 3.0 and OAS 3.1 compatible schemas. It is recommended to develop new building blocks using improved modularity and reuse support in modern schema versions, and allow the Building Block to create a "down-compiled version". - -## OAS 3.0 Compatibility - -OGC APIs are currently bound to OAS v3.0 which limits JSON schema patterns that can be supported. - -The implication is that currently it is typical necessary to recreate complex structural hierarchies and compose into "allOf[]" structures in order to place constraints into a location. - -e.g. to make the relatively simple constraints that a "SurveyObservationCollection" is a collection "SurveyObservation" objects, and must declare that some schema for describing "SensorType" is used, a significant portion of the structure must be detailed. - -```json - -"SurveyVectorObsCollection": { - "allOf": [ - { - "$ref": "https://opengeospatial.github.io/ogcapi-sosa/build/annotated/unstable/sosa/features/observationCollection/schema.json" - }, - { - "properties": { - "features": { - "type": "array", - "items": { - "$ref": "#/$defs/SurveyVectorObsFeature" - } - }, - "properties": { - "properties": { - "madeBySensor": { - "$ref": "#/$defs/SensorType" - } - }, - "required": [ - "madeBySensor" - ] - } - } - } - ] - } - } -``` - -## Future options - -A number of strategies are being considered to simplify this. At this stage alternative approaches: -- define a new constraint language that can be directly compiled from simple statements into the target schema constraint -- use the most compact form in more recent JSON schema - potentially requiring extension hooks in the base schemas - and compile to legacy forms with full structure replication -- work with JSON schema community to define new capabilities designed for easier profiling in a future version of JSON -- create a "wizard" tool to write constraints - -All these have significant impact and effort implications. - -Follow updates at [this issue](https://github.com/opengeospatial/bblock-template/issues/2) diff --git a/PROFILES.md b/PROFILES.md deleted file mode 100644 index 23076f2..0000000 --- a/PROFILES.md +++ /dev/null @@ -1,62 +0,0 @@ -# Profiles and BuildingBlocks - -BuildingBlocks support two modes: -- composition -- profiling - -[USAGE](USAGE.md) describes common aspects. This document described profiling mechanisms. - -**Profiles** allow all the underlying details of base standards to be automatically included in testing and validation - this _encapsulates_ the underlying complexity of base specifications. - -This dramatically **simplifies** profiles in terms of both development and usage, and ensures **consistency** and conformance of profiles with base specifications. - -In particular, if base specifications use the OGC BuildingBlocks then profiles can _leverage_ all the effort in design, testing and validation capabilities. - -Thus profiles also use the same structures, so they can be profiled in turn. - -## What is a profile? - -A profile defines a set of constraints on a base specification. Implementations of profiles conform to the base specification. - -Because many technologies like JSON and RDF are permissive (by default) about additional information being present, definition of an *extension* is effectively defining a *constraint* on how additional information should be represented. - -## Profiles of profiles... - -Profiles can be designed as separate re-usable sets of constraints that can be reused - for example a time-series of water-quality monitoring observations could be specified as a profile of both a time-series profile of Observations and a water-quality profile for the results of such observations. -In turn the time-series profile could defined as data structure using GeoJSON, or Coverage JSON. The water-quality content requirements could be described using constraints independent of the data structure. - -## What forms of constraints are possible? - -The **OGC BuildingBlock** model supports a range of possible constraint approaches. The goal is to make such constraints **_machine-readable_** to the extent possible. - -Constraints SHOULD be defined in a form that allows for **_validation_** of test cases and examples. - -Built-in support is provided for automatic validation of the following forms: -- project metadata (description) -- well-formed example encoding (JSON, TTL) -- JSON schema (for JSON examples) for **structure** -- SHACL (Shapes Constraint Language for RDF) for **content** and **logical consistency** - -In addition [custom validators](VALIDATORS) 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 - -## Testing - -Test cases should be provided for each component part of a specification. This requires a minimal conformant **base example** that the specific test case can be added to. - -(Note consideration is being given to making such a baseline example resuable by reference instead of duplication, and potentially derived automatically from declared schema) - -Testing should start by validating the **base example** passes all declared constraints, then for each profile constraint: -- identifying a set of valid cases that should conform to the constraint, testing each aspect -- creating a copy of the base under the **/tests/** folder with a name indicating which constraint and case is being tested - e.g. **my-building-block/tests/mything-property-b-number.json** -- adding the specific example to the example -- creating one or more failure tests with **-fail** file name endings - e.g. **my-building-block/tests/mything-property-b-number-fail.json** - - - - - - - - diff --git a/RDF.md b/RDF.md deleted file mode 100644 index dfd8e61..0000000 --- a/RDF.md +++ /dev/null @@ -1,33 +0,0 @@ -# RDF-only building blocks - -Building Blocks can be defined that use RDF only, - -A 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](TXFORMS.md) and validate results - -Test cases and examples as either TTL or JSONLD will undergo syntax and SHACL validation. - -`examples.yaml` can have embedded TTL - eg. - -``` -- title: Example of SOSA ObservationCollection - comment: - This class is a target for the SOSA v 1.1 update. - - snippets: - - language: turtle - code: |- - @prefix sosa: . - @prefix xsd: . - @prefix eg: . - @prefix skos: . - - eg:c1 a sosa:ObservationCollection ; - sosa:hasMember eg:pop1999, eg:pop2000 ; - sosa:observedProperty ; - . - -``` diff --git a/README.md b/README.md index 1eba56e..bbd1f08 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,7 @@ -# OGC Building Block template +# CityGML Profiles -This template provides a working example of an [OGC Building Block](https:blocks.ogc.org). For more info see [the Documentation](https://ogcincubator.github.io/bblocks-docs/). +This repository is for the development, testing and publication of CityGML profiles. -This template is a working automation recipe to define, test and document a set of Building Blocks. - -The automation-generated documentation for this example is here: [https://opengeospatial.github.io/bblock-template/](https://opengeospatial.github.io/bblock-template/) - -[Examples of using this with typical applications of OGC standards](https://github.com/ogcincubator/bblocks-examples) - -Please replace the contents of this README with information about your Building Block(s). - -# How to use this template - -[More information on design and usage](https://github.com/opengeospatial/bblock-template/blob/master/USAGE.md) +Building blocks represent different levels of abstraction, from conceptual to implementation modules to individuals Feature Types, and ways of combining these. diff --git a/SCHEMAS.md b/SCHEMAS.md deleted file mode 100644 index 8d3f2d9..0000000 --- a/SCHEMAS.md +++ /dev/null @@ -1,37 +0,0 @@ -# Reusing existing JSON Schemas - -Building Blocks can be defined to reuse existing JSON schemas in a more sophisticated way. - -A re-used schema can be: - -1. [profiled (by extension or constraints)](JSONSCHEMA-PROFILING.md) -2. Mapped to a [semantic (RDF)](RDF.md) model allowing richer specification of constraints. -3. [Tested](TESTING.md) with examples and test cases. - -## How to reuse - -This is simply a matter of referencing the reused schema in the building block schema(.json|.yaml): - -```json -{ "$ref": "http://somestablelocation.org/schema.json" } -``` - -## How to reuse a building block with its added components... - -this is done in a two-step process: - -1. in the (_bblocks-config.yaml)[_bblocks-config.yaml] file tell the processing where to find building block registers: -```yaml -schema-mapping: - default: https://opengeospatial.github.io/bblocks/annotated-schemas/ - -imports: - - default - - https://opengeospatial.github.io/ogcapi-sosa/build/register.json -``` - -The default is the OGC master register of building blocks. - -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](TESTING.md). diff --git a/TESTING.md b/TESTING.md deleted file mode 100644 index 0a0024d..0000000 --- a/TESTING.md +++ /dev/null @@ -1,62 +0,0 @@ -# Testing - -Building Blocks have powerful automated testing capabilities using the built-in github actions. - -These can be supplemented with additional custom validation and transformation processes as required. - - -## Examples - -Examples defined in the `examples.yaml` (inline or by file reference) get validated and included in generated documentation. - -Test cases defines in the `tests/` subdirectory of each building block get validated. Additional or external tests -can be added in `tests.yaml` as a list of objects with a `ref` property pointing to the test resource's location, -and optionally defining the `output-filename` and/or `require-fail` properties (for more information, see the -example `tests.yaml` file provided in the template and -[the JSON Schema for `tests.yaml`](https://github.com/opengeospatial/bblocks-postprocess/blob/master/ogc/bblocks/extra-tests-schema.yaml). - -In each case, the `/build/tests/` directory contains a set of validation outputs. - -Validation includes the following steps: - -1. (if JSON and context supplied) JSON-LD uplift ( {testcase}.ttl generated) -2. (if JSON schema supplied) JSON schema validation -3. (if SHACL rules defined) SHACL validation - -A summary report is produced at `/build/tests/report.html`. - -This is linked from the generated building block index. - -## SHACL Validation - -SHACL rules can be defined in a ```rules.shacl``` file or any other files or URLs in the bblocks.json: - -``` - "shaclRules": [ - "vocabs-shacl.ttl" - ] - "shaclClosures": [ - "../../vocabularies/terms.ttl", -``` - - "shaclClosures" refers to additional files with RDF data required to perform validation - such as checking the types of related objects. - -this is particularly useful for relatively small, static vocabularies (e.g. "codelists") that form part of the specification realised by the building block - -## Tools - -In addition to built-in testing capabilities the following online tools can be helpful in developing and debugging different layers of the design: - -* [JSON Schema validator](https://www.jsonschemavalidator.net/) -* [JSON-LD Playground](https://json-ld.org/playground/) -* [SHACL Validator](https://shacl-play.sparna.fr/play/validate) - -Hint - to use the JSON Schema validator with a published schema you can create a wrapper such as - -```json -{ - "$ref": "https://my.org/schema.json?version" -} -``` - -(updating ```version``` forces the validator to pick up any changes in the published schema.) \ No newline at end of file diff --git a/USAGE.md b/USAGE.md deleted file mode 100644 index 12f8d04..0000000 --- a/USAGE.md +++ /dev/null @@ -1,298 +0,0 @@ -# OGC Building Block template - -This repository can be used as a template to create new collections of -[OGC Building Blocks](https://opengeospatial.github.io/bblocks). - -Building Blocks can be reused by either: - -- cut and paste "ready to use" forms from the "build/" directory -- directly reference the artefacts in the "build" directory using the URL pattern specified in the building block - description - -## How-to - -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. 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 [additional register metadata properties]() in `bblocks-config.yaml`. -6. 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**. -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. - 2. See [Semantic Annotation](JSONLD.md) for information how to "uplift" a schema - linking to a model using JSON-LD. - 3. See [Semantic Models in RDF](RDF.md) for information how to create a building block to profile and test semantic models. - 4. See [JSON Schema Profiling](JSONSCHEMA-PROFILING.md) for information how to specialise an existing schema. - 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. 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: - -``` -type1/ - bb1-1/ - bblock.json - bb1-2/ - bblock.json -type2/ - subtype2-1/ - bb2-1-1/ - bblock.json -[...] -``` - -In that case, `type1`, `type2` and `subtype2-1` will also be part of the building block identifiers. - -## Registering your building block - -Building blocks can be aggregated into registers, such as OGC's official and incubator registries. - -### Making your own Building Block Register - -TBD - -## Building block structure - -The following image summarizes the general usage of a building block: - -![Usage](usage.png) - -### Sources - -The `_sources` directory will contain the sources for the building blocks inside this repository. - -- `bblock.json`: Contains the metadata for the building block. Please refer to this - [JSON schema](https://raw.githubusercontent.com/opengeospatial/bblocks-postprocess/master/ogc/bblocks/metadata-schema.yaml) - for more information. -- `description.md`: Human-readable, Markdown document with the description of this building block. - Relative links and images can be included in this file, and they will be resolved to full - URLs when the building block is processed. -- `examples.yaml`: A list of examples for this building block. See [Examples](#examples) below. -- `schema.json`: JSON schema for this building block, if any. See [JSON schema](#json-schema) below. - - `schema.yaml`, in YAML format, is also accepted (and even preferred). -- `assets/`: Documentation assets (e.g. images) directory. See [Assets](#assets) below. -- `tests/`: Test resources. See [Validation](#validation-and-tests). - -This repository includes a sample building block in the `my-building-block` directory. - -Building Block identifiers are automatically generated in the form: - -``` - -``` - -where: - -- `identifier-prefix` is read from `bblocks-config.yaml`. This will initially be a placeholder value, - but should have an official value eventually (see [How-to](#how-to)). -- `bb-path` is the dot-separated path to the building block inside the repository. - -For example, given a `r1.branch1.` identifier prefix and a `cat1/cat2/my-bb/bblock.json` metadata file, -the generated identifier would be `r1.branch1.cat1.cat2.my-bb`. This applies to the documentation -subdirectories as well, after removing the first element (e.g., Markdown documentation will be written to -`generateddocs/markdown/branch1/cat1/cat2/my-bb/index.md`). - -### Setting up imports - -Any building blocks repository can import any other repository, so that references by id to building blocks -(e.g. inside schemas, in `bblock.json`, etc.) belonging to the imported repositories can be automatically resolved. - -Repository imports can be defined as an array of URLs to the output `register.json` of other repositories inside -`bblocks-config.yaml`: - -* If `imports` is missing from `bblocks-config.yaml`, the - [main OGC Building Blocks repository](http://blocks.ogc.org/register.html) will be imported by default. -* `default` can be used instead of a URL to refer to the - [main OGC Building Blocks repository](http://blocks.ogc.org/register.html). -* If `imports` is an empty array, no repositories will be imported. - -For example, the following will import two repositories, one of them being the main OGC Building Blocks repository: - -```yaml -name: Repository with imports -imports: - - default - - https://example.com/bbr/repository.json -``` - -### Additional register metadata properties - -The following additional properties can be set inside `bblocks-config.yml`: - -* `name`: A (short) string with the name of the register. -* `abstract`: A short text to serve as an introduction to the register or building blocks collection. - Markdown can be used here. -* `description`: A longer text with a description of the register or collection. Markdown can be used here. - -### Ready to use components - -The `build/` directory will contain the **_reusable assets_** for implementing this building block. - -*Sources* minimise redundant information and preserve original forms of inputs, such as externally published -schemas, etc. This allows these to be updated safely, and also allows for alternative forms of original source -material to be used whilst preserving uniformity of the reusable assets. - -**The `build` directory should never be edited**. Moreover, applications should only use (copy or reference) resources -from this directory. - -### Examples - -Each example consists of Markdown `content` and/or a list of `snippets`. `snippets`, in turn, -have a `language` (for highlighting, language tabs in Slate, etc.) and the `code` itself. - -`content` accepts text in Markdown format. Any relative links or images will be resolved to full -URLs when the building block is published (see [Assets](#assets)). - -Instead of the `code`, a `ref` with a filename relative to `examples.yaml` can be provided: - -```yaml -- title: My inline example - content: Example with its code in the examples.yaml file - snippets: - - language: json - code: '{ "a": 1 }' -- title: My referenced example - content: Example with its code pulled from a file - snippets: - - language: json - ref: example1.json # in the same directory as examples.yaml -``` - -Please refer to -[the updated JSON schema for `examples.yaml`](https://raw.githubusercontent.com/opengeospatial/bblocks-postprocess/master/ogc/bblocks/examples-schema.yaml) -for more information. - -The `examples.yaml` file in `my-building-block` can be used as a template. - -### JSON schema - -If a `schema.json` (or `schema.yaml`) file is found, it is not necessary to add the `schema` property -to `bblock.json`; it will be done automatically on the OGC Building Blocks Register. The same thing -applies to the `context.jsonld` file and the `ldContext` property. - -References to the schemas of other building blocks can be added using `$ref`. The special `$_ROOT_/` directory -can be used to refer to the root of the central OGC Building Blocks tree. - -### "Semantic Annotation" - -The Building block design allows for "semantic annotation" through the use of a **_context_** document that -cross-references each schema element to a URI, using the JSON-LD syntax. The end result is still a valid JSON schema, -but may also be parsed as flexible RDF graphs if desired. - -This provides multiple significant improvements over non-annotated schemas: - -1. differentiates between the same and different meanings for common element names used in different places -2. can be used to link to a semantic model further describing each element -3. allows use of advanced, standardised validation of instance data -4. allows automated annotation of schemas themselves for tools able ot exploit additional information - -The JSON schema for a building block is optionally linked to a conceptual model by using a root-level `x-jsonld-context` -property pointing to a JSON-LD context document (relative paths are ok). The Building Blocks Register can -then annotate every property inside the JSON schemas with their corresponding RDF predicate automatically. - -### Validation and tests - -The `tests` directory contains test resources that can be used for performing validation tasks. There are two -types of validations: - -- JSON schema -- RDF / [SHACL](https://www.w3.org/TR/shacl/), if a top-level (i.e., same directory as `bblock.json`). - -Inside the `tests` directory, 3 types of files will be processed: - -- `*.ttl`: [Turtle](https://www.w3.org/TR/turtle/) RDF files that will be validated against the SHACL rules. - - SHACL rules are loaded from the `shaclRules` property inside `bblock.json`. If a `rules.shacl` file is found - in the Building Block directory it will be used by default. **SHACL files must be serialized as Turtle**. -- `*.jsonld`: JSON-LD files that will be first validated against the Building Block JSON Schema - and then against the SHACL rules. -- `*.json`: JSON files that will be first validated against the JSON Schema, then "semantically uplifted" - by embedding the Building Block's `context.jsonld`, and finally validated against the SHACL rules. - -If the filename for a test resource ends in `-fail` (e.g., `missing-id-fail.json`), validation will only pass -if the test fails (JSON SCHEMA, SHACL shapes, etc.); this allows writing negative test cases. - -[Examples](#examples) in JSON and JSON-LD format will also be uplifted and validated. - -### Assets - -Any relative URL included in the description of the building block and in the markdown content of the -examples will be converted into a full URL relative to the source location (i.e., that of `bblock.json`).- - -Assets (e.g., images) can be placed in the `assets/` directory for later use in documentation pages, -by using references to `assets/filename.ext`. - -For example, a `sample.png` image in that directory can be included in the description -Markdown code of a building block like this: - -```markdown -![This is a sample image](assets/sample.png) -``` - -### "Super Building Blocks" - -A super building block is a building block whose `schema.yaml` is automatically generated as the `oneOf` -union of all the schemas recursively found in all its subdirectories. This needs to be enabled -in `bblock.json` by setting the `superBBlock` property to `true`. - -When super building block mode is enabled, the `schema.yaml` inside the source directory for the building -block **will be overwritten**. - -## Postprocessing overview - -This repository comes with a GitHub workflow that detects, validates and processes its building blocks, -so that their outputs can be tested before inclusion in the main OGC Register: - -![OGC Building Blocks processing](https://raw.githubusercontent.com/opengeospatial/bblocks-postprocess/master/process.png) - -### Output testing - -The outputs can be generated locally by running the following: - -```shell -# 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/ -``` - -**Notes**: - -* Docker must be installed locally for the above commands to run -* The syntax for `-v "$(pwd):/workspace"` may vary depending on your operating system -* Output files will be created under `build-local` (not tracked by git by default) -* The value for `--base-url` will be used to generate the public URLs (schemas, documentation, etc.). In this case, - we use the local `http://localhost:9090/register/` URL to make the output **compatible with the - viewer** when running locally (see below). If omitted, the value will be autodetected from the repository - metadata. - -#### Building Blocks Viewer - -You can also preview what the output will look like inside the Building Blocks Viewer application: - -```shell -docker run --rm --pull=always -v "$(pwd):/register" -p 9090:9090 ghcr.io/ogcincubator/bblocks-viewer -``` - -**Notes**: - -* Make sure to [compile the register](#output-testing) before running the viewer (or delete `build-local` - altogether to view the current build inside `build`). -* Docker must be installed locally for the above commands to run -* The syntax for `-v "$(pwd):/register"` may vary depending on your operating system -* `-p 9090:9090` will publish the Viewer on port 9090 on your machine - -## Tools - -The following tools are useful for getting each component working during development: - diff --git a/_sources/myFeature/bblock.json b/_sources/CityFeatureJSON/bblock.json similarity index 70% rename from _sources/myFeature/bblock.json rename to _sources/CityFeatureJSON/bblock.json index 842272f..6fa2c30 100644 --- a/_sources/myFeature/bblock.json +++ b/_sources/CityFeatureJSON/bblock.json @@ -1,6 +1,6 @@ { - "name": "Custom Feature", - "abstract": "This examples shows a simple customisation for OGC API Feature schemas", + "name": "CityGML Feature JSON Schema", + "abstract": "A Generic OGC API Features compliant JSON schema. The schema is derived from the CityGML UML model", "status": "under-development", "dateTimeAddition": "2023-05-19T00:00:00Z", "itemClass": "schema", @@ -16,11 +16,12 @@ "maturity": "development", "scope": "unstable", "dependsOn": [ + "ogc.geo.citygml.conceptual" ], "tags": [ "feature", "examples" ], - "group": "Examples", + "group": "Implementations", "highlighted": true } diff --git a/_sources/CityFeatureJSON/description.md b/_sources/CityFeatureJSON/description.md new file mode 100644 index 0000000..1b4acd3 --- /dev/null +++ b/_sources/CityFeatureJSON/description.md @@ -0,0 +1,5 @@ +## CityGML as JSON based on FG-JSON schema + + + + diff --git a/_sources/myFeature/examples.yaml b/_sources/CityFeatureJSON/examples.yaml similarity index 100% rename from _sources/myFeature/examples.yaml rename to _sources/CityFeatureJSON/examples.yaml diff --git a/_sources/myFeature/examples/feature.json b/_sources/CityFeatureJSON/examples/feature.json similarity index 100% rename from _sources/myFeature/examples/feature.json rename to _sources/CityFeatureJSON/examples/feature.json diff --git a/_sources/CityFeatureJSON/schema.yaml b/_sources/CityFeatureJSON/schema.yaml new file mode 100644 index 0000000..999de94 --- /dev/null +++ b/_sources/CityFeatureJSON/schema.yaml @@ -0,0 +1,3 @@ +"$schema": https://json-schema.org/draft/2020-12/schema +description: 'Example of a sinmple GeoJSON Feature specialisation' +$ref: bblocks://ogc.geo.features.feature diff --git a/_sources/conceptual-core-profile/bblock.json b/_sources/conceptual-core-profile/bblock.json new file mode 100644 index 0000000..a7f44c2 --- /dev/null +++ b/_sources/conceptual-core-profile/bblock.json @@ -0,0 +1,49 @@ +{ + "name": "CityGML Core Profile", + "abstract": "Core CityGML profile - as UML if applicable", + "status": "under-development", + "dateTimeAddition": "2024-06-19T00:00:00Z", + "itemClass": "schema", + "register": "ogc-building-block-examples", + "version": "1.0", + "dateOfLastChange": "2024-06-19", + "dependsOn": [ + "ogc.geo.citygml.conceptual" + ], + "sources": [ + { + "title": "CityGML Conceptual Model Core Profile", + "link": "TBD" + }, + { + "title": "CityGML Conceptual Model Profile - UML in server", + "link": "TBD", + "role": "model-link" + }, + { + "title": "XMI source file", + "link": "TBD", + "role": "xmi" + }, + + { + "title": "Package Diagram", + "link": "TBD", + "role": "package-diagram" + }, + + { + "title": "Class Diagram", + "link": "TBD", + "role": "class-diagram" + } + ], + "maturity": "development", + "scope": "unstable", + "tags": [ + "feature", + "examples" + ], + "group": "Implementations", + "highlighted": true +} diff --git a/_sources/conceptual/bblock.json b/_sources/conceptual/bblock.json new file mode 100644 index 0000000..afbe559 --- /dev/null +++ b/_sources/conceptual/bblock.json @@ -0,0 +1,46 @@ +{ + "name": "CityGML Feature ConceptualModel", + "abstract": "The CityGML Conceptual Model. Normative artefact is a UML model, this building block registers it and provides for transparency regarding other implementation relationships to the model.", + "status": "under-development", + "dateTimeAddition": "2023-05-19T00:00:00Z", + "itemClass": "schema", + "register": "ogc-building-block-examples", + "version": "1.0", + "dateOfLastChange": "2023-05-19", + "sources": [ + { + "title": "CityGML Conceptual Model", + "link": "https://www.ogc.org/standard/citygml/" + }, + { + "title": "CityGML Conceptual Model UML in server", + "link": "TBD", + "role": "model-link" + }, + { + "title": "XMI source files", + "link": "https://github.com/opengeospatial/CityGML-3.0CM/releases/download/3.0.0-final.2021.02.23/XMI.Files.zip", + "role": "xmi-zip" + }, + + { + "title": "Package Diagram", + "link": "TBD", + "role": "package-diagram" + }, + + { + "title": "Class Diagram", + "link": "TBD", + "role": "class-diagram" + } + ], + "maturity": "development", + "scope": "unstable", + "tags": [ + "feature", + "examples" + ], + "group": "Implementations", + "highlighted": false +} diff --git a/_sources/myFeature/description.md b/_sources/myFeature/description.md deleted file mode 100644 index 40cf159..0000000 --- a/_sources/myFeature/description.md +++ /dev/null @@ -1,14 +0,0 @@ -## Custom Feature Type - -This building block illustrates a typical "Feature Type" - where an object is modelled as a "Feature with geometry", but has its own "native schema" - or "domain model". - -This is an **interoperable** approach to defining a Feature, allowing re-use of a well-defined domain model. - -i.e. the attributes (properties) are managed independently of the packaging container (Feature) - -the **mySchema" building block is referenced by this container, complete with an example of semantic annotations for the domain model. It may inherit reusable sub-components using the same mechanisms - after all there is usually a lot in common across a range of FeatureTypes in any environment. - -This building block **inherits** reusable semantic annotations from a common library, simplifying implementation. - - - diff --git a/_sources/myFeature/schema.yaml b/_sources/myFeature/schema.yaml deleted file mode 100644 index 8903181..0000000 --- a/_sources/myFeature/schema.yaml +++ /dev/null @@ -1,11 +0,0 @@ -"$schema": https://json-schema.org/draft/2020-12/schema -description: 'Example of a sinmple GeoJSON Feature specialisation' -$defs: - MyFeature: - allOf: - - $ref: bblocks://ogc.geo.features.feature - - properties: - properties: - $ref: ../mySchema/schema.yaml -anyOf: - - $ref: "#/$defs/MyFeature" diff --git a/_sources/myFeature/tests/feature-fail.json b/_sources/myFeature/tests/feature-fail.json deleted file mode 100644 index 8509490..0000000 --- a/_sources/myFeature/tests/feature-fail.json +++ /dev/null @@ -1,20 +0,0 @@ -{ - "id": "f1", - "type": "Feature", - "geometry": { - "type": "LineString", - "coordinates": [ - [ - -111.67183507997295, - 40.056709946862874 - ], - [ - -111.71, - 40.156709946862874 - ] - ] - }, - "properties": { - "notMyProp": "Mandatory property not present example" - } -} diff --git a/_sources/mySchema/assets/README.md b/_sources/mySchema/assets/README.md deleted file mode 100644 index 8529c58..0000000 --- a/_sources/mySchema/assets/README.md +++ /dev/null @@ -1,9 +0,0 @@ -Assets (e.g., images) can be placed in this directory for later use in documentation pages, -by using references to `assets/filename.ext`. - -For example, a `sample.png` image in this directory can be included in the description -Markdown code of a building block like this: - -```markdown -![This is a sample image](assets//sample.png) -``` diff --git a/_sources/mySchema/assets/example.png b/_sources/mySchema/assets/example.png deleted file mode 100644 index 4d53488..0000000 Binary files a/_sources/mySchema/assets/example.png and /dev/null differ diff --git a/_sources/mySchema/bblock.json b/_sources/mySchema/bblock.json deleted file mode 100644 index 4181a8c..0000000 --- a/_sources/mySchema/bblock.json +++ /dev/null @@ -1,21 +0,0 @@ -{ - "$schema": "metaschema.yaml", - "name": "My Schema", - "abstract": "An example schema defining the set of properties of any type of object.", - "status": "under-development", - "dateTimeAddition": "2023-04-05T00:00:00Z", - "itemClass": "schema", - "register": "ogc-building-block-register", - "version": "0.1", - "dateOfLastChange": "2023-04-05", - "link": "https://github.com/opengeospatial/bblock-template", - "sources": [ - { - "title": "Sample source document", - "link": "https://example.com/sources/1" - } - ], - "maturity": "mature", - "scope": "unstable", - "tags": ["templates"] -} diff --git a/_sources/mySchema/context.jsonld b/_sources/mySchema/context.jsonld deleted file mode 100644 index 175bab6..0000000 --- a/_sources/mySchema/context.jsonld +++ /dev/null @@ -1,7 +0,0 @@ -{ - "@context": { - "a": "@type", - "b": "https://example.org/my-bb-model/b", - "c": "https://example.org/my-bb-model/c" - } -} \ No newline at end of file diff --git a/_sources/mySchema/description.md b/_sources/mySchema/description.md deleted file mode 100644 index 80e1024..0000000 --- a/_sources/mySchema/description.md +++ /dev/null @@ -1,7 +0,0 @@ -## My Schema - -Defines a set of properties that may be used in **any** JSON schema. - -> Note these properties may be used in the "properties" sub-component of a GeoJSON object, as a simple object - -The numeric properties "b" and "c" have an example SHACL rule that if c is present, then c > b \ No newline at end of file diff --git a/_sources/mySchema/example.json b/_sources/mySchema/example.json deleted file mode 100644 index 0695ca9..0000000 --- a/_sources/mySchema/example.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "@context": { - "mynamespace": "http://example.org/ns1/" - }, - "a": "mynamespace:aThing", - "b": 23, - "c": 1 -} - diff --git a/_sources/mySchema/examples.yaml b/_sources/mySchema/examples.yaml deleted file mode 100644 index 5db4327..0000000 --- a/_sources/mySchema/examples.yaml +++ /dev/null @@ -1,24 +0,0 @@ -- title: This is an example with just a description and no code snippets. - content: |- - This an example. - - In **Markdown** format. - - snippets: - - language: json - ref: example.json - -- title: Examples can have content and/or code snippets. - content: |- - The content of this example. - - snippets: - - language: shell - code: |- - echo 'Hello, world!' - - language: python - code: |- - print('Hello, world!') - - language: javascript - code: |- - console.log('Hello, world!') diff --git a/_sources/mySchema/rules.shacl b/_sources/mySchema/rules.shacl deleted file mode 100644 index c124e74..0000000 --- a/_sources/mySchema/rules.shacl +++ /dev/null @@ -1,15 +0,0 @@ -@prefix rdf: . -@prefix rdfs: . -@prefix sh: . -@prefix xsd: . -@prefix mynamespace: . -@prefix ns1: . -@base . - -<#testValues> - a sh:NodeShape ; - sh:targetClass mynamespace:aThing ; - sh:message "C must be greater than B" ; - sh:property [ sh:path ns1:c ; - sh:lessThan ns1:b ] -. diff --git a/_sources/mySchema/schema.yaml b/_sources/mySchema/schema.yaml deleted file mode 100644 index a4b747c..0000000 --- a/_sources/mySchema/schema.yaml +++ /dev/null @@ -1,14 +0,0 @@ -"$schema": https://json-schema.org/draft/2020-12/schema -description: 'My example schema' -type: object -properties: - a: - type: string - format: uri - b: - type: number - c: - type: number -required: - - a - - b diff --git a/_sources/mySchema/tests.yaml b/_sources/mySchema/tests.yaml deleted file mode 100644 index 51c8c71..0000000 --- a/_sources/mySchema/tests.yaml +++ /dev/null @@ -1,9 +0,0 @@ -# Additional / external tests resources by reference - -# - ref: https://example.com/my-test.json # Simple test resource by reference - -# - ref: https://example.com/my-other-test.json -# output-filename: different.json # Test with custom output-filename - -# - ref: https://example.com/failing-test.json -# require-fail: true # Override require fail without changing filename \ No newline at end of file diff --git a/_sources/mySchema/tests/rules-fail.json b/_sources/mySchema/tests/rules-fail.json deleted file mode 100644 index 61c39e3..0000000 --- a/_sources/mySchema/tests/rules-fail.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "@context": { - "mynamespace": "http://example.org/ns1/" - }, - "a": "mynamespace:aThing", - "b": 23, - "c": 25.5 -} diff --git a/bblocks-config.yaml b/bblocks-config.yaml index 127c49f..375bd47 100644 --- a/bblocks-config.yaml +++ b/bblocks-config.yaml @@ -1,18 +1,17 @@ # A short, descriptive name of this building block collection -name: My OGC Building Blocks repository +name: CityGML Profiles # Short abstract for this collection (optional) abstract: | - This is an example text for the abstract. It should be short and to the point. - A "Tell me more" link will appear if there is an additional description with a longer explanation. + This repository is for the development, testing and publication of CityGML profiles. + Building blocks represent different levels of abstraction, from conceptual to implementation modules to individuals Feature Types, and ways of combining these. # Description for this collection (optional) description: | - The description can be longer. Both **the abstract** *and the description* support Markdown, - including [links](https://google.es). + TBD # Customize the following prefix (will be prepended to the path of the building blocks): -identifier-prefix: ogc.bbr.template. +identifier-prefix: ogc.geo.citygml. # List of imports ("default" is an alias for the main OGC Building Blocks Register) imports: