move environmental measurement type terms from the Salmon Ontology to ECSO

[samanthacsik]

There are a few environmental measurement type terms that I have added to the Salmon Ontology #49 which were either (a) missing from ECSO or (b) lacking definitions. @amoeba @mpsaloha we discussed moving these terms out of the current Salmon Ontology draft and into ECSO:

Terms that need to be minted in ECSO (i.e. terms that don't yet exist in ECSO)

• Seawater alkalinity
• Stream water temperature
• Subsurface sea temperature (open to discussing this rdfs:label)
• Sea surface salinity

Terms that are already in ECSO, but need added definitions/altLabels/etc.

• dissolved oxygen saturation (http://purl.dataone.org/odo/ECSO_00002386)
• freshwater alkalinity (http://purl.dataone.org/odo/ECSO_00002895)
• freshwater temperature (http://purl.dataone.org/odo/ECSO_00001525)
• river water temperature (http://purl.dataone.org/odo/ECSO_00001528)

I have defined all of the above terms in the Salmon Ontology, included links any source material, and added skos:altLabels where appropriate so it shouldn't be too much work to get them migrated over to ECSO (NOTE: it would be beneficial to have someone review these definitions). We should be careful to follow ECSO design patterns when migrating information, however -- for example, we use the skos:definition annotation property in the Salmon Ontology, while ECSO uses IAO_0000115. For a full list of annotation properties and how they were used in the Salmon Ontology, see its README.md.

One other thing to consider is how we will re-import these environmental measurement type terms back into the Salmon Ontology from ECSO, or if we even think that's necessary to do so. I've structured my Environmental measurement type sub-tree in the Salmon ontology (see screenshot below) a bit differently than terms are arranged in ECSO (e.g. I made Precipitation Volume a subclass of Precipitation measurement type in the Salmon Onto, while in ECSO it's a subclass of Volume Measurement Type). I'm mentioning this because these additional XXX measurement type terms are also mostly absent and/or missing definitions in ECSO:

In ECSO, but missing definition

• alkalinity measurement type (http://purl.dataone.org/odo/ECSO_00001749)

Not yet in ECSO

• Dissolved oxygen measurement type
• Precipitation measurement type
• Water salinity measurement type

[amoeba]

Those terms look pretty reasonable. Thanks for writing all of this up!

To your question about importing the terms back once extracted, I'm not sure I know enough just yet to say. You mention importing individuals terms though I'm not sure that's really a thing in the OWL sense. I could be wrong here though. Ontologies are just sets of triples and if you want to use a term in another ontology in your own you can just do that without an import.

When we import one ontology into another, we are essentially explicitly smushing their worlds together while maintaining their independence. I think you'd do this when you want to add additional axioms about terms housed in another ontology. This appears to be what you're doing in your above example because you're adding a subClassOf axiom. I think a practical reason to import one ontology into another is when importing is fundamental to understanding the target ontology. What do you think?

Either way, sounds like we should carve out some time to get these terms into ECSO and probably in pretty short order. I'm happy to volunteer here and we can coordinate. How does that sound?

[samanthacsik]

I know this conversation is split between here and slack, so to summarize for organization's sake: @mpsaloha is looking into how to properly reference terms from other ontologies. Importing individual terms from an ontology (as opposed to the whole ontology) has been challenging, largely for the reasons @amoeba describes above. SSOM (https://github.com/mapping-commons/SSSOM) is one new approach to ontology mappings that's being explored/developed, but also using skos:exactMatch may get us close to where we need to be, at least in the meantime.

Regardless of whether we end up mapping/importing (or not), getting these above terms moved over to ECSO is definitely a top priority. @amoeba your help would be much appreciated! Figuring out which version of ECSO to do this on (if that's not already obvious?) would be helpful place to start.

[mbjones]

Hi @samanthacsik changes targeting ECSO 0.10 should be done on the designated branch for that, https://github.com/DataONEorg/sem-prov-ontologies/tree/feature_41_ecso_0.10/ecso There is currently an ECSO8.owl file in there that we have determined is the most recent, and it will be renamed ECSO.owl before the release occurs. I'll talk to @amoeba about renaming things and cleaning up to make that all clearer today.

[amoeba]

Just a minor note: The most recent in-dev version of ECSO is on @mpsaloha 's computer and he's planning to send that to me ASAP so I can integrate it here.