gusdev-gusdev

[Gusdev-gusdev] SRes.ReviewStatus

[Jonathan C. <cra...@sn...>]

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

Re: [Gusdev-gusdev] SRes.ReviewStatus

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

Jonathan,
These sound good to me including manually reviewed and found to be  
incorrect.
Chris

On Thursday, January 23, 2003, at 01:17  AM, 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
>

Re: [Gusdev-gusdev] SRes.ReviewStatus

[Angel P. <an...@sn...>]

On Thu, 23 Jan 2003, 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.
>

I believe that this is roughly what we had agreed on before but never
implemented.

> 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.

We should add this.
angel

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

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