Add and maintain UUID (or similar identifying element) to ontologies built in pipeline

[kltm]

Breifly discussed with @balhoff on the pipeline gitter, but would love feedback from @cmungall , @goodb , or others.

@balhoff , you mentioned a ROBOT ticket; would you mind adding that to this one for reference?

What I'm proposing here is that something respects an optional environmental variable along the way (i.e. something like GENE_ONTOLOGY_ID where robot uses it directly or the go-ontology Makefile then passes it to robot) and adds it to the internal ontology metadata. When ontologies are merged, etc., by our tools, this metadata is passed through, allowing us to tie any materialized standalone ontology, release, snapshot, or experimental, back to its source. This would make debugging some of the things that happen within our pipeline simpler, allowing us to eliminate certain types of errors more quickly.

To clarify a little, this is not just referencing version, as we do not have versions for a lot of the ontologies that are used. a UUID would let us know it one ontology was derived from another. A build and release number (w/ or w/o a UUID) would let us trace things back more specifically. For example, snapshot_2019-05-30_1559769396 (release type, date, epoch time).

[balhoff]

I think it would be a great help if our various merge steps preserved a record of which ontologies (and their versions) were merged. This is part of the features described in ontodev/robot#6.

I think the UUID annotation would have to only be inserted into the main go-edit at the beginning of the build, and then could be checked everywhere that ontology was transformed into something else.

[kltm]

@balhoff Following on to that, my understanding it that for many ontologies, in particular our snapshot ones, there is not any real viable version available. Part of this, in my mind, would help us work around that. Does that make sense?

[kltm]

Okay, from a discussion on the software call today, if we can make sure to use only merged internal ontologies within the pipeline, the additional version info (date) that @balhoff mentions above should be sufficient to do the tracing that I'm hoping for. This is closed in favor of ontodev/robot#6 and #27