[Discovery] Sort By Year not working

[ghost]

pub_date_sort isn't being populated.

Current state of the problem (Oct. 2018):

when fixed, items should consistently appear in reverse chronological order when sorting by date and vice versa when sorting chronologically. [not clear what the distinction is between "sorting by date" and "sorting chronologically": is the point just that there should be options for oldest first and newest first? @seanluyk ] Issue is with the date being populated from the wrong MARC field. For issues like this we could choose to start from scratch and use our fancy new templates as I can see how this could be hard work on as is!

@weiweishi 's summary:

Three options for the date property would be:

008 character position 07-10 260c 264c Next steps

Will test the mapping in UAT with more production-like data. investigate other institution's mapping rule for the date

[ghost]

It turns out you can't populate one CopyField (pub_date_sort) from another (pub_date). Populating pub_date_sort from aacr_pub_date and rda_pub_date seems to fix it.

[ghost]

This will be fixed in the next release, however it will only sort on AACR dates. We need to look at the RDA date field again to get it to sort on that field as well.

[seanluyk]

This is fixed. Closing.

[theLinkResolver]

This seems to be broken again. e.g. https://www.library.ualberta.ca/symphony?page=87&q=canada+business+corporations+act&sort=pub_date_sort+desc%2C+title_sort+asc

[theLinkResolver]

still broken https://www.library.ualberta.ca/symphony?q=%22Global+business+today%22&sort=pub_date_sort+desc%2C+title_sort+asc

[pgwillia]

What does this look like when it's fixed?

[seanluyk]

@pgwilla, when fixed, items should consistently appear in reverse chronological order when sorting by date and vice versa when sorting chronologically. Issue is with the date being populated from the wrong MARC field. For issues like this we could choose to start from scratch and use our fancy new templates as I can see how this could be hard work on as is!

[weiweishi]

Three options for the date property would be:

• 008 character position 07-10
• 260c
• 264c

Next steps

• Will test the mapping in UAT with more production-like data.
• investigate other institution's mapping rule for the date

[pbinkley]

@seanluyk : it's not clear what the distinction is between "sorting by date" and "sorting chronologically" in your most recent comment: is the point just that there should be options for oldest first and newest first?

[pbinkley]

Further question re the three marc field identified by @weiweishi : is it ever the case that more than one of them is populated, with different values? (If so we need rules to choose.)

[seanluyk]

@pbinkley - no distinction between the 2, I think I was trying to make the issue clearer. The issue, in a nutshell, is this - date sorting (i.e. by pub date, oldest to newest (default) and vice versa) has never worked 100% in Blacklight because we've not used the correct MARC field(s) (we're using AACR2 dates, not RDA dates, so newer items don't sort properly). I believe we need to use both (AACR2 and RDA) because that data has not been migrated to its RDA field. There were questions of using the 008 instead, which should apply to all records since it's content standard agnostic

[theLinkResolver]

@pbinkley @seanluyk yes, there will always be at least two values to choose from and often many more (multiple 260s and 264s, plus always one or two values in 008/07-14 - definitely need to gather some requirements from Bib!

[pbinkley]

Discussion with Ian 2018-10-05: for items with a single date (not a range), the preferred sequence would be 264, 260, 008. The difficult case is a record for e.g. a periodical, with a date range: which end of the range do you take?

[seanluyk]

Will try one option in staging and report back to group

[seanluyk]

• Will use 264 instead of 260 and borrow mapping from Stanford

[theLinkResolver]

@seanluyk is the borrowed code from Stanford likely to be the final answer on this one?

[seanluyk]

@theLinkResolver possibly, but Stanford has also done lots of work to improve their ingest process dramatically, for example, https://github.com/sul-dlss/searchworks_traject_indexer and possibly some improvements on the data side too. This is still a top priority so at our next grooming meeting we'll discuss this idea of looking at their code.