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