[OBO-Edit Working Group] Deleting cross-product genus [was Re: Cross Product editor: synonym converted to term name]

[Nomi H. <nlh...@lb...>]

Yes, this is already logged as a bug report (though really it's more of a feature request).
http://sourceforge.net/tracker/index.php?func=detail&aid=3303595&group_id=36855&atid=418257 "deleting genus relationship in cross product tab"
Should we bump up the priority?
	Nomi

On Dec 1, 2011, at 3:50 AM, Jane Lomax wrote:

> While you're working on the cross-product interface Nomi, I don't know 
> whether it's a bug really but once you've added a genus and differentia 
> in the the text editor tab you can't delete it again. You can delete the 
> differentia but not the genus. I ended up doing a hand edit when I was 
> trying to delete one for real the other day, although I realise now I 
> could have just used the parent editor.
> 
> thanks,
> 
> Jane
> 
> 
> On 01/12/2011 02:32, Chris Mungall wrote:
>> On Nov 30, 2011, at 10:09 AM, Nomi Harris wrote:
>> 
>>> I have done a bunch more testing on this, and have realized that what seemed like a bug (selected genus getting replaced by a different one) is in fact not really a bug, though it's behavior that you wouldn't necessarily expect.
>>> 
>>> Here's the example I gave of the misbehavior:
>>>> It now looks like this, right before I click Commit:
>>> <Screen shot 2011-11-17 at 2.01.58 PM.png>
>>>> 
>>>> 
>>>> As soon as I commit, both the genus and the differentia change to other terms (terms that weren't even in the pulldown lists!)
>>> <Screen shot 2011-11-17 at 2.02.11 PM.png>
>>>> 
>>> What I discovered is that  (1R,4R)-1,7,7-trimethylbicyclo[2.2.1]heptan-2-one is in fact a synonym of ( R )-camphor--it doesn't exist as an independent primary term name. The autocomplete dropdown offers you synonyms as well as term names, but if you choose a synonym, it silently converts that to the primary term name, since there isn't a term with the name you selected.
>>> 
>>> I don't know if that's desirable behavior, but it's not actually a bug--the changed genus is not just random.
>> Ah, ok! That's good to know.
>> 
>> The camphor catabolism ontology is a terrible one for testing things like this. It's only in the test directory as it was used to test a reasoner bug from a number of years ago.
>> 
>> caro is a better small ontology for testing
>> 
>> although of course it could somehow only be manifesting with certain ontologies, either due to size or something in the ontology. I think fly anatomy xp and go are good ones to do additional tests with
>> 
>>> I was unable to find any other examples where the cross-product editor changed the chosen genus to something other than the term name for which a synonym had been selected. If there are other cases where it misbehaves, I need examples.
>> I've been testing on fly_anatomy_XP and haven't been able to replicate, but I certainly haven't exhausted all possibilities.
>> 
>> 
>>> I did manage to get it into a state at one point where I couldn't remove the selected-for-me genus--if I tried to erase it or type something different, it quickly put the old one back over whatever I typed. That is a bug, but I haven't yet gotten it to happen repeatably. It is possible that this bug accounts for some of the cases where the saved genus is different from what you thought you typed, if it did that reversion and you didn't notice before you clicked Commit.
>>> 
>>> Please send me some repeatable examples of cross-product editor misbehavior!
>> I think the only way to track this down might be for someone to record themselves in their OE session so that we can catch the bug and then try and replicate it exactly.
>> 
>> Of course I can understand the reluctance to do this if there is no trust in the xp editing component.
>> 
>> One thing which I always do is have a parent editor panel open somewhere constantly visible, that way I can see the xp I added more easily. Although this is a little disconcerting in autocommit mode though, as you only see your changes when you switch focus
>> 
>>> 	Nomi
>>> 
>>> 
>>> On Nov 17, 2011, at 2:42 PM, Nomi Harris wrote:
>>> 
>>>> On Nov 16, 2011, at 7:46 PM, Alexander Diehl wrote:
>>>> 
>>>>> 4)  I also made a few cross products today -- for one the wrong genus
>>>>> term got saved, for another no genus term got saved.
>>>> I did some more investigation on this. The bad news is that cross products don't seem to get saved reliably. The good news is that:
>>>> 1. I can get this problem to happen repeatably (in current and past versions)
>>>> 2. The behavior was the same (or even worse) all the way back to v2.00.
>>>> 
>>>> I'm not sure how hard it would be to fix this bug. It was reported as far back as 2008:
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2126697&group_id=36855&atid=418257
>>>> "Sometimes it loses what I enter in the xp tab altogether, sometimes it keeps everything except the last differentia altogether."
>>>> and
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2008169&group_id=36855&atid=418257
>>>> "I can' t create any xps in any gui modality (more precise, I can create them, but they are lost as soon as I switch to anoter class, even when committing these class modifications or save the whole file: I create a xps, and then commit, change to another class, and when I go back again to the xps I created, all the newly specified genus and differrentiae are lost."
>>>> 
>>>> Amina closed these bugs as Fixed on 2008-10-06, but I suspect she didn't try going to another term and then going back to the one you'd edited to see the problem (see below).
>>>> 
>>>> 
>>>> Here are some more detailed notes about how I observed the bug, and its behavior in different versions.
>>>> 
>>>> First, to see the bug, you don't even have to use a fancy ontology like CL.obo--the camphor_catabolism sample ontology in test_resources shows it.
>>>> 
>>>> 1. After loading camphor_catabolism.obo, select a genus from the pulldown list (but not the first one on the list). (As an aside, the choices in this pulldown menu seem to vary inexplicably--even if you select another term and then come back to the same one, the pulldown list changes.)<Screen shot 2011-11-17 at 2.01.16 PM.png>
>>>> 
>>>> Then select a discriminating relation and one of the differentiae (not the first one in the list):
>>>> <Screen shot 2011-11-17 at 2.01.44 PM.png>
>>>> 
>>>> It now looks like this, right before I click Commit:
>>>> <Screen shot 2011-11-17 at 2.01.58 PM.png>
>>>> 
>>>> As soon as I commit, both the genus and the differentia change to other terms (terms that weren't even in the pulldown lists!)
>>>> <Screen shot 2011-11-17 at 2.02.11 PM.png>
>>>> 
>>>> When I tested earlier versions, I discovered that this is how versions from 2.1-b9 up to the present behave.
>>>> 
>>>> Versions 2.1-b6 and 2.1-b7 had worse versions of this problem--everything looked fine when you clicked Commit, but if you visited another term (by selecting it in the OTE) and then returned to the term for which you had created a cross-product, you would find that it was not the one you thought you'd saved.
>>>> 2.1-b6: looks ok when you commit, but if you select another term (in the OTE) and then return to the first one, the saved cross-product is GONE.
>>>> 2.1-b7: looks ok when you commit, but if you select another term (in the OTE) and then return to the first term, the differentia you selected has changed to a different one.
>>>> 
>>>> 2.00 behaved like the current version: the change in the cross products happens when you click Commit, not secretly behind the scenes.
>>>> 
>>>> I also noticed that some versions (e.g., 2.1-b6) offer more choices of discriminating relations. I don't know whether that's good or bad. In most versions, when you try to create a cross-product for a camphor term, the only relations it shows in the pulldown list are results_in_division_of and part_of. In 2.1-b6, you get a longer list that includes is_a, union_of, etc.
>>>> 
>>>> 
>>>> It seems to me that if this bug has existed since before 2008 and hasn't been mentioned again until this week, it does not qualify as a show-stopper. I am adding this information to the bug report, and will tackle this bug after the 2.1 release, as time permits.
>>>> 
>>>> 	Nomi