Re: [Gusdev-gusdev] [Fwd: Attribution in GUS]

[Chris S. <sto...@pc...>]

Hi Arnaud,
I think it is a good idea to add a publication type attribute to  
bibliographic reference. An alternative list of terms can be found at  
http://srs.ebi.ac.uk/srs6bin/cgi-bin/wgetz?-page+FieldInfo+- 
id+4kuFf1ITQgp+-lib+MEDLINE+-bf+PublicationType (click on 'list  
values') but the Flybase list has things like 'personal communication'  
not present in the Meldine list..

Chris

On Tuesday, November 12, 2002, at 10:29  AM, Arnaud Kerhornou wrote:

>  Hi Jonathan
>
> Sorry for the delay to come back to you with some thoughts on  
> attribution data.
>
> Here a case of what could happen on a given project:
>
> * The sequences would come from TIGR,
> * The gene models would come from SBRI,
> * The manual annotation of the gene models and the GO curation would  
> be done by TIGR,
> * The curation would be done by the Sanger,
> * Some curated comments would be sent by members of the community.
>
> Instead of using the evidence table, would it be possible to attribute  
> data by using the user_id attribute ?
> e.g. if the gene models are coming from SBRI, the user_id would  
> acknowledge the gene features as owned by SBRI. Any update would keep  
> the ownership and would acknowledge who's done the update.
>
> The other point was the attribution of data coming from publication or  
> personal communication. I had a look at flybase. Flybase considers  
> personal communication as references. To differentiate them, they have  
> an extra attribute in the reference table to allow the classification  
> of the different references.
> For more information about the refernce class controlled vocabulary,  
> see  
> http://flybase.bio.indiana.edu/.data/docs/refman/refman-B.html#B.13.2.
>
> cheers
> Arnaud
>
> ------------------------------
>
> Item 3: Attribution of data from multiple sources. Three methods are  
> available in GUS3.0 to attach information to tables. Evidence which  
> allows attributions to be linked to any row. NAComment which allows  
> multiple attachment of comments to a sequence. Comment which is  
> attached to a review_status_id; each NAFeature has a review_status_id.  
> Use cases are needed to determine if any of these mechanisms are  
> appropriate.
> see addendum from Jonathan Crabtree below.
>
>
> Addendum to item 3 from Jonathan.
> I spent a little time looking into this and the number of methods  
> differs
> depending on how you count them (and also because in most situations  
> the
> number of alternatives differs depending on which table you're  
> commenting
> on.)  But here are the ways we currently support in GUS 3.0 for adding
> comments to things (external to the tables themselves):
>
> 1. DoTS.Comments (not "Comment") + DoTS.Evidence
>    I list these together because the Comments table relies on the  
> Evidence
>    table to link its rows to other objects in the db.
>    This method can be used with any table and supports CLOB comments.
> 2. DoTS.AAComment + DoTS.CommentName
>    Can be used only with AASequence entries and supports  
> VARCHAR2(4000).
> 3. DoTS.NAComment
>    Can be used only with NASequence entries and supports  
> VARCHAR2(4000).
>    (Does *not* have a link to DoTS.CommentName)
> 4. DoTS.Note
>    Can be used only with NAFeature entries and supports VARCHAR2(4000)
>    (Note that this is different from gusdev.Note, which has a  
> VARCHAR(255)
>     AND a CLOB column.)
>
> Note that DoTS.Comments is the only generic option (that I found) for
> associating notes/comments with rows.  Note also that AASequence,
> NASequence, and NAFeature all have their own specialized comment  
> tables,
> but AAFeature doesn't appear to (at least not one with "comment" in its
> name!)  Conceptually speaking I'm also not sure that I agree with the  
> use
> of the "Evidence" table to link comments to rows in general.  For  
> example,
> during the conference call I gave the example of a note in PlasmoDB  
> that
> basically says "the second exon of this predicted gene is incorrect";  
> this
> would actually be evidence *against* the GeneFeature, not *for* it (the
> typical use of the Evidence table.)  Likewise, one could merely be
> commenting on an aspect of a predicted feature, without actually  
> providing
> any further evidence for its existence or correctness.  In other words,
> an implicit statement of the form "if this thing exists, then it's
> interesting that such and such would be true...".
>
> Another thing to point out is that none of these tables (as far as I  
> can
> remember), has a pointer to SRES.Contact, so they don't really address  
> the
> question of attribution.  In PlasmoDB right now we handle attribution
> mainly through creative use of the ExternalDatabase table  
> (external_db_id
> in the current GUSdev).  In GUS 3.0 I believe that external database
> releases will be linked to Contacts, so perhaps the thing to do is to
> allow a single entry in the database to be associated with multiple
> external databases?  This gets slightly messy if you want to be able to
> attribute something to a personal communication with somebody, or to a
> journal article (neither of which is expressed particularly well as an
> "external database".)  Although both might be nicely represented as
> References, perhaps?  There are enough possibilities that maybe we  
> should
> just find out exactly what the PSU folks have in mind, and tailor a
> solution that works for them (using the existing schema as much as  
> possible.)
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>