generated from opengeospatial/bblock-template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbblocks-config.yaml
48 lines (35 loc) · 3.1 KB
/
bblocks-config.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# A short, descriptive name of this building block collection
name: Cross-domain model
# Short abstract for this collection (optional)
abstract: |
Defines a reusable baseline "cross-domain semantic model" by defining a series of profiles and dependencies on available standards and where appropriate a set of constraints for application of such standards in the spatio-temporal domain.
# Description for this collection (optional)
description: |
These models are defined as ["building blocks"](https://ogcincubator.github.io/bblocks-docs/) to allow for transparent reuse of a range of semantic models published by OGC and other international standards organisations (SDO) that may be used to define semantic models for application domains in a consistent and interoperable way.
Application domains will typically define profiles of these core models to meet specific needs. Infrastructures supporting application domains may define more general profiles to support commonality of implementation necessary to exploit infrastructure services.
The Cross-domain model underpins proposed domain models for Agriculture, Oceans and AG4DG.
By defining these models using this common cross-domain model the interoperability between such domains is enhanced, and made transparent to applications.
Note that metadata models may be defined to exploit these semantics -
the cross-domain model is agnostic of the various metadata schemas or models that may be used, recognising that most "systems of systems" will have
multiple metadata formats in play due to evolution, backwards compatibility requirements and specific metadata needs of different communities and systems.
Defining constraints using SHACL for these building blocks allows for inheritance of validation rules.
This will dramatically reduce the complexity of defining and testing domain models in a consistent fashion.
Many such restrictions will relate to the way these models are combined -
for example the way GeoDCAT, PROV, RDF-Datacube and SOSA may be combined to standardise the way observational data is described using available standards.
# Customize the following prefix (will be prepended to the path of the building blocks):
identifier-prefix: ogc.model.cross-domain.
# List of imports ("default" is an alias for the main OGC Building Blocks Register)
imports:
- default
- https://ogcincubator.github.io/geodcat-ogcapi-records
- https://ogcincubator.github.io/bblocks-skos
# SPARQL configuration (optional)
# Authentication can be set through the sparql_username and sparql_password GitHub Workflow inputs
# (see .github/workflow/process-bblocks.yml)
#
# sparql:
# push: https://example.com/gsp # SPARQL Graph Store Protocol endpoint for uploading data
# graph: https://my.bblocks.example.com/ # SPARQL Graph where data will be uploaded
# # if left empty, the base URL for the publication will be used
# query: https://example.com/sparql # SPARQL query endpoint where data will be available