Re: [Gusdev-gusdev] Similarity table changes

[<ju...@cs...>]

Perhaps all that is needed is the table DoTS::SimilarityKeyword.


Jonathan Schug <js...@pc...> writes:
>
> Sucheta, and All:
>
> If the blast libraries do not overlap, i.e., contain different sets of
> sequences, then there is probably no problem.  You can simply
> distinguish the Similarity rows by the target sequence's
> external_database_release_id.
>
> If the libraries overlap, then the issue is more difficult.  We don't
> have the notion of a library in this sense, and of course the library
> size affects the p-values for matches.  There is a DoTS::Library table
> that holds clone information that could be hacked to provide what you
> want, but I do *not* recommend it as a long term solution.  You could
> also use the DoTS::DbRefNaSequence or DoTS::AASequenceDbRef as
> appropriate to link to a DoTS::DbRef which links to an
> ExternalDatabase.  These tables could easily be used to gather
> sequences into multiple BLAST database files.
>
> The best solution is probably to create new tables.
>
> I propose, then the following changes to the Similarity table and the
> addition of new table to track search libraries:
>
> DoTS::Similarity
>    - add search_algorithm_invocation_id link to stably point to
> parameter values for the search.
>
> SRes::SearchLibrary
>    - contains a description of the search library including entry count
> etc.
>
> SRes::SearchLibraryMember
>    - uses a soft link, i.e., table_id, row_id to indicate membership.
>    - link is soft so that SearchLibrary can also be used for motifs,
> etc. that may not be in sequence table.
>    - SearchLibrary might contain a table_id to record what kind of
> entries are in the library.
>
> Thoughts?
>
> Jonathan
>