Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"type" of an APEx algorithm OGC record #65

Open
soxofaan opened this issue Nov 27, 2024 · 2 comments
Open

"type" of an APEx algorithm OGC record #65

soxofaan opened this issue Nov 27, 2024 · 2 comments
Labels
bug Something isn't working help wanted Extra attention is needed question Further information is requested

Comments

@soxofaan
Copy link
Contributor

soxofaan commented Nov 27, 2024

from ESA-EarthCODE/EarthCODE#5

There is a conflict between the current constraint/convention to use "apex_algorithm" as properties.type in algorithm_catalog OGC records and EarthCODE expectations

e.g.:

{
"id": "max_ndvi_composite",
"type": "Feature",
"conformsTo": [
"http://www.opengis.net/spec/ogcapi-records-1/1.0/req/record-core"
],
"geometry": null,
"properties": {
"created": "2024-09-06T00:00:00Z",
"updated": "2024-09-06T00:00:00Z",
"type": "apex_algorithm",

this is currently enforced in CI as well by

assert data["properties"]["type"] == "apex_algorithm"

However, as discussed in ESA-EarthCODE/EarthCODE#5 , the EarthCODE tooling/schemas expect an enum ['dataset', 'service', 'process', 'workflow'] instead of "apex_algorithm"

Should we align here with EarthCODE? Note that it's currently not very clear why the enum constraint is in place there in the first place -> EOEPCA/metadata-profile#1

And should we use a different field (or approach) than properties.type to indicate that this is an APEx algorithm OGC record

@jdries
Copy link
Contributor

jdries commented Nov 27, 2024

Alignment is always better, if for sure does not have to remain 'apex_algorithm'.
So the real question is if these things indeed have the same 'type', so apex algorithms can be fully described as earth code process or workflow?

And related: how to detect the subtype? Like the standard used to define the workflow or process?

@soxofaan
Copy link
Contributor Author

I guess we should go for something like

"type": "workflow", 
"subtype": "apex_algorithm", 

to at least align with https://github.com/EOEPCA/metadata-profile.

But we probably also want to work with different APEx algorithm subtypes (UDP, ...), which might get messy that way.
Maybe we could also go for something like

"type": "workflow", 
"apex-type": "openeo-process", 

(which avoids the risk on collision with other/future schemas)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants