New Additions facet

[edgartdata]

Currently the "New Additions" facet pulls the year from the TMS accession numbers and displays the objects with B# for this year and last year (currently 2020-2021).

If we vend to LIDO a new element with the date a TMS object record is added to one of the TMS object packages that an object record needs to be in to be published to BL, we can more in control of what gets in the "New Additions" facet. We could for example, make up the rule that the "New Additions" facet would show new additions to the online catalog per fiscal year. That new logic would account for example for an art object accessioned in 1981 (and that has an accession number of B1981....) added to the online collections catalog for the first time in August 2021. Such an object would appear in the New Additions group 2021-2022.

@flapka This new LIDO element with the date the TMS record is published to BL seems to be somewhat similar to MARC's "date entered on file" that you mentioned in https://github.com/ycba-cia/blacklight-collections2/issues/18 ? Would that work for RBMS?

[flapka]

From my perspective, there are two primary issues to work out (the 2nd is specific to Voyager collections).

1. How do we define recent additions? I'm open to any of the following, but the first two seem intuitively closer to what a user might expect in Blacklight:

   • Index the exact date added to the catalog, and then the facet can calculate intervals (within 1 year, 1 month, 1 week, etc.), in the manner of the same facet in Quicksearch
   • Index the exact date added to the catalog, and then the facet could let the user select a calendar year of interest. Alternatively, would users find more interest in a date of acquisition facet?
   • Index the exact date added to the catalog, and then facet by fiscal year. I suppose I have doubts about whether fiscal year is of primary interest to our researchers.

2. The Voyager-specific challenge: My earlier assessment of MARC's "date entered on file" includes a misunderstanding that leads to imperfect data. In short, the data that we'd want for this facet is in the "date entered on file" associated with the Holdings record, not the Bibliographic record (in the bib record, this date represents when the record was created at Yale or beyond). This circles us back to an old problem (well known to @yulgit1) -- indexing data from MARC Holdings causes performance issues, at least with our data stream. My hope is that a day will come when YUL's "Metadata Cloud" data stream will give us better access to Holdings -- because there are at least a half-dozen data elements there that we really want access to. I recognize, however, that now might now be the best time to make that transition, given the extra demands on Eric's time.

[yulgit1]

We can't talk about (1) until we have (2), and (2) is tricky. As is, the holdings data of item records are pulled via AJAX to the object records. It might slow the page say by .5 sec but that is relatively small for one page, but for a facet this would have to occur indexing time to ~60000 objects X .5 sec = 8 hrs which is too slow.

For (1) though, I think Francis's bullet point 2 would give the user more power without too much extra complication, so that would be my preference. For reports we could simply stream and filter (fiscal or calendar) by the exact date in this new proposed date_added_to_catalog field.

[edgartdata]

@flapka @LaurelOP @yulgit1 Would it be okay and possible to move the "New Additions" facet to the 6 facets presented by default to users at https://collections.britishart.yale.edu/ before any search terms are entered? This will make more prominent our new acquisitions and records recently added to the online catalog.

[flapka]

Okay with me.

[yulgit1]

Okay and possible.

[LaurelOP]

That's also fine with me!

[yulgit1]

New Additions move resolved: https://github.com/ycba-cia/blacklight-collections2/commit/c7f3f8f9a2588561dad464aec687e13c848720d6