Adding terms from ESIP harmonization cryo activity

[charlesvardeman]

Adding back progress from ESIP harmonization cluster efforts on creating definitions for the cryosphere terms. Crossrefs to from SWEET to ENVO terms added during the harmonization captured using skos:closeMatch and a prov:wasDerived from in the definition. Additional provenance added by rdfs:seeAlso to GitHub issue where the discussion was documented. Additional discussion is needed to create a graph fragment for a prov:Activity in some namespace that corresponds to the ESIP harmonization cluster effort to capture the provenance of additions of definitions to SWEET. There were no axiom changes to realmCryo.ttl, but axiom changes were needed for phenCryo.ttl to reconcile the definition with existing SWEET axioms. Periglacial was changed to be a subclass of PhysicalProcess since it is not a Glacial Process. Periglaciation needs more discussion since the term does not occur in any community of practice references. It was changed to match Periglaciation axiomatization, ENVO created it as a synonym of Periglacial.

[lewismc]

+1, I've reviewed the additions for syntax and sampled many IRI's.
I like the way you have structured the skos:definition and will back back and reflect this in my Scala logic.

[smrgeoinfo]

Various problems with definitions that are not definitions, are not clear, or don't seem correct.

[lewismc]

Hi @smrgeoinfo thank you so much for the review this is exactly the kind of thing we need. My review was based on syntax and IRI resolution... not particularly on the quality of the annotations.

[charlesvardeman]

So, these are the definitions the @rdurr had collected and @pbuttigieg entered into ENVO from which they have been extracted (hence the prov:wasDerivedFrom triple). Would @smrgeoinfo be able to join the next Semantic Harmonization Cluster Hackathon on May 13th to help resolve some of these issues? Alternatively, I can remove the definition annotations leaving the SKOS crosswalk to ENVO and let the definitions live in ENVO?

[smrgeoinfo]

@rduerr -- are you actually OK with the definitions I flagged? As I went through the review, you'll note there are many definitions I thought were useful (as in no comment), and I have to confess that when I read those I thought "this sounds like Ruth..."

[smrgeoinfo]

Yes, I'd be interested in the hackathon on May 13, please send details; I have some experience with glaciers (two field seasons in Antarctica). To me the big problem is construction of logically coherent Aristotilean definitions. My experience over the years is that its difficult to get geoscientists to logically analyze their assertions in a way that's useful for automated computation. Humans are so much better at listening to what someone means, as opposed to what they say, that they find it hard to really consider the actual words they use. The actual words are all the computer system has to work with....

[rduerr]

OK, I finally have time to look into this. I was under the impression that all the changes made had come through the harmonization cluster but maybe not. Standby (but at least I spurred action on this pull request!).

…

On Apr 30, 2020, at 11:47 AM, Stephen Richard ***@***.***> wrote: Yes, I'd be interested in the hackathon on May 13, please send details; I have some experience with glaciers (two field seasons in Antarctica). To me the big problem is construction of logically coherent Aristotilean definitions. My experience over the years is that its difficult to get geoscientists to logically analyze their assertions in a way that's useful for automated computation. Humans are so much better at listening to what someone means, as opposed to what they say, that they find it hard to really consider the actual words they use. The actual words are all the computer system has to work with.... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALZFPFIDX3OAMDUQSU4LB3RPG2TZANCNFSM4MEZT5EA>.

[charlesvardeman]

@smrgeoinfo here is a link to the ESIP wiki for the Harmonization Cluster. The meetings are on the ESIP Calendar

[rduerr]

Ah, there’s the problem- we aren’t doing geology stuff we are doing Cryosphere stuff....

…

Sent from my iPhone

On May 1, 2020, at 5:03 PM, Stephen Richard ***@***.***> wrote: @smrgeoinfo commented on this pull request. In src/phenCryo.ttl: > ### http://sweetontology.net/phenCryo/Glacial sophcr:Glacial rdf:type owl:Class ; owl:equivalentClass sophcr:Glaciation ; - rdfs:label ***@***.*** . + rdfs:label ***@***.*** ; + skos:definition [ + rdfs:comment "An environmental process which involves glaciers or ice ***@***.*** ; Neuendorf, K.K.E., Mehl Jr, J.P., and Jackson, J.A., 2005, Glossary of Geology, Fifth Edition: Alexandria, VA, American Geological Institute, 779 pages. I assumed anyone doing geology related stuff would be familiar with the AGI Glossary. Sorry! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[smrgeoinfo]

Guess it depends on how you define geology.

One way or the other, the AGI glossary is a useful reference for Earth Science definitions and includes terms like glacial and glaciation with useful definitions, commonly more that one, reflecting the polysemous use of words in natural language and the science literature. If SWEET is intended to be an 'ontology' useful for precise semantic annotation, then each class in SWEET must map to one definition/usage, and there should be separate classes for the different meanings, with glosses on the refs:label to distinguish them for people. Opaque identifiers are an obvious benefit in this situation.... If that's not the intention, save trouble and point people to an existing glossary or glossaries for definitions, and call SWEET a glossary, not an ontology.

[rduerr]

OK, actually now that you have the full citation, I can say that the AGI glossary is one of the glossaries in the list I was using. Too bad most cryosphere folks have never heard of it (it isn't in the compilation of terms for WMO's Global Cryosphere Watch). I guess that is just the way different disciplines work! Before any of these are resolved, we need to decide whether:

1. Correcting all of the SWEET problems both hierarchical and axiomatic at once is really a requirement (since that would take years to release any updates),
2. Correcting all of the problems in a single SWEET file is required before an update can be made (which also would take a long time to get to the first pull request that passed),
3. Commenting on terms and axioms changes that are not addressed by a particular pull request is OK (i.e., its OK to review things that are not in scope of a pull request, even when there are other issues to address these);

[lewismc]

Hi @rduerr I kinda feel like the three issue that you bring up are important... but I would rather take those discussions outside of this pull request.
This pull request is quite large as it is... and it turns out that some of the definitions needs to be updated inline with some of the peer review from @smrgeoinfo.

Can someone please outline what the blockers are for this pull request? I'm not able to parse that out from above. Thank you

[rduerr]

Hi Lewis,

I agree with your assessment above and actually that is the conclusion from today's meeting. And we even have proposed answers to my three questions from above:

1. Correcting all of the SWEET problems both hierarchical and axiomatic at once is really a requirement (since that would take years to release any updates),

We agreed that semantic harmonization is NOT correcting all of the SWEET problems, just adding definitions and pointers to the relevant ENVO terms.

2. Correcting all of the problems in a single SWEET file is required before an update can be made (which also would take a long time to get to the first pull request that passed),

We agreed that this was also NOT the mission of the Harmonization work. These two decisions mean that @smrgeoinfo will be writing a series of issues about the non-Harmonization issues he brought up.

3. Commenting on terms and axioms changes that are not addressed by a particular pull request is OK (i.e., its OK to review things that are not in scope of a pull request, even when there are other issues to address these);

We didn't explicitly agree on this, but given the other two and the request to have @smrgeoinfo turn his comments into issues kind of says that we agreed that a review should only be commenting on changes made in the request and that other issues observed should be documented as issues.

That said there are a few outstanding items:

1. We didn't actually get to review all of the comments from @smrgeoinfo today (there are a few left) but plan to do that at the meeting next Wednesday.
2. There are come procedural/policy questions that need to be resolved and documented in the SWEET how-to's. The one I remember off the top of my head is how to deprecate a term; also how to update a term (given that the current term is not representative of its subclasses, etc.).

Any pointer's to existing relevant policy/procedures would be helpful here or if no one objects to the decisions made and content of the request, those could form the core of additional editorial guidance.

[smrgeoinfo]

I went through my comments, most are related to SWEET definitions, and don't directly affect harmonization with ENVO. Problems with the imported ENVO definitions have been fixed. Several issues with labels and definitions added in Esipfed/SWEET issue tracker. Broader problem with logical incoherence and lack of definitions in SWEET too big to solve in one PR!

[rduerr]

Looks good to me!

[lewismc]

+1

[lewismc]

Excellent work folks.