| Time |
Nick |
Message |
| 07:16 |
|
Callender joined #evergreen |
| 07:31 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
mrpeters joined #evergreen |
| 07:45 |
|
ericar joined #evergreen |
| 07:46 |
|
mrpeters joined #evergreen |
| 07:49 |
|
Elaine joined #evergreen |
| 08:16 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
mdriscoll joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:58 |
|
collum joined #evergreen |
| 08:59 |
StomproJ |
mmorgan++ tsbere++ #Answering my parts/notices question |
| 09:00 |
StomproJ |
tsbere, we are trying out your suggestion of disabling the soft stalling for our hub location. Thanks for the idea. |
| 09:02 |
tsbere |
StomproJ: I figured it couldn't hurt to at least try that option. |
| 09:04 |
|
agent11 joined #evergreen |
| 09:21 |
|
rlefaive joined #evergreen |
| 09:21 |
|
maryj joined #evergreen |
| 09:34 |
|
mllewellyn joined #evergreen |
| 09:42 |
kmlussier |
@tea |
| 09:42 |
* pinesol_green |
brews and pours a pot of Bio Pao Chung Pouchong, and sends it sliding down the bar to kmlussier (http://ratetea.com/tea/teehaus-bachfischer/bio-pao-chung-pouchong/7609/) |
| 09:53 |
|
yboston joined #evergreen |
| 10:06 |
|
artunit_away joined #evergreen |
| 10:28 |
Dyrcona |
-rw-rw-r-- 1 jason jason 666 Mar 11 10:23 more_incorrectly_open_circs.sql |
| 10:28 |
Dyrcona |
The SQL of the Beast! |
| 10:36 |
berick |
it burnses |
| 10:42 |
Dyrcona |
heh |
| 11:05 |
|
sandbergja joined #evergreen |
| 11:43 |
|
bmills joined #evergreen |
| 11:51 |
|
ericar_ joined #evergreen |
| 11:52 |
|
jihpringle joined #evergreen |
| 11:54 |
|
abneiman joined #evergreen |
| 11:56 |
|
Christineb joined #evergreen |
| 12:17 |
mmorgan |
If I change group penalty thresholds, how to the standing penalties get recalculated? Should they just update when I retrieve a patron? |
| 12:17 |
jeff |
they will update when you select "refresh", or when some other action would otherwise cause them to be re-calculated. |
| 12:18 |
jeff |
or you can run a script to recalc them -- i think one or two examples are out there, though none included in Evergreen last i looked. |
| 12:19 |
mmorgan |
Ok, I thought they should recalc when I refreshed, I must have something set up wrong. |
| 12:20 |
mmorgan |
I googled for ways to force a recalc, but came up empty:-( |
| 12:25 |
jeff |
if the recalc doesn't seem to be taking effect when you press Refresh in the staff client when viewing a patron, then the threshold might be set up incorrectly. |
| 12:25 |
jeff |
it's also possible that you're running into a depth issue. |
| 12:26 |
mmorgan |
I set a threshold, retrieved the patron, there was no block. I refreshed the patron and the block appeared. |
| 12:26 |
mmorgan |
Does the fine generator force recalc when it runs each night? |
| 12:28 |
* mmorgan |
is trying to wrap brain around the whole penalty org depth thing, too. |
| 12:29 |
yboston |
FYI, there is going to be a IRC practice seesion starting at 12:30 PM EST (basically now) |
| 12:29 |
yboston |
until the start of the EG search meeting |
| 12:30 |
kmlussier |
yboston++ |
| 12:30 |
yboston |
welcome to anyone that is here on IRC for the first time |
| 12:31 |
yboston |
Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 12:31 |
yboston |
(this message will be repeated several times int he next 27 minutes) |
| 12:35 |
kmlussier |
yboston: Do you have an autorepeat plugin for that? |
| 12:38 |
yboston |
kmlussier: no, just went back to the log |
| 12:38 |
yboston |
welcome to anyone that is here on IRC for the first time |
| 12:38 |
yboston |
Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 12:40 |
|
cprince joined #evergreen |
| 12:44 |
kmlussier |
Just a heads up that the search discussion will begin in about 15 minutes. |
| 12:44 |
yboston |
welcome to anyone that is here on IRC for the first time |
| 12:44 |
yboston |
Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 12:48 |
|
tspindler joined #evergreen |
| 12:51 |
yboston |
welcome to anyone that is here on IRC for the first time |
| 12:51 |
yboston |
Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 12:53 |
kmlussier |
Also, anyone should feel free to practice by posting some messages before we begin the search discussion. |
| 12:55 |
|
Elaine joined #evergreen |
| 12:56 |
kmlussier |
Hi Elaine! |
| 12:56 |
Elaine |
Hi Kathy! |
| 12:57 |
tspindler |
@weather 01605 |
| 12:57 |
pinesol_green |
tspindler: Worcester, MA :: Mostly Cloudy :: 53F/12C | Friday: A mix of clouds and sun. High 56F. Winds NW at 10 to 20 mph. Friday Night: A clear sky. Low 31F. Winds NW at 5 to 10 mph. | Updated: 3m ago |
| 12:57 |
kmlussier |
@weather |
| 12:57 |
pinesol_green |
kmlussier: Seekonk, MA :: Mostly Cloudy :: 62F/17C | Friday: Partly cloudy. High 59F. Winds NNW at 10 to 15 mph. Friday Night: Clear skies. Low 34F. Winds NNW at 5 to 10 mph. |
| 12:57 |
tspindler |
@bartender kmlussier |
| 12:57 |
* pinesol_green |
fills a pint glass with Kriek Boon, and sends it sliding down the bar to kmlussier (http://beeradvocate.com/beer/profile/47/2426) |
| 12:58 |
kmlussier |
tspindler: Wow! That's almost a 10-degree difference. |
| 12:58 |
tspindler |
windy here <shrugs> |
| 12:58 |
kmlussier |
tspindler: Are you encouraging me to drink on the job? |
| 12:58 |
Elaine |
@weather |
| 12:58 |
pinesol_green |
Elaine: Error: I did not find a preset location for you. Set via setweather <location> |
| 12:58 |
tspindler |
only virtually |
| 12:58 |
kmlussier |
Elaine: If you add a zip code, it should work. I can't remember how I got it to remember my zip code. |
| 12:59 |
Elaine |
@weather 30016 |
| 12:59 |
pinesol_green |
Elaine: Covington, GA :: Partly Cloudy :: 75F/24C | Friday: Overcast. High 78F. Winds light and variable. Friday Night: Cloudy skies. Low 58F. Winds light and variable. | Updated: 24m ago |
| 12:59 |
Elaine |
Spring like weather here as well |
| 13:00 |
bshum |
@weather setweather 06810 |
| 13:00 |
pinesol_green |
bshum: I have changed bshum's weather ID to 06810 |
| 13:00 |
bshum |
It says what to do in the error message. |
| 13:00 |
bshum |
@weather |
| 13:00 |
pinesol_green |
bshum: Danbury, CT :: Mostly Cloudy :: 59F/15C | Friday: Partly cloudy. High around 60F. Winds NNW at 10 to 15 mph. Friday Night: Clear skies. Low 32F. Winds NNW at 5 to 10 mph. |
| 13:00 |
kmlussier |
OK, I'm going to start the discussion. |
| 13:00 |
kmlussier |
And tells all non-Evergreeners to get back to work. ;) |
| 13:01 |
kmlussier |
#startmeeting 2016-03-11 - Evergreen focus group discussion on search |
| 13:01 |
pinesol_green |
Meeting started Fri Mar 11 13:01:23 2016 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 13:01 |
pinesol_green |
The meeting name has been set to '2016_03_11___evergreen_focus_group_discussion_on_search' |
| 13:01 |
kmlussier |
#topic Introductions |
| 13:01 |
kmlussier |
Please introduce yourselves, as follows |
| 13:01 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:01 |
|
Cybrarian joined #evergreen |
| 13:02 |
tspindler |
#info tspindler is Tim Spindler, C/W MARS |
| 13:02 |
Elaine |
#info Elaine is Elaine Hardy PINES/GPLS |
| 13:02 |
Cybrarian |
#info Cybrarian is Jennifer Walz from Asbury University. |
| 13:03 |
kmlussier |
While we wait for more people to come in, I'm posting a link to some ground rules I wrote up. http://wiki.evergreen-ils.org/doku.php?id=scratchpad:search:focus_groups |
| 13:04 |
kmlussier |
Basically, what they say is this is primarily a brainstorming discussion to discuss what we would like to see in search. |
| 13:04 |
berick |
#info berick is Bill Erickson / KCLS |
| 13:04 |
Cybrarian |
Will we talk about specifics of the software? Or in general about opacs and book searching? |
| 13:04 |
kmlussier |
So it's really an opportunity to talk about ideas. Although it's tempting, especially for technical folks, to get in the nitty gritty of how to make those ideas happen, we don't want to get bogged down in the details today. |
| 13:04 |
kmlussier |
Cybrarian: We're talking specifically about Evergreen. |
| 13:04 |
tspindler |
kmlussier: the ground rules link returned a 404 error |
| 13:05 |
kmlussier |
bah |
| 13:05 |
Elaine |
I got the 404 error as well |
| 13:05 |
kmlussier |
Oh, the line broke |
| 13:05 |
kmlussier |
#link http://wiki.evergreen-ils.org/doku.php?id=scratchpad:search:focus_groups |
| 13:05 |
kmlussier |
That should work. |
| 13:05 |
tspindler |
kmlussier ++ |
| 13:05 |
Elaine |
It does work, thanks! |
| 13:06 |
kmlussier |
Also, as is the case with any brainstorming, there are no stupid ideas. Feel free to share whatever ideas you have. And please don't be critical of others ideas. |
| 13:06 |
kmlussier |
However, I enourage you to build on each other's ideas. |
| 13:06 |
kmlussier |
At this point, I think I've repeated everything that's in the link. :) |
| 13:06 |
kmlussier |
I'm going to kick off the discussion, but if people wander in late, please feel free to introduce yourselves. |
| 13:07 |
kmlussier |
#topic Strengths of current search |
| 13:07 |
Cybrarian |
With regards to the evergreen interface for the public, I would really like a way to let them search by collection, not just media type. |
| 13:07 |
kmlussier |
OK, we'll get to improvements soon :) |
| 13:07 |
kmlussier |
I want to start by asking people to identify what they like about the current Evergreen search. What are its strengths? Is there anything that Evergreen search has that makes it unique? |
| 13:07 |
Cybrarian |
It is really quick. |
| 13:08 |
Cybrarian |
The interface is uncluttered for the most part. |
| 13:08 |
Elaine |
Retrieval is comprehensive |
| 13:08 |
tspindler |
I'm not sure this is related to search but the ability to customize the interface is a strong point |
| 13:08 |
Elaine |
Good filtering |
| 13:09 |
kmlussier |
tspindler: Well, there is also the ability to customize what you search, so in that respect, I would say it's related to search. |
| 13:09 |
tspindler |
Filtering ++ |
| 13:09 |
kmlussier |
Elaine: And is that the pre-set filters from the advances search screen, the facets, or all of the above? |
| 13:09 |
Cybrarian |
I like the filtering, but also would like additional options to customize further. |
| 13:09 |
berick |
agreed on filtering, specifically item level (and thereabouts) filtering is strong/flexible |
| 13:09 |
Cybrarian |
I like the ability to customize the interface - to a point. |
| 13:09 |
Elaine |
all of the above |
| 13:09 |
tspindler |
filtering on advanced screen is very good |
| 13:10 |
Cybrarian |
I like the browse by shelf feature - though it does confuse people some. |
| 13:10 |
kmlussier |
Yes, the browse shelf feature is nice. |
| 13:11 |
Cybrarian |
Advanced ++ |
| 13:11 |
kmlussier |
The reason I ask this question is because, if we decide to make changes to search, we want to make sure we don't lose the things that are already working well for us. |
| 13:11 |
Elaine |
I don't think the problem is the search but rather how it displays the results to you. |
| 13:11 |
Cybrarian |
I always say that you should never change any functional parts, instead add new options for people to chose. |
| 13:12 |
Cybrarian |
I will agree with Elaine on the display. |
| 13:12 |
kmlussier |
Cybrarian: Yes, true. I agree. But sometimes, it's easier said than done. :) |
| 13:12 |
kmlussier |
And if you're rebuilding (not necessarily saying that we are) it's easy to forget some things if they aren't explicitly stated. |
| 13:12 |
Elaine |
I should say the main problem. I do have some problems when we get to that part of the discusson |
| 13:13 |
Cybrarian |
Indeed. Because the function has become part of the language of what you do, you forget that it is essential. |
| 13:13 |
kmlussier |
Are there other strengths people would like to bring up? Or anything that makes Evergreen's search unique when compared to other systems? |
| 13:13 |
phasefx |
not that we'd ever go in the opposite direction, but it's nice having "sessionless" searches |
| 13:13 |
kmlussier |
phasefx: YES! |
| 13:13 |
phasefx |
so URL's are shareable |
| 13:14 |
Cybrarian |
One feature? is how the subjects are searched. |
| 13:14 |
kmlussier |
Cybrarian: Can you expand upon that? |
| 13:14 |
Cybrarian |
Well, we also just did a re-index so now it is better. |
| 13:14 |
Cybrarian |
But I still am not completely satisfied with how the LC subject headings get searched. |
| 13:15 |
Cybrarian |
But I am still not sure that I understand why. |
| 13:15 |
Cybrarian |
I think our re-index has helped some. |
| 13:15 |
kmlussier |
OK, I think I'm going to move to the next topic, and maybe we can get more info on that. |
| 13:15 |
kmlussier |
But if you think of anything else, feel free to shout it out later on. |
| 13:15 |
Cybrarian |
I'm also a little "old school" when it comes to LCSH. :-) |
| 13:16 |
kmlussier |
#topic Areas for improvement |
| 13:16 |
kmlussier |
Where are the areas where you would like to see improvement? |
| 13:16 |
kmlussier |
And we've already touched upon a few of these. |
| 13:16 |
Elaine |
Authority links should be in advanced search |
| 13:16 |
tspindler |
kmlussier has heard this from us but it is speed and relevance |
| 13:16 |
berick |
1. search speed. 2. indexing/ingest speed |
| 13:16 |
tspindler |
++ to indexing/ingest speed |
| 13:17 |
Elaine |
When you search author should be keyword -- when I search for au Mary Jones I don't want to see titles with Mary smith and David Jones |
| 13:17 |
Cybrarian |
More browse options? |
| 13:17 |
jihpringle |
a "did you mean..." would be awesome (especially for the KPAC) |
| 13:17 |
Cybrarian |
Searching by collection |
| 13:18 |
tspindler |
improvements to failed searches, in particular I would like to see a 0 results search at least on title and author drop you into browse search |
| 13:18 |
Cybrarian |
More hyperlinking |
| 13:18 |
kmlussier |
Elaine: Are you saying that when you do an author search, the hits retrieved are based in words in other fields? |
| 13:19 |
Elaine |
I would like to see an intermediate result screen so that if you searched for au mary jones you would get a list of authors not a list of titles. |
| 13:19 |
kmlussier |
Cybrarian: What kind of browse options would you like to see? |
| 13:19 |
tspindler |
including see references in author search index and subject search index |
| 13:19 |
Cybrarian |
++ for Elaine suggestion! |
| 13:19 |
Elaine |
Kmlussier -- hits are based on words in all author fields for an author search, for example |
| 13:20 |
phasefx |
* UI for hand-tweaking metarecords |
| 13:20 |
abneiman |
from the lurk-gallery +1 on search by collection -- we have a sorta-kludge in place for this thanks to ESI but would be nice to have it native. Also +1 on "did you mean". |
| 13:20 |
kmlussier |
tspindler: Can I rephrase that one in a different way? Maybe...finding good ways to make use of cross-references when keyword searches? It might be adding them to indexes, but maybe there are other ways to make use of them. |
| 13:20 |
Cybrarian |
Browse - call number, publisher, date? |
| 13:20 |
tspindler |
kmlussier: that's good |
| 13:20 |
kmlussier |
Elaine: Ah, gotcha. Thanks for explaining. |
| 13:20 |
phasefx |
#info phasefx is Jason Etheridge, ESI |
| 13:20 |
Elaine |
tspindler -- that is what I mean by tying to authority file |
| 13:21 |
kmlussier |
phasefx: I've just been delving into metarecords recently. Do you mean handtweaking for when there are bad groupings? Or do you envision other tweaking? |
| 13:21 |
tspindler |
including prefixes in call number searches |
| 13:21 |
phasefx |
kmlussier: putting records in and out of groupings for whatever reason |
| 13:21 |
kmlussier |
phasefx: Excellent! Thanks! |
| 13:22 |
tspindler |
phasefx: what kinds of groupings, not sure I understand |
| 13:22 |
kmlussier |
Cybrarian: I'm also interested in what you mean when you say searching collections? Is this something outside of using copy locations? |
| 13:22 |
kmlussier |
tspindler: For the group formats and editions searches |
| 13:22 |
Cybrarian |
Browse by journal title would also be nice. :-) |
| 13:22 |
phasefx |
* ability to display canned information for specific searches |
| 13:23 |
Cybrarian |
I probably do mean copy locations, but right now we can't seem to do even that. |
| 13:23 |
Cybrarian |
And I have not seen an implementation of it that is what we really need. |
| 13:23 |
tspindler |
I know our cataloging head has issues with LC searches and subheadings but trying to remember details |
| 13:23 |
berick |
phasefx: can you expand (on canned)? |
| 13:23 |
Elaine |
Cybrarian: copy locations should appear at branch level searching |
| 13:24 |
Cybrarian |
Maybe a way to do a combination of copy location and circ mod? I think we want to be too creative. :-) |
| 13:24 |
kmlussier |
Cybrarian: There is no too creative for today. Too creative comes up later. |
| 13:24 |
phasefx |
berick: well, not just canned, but perhaps non-bib linked data as well. For example, how Google shows non-search results for celebrities, etc. Wikipedia links, images |
| 13:24 |
kmlussier |
Cybrarian: As I said, we don't want to dive too far into details, but I wonder if copy location groups might help. I would be willing to follow up with you later on that. |
| 13:24 |
Elaine |
phasefx: linked data!! |
| 13:24 |
tspindler |
phasefx++ |
| 13:25 |
Cybrarian |
Thanks Kathy! |
| 13:25 |
berick |
phasefx: ah, gotcha. getting into linked data (woohoo) |
| 13:25 |
Elaine |
and BIBFRAME |
| 13:25 |
kmlussier |
That's a great idea phasefx |
| 13:25 |
berick |
Elaine: yep |
| 13:25 |
phasefx |
could also be a way to promote certain things when on-topic |
| 13:25 |
phasefx |
the opening of a new library feature, etc. that is pertinent to the search |
| 13:25 |
tspindler |
better normalization also |
| 13:25 |
Elaine |
That is where cataloging is heading but not there yer |
| 13:26 |
kmlussier |
OK, we have a lot of improvements mentioned here. Are there features you've seen in other search systems that you would like to see implemented in Evergreen? |
| 13:27 |
kmlussier |
A few have been mentioned so far. Like phasefx's canned searches idea and the did you mean? suggestion. |
| 13:27 |
Cybrarian |
For our students, they would like to have more features like creating list of books and then saving / keeping the list. |
| 13:27 |
Elaine |
No one else does this anymore -- cross references within an authority record should be implemented |
| 13:27 |
Cybrarian |
But without having to login. |
| 13:27 |
dbs |
I think it's important to separate canned searches from "related info cards" (which may or may not be based on linked data) |
| 13:28 |
phasefx |
Cybrarian: I've always wanted a better way to "consume" and share bookbags/booklists |
| 13:28 |
Cybrarian |
Or emailing. :-) |
| 13:28 |
phasefx |
dbs++ |
| 13:28 |
dbs |
Focus on what you want to have as a result, versus how it's accomplished under the covers |
| 13:28 |
tspindler |
if we are talking pie in the sky, maybe discoverability so that instead of loading Overdrive we link to their database ala z39.50 |
| 13:28 |
kmlussier |
dbs: Yes, I think that's a very good point. |
| 13:29 |
Elaine |
tspindler ++ I would rather not put all those bib records for a e-resource collection that might change next month |
| 13:29 |
tspindler |
..or link some other way |
| 13:29 |
dbs |
Cybrarian: phasefx: it would be cool for searches to also turn up "Here are some lists that people put together on that topic" for example? |
| 13:29 |
Cybrarian |
For the output, it would also be nice to be able to select the data you want to "keep". Not just the default stuff. |
| 13:30 |
kmlussier |
Cybrarian: So you're saying people would be able to define which fields are kept when you save titles to a list? |
| 13:30 |
kmlussier |
Cybrarian: Sorry, that was output. When printing, emailing, etc. |
| 13:30 |
phasefx |
dbs: that would be awesome |
| 13:30 |
Cybrarian |
kmlussier - yes. |
| 13:30 |
kmlussier |
gotcha |
| 13:30 |
tspindler |
better my lists management, ability to select multiple titles and add at once |
| 13:31 |
Elaine |
When search caps out as 10,000, system should tell you |
| 13:31 |
Cybrarian |
tspindler - yes! |
| 13:32 |
Elaine |
Not have lists reload everytime you delete a title.... |
| 13:32 |
kmlussier |
Elaine: OK, I think I saw something on that in an email too. So you're talking about the system not retrieving all search results with very broad searches? |
| 13:33 |
Elaine |
kmlussier: yes -- user should no not all bib records retrieved |
| 13:33 |
Elaine |
know!! |
| 13:33 |
kmlussier |
Elaine: no worries, I understood. It happens in here all the time. :) |
| 13:33 |
kmlussier |
Too difficult to type quickly. |
| 13:34 |
Elaine |
And spell at the same time |
| 13:34 |
dbs |
Something like "You searched for 'the', and that's not really cool, can you try adding some more specific keywords please?" |
| 13:34 |
kmlussier |
I think I'm about ready to move on to the next topic. But I just want to give another minute in case anyone else has ideas on something they think would really bring search to the next level. |
| 13:34 |
* phasefx |
was thinking canned info could help with broad searches as well |
| 13:34 |
Cybrarian |
Just a question: can you do phrase searching? |
| 13:35 |
Cybrarian |
I don't really know... |
| 13:35 |
kmlussier |
yes |
| 13:35 |
Elaine |
Not necessarily more keywords -- try filtering |
| 13:35 |
dbs |
(right now we just immediately return 200 OK and pretend a search never happened based on some local Apache rewrites for broooad searches) |
| 13:35 |
Cybrarian |
Does it work with quotes? |
| 13:35 |
Elaine |
Cybrarian -- yes with quotes |
| 13:35 |
kmlussier |
Cybrarian: Yes, if you wrap it in quotes, the search terms are searched as a phrase. |
| 13:35 |
Cybrarian |
Thanks! |
| 13:35 |
kmlussier |
Also, quoting also forces the system to search the exact terms, not a stemmed variation. |
| 13:36 |
kmlussier |
I like these ideas of having more user assistance when we have overly broad searches. Excellent! |
| 13:36 |
kmlussier |
OK, I'm going to move on to our next topic, which is specific to relevance ranking. |
| 13:36 |
kmlussier |
#topic Defining relevance |
| 13:37 |
kmlussier |
As tspindler mentioned above, relevance is something that comes up as an area for improvement. But relevance for one person might not be so relevant for another. |
| 13:37 |
kmlussier |
When ranking search results, which factors should play a strong role in relevancy? |
| 13:37 |
kmlussier |
Are there specific places where you find Evergreen is falling short on returning relevant results? |
| 13:38 |
Elaine |
Relevance is much better than it was |
| 13:38 |
tspindler |
proximity ranking (isn't this non existent right now?) |
| 13:38 |
Cybrarian |
I try to avoid relevancy at all costs. |
| 13:38 |
kmlussier |
tspindler: No, I'm pretty sure that it looks at proximity. |
| 13:39 |
tspindler |
i don't have examples but it seemed that some search results i have had suggested it wasn't paying attention but I could be wrong |
| 13:39 |
Elaine |
It does seem like proximity is not always adhered to |
| 13:39 |
kmlussier |
But if you're looking at search results and don't think records with word proximity are ranking higher, it doesn't mean the system isn't paying attention to it. It might not be doing it at a level you expect it. |
| 13:39 |
dbs |
proximity is part of the density scoring in postgresql's full text search |
| 13:40 |
phasefx |
I haven't thought this through, but a pie in the sky feature may be to the let the patron give a hint for what is relevant, e.g. "for a paper", "for leisure", "from a fever dream" |
| 13:40 |
dbs |
but how that plays out in practice may differ, so examples of where expectations are not met are welcome |
| 13:40 |
kmlussier |
"fever dream" I like it! |
| 13:40 |
Cybrarian |
Word count? |
| 13:41 |
kmlussier |
Cybrarian: So you're saying the number of times a word appears should influence its relevance? |
| 13:41 |
dbs |
http://www.sai.msu.su/~megera/postgres/fts/fts.pdf for a classic, dated, but still relevant (hah) 77-page intro to full-text search that Evergreen currently relies on :) |
| 13:41 |
tspindler |
kmlussier: i think my staff have provided better examples than I can come up with right now, I know you have them |
| 13:41 |
Elaine |
phasefx: but even if fever dream, user still wants life of a crazy cat lady to be near the top when they search |
| 13:41 |
kmlussier |
tspindler: Yes, I do. And probably more. :) |
| 13:41 |
Cybrarian |
Read their minds? |
| 13:41 |
phasefx |
Elaine: we can put that up near the top for _every_ search :) |
| 13:42 |
kmlussier |
Cybrarian: I'm working on that technology, but it's still a few years away. :) |
| 13:42 |
Elaine |
phasefx: works for me. |
| 13:42 |
Cybrarian |
yes, word count means the number of times the keyword entered appears in the record. |
| 13:42 |
kmlussier |
gotcha |
| 13:42 |
dbs |
Cybrarian: yes that's there |
| 13:42 |
* Dyrcona |
is still working on the "read user's mind patch." Should be ready any day now. :) |
| 13:42 |
tspindler |
d |
| 13:42 |
kmlussier |
Dyrcona obviously works more quickly than I do. |
| 13:42 |
tspindler |
Dyrcona++ |
| 13:42 |
phasefx |
Cybrarian: word count that is, not mind reading :) |
| 13:43 |
tspindler |
Dyrcona: the question is, do the spell correctly in their mind ;) |
| 13:43 |
kmlussier |
Yes, and so the question is what should be a factor in relevance. So many of those things are probably available in Evergreen. |
| 13:43 |
kmlussier |
And then the followup (which maybe should have been asked later), is if you see Evergreen falling short. |
| 13:44 |
kmlussier |
Things that have been mentioned thus far, then, is that word count, and proximity should play a part in relevance. Did I miss anything? |
| 13:45 |
tspindler |
i thin popularity has a role also |
| 13:45 |
tspindler |
i know its coming |
| 13:45 |
phasefx |
and maybe self-fulfilling :) |
| 13:45 |
Elaine |
I don't necessarily see the value of word count -- words in a title might only appear once in a record' |
| 13:45 |
kmlussier |
OK, so the amount of use a title gets should also play into relevance. |
| 13:45 |
dbwells |
As many here know, the primary driver of relevance in current Evergreen is "cover density". It's a fairly complex algorithm which accounts for the most typical factors in "average" sets of text. I think any improvements we could make would involve knowledge of how our data is not average. |
| 13:46 |
kmlussier |
Elaine: Well, I think that's a key element, then. Where the words are located, right? |
| 13:46 |
Cybrarian |
Funny story - I just had to help a student find a book in the catalog. :-) |
| 13:46 |
kmlussier |
dbwells: That's interesting. In what ways is our data not average? |
| 13:46 |
kmlussier |
Cybrarian: Were your search results relevant? |
| 13:46 |
Elaine |
kmlussier: yes -- 245 for title should always retrieve first, for example |
| 13:47 |
dbwells |
As others suggest, if we could easily weight title/author matches higher, that would be a win. We know those words are more important than average. |
| 13:47 |
kmlussier |
Elaine: OK, good, so we not only have word count, but more importantly, where they should appear. |
| 13:47 |
kmlussier |
And we do have that ability in Evergreen, but it's good to note that it's important.' |
| 13:47 |
|
linuxhiker joined #evergreen |
| 13:48 |
kmlussier |
dbwells: I'm going to pick up on something you said there. 'easily' Because we can weight author/title, but is it easy to do so? Especially for those who are new to Evergreen? |
| 13:48 |
linuxhiker |
Did the search discussion already end? |
| 13:48 |
dbwells |
It's not a new idea, of course, so the harder question is how. Not sure if we are supposed to talk about that part yet. |
| 13:48 |
kmlussier |
linuxhiker: It will end in about 10 minutes |
| 13:48 |
Elaine |
I also think not having to first navigate a long list of titles would be beneficial to most users regardless of the type of search |
| 13:48 |
dbs |
Easily and without impacting speed, of course :) |
| 13:48 |
Cybrarian |
Relevance to me is "did the words appears in the subject heading". |
| 13:48 |
kmlussier |
dbwells: No, I'm trying to avoid hows for now. |
| 13:49 |
kmlussier |
Cybrarian: I think it's important for each library to define which fields they want to be relevant. Because what's relevant in an academic environment may differ from a public or a k-12 |
| 13:50 |
kmlussier |
OK, any other thoughts on where Evergreen may fall short on relevance? Because I'm about ready to ask my final question. |
| 13:50 |
kmlussier |
#topic Highest priority for improvement |
| 13:51 |
kmlussier |
If you could only improve two things in Evergreen search, what would those 2 things be? |
| 13:51 |
linuxhiker |
speed |
| 13:51 |
kmlussier |
And be sure to focus on search for this question. |
| 13:51 |
Cybrarian |
true - relevance factors should be set for a location. |
| 13:51 |
Elaine |
Better cross references and having that intermediate returns screen |
| 13:51 |
tspindler |
speed and relevance |
| 13:51 |
tspindler |
speed might be higher than relevance |
| 13:51 |
Cybrarian |
I'm with Elaine |
| 13:52 |
kmlussier |
Elaine: I'm having trouble keeping up. Can you remind me what you mean by intermediate returns screen. I'm sure it's up higher in the disucssion. |
| 13:52 |
Elaine |
If I have a list of authors names Jones, Mary, rather than a list of several thousands of titles, I could drill down to what I want more readily |
| 13:52 |
Cybrarian |
I'd vote for speed first though. |
| 13:53 |
kmlussier |
Anyone else? There were way more people talking earlier who haven't answered this question. |
| 13:54 |
dbwells |
We wrote a custom search engine in our pre-EG days. One thing we had then was a way to *lower* relevancy based on certain factors. For example, one loss of relevancy came from being in a certain special collection. Another decrement came from having titles greater than 200 characters (or some very long length). I should go back and look up if we had any novel ideas back then :) |
| 13:54 |
linuxhiker |
I would note that due to speed AND relevancy, I know of at least one major library system that now outsources their evergreen search to a different technology |
| 13:54 |
tspindler |
dbwells: were the long titles special collections also? |
| 13:54 |
kmlussier |
Well, there are two more chats coming up with which to share those ideas if you find them. |
| 13:56 |
dbwells |
tspindler: we just did a broad survey of search results, and found a lot of stuff from, for example, the 1800s which had multi-sentence titles, and were getting to the top of many lists based on title "matching". |
| 13:56 |
kmlussier |
OK, I'm going to wrap things up then. But feel free to let me know if you get any other ideas. |
| 13:56 |
kmlussier |
#endmeeting |
| 13:56 |
pinesol_green |
Meeting ended Fri Mar 11 13:56:24 2016 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 13:56 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-11-13.01.html |
| 13:56 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-11-13.01.txt |
| 13:56 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-11-13.01.log.html |
| 13:56 |
dbwells |
I guess you could call them special collections. |
| 13:56 |
Elaine |
kmlussier:Thanks! |
| 13:57 |
|
Cybrarian left #evergreen |
| 13:57 |
berick |
kmlussier++ |
| 13:57 |
tspindler |
i only ask because many years ago i cataloged archives and some 245s could get long with MARC-AMC |
| 13:57 |
kmlussier |
Also, we do have two more chats coming up next week on Tuesday and Wednesday, both at 3 p.m. Eastern. |
| 13:57 |
tspindler |
kmlussier++ |
| 13:57 |
phasefx |
kmlussier++ |
| 13:57 |
dbwells |
kmlussier++ |
| 13:58 |
|
linuxhiker left #evergreen |
| 14:04 |
dbwells |
kmlussier: Do you know of any docs for the title/author boosts you were talking about? I think I am familiar with what's available, but hoping there is something more clever out there than what I've already seen. |
| 14:05 |
kmlussier |
dbwells: I did a presentation on it at the conference last year. I think I was up against you. Let me see if I can find it. |
| 14:06 |
kmlussier |
dbwells: But I initially found the info in a 1.6-era blog post from dbs. :) |
| 14:07 |
kmlussier |
Did anyone ever post presentations from last year's conference to the web site? |
| 14:07 |
kmlussier |
dbwells: http://slides.com/kathylussier/evergreen-search |
| 14:07 |
dbwells |
kmlussier: We've tried a lot of things over the years, but I think they never went into production for speed cost reasons. With a new server, maybe time to try again :) |
| 14:08 |
dbwells |
kmlussier++ thank you! |
| 14:08 |
gmcharlt |
kmlussier: generally, yes - http://evergreen-ils.org/conference/eg15/schedule/ |
| 14:09 |
kmlussier |
dbwells: If you're adding a title or author index for relevance, I don't think it will add to much cost to the speed. In our case, we've added a lot of indexes for various reasons, and I think it has hurt our speed. |
| 14:09 |
kmlussier |
On the other hand, we like having those indexes. |
| 14:11 |
Dyrcona |
Yay for SIP and SIP! |
| 14:12 |
Dyrcona |
:) |
| 14:15 |
Dyrcona |
We get to rename a server because two protocols have the same name and one vendor's implementation of one of them demands your hostname be sip.domain.tld. |
| 14:16 |
|
tspindler left #evergreen |
| 14:43 |
|
jlitrell joined #evergreen |
| 14:45 |
miker |
kmlussier++ |
| 14:48 |
miker |
that was a great search chat! regarding the "better metarecord handling", there was a c4l talk that showed basically my dream version of a metarecord result list. they "rediscovered" our concept of MRs (title+author grouping), calling it "FauxBR" ;) and showing all the subordinate records up front in an expanded display. once the talks from Thursday are up on youtube I'll point to it in here |
| 14:49 |
kmlussier |
miker: I saw you mention something about it in the code4lib channel. I'm very interested in seeing it. |
| 14:49 |
* kmlussier |
wanders away for the weekend. |
| 14:50 |
mmorgan |
kmlussier: Have a great weekend! |
| 15:01 |
dbs |
timely article: http://matthew.reidsrow.com/articles/173 "Algorithmic Bias in Library Discovery Systems" |
| 15:47 |
dbwells |
dbs++ |
| 15:53 |
Dyrcona |
@blame Dyrcona for broken hold history pagination |
| 15:53 |
pinesol_green |
Dyrcona: I come to bury Dyrcona, not to praise them. for broken hold history pagination |
| 15:54 |
Dyrcona |
Bah... Pick a different blame next, pinesol_green. |
| 16:11 |
Dyrcona |
@blame prng |
| 16:11 |
pinesol_green |
Dyrcona: Your failure is now complete, prng. |
| 17:10 |
|
mmorgan left #evergreen |
| 17:20 |
|
bmills joined #evergreen |
| 18:11 |
|
bmills joined #evergreen |
| 20:20 |
jeffdavis |
bug 1556339 |
| 20:20 |
pinesol_green |
Launchpad bug 1556339 in Evergreen "API attempts to use nonexistent user_visible_circs method" [Undecided,New] https://launchpad.net/bugs/1556339 - Assigned to Jeff Davis (jdavis-sitka) |
| 20:23 |
jeffdavis |
^ I'll be away next week but I think that bugfix needs to get into the release candidate |
| 20:40 |
|
Stompro joined #evergreen |
