Add inverse role for all properties in SOSA (SSN)

[kjano]

As discussed, it seems like we defined inverse properties for most but not all relationships in SOSA/SSN. It would be good to either explicitly define all inverse property names or make sure we know why we omitted some.

[dr-shorthair]

Inverse properties were only defined where there was a requirement or request. Do they need to be complete? Is this desirable?

There are 22 object-properties without inverses in the sosa: namespace (see below).
Adding these would enlarge the vocabulary quite a bit.

Prov-o explicitly minimised the number of inverse properties - https://www.w3.org/TR/prov-o/#inverse-names - though it 'reserved' the names for all the inverses. DCAT also includes a note about the 'missing' inverses - https://www.w3.org/TR/vocab-dcat-3/#inverse-properties .

Perhaps we could just add a similar note in the SSN Ontology documentation?

---

SOSA ObjectProperties without an inverse:

• sosa:forProperty
• sosa:hasInput
• sosa:hasOutput
• sosa:usedProcedure
• sosa:phenomenonTime
• sosa:hasUltimateFeatureOfInterest
• sosa:hasInputValue
• sosa:hasOutputValue
• sosa:hasSubSystem
• sosa:deployedAsset (super-property of sosa:deployedSystem )
• sosa:hasMember
• sosa:resultQuality
• sosa:observedProperty
• sosa:relatedObservation
• sosa:isProxyFor
• sosa:wasOriginatedBy
• sosa:detects
• sosa:isSampleOf
• sosa:hasOriginalSample
• sosa:hasSampledFeature
• sosa:isResultOfMadeBySampler
• sosa:isResultOfUsedProcedure

[sgrellet]

Sounds like a good idea.

I'd tend to be closer to the PROV-O note; I feel DCAT one rather short on the explanatation side.

[dr-shorthair]

OK - tabulation of recommended names for inverses in an appendix - See #228 and https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html#inverse-properties The tabulation is similar to how it was done in PROV-O.

Building this table also allowed a consistency check so I fixed up some domain/range inconsistencies in both the TTL and HTML

[KathiSchleidt]

I get the point that this does add a lot of additional inverse properties. At the same time, I do see use cases for quite a few of them. @dr-shorthair many thanks for this overview table!!!

Would a Solomonic approach be useful? Provide these additional inverse properties, but in an extension? This way, those who don't need them are not overburdened, while those who would like to use them can do so in an aligned manner.

[rob-metalinkage]

An extension that defines SHACL rules to infer them might be useful too. Particularly any transitive properties.

[dr-shorthair]

Creation of inverse roles for all properties of Observation supersedes some uses of the relatedObservation predicate that was added for the OMS alignment.

Looking at the relatedObservation roles in the OMS Conceptual Observation Schema and OMS Conceptual Sample Schema they are implemented more specifically as follows

• ObservingProcedure -- usedForExecution --> Observation
• ObservableProperty -- wasObservedBy --> Observation
• Observer (Sensor) -- madeObservation --> Observation
• Sample -- isFeatureOfInterestOf --> Observation

SSN/SOSA has indirect relationships (property-chains) for the other cases as follows

• Deployment -- deployedSystem --> Sensor -- madeObservation --> Observation
• Platform (Host) -- hosts --> Sensor -- madeObservation --> Observation

I'm reluctant to clutter SSN/SOSA with additional direct relationships mirroring these, however.

So relatedObservation is only required for the relationships from the Executions (and their collections) to observations. A particular case that we already mentioned in the document is to link an Actuation to an Observation used to verify the outcome.

So my feeling is that we should just limit the domainIncludes for relatedObservation to these latter cases, and update the OMS alignment table to reflect this.

Optionally we could also make the specific cases above into subPropertyOf relatedObservation. It could make the alignment a bit easier to express formally, though that would probably make it harder for readers to understand.

[dr-shorthair]

Previews: https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html#inverse-properties - new terms with asterisks

https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html#OMS-Alignment-Property-OMS

[dr-shorthair]

It was agreed in the 2024-06-12 telecon that (i) we should proceed with a full set of inverse properties (ii) the tabulation in the Appendix was useful (iii) the adjustments to the OMS alignment were needed (iv) the HTML documentation needs completing to reflect the additions to the Ontology.

I think I have now executed those changes. See preview at https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html

228 is now ready for review and (I hope) merging.

Please take a look.

[avillar]

I've added a prototype for sorting tables like we discussed today: https://raw.githack.com/w3c/sdw-sosa-ssn/218-with-sort/ssn/index.html#inverse-properties

Is this what you had in mind?