Complete inverses and add tabulation

[dr-shorthair]

And fix up inconsistencies on properties uncovered in tabulation

closes #218

[dr-shorthair]

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

[dr-shorthair]

I've now added in definitions for all the inverse properties into the HTML docs Re-ordered the definitions in the specification section - Classes first, then pairs of inverse properties. Updated the master alphabetical index.

[dr-shorthair]

Preview here: https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html

[dr-shorthair]

Please review this PR, following consensus on #218 agreed at 2024-06-12 telecon.

[ldesousa]

@dr-shorthair I am about half way with the review, there are many changes, it will take a while longer. In the meantime I have two general questions:

1. The OSM alignment document is also modified by this PR. Is it intentional?
2. There are various predicates (and their inverses) declared at the sub-class level, e.g. between Procedure and ObservableProperty sub-classes. Can these predicates be instead defined at the super-class level instead? I would prefer an ontology as parsimonious as possible. Was this argued before? I don't what to re-open the discussion, just the heads up.

[dr-shorthair]

Thank you @ldesousa

Yes, there were some changes needed to the OMS alignment as a consequence of defining more inverses. It was discussed here

The predicates that link ActuatingProcedure to ActuatableProperty, and ObservingProcedure to ObservableProperty that are shown in the overview diagrams are the general predicates defined at the superclass level, as you suggest. Guarded constraints (owl:Restriction) to limit the ranges in are provided in the ssn-observation.ttl and ssn-actuation.ttl modules, so these are reflected in the (non-normative) overview diagrams.

It is true that the set of classes in domainIncludes and rangeIncludes are quite big for some predicates because of the sub-classing of Execution and Procedure, which leads to big lists in the tabulation at https://raw.githack.com/w3c/sdw-sosa-ssn/218-add-inverse-role-for-all-properties-in-sosa-ssn/ssn/index.html#inverse-properties. But this is necessary for SOSA users who do not load the SSN modules to see the sub-class relationships.

Am I addressing your concern or is there another specific proposal?

[sgrellet]

I mainly managed to work on B. Tabulation of properties and their inverses

Find below 2 questions and a feedback below

• sosa:featureSampledBy*/ sosa:isUltimateFeatureOfInterestOf I hope I don't re-open an already long discussed topic. Do we need to scope the Domain here ? From the 'FoI is a role/property not a class' discussion I feel that in many implementation sosa:hasSampledFeature will point to an instance defined in a domain model (ex in water : river, lake, aquifer) not by sosa:FeatureOfInterest only Or is it that we expect that instance (ex : French Catchment of foo1) to be both a https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment and a sosa:FeatureOfInterest ?

The same question & logic applies to sosa:isUltimateFeatureOfInterestOf

• sosa:phenomenonTime / sosa:phenomenonOccurred* no 'Inverse property of' mentionned when traversing the link to their individual description (ex : 5.3.4.2.10 sosa:phenomenonTime)

• Tabulation table formating

I still feel the 'Tabulation' is both super useful and hard to read IMHO, we want to 1st document there properties and their inverse

Is the addition of Domain and Range of a Property helping to solve extra aspects that only a big lookup/compendium table can achieve ? Said differently : we can already get the individual Domain/Range of a given property

• if yes we need to keep this but not sandwich the 'Inverse property' column as it is right now => suggestion adjust the column order 'Property' | 'DomainIncludes' | 'RangeIncludes' | 'Inverse property of' to make it clear that these are the Domain/Range of the value in the Property column

I'll also add a 'of' at the very end ('Inverse property of') to really match what we have for a given property

• BTW we need to make diagrams searchable That will help not loosing the overview when looking at class/property definition