geneontology-amigo Mailing List for [DEPRECATED] Gene Ontology

AmiGO bug tracker item #3606798, was opened at 2013-03-04 11:11
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3606798&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: AmiGO to QuiCKGO link 404 error

Initial Comment:
https://twitter.com/pjacock/statuses/308570495203287040

The image GETs still work, but the link to QuickGO through the image seem to be off now.

http://t.co/BGJPwa4OJj
http://t.co/s774E6VmZe

Contacted Tony.

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2013-03-05 00:34

Message:
Link updated; EBI will look at what happened to legacy URL in load
balancer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3606798&group_id=36855

AmiGO bug tracker item #3606798, was opened at 2013-03-04 11:11
Message generated for change (Tracker Item Submitted) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3606798&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: AmiGO to QuiCKGO link 404 error

Initial Comment:
https://twitter.com/pjacock/statuses/308570495203287040

The image GETs still work, but the link to QuickGO through the image seem to be off now.

http://t.co/BGJPwa4OJj
http://t.co/s774E6VmZe

Contacted Tony.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3606798&group_id=36855

AmiGO bug tracker item #3601199, was opened at 2013-01-16 16:33
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; bad warning

Initial Comment:
http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
then click on generic GO slim
see warning?
then click on new link
get an error 

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-29 12:21

Message:
Hard to justify the backport of the fix at this point, it doesn't look
easy.
Would revisit if we get more complaints, but for now pushing ahead with A2
seems like a better use of time.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-16 16:34

Message:
The production branch is AmiGO 1.8. Right after the release of 1.8, a new
branch (1.9) was started for development. This bug does not occur in 1.9,
I
very explicitly fixed it at some point. However, 1.9 has drifted a long
ways from 1.8, and any fix for this bug requires changes to the functional
code, which means that it should go through the test cycle, etc.
Essentially, any work this deep on 1.8 at this point would be the same
thing as getting 1.9 ready for release to production, which is a pretty
big
effort, especially considering how much of 1.9 switched to GOlr. Since
there aren't a lot of complaints about this, I feel like the effort could
better be spent on AmiGO 2 for the time being.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

AmiGO bug tracker item #3601199, was opened at 2013-01-16 16:33
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Pending
>Resolution: Postponed
Priority: 3
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; bad warning

Initial Comment:
http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
then click on generic GO slim
see warning?
then click on new link
get an error 

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-16 16:34

Message:
The production branch is AmiGO 1.8. Right after the release of 1.8, a new
branch (1.9) was started for development. This bug does not occur in 1.9,
I
very explicitly fixed it at some point. However, 1.9 has drifted a long
ways from 1.8, and any fix for this bug requires changes to the functional
code, which means that it should go through the test cycle, etc.
Essentially, any work this deep on 1.8 at this point would be the same
thing as getting 1.9 ready for release to production, which is a pretty
big
effort, especially considering how much of 1.9 switched to GOlr. Since
there aren't a lot of complaints about this, I feel like the effort could
better be spent on AmiGO 2 for the time being.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

AmiGO bug tracker item #3601199, was opened at 2013-01-16 16:33
Message generated for change (Tracker Item Submitted) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; bad warning

Initial Comment:
http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
then click on generic GO slim
see warning?
then click on new link
get an error 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601199&group_id=36855

AmiGO bug tracker item #3601198, was opened at 2013-01-16 16:28
Message generated for change (Settings changed) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 3
Private: Yes
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; warning ineffective

Initial Comment:
From Tanya:

http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
[15:06:10] Tanya Berardini: then click on generic GO slim
[15:06:29] Tanya Berardini: see warning?
[15:06:33] Tanya Berardini: then click on new link
[15:06:36] Tanya Berardini: I get an error 


----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-16 16:29

Message:
The production branch is AmiGO 1.8. Right after the release of 1.8, a new
branch (1.9) was started for development. This bug does not occur in 1.9, I
very explicitly fixed it at some point. However, 1.9 has drifted a long
ways from 1.8, and any fix for this bug requires changes to the functional
code, which means that it should go through the test cycle, etc.
Essentially, any work this deep on 1.8 at this point would be the same
thing as getting 1.9 ready for release to production, which is a pretty big
effort, especially considering how much of 1.9 switched to GOlr. Since
there aren't a lot of complaints about this, I feel like the effort could
better be spent on AmiGO 2 for the time being.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

AmiGO bug tracker item #3601198, was opened at 2013-01-16 16:28
Message generated for change (Settings changed) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Open
Resolution: Postponed
Priority: 3
>Private: Yes
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; warning ineffective

Initial Comment:
From Tanya:

http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
[15:06:10] Tanya Berardini: then click on generic GO slim
[15:06:29] Tanya Berardini: see warning?
[15:06:33] Tanya Berardini: then click on new link
[15:06:36] Tanya Berardini: I get an error 


----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-16 16:29

Message:
The production branch is AmiGO 1.8. Right after the release of 1.8, a new
branch (1.9) was started for development. This bug does not occur in 1.9, I
very explicitly fixed it at some point. However, 1.9 has drifted a long
ways from 1.8, and any fix for this bug requires changes to the functional
code, which means that it should go through the test cycle, etc.
Essentially, any work this deep on 1.8 at this point would be the same
thing as getting 1.9 ready for release to production, which is a pretty big
effort, especially considering how much of 1.9 switched to GOlr. Since
there aren't a lot of complaints about this, I feel like the effort could
better be spent on AmiGO 2 for the time being.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

AmiGO bug tracker item #3601198, was opened at 2013-01-16 16:28
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
>Status: Pending
>Resolution: Postponed
Priority: 3
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; warning ineffective

Initial Comment:
From Tanya:

http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
[15:06:10] Tanya Berardini: then click on generic GO slim
[15:06:29] Tanya Berardini: see warning?
[15:06:33] Tanya Berardini: then click on new link
[15:06:36] Tanya Berardini: I get an error 


----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2013-01-16 16:29

Message:
The production branch is AmiGO 1.8. Right after the release of 1.8, a new
branch (1.9) was started for development. This bug does not occur in 1.9, I
very explicitly fixed it at some point. However, 1.9 has drifted a long
ways from 1.8, and any fix for this bug requires changes to the functional
code, which means that it should go through the test cycle, etc.
Essentially, any work this deep on 1.8 at this point would be the same
thing as getting 1.9 ready for release to production, which is a pretty big
effort, especially considering how much of 1.9 switched to GOlr. Since
there aren't a lot of complaints about this, I feel like the effort could
better be spent on AmiGO 2 for the time being.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

AmiGO bug tracker item #3601198, was opened at 2013-01-16 16:28
Message generated for change (Tracker Item Submitted) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: slim/subset redirect links do not work; warning ineffective

Initial Comment:
From Tanya:

http://amigo.geneontology.org/cgi-bin/amigo/term_details?term=GO:0016887
[15:06:10] Tanya Berardini: then click on generic GO slim
[15:06:29] Tanya Berardini: see warning?
[15:06:33] Tanya Berardini: then click on new link
[15:06:36] Tanya Berardini: I get an error 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3601198&group_id=36855

AmiGO Requests item #1537372, was opened at 2006-08-09 06:31
Message generated for change (Settings changed) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=1537372&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.0
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Nobody/Anonymous (nobody)
Summary: order search results

Initial Comment:
At the moment, the search results are ordered alphabetically (I think?). It 
would be much better if they could be ordered according to how relevant 
they were, so that exact matches were listed first.

The example I have is searching for the gene "trim5" (gene product 
search). When you perform this search, the gene actually called trim5 is 
listed last, at the bottom of the page.

thanks,

Jane

----------------------------------------------------------------------

Comment By: Rama balakrishnan (ramab)
Date: 2006-08-10 12:43

Message:
Logged In: YES 
user_id=554736

Jane,

Good point again. One plan is to allow users to type in term
or gene product and on the results page we will display a 
summary of hits based on categories and if there is an exact
match the query will take the user directly to that page
skipping the summary page. This is just an idea. we need to
talk about this.

Rama


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=1537372&group_id=36855

AmiGO Requests item #1537372, was opened at 2006-08-09 06:31
Message generated for change (Comment added) made by cooperl09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=1537372&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.0
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Nobody/Anonymous (nobody)
Summary: order search results

Initial Comment:
At the moment, the search results are ordered alphabetically (I think?). It 
would be much better if they could be ordered according to how relevant 
they were, so that exact matches were listed first.

The example I have is searching for the gene "trim5" (gene product 
search). When you perform this search, the gene actually called trim5 is 
listed last, at the bottom of the page.

thanks,

Jane

----------------------------------------------------------------------

Comment By: Laurel Cooper (cooperl09)
Date: 2012-11-14 16:27

Message:
This would be a great feature and the subject was recently brought up in a
Plant Ontology manuscript review.  It would be great to add it to the list
of features for 2.0.
Thanks!

----------------------------------------------------------------------

Comment By: Rama balakrishnan (ramab)
Date: 2006-08-10 12:43

Message:
Logged In: YES 
user_id=554736

Jane,

Good point again. One plan is to allow users to type in term
or gene product and on the results page we will display a 
summary of hits based on categories and if there is an exact
match the query will take the user directly to that page
skipping the summary page. This is just an idea. we need to
talk about this.

Rama


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=1537372&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: Firefox
>Status: Closed
Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-09 15:14

Message:
Text correction committed to repo; will update at next bugfix.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-10 02:53

Message:
Okay, that'll do - thanks Seth!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Settings changed) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: AmiGO 1.8
Group: Firefox
>Status: Open
Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-10 02:53

Message:
Okay, that'll do - thanks Seth!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3553779, was opened at 2012-08-02 14:34
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: All
>Status: Pending
>Resolution: Postponed
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: term enrichment has reached an undefined state

Initial Comment:
Reported by through lists:

Possibly due to a bug in the system, this term enrichment has reached an undefined state (with k=41, n=124, M=5213, N=5291). Please report this message, as well as your inputs, to the GO Helpdesk. Our apologies for the inconvenience at /data/share/goweb/www-data/html/go-dev/go-db-perl/GO/AppHandles/AppHandleSqlImpl.pm line 1718.

On input:

[PomBase]

SPAC1F5.10
SPAC1751.02c
SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC6F12.07
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC6F6.07c
SPAC24C9.16c
SPAC26A3.14c
SPAC27D7.08c
SPAC30C2.05
SPAC19B12.05c
SPAC890.07c
SPAC140.03
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC19B12.09
SPAC1952.04c
SPAC29A4.14c
SPAC3G6.01
SPBC839.17c
SPBC18H10.04c
SPBC1711.03
SPBC15C4.01c
SPBC16H5.13
SPBC19G7.17
SPBC3E7.07c
SPBP4H10.08
SPBC2G2.03c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC354.07c
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC13G1.12
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09
SPCC1442.10c
SPCC830.10
SPCC4G3.02
SPCC1672.10
SPCC622.14
SPCC126.11c
SPCP1E11.02
SPAC1D4.02c
SPAC22G7.09c
SPAC167.04
SPAC664.08c
SPAC823.14
SPAC3G9.17
SPAC1B1.04c
SPAC16.02c
SPAC458.06
SPAC19B12.06c
SPAC227.07c
SPAC821.06
SPAC6F6.15
SPAC2F3.15
SPAC23D3.16
SPAC17C9.08
SPAC11H11.03c
SPAC1B3.14
SPBPB8B6.04c
SPBC713.05
SPBC19G7.03c
SPBC4C3.10c
SPBC25H2.03
SPBC3B9.08c
SPBC1709.02c
SPBC1709.14
SPBC23G7.16
SPBC19C7.10
SPBC887.06c
SPBC543.06c
SPBC1539.08
SPCC320.11c
SPCC1322.16
SPCC777.10c
SPCC663.17
SPCC663.18
SPCC1840.04
SPAC22A12.08c
SPAC23H4.04
SPAC8E11.04c
SPAC2C4.09
SPAC1639.02c
SPAC6F12.08c
SPAC8C9.05
SPBC36.05c
SPBC28F2.12
SPBC16E9.15
SPBC1A4.08c
SPBC336.14c
SPBC25H2.16c
SPBC11C11.01
SPBP8B7.08c
SPCC18B5.10c
SPCC23B6.01c
SPAC56F8.05c
SPAC22A12.09c
SPAC3G9.13c
SPAC17A2.08c
SPAC15A10.15
SPAC29E6.01
SPAC1782.07
SPAC630.11
SPBC725.08
SPBC20F10.09
SPBC3B9.10
SPBC409.03
SPCC1494.02c
SPCC1183.05c
SPCC1393.09c
SPCC825.05c
SPCC4E9.01c
SPAC17G8.14c
SPAC637.05c
SPAC31A2.02


----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-07 11:23

Message:
The origin of the issue seems to be when the dbxref identifiers pombase and
PomBase get confused. This is a data issue and is being worked on upstream.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 17:03

Message:
Apparently minimal subset (all combinations not tried):

SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC26A3.14c
SPAC27D7.08c
SPAC19B12.05c
SPAC890.07c
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC3G6.01
SPBC839.17c
SPBC1711.03
SPBC15C4.01c
SPBC3E7.07c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09


----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 15:12

Message:
Failure occurs at ontology roots and certain subsets succeed.
Find minimal failing set.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 14:48

Message:
Duplicated locally on go_latest_lite.
So far, values of N and n and confirmed to be correct; still need to check
for a higher k and/or a lower M.
Need to check consistency--triggered by (N - M) < (n - k) not being met,
but no such qualms in octave.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

AmiGO bug tracker item #3553779, was opened at 2012-08-02 14:34
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: All
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: term enrichment has reached an undefined state

Initial Comment:
Reported by through lists:

Possibly due to a bug in the system, this term enrichment has reached an undefined state (with k=41, n=124, M=5213, N=5291). Please report this message, as well as your inputs, to the GO Helpdesk. Our apologies for the inconvenience at /data/share/goweb/www-data/html/go-dev/go-db-perl/GO/AppHandles/AppHandleSqlImpl.pm line 1718.

On input:

[PomBase]

SPAC1F5.10
SPAC1751.02c
SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC6F12.07
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC6F6.07c
SPAC24C9.16c
SPAC26A3.14c
SPAC27D7.08c
SPAC30C2.05
SPAC19B12.05c
SPAC890.07c
SPAC140.03
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC19B12.09
SPAC1952.04c
SPAC29A4.14c
SPAC3G6.01
SPBC839.17c
SPBC18H10.04c
SPBC1711.03
SPBC15C4.01c
SPBC16H5.13
SPBC19G7.17
SPBC3E7.07c
SPBP4H10.08
SPBC2G2.03c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC354.07c
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC13G1.12
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09
SPCC1442.10c
SPCC830.10
SPCC4G3.02
SPCC1672.10
SPCC622.14
SPCC126.11c
SPCP1E11.02
SPAC1D4.02c
SPAC22G7.09c
SPAC167.04
SPAC664.08c
SPAC823.14
SPAC3G9.17
SPAC1B1.04c
SPAC16.02c
SPAC458.06
SPAC19B12.06c
SPAC227.07c
SPAC821.06
SPAC6F6.15
SPAC2F3.15
SPAC23D3.16
SPAC17C9.08
SPAC11H11.03c
SPAC1B3.14
SPBPB8B6.04c
SPBC713.05
SPBC19G7.03c
SPBC4C3.10c
SPBC25H2.03
SPBC3B9.08c
SPBC1709.02c
SPBC1709.14
SPBC23G7.16
SPBC19C7.10
SPBC887.06c
SPBC543.06c
SPBC1539.08
SPCC320.11c
SPCC1322.16
SPCC777.10c
SPCC663.17
SPCC663.18
SPCC1840.04
SPAC22A12.08c
SPAC23H4.04
SPAC8E11.04c
SPAC2C4.09
SPAC1639.02c
SPAC6F12.08c
SPAC8C9.05
SPBC36.05c
SPBC28F2.12
SPBC16E9.15
SPBC1A4.08c
SPBC336.14c
SPBC25H2.16c
SPBC11C11.01
SPBP8B7.08c
SPCC18B5.10c
SPCC23B6.01c
SPAC56F8.05c
SPAC22A12.09c
SPAC3G9.13c
SPAC17A2.08c
SPAC15A10.15
SPAC29E6.01
SPAC1782.07
SPAC630.11
SPBC725.08
SPBC20F10.09
SPBC3B9.10
SPBC409.03
SPCC1494.02c
SPCC1183.05c
SPCC1393.09c
SPCC825.05c
SPCC4E9.01c
SPAC17G8.14c
SPAC637.05c
SPAC31A2.02


----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 17:03

Message:
Apparently minimal subset (all combinations not tried):

SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC26A3.14c
SPAC27D7.08c
SPAC19B12.05c
SPAC890.07c
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC3G6.01
SPBC839.17c
SPBC1711.03
SPBC15C4.01c
SPBC3E7.07c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09


----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 15:12

Message:
Failure occurs at ontology roots and certain subsets succeed.
Find minimal failing set.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 14:48

Message:
Duplicated locally on go_latest_lite.
So far, values of N and n and confirmed to be correct; still need to check
for a higher k and/or a lower M.
Need to check consistency--triggered by (N - M) < (n - k) not being met,
but no such qualms in octave.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

AmiGO bug tracker item #3553779, was opened at 2012-08-02 14:34
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: All
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: term enrichment has reached an undefined state

Initial Comment:
Reported by through lists:

Possibly due to a bug in the system, this term enrichment has reached an undefined state (with k=41, n=124, M=5213, N=5291). Please report this message, as well as your inputs, to the GO Helpdesk. Our apologies for the inconvenience at /data/share/goweb/www-data/html/go-dev/go-db-perl/GO/AppHandles/AppHandleSqlImpl.pm line 1718.

On input:

[PomBase]

SPAC1F5.10
SPAC1751.02c
SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC6F12.07
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC6F6.07c
SPAC24C9.16c
SPAC26A3.14c
SPAC27D7.08c
SPAC30C2.05
SPAC19B12.05c
SPAC890.07c
SPAC140.03
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC19B12.09
SPAC1952.04c
SPAC29A4.14c
SPAC3G6.01
SPBC839.17c
SPBC18H10.04c
SPBC1711.03
SPBC15C4.01c
SPBC16H5.13
SPBC19G7.17
SPBC3E7.07c
SPBP4H10.08
SPBC2G2.03c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC354.07c
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC13G1.12
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09
SPCC1442.10c
SPCC830.10
SPCC4G3.02
SPCC1672.10
SPCC622.14
SPCC126.11c
SPCP1E11.02
SPAC1D4.02c
SPAC22G7.09c
SPAC167.04
SPAC664.08c
SPAC823.14
SPAC3G9.17
SPAC1B1.04c
SPAC16.02c
SPAC458.06
SPAC19B12.06c
SPAC227.07c
SPAC821.06
SPAC6F6.15
SPAC2F3.15
SPAC23D3.16
SPAC17C9.08
SPAC11H11.03c
SPAC1B3.14
SPBPB8B6.04c
SPBC713.05
SPBC19G7.03c
SPBC4C3.10c
SPBC25H2.03
SPBC3B9.08c
SPBC1709.02c
SPBC1709.14
SPBC23G7.16
SPBC19C7.10
SPBC887.06c
SPBC543.06c
SPBC1539.08
SPCC320.11c
SPCC1322.16
SPCC777.10c
SPCC663.17
SPCC663.18
SPCC1840.04
SPAC22A12.08c
SPAC23H4.04
SPAC8E11.04c
SPAC2C4.09
SPAC1639.02c
SPAC6F12.08c
SPAC8C9.05
SPBC36.05c
SPBC28F2.12
SPBC16E9.15
SPBC1A4.08c
SPBC336.14c
SPBC25H2.16c
SPBC11C11.01
SPBP8B7.08c
SPCC18B5.10c
SPCC23B6.01c
SPAC56F8.05c
SPAC22A12.09c
SPAC3G9.13c
SPAC17A2.08c
SPAC15A10.15
SPAC29E6.01
SPAC1782.07
SPAC630.11
SPBC725.08
SPBC20F10.09
SPBC3B9.10
SPBC409.03
SPCC1494.02c
SPCC1183.05c
SPCC1393.09c
SPCC825.05c
SPCC4E9.01c
SPAC17G8.14c
SPAC637.05c
SPAC31A2.02


----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 15:12

Message:
Failure occurs at ontology roots and certain subsets succeed.
Find minimal failing set.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 14:48

Message:
Duplicated locally on go_latest_lite.
So far, values of N and n and confirmed to be correct; still need to check
for a higher k and/or a lower M.
Need to check consistency--triggered by (N - M) < (n - k) not being met,
but no such qualms in octave.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

AmiGO bug tracker item #3553779, was opened at 2012-08-02 14:34
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: All
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: term enrichment has reached an undefined state

Initial Comment:
Reported by through lists:

Possibly due to a bug in the system, this term enrichment has reached an undefined state (with k=41, n=124, M=5213, N=5291). Please report this message, as well as your inputs, to the GO Helpdesk. Our apologies for the inconvenience at /data/share/goweb/www-data/html/go-dev/go-db-perl/GO/AppHandles/AppHandleSqlImpl.pm line 1718.

On input:

[PomBase]

SPAC1F5.10
SPAC1751.02c
SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC6F12.07
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC6F6.07c
SPAC24C9.16c
SPAC26A3.14c
SPAC27D7.08c
SPAC30C2.05
SPAC19B12.05c
SPAC890.07c
SPAC140.03
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC19B12.09
SPAC1952.04c
SPAC29A4.14c
SPAC3G6.01
SPBC839.17c
SPBC18H10.04c
SPBC1711.03
SPBC15C4.01c
SPBC16H5.13
SPBC19G7.17
SPBC3E7.07c
SPBP4H10.08
SPBC2G2.03c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC354.07c
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC13G1.12
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09
SPCC1442.10c
SPCC830.10
SPCC4G3.02
SPCC1672.10
SPCC622.14
SPCC126.11c
SPCP1E11.02
SPAC1D4.02c
SPAC22G7.09c
SPAC167.04
SPAC664.08c
SPAC823.14
SPAC3G9.17
SPAC1B1.04c
SPAC16.02c
SPAC458.06
SPAC19B12.06c
SPAC227.07c
SPAC821.06
SPAC6F6.15
SPAC2F3.15
SPAC23D3.16
SPAC17C9.08
SPAC11H11.03c
SPAC1B3.14
SPBPB8B6.04c
SPBC713.05
SPBC19G7.03c
SPBC4C3.10c
SPBC25H2.03
SPBC3B9.08c
SPBC1709.02c
SPBC1709.14
SPBC23G7.16
SPBC19C7.10
SPBC887.06c
SPBC543.06c
SPBC1539.08
SPCC320.11c
SPCC1322.16
SPCC777.10c
SPCC663.17
SPCC663.18
SPCC1840.04
SPAC22A12.08c
SPAC23H4.04
SPAC8E11.04c
SPAC2C4.09
SPAC1639.02c
SPAC6F12.08c
SPAC8C9.05
SPBC36.05c
SPBC28F2.12
SPBC16E9.15
SPBC1A4.08c
SPBC336.14c
SPBC25H2.16c
SPBC11C11.01
SPBP8B7.08c
SPCC18B5.10c
SPCC23B6.01c
SPAC56F8.05c
SPAC22A12.09c
SPAC3G9.13c
SPAC17A2.08c
SPAC15A10.15
SPAC29E6.01
SPAC1782.07
SPAC630.11
SPBC725.08
SPBC20F10.09
SPBC3B9.10
SPBC409.03
SPCC1494.02c
SPCC1183.05c
SPCC1393.09c
SPCC825.05c
SPCC4E9.01c
SPAC17G8.14c
SPAC637.05c
SPAC31A2.02


----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-08-02 14:48

Message:
Duplicated locally on go_latest_lite.
So far, values of N and n and confirmed to be correct; still need to check
for a higher k and/or a lower M.
Need to check consistency--triggered by (N - M) < (n - k) not being met,
but no such qualms in octave.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

AmiGO bug tracker item #3553779, was opened at 2012-08-02 14:34
Message generated for change (Tracker Item Submitted) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AmiGO 1.8
Group: All
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Carbon (sjcarbon)
Assigned to: Seth Carbon (sjcarbon)
Summary: term enrichment has reached an undefined state

Initial Comment:
Reported by through lists:

Possibly due to a bug in the system, this term enrichment has reached an undefined state (with k=41, n=124, M=5213, N=5291). Please report this message, as well as your inputs, to the GO Helpdesk. Our apologies for the inconvenience at /data/share/goweb/www-data/html/go-dev/go-db-perl/GO/AppHandles/AppHandleSqlImpl.pm line 1718.

On input:

[PomBase]

SPAC1F5.10
SPAC1751.02c
SPAC22F3.05c
SPAC1687.03c
SPAC1687.21
SPAC6F12.07
SPAC824.09c
SPAC1002.07c
SPAC9G1.05
SPAC6F6.07c
SPAC24C9.16c
SPAC26A3.14c
SPAC27D7.08c
SPAC30C2.05
SPAC19B12.05c
SPAC890.07c
SPAC140.03
SPAC26A3.06
SPAC323.05c
SPAC12B10.13
SPAC19B12.09
SPAC1952.04c
SPAC29A4.14c
SPAC3G6.01
SPBC839.17c
SPBC18H10.04c
SPBC1711.03
SPBC15C4.01c
SPBC16H5.13
SPBC19G7.17
SPBC3E7.07c
SPBP4H10.08
SPBC2G2.03c
SPBC3B9.13c
SPBC1347.07
SPBC16C6.08c
SPBC354.01
SPBC354.07c
SPBC713.02c
SPBC646.11
SPBC337.14
SPBC1734.08
SPBC13G1.12
SPBC31F10.13c
SPCC1183.03c
SPCC1322.09
SPCC1442.10c
SPCC830.10
SPCC4G3.02
SPCC1672.10
SPCC622.14
SPCC126.11c
SPCP1E11.02
SPAC1D4.02c
SPAC22G7.09c
SPAC167.04
SPAC664.08c
SPAC823.14
SPAC3G9.17
SPAC1B1.04c
SPAC16.02c
SPAC458.06
SPAC19B12.06c
SPAC227.07c
SPAC821.06
SPAC6F6.15
SPAC2F3.15
SPAC23D3.16
SPAC17C9.08
SPAC11H11.03c
SPAC1B3.14
SPBPB8B6.04c
SPBC713.05
SPBC19G7.03c
SPBC4C3.10c
SPBC25H2.03
SPBC3B9.08c
SPBC1709.02c
SPBC1709.14
SPBC23G7.16
SPBC19C7.10
SPBC887.06c
SPBC543.06c
SPBC1539.08
SPCC320.11c
SPCC1322.16
SPCC777.10c
SPCC663.17
SPCC663.18
SPCC1840.04
SPAC22A12.08c
SPAC23H4.04
SPAC8E11.04c
SPAC2C4.09
SPAC1639.02c
SPAC6F12.08c
SPAC8C9.05
SPBC36.05c
SPBC28F2.12
SPBC16E9.15
SPBC1A4.08c
SPBC336.14c
SPBC25H2.16c
SPBC11C11.01
SPBP8B7.08c
SPCC18B5.10c
SPCC23B6.01c
SPAC56F8.05c
SPAC22A12.09c
SPAC3G9.13c
SPAC17A2.08c
SPAC15A10.15
SPAC29E6.01
SPAC1782.07
SPAC630.11
SPBC725.08
SPBC20F10.09
SPBC3B9.10
SPBC409.03
SPCC1494.02c
SPCC1183.05c
SPCC1393.09c
SPCC825.05c
SPCC4E9.01c
SPAC17G8.14c
SPAC637.05c
SPAC31A2.02


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3553779&group_id=36855

AmiGO Requests item #3552711, was opened at 2012-07-31 10:40
Message generated for change (Tracker Item Submitted) made by masciam
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=3552711&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: anna maria masci (masciam)
Assigned to: Nobody/Anonymous (nobody)
Summary: BCR receptor internalization

Initial Comment:
A receptor-mediated endocytosis process that results in the movement of a B cell  receptor from the plasma membrane to the inside of the cell.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=494390&aid=3552711&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Settings changed) made by jl242
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
>Status: Pending
Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-10 02:53

Message:
Okay, that'll do - thanks Seth!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Comment added) made by jl242
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
>Status: Open
Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

>Comment By: Jane Lomax (jl242)
Date: 2012-07-10 02:53

Message:
Okay, that'll do - thanks Seth!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Settings changed) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
Status: Pending
Resolution: Wont Fix
>Priority: 3
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-06 13:43

Message:
I've finally traced through the old code that runs the search and it is
wrong--it treats the wildcards as described in the instructions as literals
when searching. At some point in the past it may not have done so, but it
no longer works in the cases that I checked. Unfortunately, this code is
large, old, and undocumented, so it's probably more trouble than it's worth
to see if it can be fixed as I'm very likely to break something else
unintentionally in the process.

That said, as a quirk of the query parsing, it does seem that using a % as
the wildcard words just fine, so searching for rhea:% pulls the results you
expected. If you could play with the % as the only wildcard for a little,
I'll update the instructions (which are simply wrong right now).

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Comment added) made by sjcarbon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

>Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 12:17

Message:
Sorry I can't be more help with this right away. Between the possibly
misleading instructions and a little weirdness in the advanced search with
how it handles the different fields and and wildcards, I'll leave this open
until tomorrow when I'll trace through and double check what I think is
happening (that the wildcard will only work on "stringy" fields like
symbol, name, etc.). An update to the instructions might be appropriate
after that.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

AmiGO bug tracker item #3540089, was opened at 2012-07-04 02:38
Message generated for change (Comment added) made by jl242
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Firefox
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jane Lomax (jl242)
Assigned to: Seth Carbon (sjcarbon)
Summary: dbxref search doesn't work

Initial Comment:
I was trying to perform a search for dbxrefs that contain 'rhea' using the AmiGO advanced search. It doesn't return any results, although there are over 2000 dbxrefs of this type in the db.

Jane

----------------------------------------------------------------------

>Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:47

Message:
Ah, okay so it works for specific xrefs. I was trying to do a blanket
search for all general dbxrefs that contain 'RHEA:'. I tried the wildcard
search, and you're right it doesn't seem to work.

I've told the person I'm working with to just search the flat file directly
for now - GOOSE is probably overkill for what she needs. Unfortunately
QuickGO doesn't index term dbxrefs so she can't use that either!

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 05:18

Message:
Using the advanced search, with the search string (chosen randomly)
"rhea:11731" and using either "database cross-references" or "all" gives me
the correct GO term. If you are trying to do a blanket search for all term
dbxrefs that begin with "rhea", I don't believe that AmiGO is setup for
that (although the instructions look misleading on that point), but I'll
take a closer look at it tomorrow--that may be some functionality I don't
know about. Otherwise, I think GOOSE is probably the way to go here.

----------------------------------------------------------------------

Comment By: Jane Lomax (jl242)
Date: 2012-07-04 05:02

Message:
I'm talking about term dbxrefs, Seth. It's listed as one of the search
fields in the advanced search so I'd kinda expect to be able to search on
them.

----------------------------------------------------------------------

Comment By: Seth Carbon (sjcarbon)
Date: 2012-07-04 04:55

Message:
I'm not sure AmiGO does the kind of search you want here--just because it's
in the database doesn't necessarily mean that it's exposed in the AmiGO
displays, including the various searches. For example, if you expected them
as synonyms and they weren't showing up that would be a bug, but if they
were completely disconnected dbxrefs it wouldn't. What are you expecting?
Maybe this should be a GOOSE query instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=908269&aid=3540089&group_id=36855