Re: [Gusdev-gusdev] SRes.ReviewStatus

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

Hi

Quoting Jonathan Crabtree <cra...@pc...>:

> 
> Arnaud-
> 
> > * What about an extra "automatically created" entry, along the "manually 
> > created" one ?
> 
> We've decided to drop the "manually created" term, and while it would be
> useful to know which entries were created automatically vs. manually,
> this information can be tracked using a combination of the Evidence and/or
> AlgorithmInvocation tables.  If you think it's crucial to record how an
> entry was *originally* created, then we should consider adding an extra
> column in the relevant tables to record this (and also to enable fast
> queries to retrieve entries based on their origin.)
> 
> > * 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.
> 
> I think that we're currently working under the assumption that we'll use
> the
> modification_date for this (which may or may not meet your needs).  When an
> annotator first reviews an unreviewed entry, its status is set to either
> "manually reviewed, correct" or "manually reviewed, incorrect"  and its
> modification_date is updated (and the old row versioned.)  The
> modification_date
> now records the date of last review.  Now, when something happens that
> might
> change the status of the entry (e.g., new searches are performed), its
> status
> gets changed to "updated" and its modification_date is updated.  At this
> point
> the only way to tell the date of last manual review is to look in the
> version
> table.  (Although one does know that the last manual review must have been
> before the stated modification_date.)  When the entry comes up for review
> again (since it's now marked "updated"), its status is changed once more,
> and
> it's modification_date will once again reflect the time of the most recent
> manual review.
> 
> So the reason (in our current system) that we don't independently store the
> last_checked_date is because we don't care when the entry was last checked
> in absolute terms; we only care whether anything has changed since then. 
> One
> problem with this (versus just storing a last_checked_date) is that it
> means
> that any program that makes changes (e.g., the one that runs the similarity
> searches) must determine what entries in the database *may* have been
> affected,
> and update their review_status.
> 

I think it would be an interesting functionality. A way for the
annotators/curators to be informed than a run may affect some entries in the
database and that they should be reviewed.

It sounds like some sort of "triggers" with a set of rules that specify, for a
given run, which entries may be affected. But it's probably not a simple task to
implement!

> I think I agree that last_manual_review_date would be a useful thing to
> have,
> but I think that its addition will have to be deferred until after I've
> finished working on the migration, because it will affect several tables.
> I'll put it on my list of things to deal with after the migration is done.
> 

fine

> Jonathan
> 

Arnaud