Clean up stale ECSO branches

[amoeba]

We have three long-standing and stale ECSO branches:

• ECSO8-add_non-carbon_measurements
• ArcticECSO
• run4

Having these around is problematic from my perspective because it's not clear where new work should go and it's not clear which is the authoritative copy of ECSO. We were hoping to have someone more familiar with the work resolve these issues but I think I can probably do a decent job.

I took a look through and found some things out:

• run4 appears to be lined up with master so we leave that branch is. Unfortunately, we released stuff in production that hardcodes that branch so I want to keep it there unless I can confidently update everything to a real release
• ArcticECSO has work from https://github.com/Olson87 that mainly adds a new OWL file d1-ECSO.owl. Browse that here. Does anyone think we need to drill into that branch or can we just delete it since it was never merged with another branch
• ECSO8-add_non-carbon_measurements can be cleanly merged because it just created an entirely new OWL file for its changes, ECSO8.owl. ECSO8.owl is what we've published in BioPortal and used in production services. See compare view for the branch

At this point I'm inclined to delete ArcticECSO, merge ECSO8-add_non-carbon_measurements into master and remove the existing ECSO4.owl file. I'm not sure it's worth going over it all with a fine-toothed comb.

[mobb]

Thanks for entering this issue, @amoeba ! I can't comment on the ArcticECSO or the run4 branches. TTBOMK, ECSO8.owl is the primary one, which should become the head. @stevenchong and @mpsaloha did most of the work on that, so may want to comment.

In general, is this activity part of a larger effort of ECSO-management? if so, great! we (EDI) has been looking at ECSO, putting test annotations into EML, and would like to know a bit more about management plans so we can plan future work. Thanks again.

[mpsaloha]

Hi Bryce et al. Thanks for looking into this Bryce. I also spent time looking into some of these issues, and where these overlap, we are in complete agreement. I believe you uploaded the copy of ECSO that is currently in Bioportal in late Sep 2019, and that version included *most* but not all of the additions from Steven (before he left the project), Margaret, and myself. I am currently reviewing and revising the "ECSO8-add_non-carbon_measurements" branch. That version has some additions from the Sep 2019 in BioPortal, and some small items that need fixing, but nothing critical, so the latest version in GitHub can be "merged" as you suggest. I'll consult with you about this when ready. The 'run4' was what, IIRC, Ben called the version of ECSO that was first uploaded to BioPortal and used for the initial Semantic Annotation Search Interface in DataONE years ago. I don't know how it was "hard-coded" into the infrastructure, and how that impacts our annotation interfaces, so thanks for digging into that. There may be some valuable pieces in Elizabeth's past work on d1-ecso, but our import strategy has changed significantly since then, so if there is some way to just archive that work-- so that it is not completely lost for reference, but is "out of the way", that would be ideal. Margaret-- as we have been collaborating on this all along, and you are deeply familiar with all aspects of ECSO, I would welcome your suggestions and further participation in how ECSO can be better managed for use by EDI and others. I currently have on my roster to specify how to deprecate terms, and how to note if term semantics have been altered. Establishing mechanisms for suggesting new terms, revisions or corrections to existing terms (as Corinna pointed out), getting expert review of additions, etc.-- are all areas that could benefit from greater attention and resolution. cheers, Mark

…

On Fri, Apr 9, 2021 at 8:00 AM mobb ***@***.***> wrote: Thanks for entering this issue, @amoeba <https://github.com/amoeba> ! I can't comment on the ArcticECSO or the run4 branches. TTBOMK, ECSO8.owl is the primary one, which should become the head. @stevenchong <https://github.com/stevenchong> and @mpsaloha <https://github.com/mpsaloha> did most of the work on that, so may want to comment. In general, is this activity part of a larger effort of ECSO-management? if so, great! we (EDI) has been looking at ECSO, putting test annotations into EML, and would like to know a bit more about management plans so we can plan future work. Thanks again. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHLL6LQGPEFW65WHIFY6STTH4JBFANCNFSM42RXLW6A> .

[stevenchong]

I'm glad to see that this repo is getting cleaned up! ECSO8.owl is the primary file. It has all of the updates I made and it should be merged into the master branch.

The ECSO4.owl file was used as the basis for the ECSO8 file, so it's probably worth archiving along with the d1-ecso file. I don't recall working with the ArcticECSO branch when I was adding/editing terms in ECSO.

[amoeba]

Thanks @mobb, @mpsaloha, @stevenchong .

@mobb: We're continuing to incorporate semantics into our various projects and so we'd like to get things tidier, yeah. We have no plans to abandon ECSO and are actually hoping to keep it under active management for the foreseeable future.

Sounds like we're in agreement here that we can merge in the ECSO8 file @mpsaloha is working on once he's done and I can tidy things up from there. Thanks all.

[mbjones]

@amoeba when you clean up, please don't delete branches unless you tag them beforehand so that we have a reference to the work at that point. Branches like run4 were used to flag the exact version we used for the earlier quantitative analysis runs, and we will benefit if it continues to be accessible for future inspection. tags seem appropriate if the branches are somehow annoying, but I would just leave the branch in place and tag it (ymmv).

[amoeba]

Thanks @mbjones, I'll probably leave that branch around since I know we've hardcoded it in various places. And adding a tag to go with it is a good idea.