Expected Update Frequency vs Freshness Status



Expected Update Frequency

Value stored (as numeric string) in data_update_frequency  field (f)



Freshness status
(Values are numbers of days)

Fresh (Up to date)

Not Fresh

Up-to-date

Due

Leeway

Overdue

Long Overdue

Delinquent

Every day

1

0

1



2       (f +1)



3       (f +2)

Every week

7

0 - 6

7

8-13

14     (f +7)

15-20

21     (f +14)

Every two weeks

14

0 - 13

14

15-20

21     (f +7)

22-27

28     (f +14)

Every month

30

0 -29

30

31-43

44     (f +14)

45-59

60     (f +30)

Every three months

90

0 - 89

90

91-119

120   (f +30)

121-149

150   (f +60)

Every six months

180

0 - 179

180

181-209

210   (f +30)

211-239

240   (f +60)

Every year

365

0 - 364

365

366-424

425   (f +60)

426-454

455   (f +90)

Never

-1

Always

Never

Never

Never

Never

Never

Live

0

Always

Never

Never

Never

Never

Never

As Needed

-2

Always

Never

Never

Never

Never

Never

 

How the states are applied in different processes

State

Sending of Maintainer Email

Display of Green Leaf

Allowed State Data Grid (overridden by curation)

State

Sending of Maintainer Email

Display of Green Leaf

Allowed State Data Grid (overridden by curation)

Up to date



Leaf displayed

Can be complete

Due



Leaf not displayed

Can’t be complete

Overdue



Leaf not displayed

Can’t be complete

Long overdue

Not used

Delinquent



Leaf not displayed

Can’t be complete

Special Case For Never/Live/Ad Hoc

 

Leaf not displayed

Can be complete (can be curated out if too old)


The logic behind the handling of Never/Live/As Needed is detailed in this ticket, but here is the important part:

  • treat “never” as always fresh (datasets that are too old to be relevant should be curated out anyway)

  • treat “ad hoc/as needed” as always fresh (datasets that are too old to be relevant should be curated out anyway)

  • treat “live” as always fresh