Re: [GMOD-devel] Loader: Name tag loaded into synonym table

[Scott C. <cai...@gm...>]

Eric,

I don't really think it makes it more difficult; here's why: one
something has be assigned as a name to a feature, it will forever be a
synonym of that feature.  The only question for a given entry in the
synonym table is, what kind of synonym is this?  If it is the standard
name (symbol for flybase), then it would be the primary_synonym.
Otherwise it would just be of type synonym (I'm still thinking about
what to do in the target case; ignore it for now).

Now, when you change the name of a feature, you have to find the old
name in the synonym table and update the type_id and either leaving
feature_synonym alone or updating f_s.is_current (I wasn't really aware
of that column until Pinglei mentioned it), and then create a new entry
for the new name in the synonym table for the new name and an entry in
feature_synonym for it.

OK, so yes, it is more difficult than just updating feature.name, but it
doesn't strike me that this is a onerous task.

Now, I did just think of a potential problem.  Say you have two
features, a and b.  At some point, you realize that the names of these
features is wrong and they need to be reversed, so now you have b (the
old a with a synonym of a) and a (the old b with a synonym of b).  Can
this be accurately represented in the database?  I don't think so, as
both synonyms with have a primary_synonym type_id the whole time, but
what they point to in the feature table will be different.  Hmm, I guess
this is what feature_synonym.is_current is for :-)  (The preceding
paragraph left in place even though the author thinks it is silly after
having arrived at the conclusion :-)

How's this for a mess of an email?
Scott


On Tue, 2007-01-16 at 11:57 -0600, Eric Just wrote:
> Hi Scott, thanks for the follow up.
> What would the definition of the proposed synonyms be?  I'm not sure I
> get it.  It sounds like the name is denormalized for the convenience of
> Gbrowse, but this then makes changing a name somewhat more complex than
> it needs to be.  Is there a way to write a query with a left outer join
> to look in the feature table and the synonym table in the same query
> instead of replicating the name as a synonym (not sure which query this
> is in Gbrowse)?  If that's not an option right now, I'd settle for a
> 'name' synonym and a 'synonym' synonym. Are those what primary_synonym
> and is_a synonyms are? I prefer  sequecne_similarity_synonym over
> target_synonym.
>=20
> Thanks again,
> Eric
> -----Original Message-----
> From: Scott Cain [mailto:cai...@gm...]=20
> Sent: Tuesday, January 16, 2007 11:33 AM
> To: Eric Just
> Cc: gmo...@li...
> Subject: Re: [GMOD-devel] Loader: Name tag loaded into synonym table
>=20
>=20
> Hi Eric,
>=20
> It is a speed issue: when GBrowse wants to look for a name, it is much
> faster to look in the synonym table rather than look in feature.name and
> then synonym.name if it fails.  I think the different synonym type is a
> good idea though.  In fact, I've been asked if Target names from GFF
> files could stay out of the synonym table as well, but that would alter
> the way GBrowse typically works too.
>=20
> So, I would suggest two new synonym types:
>=20
>   primary_synonym
>     is_a synonym
>=20
> and
>=20
>   target_synonym (or similarity_feature_synonym or something better)
>     is_a synonym
>=20
> Thoughts?
> Scott
>=20
>  =20
>=20
> On Tue, 2007-01-16 at 08:30 -0600, Eric Just wrote:
> > Hi Scott,
> >=20
> > It's me again.  I've been working with the gmod loader and synonyms=20
> > lately.  I really like how it loads all the Alias tags into the=20
> > synonym table.  However, currently the Name tag also  gets loaded into
>=20
> > the synonym table with the same type_id as Alias (mapping to a=20
> > 'synonym' term).  This is a little confusing as the Name also gets=20
> > loaded into Feature.Name.  In my opinion, Name does not need to go=20
> > into the synonym table as this is redundant.  I very well may be
> missing a use case
> > though.   If it does go into synonym, can it have a different type_id
> > than 'synonym'?  I would like to be able to differentiate data from=20
> > the Alias tags (for which I like the 'synonym' type_id) from data from
>=20
> > the Name tag (for which I wonder whether it needs a synonym record). =20
> > Thanks for looking into this.
> >=20
> > Eric.
> >=20
> >=20
> >=20
> >=20
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
> V
> > _______________________________________________
> > Gmod-devel mailing list
> > Gmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/gmod-devel
--=20
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   cai...@gm...
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory