Bug 10734 - Add Publication Date Facet in Searching
Summary: Add Publication Date Facet in Searching
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement with 20 votes (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
: 26839 33666 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-15 05:14 UTC by David Cook
Modified: 2024-04-14 21:05 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2013-08-15 05:14:18 UTC
I propose that we add another search facet for publication date. This is fairly common amongst other ILSes and it's been asked for by a few people now. 

However, I'm not certain about how to proceed. 

I suppose we could use the 260$c or 264$c...but maybe the 008 dates are the best to use for it. Mind you, Date1 and Date2 can get somewhat complicated depending on the type of date that is encoded...

If we are to use controlfields we'll need to refactor how facets are generated...see bug 8026
Comment 1 Katrin Fischer 2013-08-18 16:19:23 UTC
Hi David,

the publication date range search on the advanced search page I think is based on 008 Date1 - so using 008 for the facet would make sense to me.
Comment 2 David Cook 2013-08-19 00:23:00 UTC
(In reply to Katrin Fischer from comment #1)
> Hi David,
> 
> the publication date range search on the advanced search page I think is
> based on 008 Date1 - so using 008 for the facet would make sense to me.

Good point. I wonder how we should handle dates like uuuu or 190u or 19uu. Maybe it makes sense just to include definite completely numeric dates? Or maybe do a label for uuuu like "Unknown" and change the u to a question mark for other cases like 190? or 19??, perhaps?

I wrote a little TT plugin a while ago to change codes into nice labels for the facets, which I think I mentioned to you, but the problem was that it had hardcoded strings :/. 

Is there a way of maybe using the "language_descriptions" table to use translated strings?

We would run into the same problem with a record type facet. 

Actually...with record type...we could probably use authorized values like we have for item type and shelving location. I suppose that's not hardcoded but I suppose that probably still presents translation issues. 

Any ideas?
Comment 3 Katrin Fischer 2013-08-19 05:52:10 UTC
> Good point. I wonder how we should handle dates like uuuu or 190u or 19uu.
> Maybe it makes sense just to include definite completely numeric dates? Or
> maybe do a label for uuuu like "Unknown" and change the u to a question mark
> for other cases like 190? or 19??, perhaps?

I think the second would make a bit more sense to me.

> I wrote a little TT plugin a while ago to change codes into nice labels for
> the facets, which I think I mentioned to you, but the problem was that it
> had hardcoded strings :/. 

Hm, not sure I remember. If the strings can be in an include or similar, we can translate them.

> Is there a way of maybe using the "language_descriptions" table to use
> translated strings?

I think that would probably be the best option for a language facet.

> We would run into the same problem with a record type facet.

I think it is solvable especially when the options and descriptions you want to have are somehow limited by the standard.

> Actually...with record type...we could probably use authorized values like
> we have for item type and shelving location. I suppose that's not hardcoded
> but I suppose that probably still presents translation issues. 

I always prefer template translation over using authorised values because the latter are one language only currently.
Comment 4 Mathieu Saby 2013-09-15 17:18:16 UTC
Koha facets are a nightmare. And Marc21 facets are not the same as Unimarc...
What we need is either a syspref or a specific page for configuring them (what index, what order for displaying them, etc.), so each library could add or suppress useless/useful facets.
I've thought of that for ages, but I will try to code it in the next days.

M. Saby
Comment 5 Mathieu Saby 2013-09-15 17:19:33 UTC
By the way, I think the most usefull missing facets are
- date of publication
- language of publication

M. Saby
Comment 6 Mathieu Saby 2013-09-16 07:44:20 UTC
I have a plan to improve facets. Could you please take a look and comment the bug if you have any remarks?
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10891

M. Saby
Comment 7 Mathieu Saby 2021-08-02 09:39:10 UTC
This is still needed...
Comment 8 Fridolin Somers 2022-04-21 18:22:07 UTC
We should add this facet at least for Elasticsearch where it can be configured and disabled via staff interface.
Comment 9 Séverine Queune 2022-04-22 07:55:38 UTC
(In reply to Fridolin Somers from comment #8)
> We should add this facet at least for Elasticsearch where it can be
> configured and disabled via staff interface.

+1 !
Comment 10 Owen Leonard 2022-04-25 11:39:13 UTC
*** Bug 26839 has been marked as a duplicate of this bug. ***
Comment 11 Barbara Johnson 2022-04-26 14:23:56 UTC
Being able to limit search results by publication date would help our patrons as well as staff who are assisting them.  This is really needed.
Comment 12 Michaela Sieber 2023-06-14 20:31:47 UTC
(In reply to Barbara Johnson from comment #11)
> Being able to limit search results by publication date would help our
> patrons as well as staff who are assisting them.  This is really needed.

+1

We agree!
Comment 13 Katrin Fischer 2023-08-09 17:36:02 UTC
*** Bug 33666 has been marked as a duplicate of this bug. ***
Comment 14 David Cook 2024-03-20 00:10:32 UTC
We've added this locally for Zebra. At some point I'll look at upstreaming it.

We might look at some related date facet changes too...