NTR robot file of new transportation and medical infrastructure and other terms

[ddooley]

A Google sheet ENVO tab of NTR requests which has been edited and reviewed for a number of months [edit] will soon exist as a Robot pull request. The terms are motivated by text mining and tagging of Covid19 related paper content.

One question is the overlap of some OMSRE hospital/clinic facilities, raised in OMSRE issue mcwdsi/OMRSE#157 . If there is no OMRSE impact on that chunk of the terminology, then the pull request will have about 260 terms.

A second ENVO batch edit that should be included in this involves a bit of a reorganization or touchup to some existing related ENVO terms, detailed in rows 271 - 292 of above google sheet.

[wdduncan]

The definition for polytunnel should have a 'which' in it; i.e., "A tunnel which ..."

Why is clinic in red? Also the definition for clinic references "A facility ...", but the parent class is building. I also see the word 'facility' used for a number of other classes (e.g., child care facility). Is facility being used as a synonym to building?

see mcwdsi/OMRSE#157 for comments about functions/roles and poly-hierachy.

[ddooley]

Polytunnel fixed.

Indeed I see some cleaning up is needed there about facility vs. building. It should be a facility I think because this allows for clinics that are not in buildings per se. like mobile clinics.

Clinic is in red as a highlight for the issue I should have commented [edit: I see I did leave a comment there] - a discussion of how general a term it should be. As a human construction, does it have broader semantics than just a human medical domain? I'm guessing animal health can be included too, e.g. veterinary clinic.

Also I'm moving towards labelling most hospital units to include facility at end.

[kaiiam]

Hey @ddooley thanks for all the work here hopefully between the ENVO-Robot-template-and-merge-workflow PR instructions as well as @pbuttigieg's guide to Creating-good-definitions you should be able to proceed. Although I haven't had a chance to deeply review it, at first pass it's looking decent to me but there are always things to fix and I'm not the important reviewer here.

A quick note some of your def cross references are just ENVO,

It'd be better to add links to citations for these.

[ddooley]

So where it says ENVO basically we didn't draw on any other resource for the definition. Often that was because there seemed to be no easy reference to a definition for the term or phrase alone, e.g. "subway train". Should I just leave that field empty then?

[kaiiam]

I would say briefly try to find something like a Wikipedia reference, these are definitional database cross references not claiming to be exact definition sources but if there is no such obvious reference then I would say just just leave the field empty.

[cmungall]

I merged the PR but I am only now noticing a lot of problems with it, some noted on the PR

@ddooley will you have time to go through and fix a lot of these

for example, why do we have ragged shadow hierarchies?

these are causing immediate issues (dupe of syn - I will fix this)

but I think these shadows are a really bad idea, massively confusing to users, inconsistently populated. only an ontologist would draw the distinction between these concepts.

[ddooley]

Ah - so we were unaware of Jagadish adding the intensive care unit / neonatal intensive care unit terms, so this is a collision of two requests for the same term showing up in ENVO draft. I guess his was a smaller request so got approved well before our big chunk of terms. What would you like for deprecation/replacement? There is a "facility" pattern here meant to emphasize the material parts not the organizational parts, which OMRSE has more in its domain.

[cmungall]

oh I see that's interesting so coincidentally we had two PRs from two different people both adding roughly similar content, fun!

The fact that we ended up with two parallel hierarchies rather than in the same place is an interesting N-of-2 annotation consistency experiment. This suggests that we have too many ontological ways of slicing and dicing things

and also that we need to merge PRs faster!

tho it's not clear why they both showed up in your PR - maybe there was a merge that didn't rebase/no-ff?

anyway I think "building part" should be structural parts, functional units like NICU should go in facility. Agreed @pbuttigieg ?

[kaiiam]

Although I agree I'd be nice to merge PRs faster I think we should try to be careful about checking conflicts prior to merging. I understand if the first batch had been merged prior to the second being added the second could have more easily found existing terms similar to those in the 2nd request.

Perhaps we could add something like automated synonym checks to the build routine? ATM I believe it'll give warning about duplicate EQ classes, labels and defs but what about duplicate synonyms? Could we implement something like a cosine or hamming distance function for labels to identify potential duplicates?