[fmigneault]

Note

As discussed at the STAC Community Meeting 2026-10-19, and as replacement of:

• Proposal: Define processing:expression with format: results #44

Changes

• New parameters field under processing:expression to provide a mapping of named input values employed.
• Asset roles processing-input, processing-output, processing-parameters and processing-results.
• Recommendation to employ profile in Asset using the above roles and examples for common applications.

[fmigneault]

FYI @gadomski @emmanuelmathot @m-mohr @jsignell

[gadomski]

Thanks, this makes more sense to me, but there's a few bits that I find confusing ... I might not be the target audience for these changes, though.

[gadomski]

This change (adding ogcapi-processes) might be easier to review in its own PR, since it's technically independent of processing parameters.

[fmigneault]

I've added it because the document already mentioned "OGC Process API" in the relation types, but didn't provide any corresponding value here.

[gadomski]

I guess my point is, "Add ogciapi-processes to expression formats" could be its own, light pull request that could be easily reviewed and merged?

[fmigneault]

I can cherry-pick it if desired.

[gadomski]

I'm not familiar with a "profile URI" — it could be helpful to link out to an explanation to help the reader understand how to use a profile?

[fmigneault]

I agree about adding an example for clarity.
Following is an example: https://www.opengis.net/def/profile/OGC/0/ogc-process-description

It can be any URI. Ideally it resolves to a concept/ontology, but it can technically be even just an well-defined string in a standard document. It can also be a JSON schema URI or some other identifiable resource that strictly characterizes the resource.

The idea of using profile URIs is mainly such that what they refer to is more interpretable and removes potential ambiguity in otherwise generic strings.

[gadomski]

I don't intuitively understand the different between the input and the parameters? In programming terms, aren't they both "function arguments"?

[fmigneault]

The difference would be as follows.
Given a process that takes {"a": <some-geotiff>, "b": <some-parquet>, "c": <some-float>}.

You would have multiple processing-input, each respectively pointing at the href of <some-geotiff> and <some-parquet>. The <some-float> can be embedded in an Asset file as text/plain, JSON, or similar if one really feels the need for it.

The processing-parameters instead represent the structure itself, as submitted to the process, i.e.:

{
  "a": {"href": <some-geotiff>},
  "b": {"href": <some-parquet>},
  "c": <some-float>
}

This is dependant of the specific encoding the process takes. Ideally it is also indicated as processing:expression to clarify, though not strictly enforced.

The processing-parameters also allows other formats, so if a multipart/related was used for examples instead of the JSON, it could also be provided as a whole.

I purposely used processing-parameters to align with the suggested (as discussed the meeting):

"processing:expression": {
  "format": "https://www.opengis.net/def/profile/OGC/0/ogc-process-description",
  "expression": { ... the big process description ... },
  "parameters": { ... same as above 'processing-parameters' content ... }
}

I think it is also a good idea to have distinct inputs/outputs and parameters/results names because they represent differ document contents. From experience with OGC Processes, "inputs" term as been used to refer to different concepts (description vs execution values), and people always get very confused about the structures. Different terms ensure a clear distinction.

[gadomski]

The processing-parameters instead represent the structure itself, as submitted to the process, i.e.:

If I'm understanding (I'm probably not), the asset hrefs are duplicated in processing-input and processing-parameters? If so, this feels redundant.

Different terms ensure a clear distinction.

To me, it's less clear (inputs are inputs, that seems simplest to me). But again, I'm probably not the target audience for this extension, so I won't block.

[fmigneault]

Optionally duplicated. It gives the flexibility. I would say it depends how specific the provenance wants to illustrate the concepts.

I can see at least 2 reasons why processing-parameters remains relevant:

1. If a process only used a few floating point values, it is overkill to have it generate multiple distinct asset files with just a few bytes of data. Those files might not even exist also.
2. If a provenance chain provides the original submission (in the context of how the openEO, OGC API, etc. produced it), it easy to re-execute it as is. Using processing-inputs would force a client to manually recompose it (maybe incorrectly) from the Assets.

[gadomski]

Similarly, what's the different between an "output" and a "result"? Aren't these both akin to "the return value of the function"?

[fmigneault]

Output/Results happens to align with the same OGC concepts of the big "Results" document containing all of the individual "Outputs".

Beside that, same reason as Inputs/Parameters for distinct naming for different concepts.

[m-mohr]

Wondering whether this should be of type *, like expression. We don't really know how parameters look like in formats. Could be an array with values or a map with parameter name => argument paris, for example.

[jsignell]

Yeah that's a good point. In OGC Application packages I think parameters are an array.

[fmigneault]

I'm fine with that. It is up for the "expression format" implementation to define what it allows.

[m-mohr]

An OGC API Process is only metadata, not the actual "thing" to run, right? At least that's how the example looks like, if I understand it correctly. I think processing:expression should be something you can executy, not just metadata.

[fmigneault]

Depends how you look at it. It is an abstraction just like gdal-calc is an abstraction to some very specific C++ functions invoked. You don't actually need to know the internals of the process.

The example would be something like (YAML and single input for simplicity):

processing:expresssion:
  format: ogcapi-processes
  expression:
    process: https://example.com/ogcapi/processes/Echo
    inputs:
      message:
        schema:
          type: string
    outputs:
      result:
        schema:
          type: string
    jobControlOptions: [execute-sync]
  parameters:
    inputs:
      message: "Hello, World"

[m-mohr]

Should these be Link Relation Types instead? Or why are these assets?
How's the relation to https://github.com/stac-extensions/application#relation-types ? Is there potential for alignment?

[jsignell]

Yeah it doesn't seem obvious to me why processing-expression and processing-execution are link relation types and these ones are assets.

[fmigneault]

I started with Assets because I initially only had the processing-output and processing-results, and those would potentially be the actual results for which the STAC definition exists (the whole point of processing in this case is to provide their provenance). So, the idea is that we simply tag the role on top of the Asset already there just to make it clear it is part of the provenance (in contrast for example to some thumbnail or other alternate Asset that could be supplied from elsewhere).

I agree for the processing-input and processing-parameters, it makes more sense to have them as links since they are not the results.

Is there a strong distinction between Asset/Links for those cases? It seems to be walking the fine line between what should be an Asset or a Link.

[jsignell]

I like the concept. I definitely see the gap in the current extension. It just seems like there might be a few too many ways to say the same thing. Do you already have a need for all these different fields? Otherwise might it make sense to add less in this PR and see if a need becomes clear?

[fmigneault]

Do you already have a need for all these different fields?

I'd say most often than not, I could "manage" with processing-parameters and a link to the original OGC API Processes job that contains the extra details. The only problem with this is that it doesn't make the provenance metadata self-contained in the STAC Collection/Items. If the server does some cleanup of old jobs, provenance disappears. In such case, processing-parameters and processing-results is probably sufficient. The results' content can point at the same URIs the individual assets would provide.