SOSA-OMS Alignment

[alexrobin]

This is my initial attempt to merge SSN Extensions and OMS concepts into the SOSA/SSN Ontology.

Only Turtle files have been modified so far. RDF files are still the original version so they don't match. We can regenerate them automatically when ready.

The changes are recorded in readme.md.

Design Choices

• No change to URIs of existing SOSA/SSN classes and properties.
• Only allow minor documentation changes or clarifications that don't fundamentally change the meaning of existing concepts.
• Keep most notes and examples from OMS
• Allowed some changes to relations to better integrate new OMS classes (range or domain)
• Rename OMS associations with more specific names since unique URIs are needed in RDF

Discussion Items

• Observer and Host are kept more abstract (they are not Systems). Is everybody OK with this?

• More specific procedure types are introduced by OMS. I made the choice to reinforce the constraints on the existing properties to reflect this, but this is a breaking changes compared to the existing version. So we may prefer to keep the existing looser constraint, or create a separate sub-property with a stricter constraint (e.g. have both usedProcedure and usedObservingProcedure on Observation)

• Should we also add observableProperty association between ObservingProcedure and ObservableProperty? (requested by Sylvain Grellet). If we do, then we should also add the actuableProperty association between ActuationProcedure and ActuableProperty. This makes sense to me so we can discover procedures by property.

• SampleCollection could get common properties like ObservationCollection (e.g. same Sampler or same SamplingProcedure used for all samples in the collection). OMS doesn't define this, but should we do it here?

[KathiSchleidt]

Discussion Items

numbered for easier reference in such a lumped issue

1 Observer and Host are kept more abstract (they are not Systems). Is everybody OK with this?

Not really, as they're a core part of the OMS model

2 More specific procedure types are introduced by OMS. I made the choice to reinforce the constraints on the existing properties to reflect this, but this is a breaking changes compared to the existing version. So we may prefer to keep the existing looser constraint, or create a separate sub-property with a stricter constraint (e.g. have both usedProcedure and usedObservingProcedure on Observation)

Don't understand the issue in adding a more abstract Procedure, then specializing as done in OMS. How does this break the existing version?

3 Should we also add observableProperty association between ObservingProcedure and ObservableProperty? (requested by Sylvain Grellet). If we do, then we should also add the actuableProperty association between ActuationProcedure and ActuableProperty. This makes sense to me so we can discover procedures by property.

Makes sense, in OMS you can only discover this link via the OMS:Observer.

In addition, I'm all for keeping the core patterns between Observation, Actuation, Sampling aligned

4 SampleCollection could get common properties like ObservationCollection (e.g. same Sampler or same SamplingProcedure used for all samples in the collection). OMS doesn't define this, but should we do it here?

Agreed. SampleCollection was not discussed enough in OMS. Creating SamplingCharacteristics parallel to the OMS:ObservationCharacteristics to describe the nature of the SampleCollection would be valuable.

In addition, I find the decision to on No change to URIs of existing SOSA/SSN classes and properties. a bit premature. We can state this as a goal, but must be aware that the required modifications may shift the semantics of some classes to the point where a new URI may be necessary.

[alexrobin]

@KathiSchleidt

Point 1

If you look at my changes to the ontology, you'll see that Observer and Host are in there, very much at the core of SOSA, and they are connected to other classes just like in the OMS model.

However, SOSA also had Sensor and Platform which more or less correspond to Observer and Host, but their name and definition sound slightly less general to me and, more importantly, they are also subclasses of System. So basically, in this new version, a Sensor is both an Observer and a System, and a Platform is both a Host and a System. I only said Observer and Host are more abstract because they are not Systems in the current version, which is not a requirement of OMS either, so I thought it actually keeps things cleaner and better aligned with OMS.

That said, I don't really mind making them Systems too and perhaps change things so that Observer is equivalent to Sensor and Host equivalent to Platform if you think it's a better choice. I just assumed that if you used different names in OMS, it's because you wanted to keep these concepts a little more general that they were in SOSA.

Point 2

The Procedure class was already defined in SOSA so I only added the specializations. The additional classes themselves are not the issue, however many associations were to Procedure and not the corresponding specializations. In this version I made the associations more specific, just like on OMS (e.g. Observation to ObservingProcedure instead of simple Procedure, etc.). However, this would probably break existing uses of the ontology. During our last call, both Jeremy and Linda were in favor of not introducing breaking changes so we should discuss other alternatives.

Point 3 and 4

OK, we can discuss next time if we should do that at the same time as bringing OMS in or wait for the next revision.

Regarding keeping URIs stable, I think it is an essential component of any ontology. Cf my previous comments about avoiding breaking changes for existing users.

[KathiSchleidt]

Point 1

To our view, Sensor is a subtype of Observer (this was based on long discussions we'd have over the years convincing people that O&M or SOSA can be used without a Sensor. The term Observer is more neutral)

Why can't we slip the Observer concept between Sensor and System in the derivation hierarchy?

I fail to see how Platform is a System in the current model, only associated to System

If you look at my changes to the ontology,...

Where are these documented?

Point 2

without access to your modified version of SOSA, it's difficult to judge if the inclusion of the specialized procedures would actually break existing applications.

While I can see some reasoning issues ensuing, as the specialized procedures are all subtypes of Procedure, this should be alignable, I don't see the blocking point.

Points 3&4

As O&M and SOSA have always been leapfrogging each other as they progress, I believe we should definitely investigate the proposed refinements that came up at the end of the OMS work

Both the link between ObservingProcedure and ObservedProperty as well as the enriched SampleCollection would be most valuable.
If we have them in SOSA, it would be far easier to cleanly add to various domain models.

Point 5

While I appreciate aiming for backwards compatibility, even ontologies can evolve to new versions.
I'm not sure if we're doing the community a service by making total backwards compatibility our highest goal

[alexrobin]

@KathiSchleidt My modified version of SOSA/SSN is this PR

[dr-shorthair]

Very pleased to see this discussion.

[rob-metalinkage]

Another set of concerns,

SOSA was deliberately designed to stand-alone from SSN without the axioms and the non-OMS elements.

With the extension of OMS scope, this line is now shifted. I dont think its safe or reasonable to make OMS dependent on SSN axioms and the necessary (and unspecified) reasoning profile to use any dependencies on SSN

so I would propose we extend SOSA to include all the OMS classes we need - and make these subclasses of SSN equivalents, updating the alignment axioms in SSN. This should not affect anyone already committing to SSN and the level of reasoning required, but preserves the SOSA design philosophy.

it may be necessary to have a telecon with myself and @dr-shorthair and others from the original SOSA design teams

[dr-shorthair]

I think that SOSA used the following modeling predicates in axioms

• rdfs:subClassOf
  • but not using owl:Restriction
• rdfs:subPropertyOf
• schema:domainIncludes
• schema:rangeIncludes

while SSN also used

• rdfs:domain
• rdfs:range
• owl:Restriction

There were just a few classes in the SSN namespace

• ssn:Deployment
• ssn:Input
• ssn:Output
• ssn:Property
• ssn:Stimulus
• ssn:System

IMAO these should all be brought into the SOSA namespace, for simplicity. (Note that I minted all the SSN-extensions in the SOSA namespace for this reason - T-box ontologies have few enough classes that it really isn't necessary to segment by namespace and generally leads to unnecessary confusion.) Its fine for the SSN graph to hold all the higher-order axioms, but not necessary for any classes and properties to be in the SSN namespace.

AFACT the classes that @alexrobin has added are all in the SOSA namespace anyway. It would only be subClass/subProperty relations with SSN classes and properties that may cause confusion ...

[kjano]

Hi, IMHO, we should start working on the next version anyways. I would assume that SSN can be slowly phased out and SOSA can remain the minimal core with EXT and other parts being added as modules as originally envisioned. If I am not mistaken OMS was designed with knowledge of SOSA anyways; so OMS could depend on SOSA but should not depend on SSN. I am certainly game. Jano

…

On 4/18/23 01:34, Rob Atkinson wrote: Another set of concerns, SOSA was deliberately designed to stand-alone from SSN without the axioms and the non-OMS elements. With the extension of OMS scope, this line is now shifted. I dont think its safe or reasonable to make OMS dependent on SSN axioms and the necessary (and unspecified) reasoning profile to use any dependencies on SSN so I would propose we extend SOSA to include all the OMS classes we need - and make these subclasses of SSN equivalents, updating the alignment axioms in SSN. This should not affect anyone already committing to SSN and the level of reasoning required, but preserves the SOSA design philosophy. it may be necessary to have a telecon with myself and @dr-shorthair <https://github.com/dr-shorthair> and others from the original SOSA design teams — Reply to this email directly, view it on GitHub <#1402 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANMP5REVEJQ2ZCWXPE6QILXBXHRZANCNFSM6AAAAAAW5GBSFI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Krzysztof Janowicz Professor for Geoinformatics, Director Center for Spatial Studies Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 ***@***.*** Webpage:http://geog.ucsb.edu/~jano/ Semantic Web Journal:http://www.semantic-web-journal.net

[alexrobin]

@rob-metalinkage @dr-shorthair

I don't know if you looked at the changes in the PR but I tried to follow the exact same patterns as the ones that were already employed in SOSA and SSN. This means the SOSA file defines classes and properties with loose constraints using schema:domainIncludesand schema:rangeIncludes axioms while the SSN file tightens things further with owl:Restriction.

Personally I like keeping the two namespaces separate. SOSA is a good abstract core while SSN brings more implementation level details.

I think the only class that is in OMS and not in SOSA is Deployment. And so some relationships from SOSA namespace to Deployment may be an issue.

Happy to have a telecon with the initial SOSA team to discuss design patterns.

[rob-metalinkage]

@kjano - OMS will be "expressed as" rather than "depend on" SOSA

SOSA will be what I would call a "canonical logical model" for the OMS Conceptual Model - i.e. a lossless machine readable form that can be directly instantiated with instance data.

As discussed will also define encoding bindings for SOSA as JSON, using JSON schema linked to JSON-LD.

There may be multiple such schema bindings depending on the meta-model for encoding.

https://github.com/opengeospatial/ogcapi-sosa has been setup to define an "OGC Building Block" form of an encoding - based on the GeoJSON (and FG-JSON extensions proposed) meta-model.

Note that other meta-models could be implemented as well - such as the ODATA model used by SensorThingsAPI - but these may require formalism of equivalent logical models (e.g. ODATA)

Note that this could become part of OMS - so we could rebrand SOSA and the SOSA-bb as sub-parts of OMS

[6a6d74]

Hi folks. Glad to see we have this conversation going - and public too :-) ... Thankyou @alexrobin

I don't have practical experience of using the SOSA, SSN, or OMS vocabs so I can't comment with authority on the discussion points above. But I do see that the experts are in the (virtual) room.

What I do want to talk about is backward compatibility and examples ...

Here are a few salient points from the SDW-WG plenary call back in Nov 2022:

• @kjano noted that they have "billions of triples" deployed; let's not break existing systems (his or anyone elses)
• @rob-metalinkage noted that there are 3 different ways to describe observed property (?) in SOSA - and there are examples of all 3 methods deployed in the world; he wondered whether these 3 methods could be formalised as profiles?
• @kjano said that the provision of 3 distinct methods was by design (i.e., compromise), but there's a possibility for homogenisation
• @nicholascar, @kjano, and @rob-metalinkage all noted that the (normative machine readable) examples in the SOSA documentation (?) are wrong / out of sync - which is problematic (e.g., when trying to build documentation, including examples, directly from the model)
• @nicholascar would like to see non-normative examples in the SOSA vocabulary illustrating the "unofficial" uses of the ontology - this would follow the documentation pattern used in GeoSPARQL

The observed (observable?) property discussion was also picked up by @rob-metalinkage in the Joint Geosemantics DWG / SDW-WG session at the OGC Members meeting in Feb 2023. He was talking about establishing an "ObservableProperty register" to mitigate issues around "massive duplication and lack of federation in the wild".

So. From my perspective, I think there are 3 pieces of work on the table:

1. SOSA / OMS alignment - which should aim not to break backward compatibility and (given that we're updating the vocab) provides an opportunity to fix the examples
2. Developing 3 profiles of how ObservableProperty is used (plus mechanisms to declare which profile a given dataset uses)
3. ObservableProperty register.

I think point (1) is (at least partially) covered by this PR ( #1402 ) ... does it fix the examples? (should it?). Point (2) relates to the broader sematic uplift work being progressed within OGC. And point (3) is the subject of a OGC Discussion Paper that @rob-metalinkage is drafting ahead of the June OGC Members meeting.

TL;DR ... we need to assess backward compatibility, we should fix examples, and there's some other work that's in the mix but out of scope.

[dr-shorthair]

The changes all look well aligned with OMS, and appropriately located in the two namespaces.

However, there may be challenges relating to 'evidence of implementation'.

[nicholascar]

We are doing large-scale SOSA-based Knowledge Graph data integration for the Geological Survey of Western Australia.

This work will continue for the next 2 years and could provide implementation evidence for OMS.

We are using ConnegP in at least one of the public APIs to the KG data, so OMS data could be delivered as a profile of the SOSA-based KG data, alongside pure SOSA.

[dr-shorthair]

Since @alexrobin changed the base to sosa-oms-alignment I see no impediment to merging this PR.
It will make Alex's work more easily visible to the team using this repo.

[dr-shorthair]

(We may have preferred that the changes were factored into multiple PRs, so they could be evaluated separately.
But pragmatically we need to get this material visible in the main repo, and then we can perhaps implement changes to the working copy incrementally, converging on the sosa-oms-alignment version as and when we agree on these.)

[alexrobin]

I wanted to point out that although all changes are in a single PR, I did create separate commits for each.
This actually makes it easy to review the changes one by one after clicking the "Commits" tab of this PR.

Also, I don't know if you are aware that you can insert comments in the changed files of each commit to provide feedback on the proposed changes, directly in context. (to add a comment, just hover above the left margin when looking at the diff, and click on the + sign that appears)