Thanks for all the work & thought you've put into this. Specific responses
On Tue, 7 Apr 2009, Jennifer Deegan (nee Clark) wrote:
> I have a couple of questions for the working group this evening and I
> would like to send them out in advance to give people time to think them
> 1a) In OBOMerge if a term in the parent file has two relationships, and
> one gets deleted in the branch file and the other gets deleted in the
> output file, then the term is currently left with no relationships at
> all in the output file.
> This is because leaving a relationship in is not considered by OBO-Edit
> to be a concrete decision that would be in conflict with the other
> decision to delete the relationship. The rules of precedence are not
> invoked and the deletion is automatically accepted, regardless of which
> file has precedence.
> Is this what we want? It means that very occasionally OBOMerge might
> produce unexpected orphan children, though these would be very obvious
> to the user in the output file. Perhaps a warning message would be
> 1b)We have the same behavior with substitution tags. If a term had two
> replaced_by tags and one was deleted in the live file and the other was
> deleted in the branch file, then there would be none in the output file.
> What behavior do we want to see? Would it be best just to have a
> verification check for obsolete terms with no substitution tags?
I think we don't want obomerge to lose any tags that mention "live" terms.
Warnings would be useful for any tag differences between branch files,
but I'm inclined to err on the side of having obomerge keep tags when in
A verification check might well be useful in its own right (tho it's easy
enough to spot obsolete terms with no tags visually in the OTE), but I
don't think it would serve exactly the same purpose as obomerge warnings
-- we want to know what obomerge is doing with the tags.
(Also, there are a few obsolete terms in GO that don't have tags for very
good reasons -- 'calcium-o-sensing receptor' is the most humorous example.
A verification check won't distinguish those from any made tagless by
> 2) If a term mentioned in a substitution tag is subsumed in a merge my
> tests show that the substitution tag is not currently updated to show
> the new primary id and term name. Would we like this to happen
> automatically or should there just be a dialog box to say that
> substitution tags need updating?
I'm sure 'consider' tags can be updated automatically. I'm more inclined
to be cautious about 'replaced_by' tags ... but I guess if one term would
and the other wouldn't work for tags, we ought not merge them in the first
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> Geneontology-oboedit-working-group mailing list