@rgcmme Maybe you want to check this out ?

SOSA has no formal axiomatization, since all of it has been moved to SSN. Therefore, since the mapping is only between SOSA and SAREF, the relationships should be in the other direction.

That is, by making sosa:FeatureOfInterest (no axioms) subclass of saref:FeatureOfInterest (with axioms), sosa:FeatureOfInterest is inheriting many axioms that may not apply.

If the mapping would be between SAREF and SSN, every class should be analysed in detail. SSN has some cardinality restrictions that would make such mapping difficult (e.g., is it needed for every sosa:Execution to always have both a start time and a result time?).

Also, the mappings between inputs and outputs are strange; because of the "/sosa/saref" URIs, and there is a typo in the sosa:hasOutputValue one. In SAREF inputs and outputs are only applied to commands, but in SOSA/SSN to procedures.

I based the alignment on the literal definitions, mostly.
The goal here would only be that nothing breaks when importing SSN + SAREF + this alignment,

Regarding the mappings between inputs and outputs, they are strange indeed. I don't think either is more specific than the other, so I created a common super-property. Note that in SAREF inputs and outputs apply not only to commands:

saref:hasInput has Domain ( saref:Command or saref:CommandOfInterest or saref:Operation or saref:ProcedureExecution )
saref:hasOutput has Domain ( saref:Command or saref:CommandOfInterest or saref:Operation )

If the mappings are based in the textual definitions, from the "textual" perspective they compile. 😄

However, if they are formally encoded (using for example rdfs:subClassOf), then there will be formal entailments.

In the case of SOSA, with no axiomatization, nothing will break (even if the mappings are not correct).

If the mapping would be between SSN and SAREF, this may not be the case, since both ontologies impose their own restrictions that may not be compatible (or produce the intended result). But I haven't made that detailed analysis. And it also depends on the definition of "break", but it may happen that one SSN individual is not a valid SAREF individual (e.g., because of cardinality constraints).

SSN has some cardinality restrictions that would make such mapping difficult

I'm not fully confident in the cardinality restrictions.
Most of them are my clumsy way of adding some 'expectations'.
But cardinalities are probably better handled in the application, or using SHACL (which is planned by OGC in the next phase).

Would it be best to remove all cardinality constraints from the ssn graphs?

I am in favour of the cardinality restrictions and any other axiom that further specifies the meaning and restrictions of the concepts.

Ontologies are a good way of sharing those restrictions in a machine-procesable way; leaving applications the role of handling those restrictions will cause heterogeneity and hinder interoperability.

And using SHACL will require implementors to know/learn both OWL and SHACL and having to search for the restrictions in two places.

In any case, every option is valid in principle. My take would be, for those restrictions that are clear, to have them in OWL and in the future in SHACL.

I would try to avoid having restrictions in SHACL that do not appear in OWL (for those restrictions that can be defined in both places).

On cardinalities:

e.g., is it needed for every sosa:Execution to always have both a start time and a result time?

The way I understand it is that every Execution does necessarily have a start and end (result) time in the world.
However, these may not be known or expressed in any particular representation ... but that is handled by the OWA.

Does putting a minCardinality=1 in the OWL mean that a dataset without that property is 'wrong'?
I don't think so, OWL processing does not allow for that judgement, it can only generate entailments.
The entailment in such a case is that there is an unknown value ...

Of course, OWL and the OWA are able of handling this correctly.

However, sooner or later someone will define closed world constraints (SHACL is mentioned in this same thread) and the restriction "every execution has a start date and there is no problem if you don't find it" becomes "every execution has a start date and your data is incorrect because it does not".

The fact that every execution always has a start time can be documented in the rdfs:comment of sosa:Execution (with no strong semantics associated to it) and leave to users the decision of whether they want that to be a strong constraint (by extending SSN with further restrictions) in their applications.

At least in this case I think that it is a restriction that will not hold for many applications.

sooner or later someone will define closed world constraints (SHACL) [that are too strict or onerous]

We recognise that risk, and propose to address it by providing shared SHACL constraints that manage things like cardinality. This is on the agenda for related work to be done inside OGC - see #142 and opengeospatial/ogcapi-sosa#4

There is a placeholder space for standard SHACL resources here https://github.com/w3c/sdw-sosa-ssn/tree/gh-pages/ssn/rdf/shapes

@rob-metalinkage can you check if your concern has been addressed?