Use ObservationType to guide profiles

[KathiSchleidt]

When aligning STA with SOSA and OMS, we run into 2 different profiles:

• in some scenarios, STA:Datastream -> OMS: ObservationCollection, STA:Observation -> OMS:Observation.
• in other scenarios, STA:Datastream -> OMS:Observation, STA:Observation -> OMS:Observation.result

If we pulled OMS:ObservationType into SOSA core, we could define rules on which ObservationType leads to which mapping profile

[dr-shorthair]

Lets clarify the requirement before jumping to a solution.

Do we need a SOSA-STA alignment chapter in https://w3c.github.io/sdw-sosa-ssn/ssn/#Alignments ?
If that uncovers some missing pieces then we might consider adding them into a sosa-sta: namespace.

Then if there are overlaps with additions in other alignment namespaces, we might consider consolidating them somehow.

Note that sosa-oms:observationType is very poorly documented at present, no examples, no exposition: https://w3c.github.io/sdw-sosa-ssn/ssn/#OMSobservationType

[rob-metalinkage]

Since STA does not have a formal RDF vocabulary, is it better to develop a mapping from STA JSON elements (it has not formal schema) to SOSA - i.e. a JSON-LD context and regard this instead as an implementation? Otherwise we are bring a range of alignment languages into play which may be hard to manage. Alternatively we could provide such a mapping as an informative annex?

OMS:ObservationType is a typical soft-typing mechanism. In discussions with OpenAPI folk they have a concept of "discriminator" - https://redocly.com/docs/resources/discriminator

in SOSA, as an RDF language, we can explicitly use polymorphism at the cost of maintaining and publishing RDFS or OWL Class definitions. when using JSON-LD annotations we can declare multiple properties to be of type "@type" - with the constraint that the values is, or can be mapped to, a URI (either with an @base or a CURIE using a declared prefix).

I think with the BuildingBlocks approach to publishing STA elements and STA-SOSA bindings we could declare two different profiles with mappings using JSON-LD without introducing a new SOSA element - noting soft-typing will always be present in the real world and maybe SOSA should not try to cover this explicitly.