You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Subject briefly discussed in the 2026-05-11 SWG meeting. This is an reminder issue about possible future explorations/testbed to clarify how this fits with other OGC initiatives about data semantics.
The dataClasses definition was added to Part 1 v2. It is an array of URI(s) that can be used to refer to various data profiles applicable (or required?) by inputs/outputs.
However, data semantics are often more complicated than that, and there are still some ambiguities related to this list. Some items (non-exhaustive to consider):
Are the URIs "mandatory" or "supported" profiles?
Are they mutually exclusive definitions, inclusive/union of semantic fields, partially overlapped concepts, etc.?
Given a certain list of URIs, what should the process do with a certain input in terms of validation?
If the input is a complex reference like a collection input, how does it apply?
(for example, two different profiles that respectively apply to different STAC Asset)
Is there some examples of their application?
These items should be refined and clarified in the specification.
In order to support more complex profile combinations, there might be a need for different data structures under dataClasses.
Note
Subject briefly discussed in the 2026-05-11 SWG meeting. This is an reminder issue about possible future explorations/testbed to clarify how this fits with other OGC initiatives about data semantics.
The
dataClassesdefinition was added to Part 1 v2. It is an array of URI(s) that can be used to refer to various data profiles applicable (or required?) by inputs/outputs.However, data semantics are often more complicated than that, and there are still some ambiguities related to this list. Some items (non-exhaustive to consider):
collectioninput, how does it apply?(for example, two different profiles that respectively apply to different STAC Asset)
These items should be refined and clarified in the specification.
In order to support more complex profile combinations, there might be a need for different data structures under
dataClasses.