Re: [Gusdev-gusdev] SRes.ReviewStatus

[Arnaud K. <ax...@sa...>]

Hi

Sorry for the delay. We've got some troubles getting gusdev emails.
I think the entry set looks fine. Two comments though:

* What about an extra "automatically created" entry, along the "manually 
created" one ?

* Curators here has raised another point : they want to be able to track 
when was the last time the feature has been reviewed. By reviewed I mean 
checked even if the review status is already set on "reviewed, correct". 
Is there any way of storing a "last_checked_date" ?
I'm thinking of curated similarity evidences. Regularly new searches 
would be done and a curator would want to check that any new hit would 
confirm or cancel a prediction.

Arnaud

Marie-Adele Rajandream wrote:

>-----Original Message-----
>From: gus...@li...
>[mailto:gus...@li...]On Behalf Of Jonathan
>Crabtree
>Sent: 23 January 2003 15:23
>To: gus...@li...
>Cc: Joan Mazzarelli
>Subject: Re: [Gusdev-gusdev] SRes.ReviewStatus
>
>
>
>On Thu, 23 Jan 2003, Joan Mazzarelli wrote:
>
>  
>
>>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)
>>
>>    
>>
>
>Yes, that's right, although I think that Jonathan's addition ("manually
>created") is likely to be a useful one.  Also, based on the feedback thus
>far, I think the consensus is to have a slightly more complex vocabulary
>than the (0,1,2) that  we originally talked about.  Here's the current
>proposal, based on Angel and Chris's feedback:
>
>0 unreviewed          Entry has never been manually reviewed.
>1 manually created    Entry was created by hand; review is not needed.
>2 reviewed, correct   Entry has been manually reviewed and is deemed to be
>correct.
>3 reviewed, incorrect Entry has been manually reviewed and is deemed to be
>incorrect.
>4 updated             Entry has been updated since last being reviewed or
>manually created.
>
>The one thing that I don't like about this is that the names "reviewed,
>correct" and "reviewed, incorrect" are somewhat long.  However, it will be
>possible to do an SQL 'like' query on the ReviewStatus table to find all
>of the reviewed entries (correct or incorrect.)  By the way, the reason
>that I didn't use the original mapping of ids to terms (0 = unreviewed, 1
>= reviewed, 2 = updated) is that id 1 was already in use.  Also, I had
>originally wanted to keep the categories sorted like so:
>
>1 manually created
>2 reviewed, correct
>3 reviewed, incorrect
>4 updated
>5 unreviewed
>
>Doing this one would be able to do range queries; all entries with
>review_status_id <= 2 would be manually reviewed and correct.  All entries
>with review_status_id >= 3 would still require action of some sort.
>Anyway, I don't think it's worth the trouble to do this, and it also means
>that you potentially have to renumber the terms if and when more are
>added.  Anyway, unless anyone has strong objections I'll probably
>implement the 5-term vocabulary described above sometime later today.
>
>Jonathan
>
>
>  
>