Re: [Gusdev-gusdev] SRes.ReviewStatus

[Joan M. <ma...@pc...>]

Dear Jonathan,

In its most simplest vocabulary, I thought that the review_status_id would represent.

never reviewed = 0
reviewed = 1
updated thus review status becomes = 2 (needs to be re-reviewed)

We needed the #2 for those cases where the computational analysis may have effected
(or changed the entry) that had the review status #1.
(this was tracking entries that had changed)

Joan




Jonathan Crabtree wrote:

> While we're on the topic of populating the GUS 3.0 controlled vocabularies,
> does anyone remember how we originally decided to use the SRes.ReviewStatus
> table?  We currently have a single row in this table, courtesy of Jonathan
> Schug:
>
> REVIEW_STATUS_ID
> ----------------
> NAME
> --------------------------------------------------------------------------------
> DESCRIPTION
> --------------------------------------------------------------------------------
>                1
> manually created
> Entry was created by hand; review is not needed.
>
> I think I was one of the people who originally suggested that we do away
> with the binary "manually_reviewed" column in favor of this controlled
> vocabulary.  One reason for doing this was to be able to distinguish the
> above case (e.g., something that was *entered* manually and should
> therefore automaticaly be considered manually reviewed) from entries that
> are created automatically and then subsequently reviewed.  Another reason
> for creating the vocabulary was to allow us to distinguish between entries
> that have *never* been reviewed, versus those that have been reviewed, but
> that have been updated in some way since their last review.  Therefore I
> suggest adding the following terms to the vocabulary:
>
> 2|manually reviewed|Entry has been manually reviewed and is deemed to be correct.
> 3|updated|Entry has been updated since it was last reviewed.
> 4|unreviewed|Entry has never been manually reviewed.
>
> Comments?  Implicit in the above is that if an annotator is able to review
> something then he/she also has the ability to correct mistakes in that
> thing, and/or is able to delete the entry completely if it is erroneous.
> If we do not make this assumption then we need another term to represent
> the case where an "Entry has been manually reviewed and is deemed to be
> INcorrect."  We might want this even if the assumption I mentioned holds,
> because it would allow us to mark the entry as "manually reviewed -
> incorrect" before deleting it (i.e., moving into the version table), in
> caes where the annotator decides to delete an erroneous entry.  Note also
> that once an entry is marked with term #3, "updated", we no longer track
> (in ReviewStatus, at least) whether the entry was originally of type #1 or
> type #2.  I don't see this is a major problem, however, since the
> provenance of the entry can (and should) be tracked through other means.
>
> Jonathan
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

--
Joan Mazzarelli
Computational Biology and Informatics Laboratory
Center for Bioinformatics
1429 Blockley Hall
University of Pennsylvania
Philadelphia, PA 19104