While implementing OGC API - Processes, I encountered a limitation regarding the semantic description of process inputs and outputs.
The current specification allows describing the structure of an input/output using JSON Schema, together with media types and other metadata. This is sufficient to validate the syntax of exchanged data, but it does not appear to provide a standard mechanism to describe their semantics.
Consider the following example.
A process produces a JSON document representing a line chart. The JSON structure may define the X and Y axes, labels, values, and rendering parameters. Another process accepts two line charts and compares them.
For such a comparison to be meaningful, the consumer must know not only the structure of the JSON document, but also the semantic meaning of the represented data.
For example:
- does the X axis represent time, distance, frequency, or something else?
- what observable property is represented on the Y axis?
- what are the units of measure?
- are the two charts semantically comparable?
The same issue applies to many other output formats.
For example, a GeoTIFF contains georeferencing information and raster values, but an automated client may also need to know:
- what physical quantity the raster values represent;
- whether the values are categorical or continuous;
- which ontology or controlled vocabulary defines their meaning;
- whether they are compatible with the input requirements of another process.
In all these cases, the problem is not the syntax of the exchanged data but their semantic interoperability.
One possible solution would be to associate ontology concepts (identified by stable URIs) with process inputs and outputs, or with specific components of their schemas.
This would allow automated clients to determine whether the output of one process is semantically compatible with the input of another process before executing a workflow.
My question is therefore:
Does OGC API - Processes already provide a standard mechanism for associating semantic concepts (for example ontology terms, observable properties, controlled vocabularies, or similar semantic identifiers) with process inputs and outputs?
If not, would it be appropriate to consider introducing such a mechanism in a future version of the specification?
The objective would not be to describe the internal structure of the exchanged data—which is already handled by JSON Schema—but to provide machine-readable semantic annotations enabling automatic compatibility checks between process outputs and inputs during workflow composition.
While implementing OGC API - Processes, I encountered a limitation regarding the semantic description of process inputs and outputs.
The current specification allows describing the structure of an input/output using JSON Schema, together with media types and other metadata. This is sufficient to validate the syntax of exchanged data, but it does not appear to provide a standard mechanism to describe their semantics.
Consider the following example.
A process produces a JSON document representing a line chart. The JSON structure may define the X and Y axes, labels, values, and rendering parameters. Another process accepts two line charts and compares them.
For such a comparison to be meaningful, the consumer must know not only the structure of the JSON document, but also the semantic meaning of the represented data.
For example:
The same issue applies to many other output formats.
For example, a GeoTIFF contains georeferencing information and raster values, but an automated client may also need to know:
In all these cases, the problem is not the syntax of the exchanged data but their semantic interoperability.
One possible solution would be to associate ontology concepts (identified by stable URIs) with process inputs and outputs, or with specific components of their schemas.
This would allow automated clients to determine whether the output of one process is semantically compatible with the input of another process before executing a workflow.
My question is therefore:
Does OGC API - Processes already provide a standard mechanism for associating semantic concepts (for example ontology terms, observable properties, controlled vocabularies, or similar semantic identifiers) with process inputs and outputs?
If not, would it be appropriate to consider introducing such a mechanism in a future version of the specification?
The objective would not be to describe the internal structure of the exchanged data—which is already handled by JSON Schema—but to provide machine-readable semantic annotations enabling automatic compatibility checks between process outputs and inputs during workflow composition.