Add ogc.osc.prov-processing-step: PROV profile for a single geospatial processing step - #14
Open
nsnarayanam wants to merge 5 commits into
Open
Conversation
…l processing step
…es via qualifiedUsage — examples now validate 2/2
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
D104 (Aganitha) contribution toward Activity 1. Supersedes #13, which was built from an earlier branch — same content plus the JSON-LD bindings below.
A profile of ogc.ogc-utils.prov constrained to a single geospatial processing step. Adds a required processType property linking the step to a registered process type - the link PROV-O and OGC API - Processes Part 5 (26-038) do not themselves provide, and the point where the profile-plus-register pattern closes.
Inputs and outputs are entity references per the PROV-O object model; roles are carried in qualifiedUsage. Both examples validate locally (2/2).
Design question rather than a settled call: processType is bound to dct:type so the value resolves as a governed concept rather than a plain string, following the steer not to mint terms where existing ones will do. A dedicated ospd: property would be more precise than "type" — happy to change if the group prefers that. Worth deciding once rather than per-block.
parameters is deliberately left unbound in the context: how parameters should be typed depends on whether process types are registered coarsely or as parameterised subtypes, which is still open.
Process-type URIs are placeholders pending D110/D111.
Notes:
master build currently fails on them. Those patches are not included.
not content. The substantive addition is _sources/prov-processing-step/.