| Time |
Nick |
Message |
| 00:10 |
|
b_bonner joined #evergreen |
| 00:11 |
|
mtcarlson_away joined #evergreen |
| 00:37 |
|
b_bonner_ joined #evergreen |
| 00:38 |
|
mtcarlson_away joined #evergreen |
| 03:50 |
|
b_bonner joined #evergreen |
| 03:51 |
|
mtcarlson_away joined #evergreen |
| 04:24 |
paxed |
what i really like about Koha is their help system. a link on top right of each page which opens a page on local "wiki" for that page. |
| 06:52 |
|
phasefx joined #evergreen |
| 07:27 |
|
jboyer-isl joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:53 |
|
Callender_ joined #evergreen |
| 07:53 |
|
collum joined #evergreen |
| 07:55 |
|
Callender__ joined #evergreen |
| 07:57 |
|
Callender joined #evergreen |
| 08:19 |
|
akilsdonk joined #evergreen |
| 08:34 |
|
kbeswick joined #evergreen |
| 08:41 |
|
mdriscoll left #evergreen |
| 08:42 |
|
mdriscoll joined #evergreen |
| 08:48 |
|
kmlussier joined #evergreen |
| 08:51 |
|
timlaptop joined #evergreen |
| 08:51 |
|
mmorgan joined #evergreen |
| 08:52 |
|
mrpeters joined #evergreen |
| 08:59 |
|
ericar joined #evergreen |
| 09:38 |
|
dbwells_ joined #evergreen |
| 09:38 |
|
Guest72764 joined #evergreen |
| 10:26 |
|
dbwells_ joined #evergreen |
| 10:57 |
|
RBecker joined #evergreen |
| 10:57 |
|
RBecker joined #evergreen |
| 11:04 |
|
BigRig_ joined #evergreen |
| 11:05 |
|
BigRig_ joined #evergreen |
| 11:09 |
|
misilot joined #evergreen |
| 11:19 |
|
rfrasur joined #evergreen |
| 11:22 |
rfrasur |
Has anyone deployed a discovery layer over EG...If so, do you have a link? |
| 11:26 |
jcamins |
rfrasur: I'll be interested to hear what you learn about that? An EG driver for Biblionarrator is on my to-do list. |
| 11:26 |
jcamins |
s/\?/./ |
| 11:27 |
kmlussier |
I thought Pennsylavani was using VuFind, but I just looked at their web site and only see tpac. |
| 11:28 |
rfrasur |
jcamins: whatever I find out, I'll share (if it's not in here...ya know...redundancy) |
| 11:28 |
rfrasur |
kmlussier: I've heard urban legends of VuFind.... |
| 11:29 |
jcamins |
rfrasur: why are you looking at discovery layers, out of curiosity? |
| 11:29 |
kmlussier |
rfrasur: http://list.georgialibraries.org/pipermail/open-ils-general/2013-April/008394.html |
| 11:30 |
jcamins |
Huh. I didn't realize IISG was Evergreen. |
| 11:31 |
rfrasur |
jcamins: it's a conversation amongst our consortium members about pulling all our resources together. I know EG has the technical capability to handle anything...BUT we have some policy things that are in the way...at least right now. |
| 11:31 |
jcamins |
rfrasur: I've moved away from my belief in ILSes. Not that my belief in the current crop of discovery layers is any stronger. |
| 11:32 |
|
phasefx2 joined #evergreen |
| 11:35 |
rfrasur |
jcamins: I dunno what the answer is. I just know that it's something that we (librarians, at least. I dunno other people's perspectives beyond anecdotes) need to be actively thinking/doing something about our disparate resources. |
| 11:36 |
rfrasur |
kmlussier: ty. That's exactly what I want to see. I wish they were closer. |
| 11:36 |
* rfrasur |
would hijack them at a conference or something. |
| 11:37 |
kmlussier |
rfrasur: I've also heard that KCLS is planning to move to BiblioCommons, but it doesn't look like the move has happened yet. |
| 11:37 |
jcamins |
rfrasur: I think that a discovery layer that put aside the card catalog mentality is part of the answer. I'm not sure what the other part is. |
| 11:37 |
kmlussier |
http://www.librarytechnology.org/ltg-displaytext.pl?RC=17777 |
| 11:39 |
rfrasur |
explain the card catalog mentality briefly. |
| 11:41 |
jcamins |
rfrasur: ILSes, OPACs, and the current crop of discovery layers take the approach that online catalogs can be used like a card catalog. |
| 11:41 |
jcamins |
Enter term, flip through cards, select books, win. |
| 11:41 |
jcamins |
But when you work with a card catalog, how many cards can you flip through in, say, thirty seconds? |
| 11:41 |
jcamins |
Dozens. |
| 11:42 |
jcamins |
Maybe hundreds. |
| 11:42 |
* rfrasur |
listens |
| 11:42 |
jcamins |
With an online catalog? |
| 11:42 |
jcamins |
20. |
| 11:42 |
jcamins |
Maybe. |
| 11:42 |
jcamins |
And meanwhile we have more books. |
| 11:42 |
jcamins |
So that's a problem. |
| 11:42 |
rfrasur |
what might the alternative look like? |
| 11:43 |
jcamins |
Better relevancy ranking, not just based on search terms, but also based on what the patron is probably looking for. |
| 11:43 |
jcamins |
How many times do you go past... say, three pages on Google? |
| 11:43 |
rfrasur |
more of an Amazon search? |
| 11:44 |
rfrasur |
Never. Well, I have, but it was a fool's errand. |
| 11:44 |
kmlussier |
jcamins: I'm with you on the better relevancy ranking, but how do we do that? Popularity metrics or are you thinking we need more information about the user in question? |
| 11:44 |
jcamins |
Amazon does okay for buying, but we're libraries. |
| 11:44 |
jcamins |
Why do people come to libraries? |
| 11:44 |
phasefx |
we were resistant to giving Evergreen "browse" early on |
| 11:44 |
* jcamins |
thinks they come to libraries for the following reasons: |
| 11:44 |
jcamins |
1) to find something out, |
| 11:45 |
jcamins |
2) to find something to do, |
| 11:45 |
jcamins |
3) because they need a public bathroom. |
| 11:45 |
jcamins |
Disregard three, they won't need an OPAC. |
| 11:45 |
rfrasur |
lol...maybe |
| 11:45 |
jcamins |
The reason Google wins over the OPAC is reason 1. |
| 11:46 |
|
moodaepo joined #evergreen |
| 11:46 |
jcamins |
The OPAC is a bunch of digitized catalog cards. If you want information about something other than the book, you're SOL. On the other hand, search Google with the same term (say, a name), and the first result tells you a little something about the person. |
| 11:47 |
jcamins |
Birth date, death date, maybe a one sentence summary ("Military officer and provocateur, John Smith was known for getting lots of people angry at him, then running away across the ocean.") |
| 11:47 |
rfrasur |
ahhh...okay. So the beef is with the information that we use. The MARC/card. |
| 11:48 |
jcamins |
My vision for a discovery layer is one that combines relevancy ranking that takes into account closely related materials (you searched for "john smith pocahontas," so if the first ten results are all about Jamestown Colony, let's show you more about Jamestown Colony, eh?), and also integrates authority data. |
| 11:48 |
jcamins |
I use Wikipedia to look up everything. |
| 11:49 |
jcamins |
Then if I want more, I go to the library catalog and copy and paste things out of Wikipedia. |
| 11:49 |
jcamins |
It's faster. |
| 11:49 |
rfrasur |
yep |
| 11:49 |
* rfrasur |
does too |
| 11:49 |
* jcamins |
thinks it's absurd that we don't have any of that information in our catalogs. |
| 11:50 |
jcamins |
kmlussier: relevance is hard. And I'm definitely not an expert. |
| 11:51 |
jcamins |
But I do know that if I can say "this search results in lots of books that have these N things in common," I can probably also say "... so I might as well show the user more books with these N things, because I can't collect the level of information I'd need to answer definitively what the user wants" (i.e. replicate Google's data mining). |
| 11:52 |
jcamins |
I'd also like to see the catalog provide more ways to take in information. Computer screens are not optimized for reading long scrolling lists. |
| 11:52 |
jcamins |
So I'm trying maps, etc. |
| 11:53 |
jboyer-isl |
I don't want to put down your idea because there are lots of good parts, but I think people underestimate the volumes of data that Google has on you, specifically, when they wish that opac searches could be more like Google. The only way to be as effective as the largest advertising company in the world, is to be the largest advertising company in the world. |
| 11:53 |
rfrasur |
Honestly...and this shows how much I know...I thought each search into the catalog was a type of data mining |
| 11:54 |
jcamins |
jboyer-isl: right, that's why I think we *can't* replicate the relevance. |
| 11:54 |
* rfrasur |
takes it all in. |
| 11:54 |
jcamins |
The best we can do is my incredibly weak heuristic. |
| 11:55 |
jcamins |
That said, I think it's a better heuristic than none at all, which is the traditional approach. |
| 11:55 |
jboyer-isl |
Would that mean adding a ton of records for things not already in the catalog (or using authority records for people/places not necessarily referenced in records directly?) |
| 11:56 |
phasefx |
brain storming; maybe we can define/expose contexts that a user can choose from, like, "I'm a layperson", "I'm a student studying ___", etc. to help inform the search |
| 11:56 |
jcamins |
jboyer-isl: yeah, I don't see how we can make the OPAC useful without adding Overdrive, etc. |
| 11:56 |
jcamins |
As for authorities, it doesn't make sense to add authorities that aren't used, IMO. |
| 11:56 |
|
smyers_ joined #evergreen |
| 11:57 |
rfrasur |
phasefx: build a small reference interview into the experience? |
| 11:57 |
jcamins |
Unless your goal is to just provide a ready reference tool, without any bibliographic/holdings component, in which case you may as well just use Wikipedia, IMO. |
| 11:57 |
phasefx |
rfrasur: as an option |
| 11:58 |
phasefx |
Wikipedia is CC-BY-SA too, so we could slurp that data in and make use of it somehow |
| 11:58 |
jcamins |
But I think Wikipedia is probably more reliable than Encyclopedia Britannica, on average, so take my opinion with a grain of salt. |
| 11:58 |
jcamins |
phasefx: exactly! |
| 11:58 |
jcamins |
Think of it! Use viaf to disambiguate between your NACO headings and Wikipedia, then people get biographies and can check "is that really the author I want?" in the OPAC. |
| 11:59 |
rfrasur |
how? (hah! just kidding...I don't expect an answer...right now) |
| 11:59 |
jcamins |
http://libdemo.biblionarrator.com/search?q=henry+ward+beecher# |
| 11:59 |
jcamins |
That's the University of Michigan's records. I actually loaded it prior to adjusting relevance, so relevance is backwards. |
| 12:00 |
|
smyers_ joined #evergreen |
| 12:00 |
jcamins |
And I haven't written my Wikipedia harvester yet. But if I'm researching Henry Ward Beecher, having his biography right there would be kind of useful. |
| 12:01 |
phasefx |
another idea from the past, I think it would be neat for librarians to be able to create "canned searches" with wiki-like augmentations |
| 12:01 |
|
jdouma joined #evergreen |
| 12:01 |
phasefx |
the whole wordpress/opac thing was neat |
| 12:01 |
phasefx |
scriblio |
| 12:01 |
jcamins |
And for a more complicated search, the visualization can lead you to things you wouldn't expect. |
| 12:02 |
kmlussier |
dbwells++ #Release Notes are looking much better. :) |
| 12:02 |
jcamins |
"Oh, I see, these three books with random titles are actually in the center of my conceptual space." |
| 12:02 |
phasefx |
one advantage that a lot of libraries has is that they know their audience/community; google has to cater to everyone |
| 12:02 |
jcamins |
... except replace "conceptual space" with something that real people say. |
| 12:03 |
jcamins |
phasefx: that's true, especially in special libraries. |
| 12:04 |
* phasefx |
used to think that having essentially finite records was an advantage; not so sure these days |
| 12:05 |
phasefx |
jcamins: I've heard the notion of making the OPAC into a research tool/workspace before, where folks could gather/create/edit information |
| 12:05 |
phasefx |
share |
| 12:06 |
jcamins |
phasefx: yes. This. That is exactly what I feel it needs to be. |
| 12:06 |
phasefx |
a step in that direction would be spatial bookbags, where you can drag your resources wherever like on a post-it board |
| 12:07 |
jcamins |
Ooh, I like that idea. |
| 12:07 |
phasefx |
all good OPACs have lists/bookbags, and can "share", but none can really "consume" |
| 12:07 |
* jcamins |
borrows it. |
| 12:08 |
* phasefx |
wants to take jcamins' reading list and incorporate it into his workspace |
| 12:08 |
jcamins |
My list concept only involved one dimensional organization, but two dimensions is much better. |
| 12:08 |
phasefx |
humans have excellent spatial memory |
| 12:08 |
jcamins |
Three dimensions and a thingy-flow would be even cooler, of course. |
| 12:09 |
phasefx |
I can remember where on a page better than a page number |
| 12:09 |
jcamins |
phasefx: you can probably even remember where in a book better than a page number. |
| 12:09 |
* phasefx |
nods |
| 12:10 |
phasefx |
jcamins: let me know if you do the spatial bookbag thing; would love to see it |
| 12:10 |
jcamins |
phasefx: I think I definitely will. It's brilliant. |
| 12:10 |
jcamins |
And well beyond my current capabilities, d3js-wise! What's not to love? |
| 12:11 |
phasefx |
:D |
| 12:11 |
* phasefx |
can't imagine how to get it into the javascript-lite TPAC :) |
| 12:11 |
jcamins |
phasefx: use a discovery layer, probably. |
| 12:12 |
jcamins |
Poor rfrasur. I hope I have not scared her away from discovery layers. |
| 12:12 |
phasefx |
jcamins: make it like android, where if you drag a resource onto another resource, they get grouped |
| 12:13 |
jcamins |
phasefx: oh, that reminds me. |
| 12:13 |
rfrasur |
I'm sorry...I was actually listening in the conference and thinking at the same time. It takes much to scare me. |
| 12:13 |
jcamins |
The other thing about discovery layers. |
| 12:13 |
jcamins |
And catalogs generally. |
| 12:13 |
jcamins |
Desktops are a lousy interface for them. |
| 12:13 |
rfrasur |
You made me think about how we're dealing with the information...and what the priority...at my end...needs to be. |
| 12:14 |
jcamins |
At first they were all we had, but now we have tablets and kiosks... and we're not using those devices' capabilities. |
| 12:14 |
rfrasur |
The reference interview is the BEST interface. |
| 12:14 |
phasefx |
man, a mobile app with gps and awareness of a library's physical layout would be interesting |
| 12:14 |
rfrasur |
If you could plug the librarian person into the catalog...that'd be the best discovery layer (which I think we do). |
| 12:15 |
rfrasur |
librarians = original discovery layer |
| 12:15 |
phasefx |
imagine the geocaching type games you could get kids to play |
| 12:15 |
phasefx |
with books |
| 12:16 |
jcamins |
rfrasur: a lot of libraries don't have the luxury of enough librarians, and a good catalog is the best they can do. |
| 12:16 |
phasefx |
rfrasur: the way it seems to work most of the time these days is "ask your friends, and they ask the internet" |
| 12:16 |
rfrasur |
jcamins: phasefx: you're both right |
| 12:16 |
jcamins |
Well, a good catalog is the best they _could_ do. |
| 12:17 |
jcamins |
Often they don't do, but in a theoretical sense, there could be a good catalog. |
| 12:23 |
jcamins |
jboyer-isl: I suppose if you knew that your constituency was particularly interested in a particular thing you might load authority records relating to it, even if you didn't have any books on it. |
| 12:23 |
jcamins |
For example, a library with a large Russian immigrant population might choose to load authority records for major Russian authors, even if the acquisitions budget is too small to acquire anything by some of the less well-known ones. |
| 12:24 |
jboyer-isl |
jcamins: I think the only big point to unused auth records could be following the see or see also refs for records that match, even if there aren't direct uses of those records. I was spitballing a bit at the time. |
| 12:24 |
jcamins |
jboyer-isl: oh, I may have missed making one point about my vision clear... only valid links should show up. |
| 12:25 |
jcamins |
At present I don't have to worry about that in Biblionarrator, because I am loading only those records that are linked. |
| 12:25 |
jboyer-isl |
i see. |
| 12:25 |
jcamins |
That's definitely a crucial point, that there not be any blind links. |
| 12:25 |
* bshum |
catches up on the scrollback |
| 12:25 |
jcamins |
That's why I ended up with a graph database. |
| 12:26 |
bshum |
kmlussier: Houston Public Library in SITKA was an example of a bibliocommons using Evergreen lib: http://houstonbc.bibliocommons.com/ |
| 12:26 |
bshum |
We looked at them once upon a time |
| 12:26 |
* rfrasur |
checks out Houston. |
| 12:26 |
kmlussier |
dbwells: I'm almost ready to push a bunch of new release note entries for features that were missing notes. I just want to make sure I should still be pushing them to the subdirectories of the RELEASE_NOTES_NEXT folder? Will you be running the script again at release time? |
| 12:26 |
bshum |
Their library website seems to have links to both the SITKA catalogue as well as Bibliocommons. |
| 12:26 |
jcamins |
I really liked BiblioCommons the first time I looked at it, but recently it seems to have gotten less functional. |
| 12:26 |
bshum |
So maybe they're still deciding |
| 12:27 |
bshum |
Or TPAC is swaying them back :) |
| 12:27 |
kmlussier |
Nice! I really like BiblioCommons. But I haven't looked at it recently. |
| 12:28 |
bshum |
As for VuFind, the SPARK libs in PA probably switched back to TPAC I think when ESI took over as their hosts. Prior to that they definitely were using VuFind. |
| 12:28 |
bshum |
I can't find a nice link to the Tasmania libraries |
| 12:28 |
bshum |
They've been quiet, but in the past had indicated using Evergreen + VuFind |
| 12:28 |
bshum |
PALS used to use VuFind too, though I'm unclear on whether they've actively done anything with it, or if they're also switched to TPAC. |
| 12:30 |
jcamins |
bshum: who is PALS? I think there are several library systems with that acronym. |
| 12:30 |
bshum |
jcamins: Sorry, erm... MNPALS (Minnesota). It's the only PALS I know of in the Evergreen sphere :) |
| 12:30 |
bshum |
But looking around them, I don't see much about VuFind and all the libraries on Evergreen link to TPACs |
| 12:31 |
bshum |
So they must have went a different way |
| 12:31 |
jcamins |
Thanks. I know the catalog librarian at a PALS in NJ, and she never once mentioned migrating to Evergreen, so I figured it wasn't them. |
| 12:31 |
dbwells |
kmlussier: yes, I plan to redo them again. The way I did it for the beta was pretty ad hoc, so hopefully the second time through I can be a little more systematic about it. |
| 12:32 |
kmlussier |
dbwells: Great! That's what I was hoping you would say. :) |
| 12:35 |
|
yboston joined #evergreen |
| 12:38 |
bshum |
dbwells: So we're testing that fix for receiving |
| 12:38 |
bshum |
dbwells: And it looks like it received properly and we created the item |
| 12:38 |
bshum |
But apparently the range in the summary holdings doesn't show the updated issue |
| 12:40 |
dbwells |
bshum: what holdings display are you using? |
| 12:40 |
bshum |
Mary was looking at http://acorn.biblio.org/eg/opac/record/2236299?expand=issues;sid=1644;stype=basic;sepath=2013;sepath=09;seoffset=0;seoffset=0;seoffset=0#issues for example. |
| 12:40 |
bshum |
Where the last issue that was just added was the Sept 15 one |
| 12:40 |
bshum |
But the range isn't updated |
| 12:41 |
|
ericar joined #evergreen |
| 12:43 |
dbwells |
bshum: looking at it, but by the way, if you put those caption parts in parens (), they won't display so oddly, e.g. "$i (year)" instead of "$i year". |
| 12:43 |
bshum |
dbwells: I'll mention that to her. |
| 12:43 |
kmlussier |
bshum: Any chance it is related to bug 1000397? |
| 12:43 |
pinesol_green |
Launchpad bug 1000397 in Evergreen "Receiving unitless issues in the batch receive interface does not update tpac holdings summary" (affected: 2, heat: 10) [Undecided,Triaged] https://launchpad.net/bugs/1000397 |
| 12:43 |
bshum |
I'll ask |
| 12:44 |
dbwells |
I see a barcode, so I don't think it is that, but it could be somehow related. |
| 12:46 |
|
akilsdonk joined #evergreen |
| 12:46 |
dbwells |
I should probably just say "Oh, 'use fully compressed holdings'? That's senator's problem." ;) |
| 12:50 |
|
mllewellyn joined #evergreen |
| 12:58 |
_bott_ |
I hate weird problems. |
| 12:58 |
dbwells |
bshum: I can see what you are saying on the record you posted, but I can't duplicate it on my test box. I'd need to see the exact holding codes for your Sep.08 and Sep.15 issues, I guess, then go from there. |
| 12:59 |
* dbwells |
goes to lunch, back in a bit |
| 12:59 |
_bott_ |
Has anyone found the status_changed_time trigger not firing consistently? I have random cases where the status is changed at checkin, but the status_changed_time is not updated, it's left at the checkout time. This in turn screws up reshelving delay. |
| 13:08 |
bshum |
dbwells++ # we figured it out, it was a local holding_code problem |
| 13:08 |
bshum |
The holding_code had been modified with a bad copy/paste and the date in the code was 08 not 15 |
| 13:08 |
bshum |
User error |
| 13:08 |
bshum |
We'll test again with another sample, but I think this means your patch works to resolve the receiving problem. |
| 13:10 |
|
ericar joined #evergreen |
| 13:11 |
pinesol_green |
[evergreen|Kathy Lussier] Move various release notes into correct directory - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=30a69c4> |
| 13:11 |
pinesol_green |
[evergreen|Kathy Lussier] Adding new OPAC features to Release Notes. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e66a212> |
| 13:12 |
pinesol_green |
[evergreen|Kathy Lussier] Release note additions for new acquisitions features - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=51f6c9c> |
| 13:12 |
pinesol_green |
[evergreen|Kathy Lussier] More release note entries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ebb94c3> |
| 13:19 |
|
rfrasur joined #evergreen |
| 13:20 |
mllewellyn |
pleading guilty to the operator causing the error. |
| 13:31 |
|
RoganH joined #evergreen |
| 13:42 |
dbwells |
bshum: yay :) |
| 13:42 |
bshum |
dbwells: Yep, she tested on a different issue and it received perfectly fine. |
| 13:42 |
bshum |
I'll sign off on your fix and get that pushed to master. |
| 13:43 |
bshum |
dbwells++ |
| 13:45 |
rfrasur |
jcamins: this speaker is talking exactly what you were talking about earlier... |
| 13:46 |
pinesol_green |
[evergreen|Dan Wells] Relax MFHD subfield 'a' requirement for caption/patterns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a420b0e> |
| 13:46 |
jcamins |
rfrasur: oh? What speaker? |
| 13:46 |
rfrasur |
Ted Fons from OCLC' |
| 13:47 |
jcamins |
What conference are you at? |
| 13:49 |
rfrasur |
Midwest Cooperative for Library Services Annual Meeting (it's about open stuff this year...open access...data...source) |
| 13:49 |
* rfrasur |
thinks we should pool our money and buy some really expensive stuff from Google |
| 13:51 |
rfrasur |
He's talking about knowledge graphs which sounds a lot like the maps you were talking about. |
| 13:52 |
jcamins |
Does Google have really expensive stuff to sell us? |
| 13:53 |
rfrasur |
I dunno. |
| 13:53 |
rfrasur |
But they must, right? |
| 13:53 |
jcamins |
Expensive stuff, yeah, but I don't think they sell it. |
| 13:53 |
rfrasur |
https://docs.google.com/document/d/1ZU9sQrAkI88_NSGSDUyMiYRnnNDQcUO2SJOjJANtj0o/edit?usp=sharing My notes |
| 13:55 |
jcamins |
Interesting. |
| 13:55 |
* jcamins |
watches you type. :P |
| 13:55 |
dbwells |
I am seeing an issue with title browsing on 2.5-beta1, and am hoping for someone more familiar with the feature to troubleshoot or verify what is happening. On a clean install, I imported three records, but see 6 titles in browse. For four of the six, the only difference is trailing punctuation. |
| 13:56 |
dbwells |
For the other pair, one has a subtitle, one doesn't. |
| 13:56 |
rfrasur |
jcamins: you can see how often I delete |
| 14:00 |
jcamins |
rfrasur: was his list of how OCLC was doing this as hand wavy as it looks? |
| 14:01 |
|
kayals joined #evergreen |
| 14:01 |
rfrasur |
It wasn't to begin with...it was to end with. |
| 14:03 |
jcamins |
"Network of links and entity identifiers" really bugs me. |
| 14:04 |
rfrasur |
That part was pretty ambiguous...about the "network of links and entity identifiers" |
| 14:04 |
jcamins |
Yeah, that's why it bugs me. |
| 14:04 |
bshum |
dbwells: The punctuation difference is something that still irks me about browse search. |
| 14:04 |
jcamins |
That's what jumped out as hand-wavy. |
| 14:04 |
bshum |
Same with case sensitivity, all caps, vs. initcap vs. all lowercase |
| 14:04 |
rfrasur |
the way he framed entity identifiers is basically authorities...although maybe a little more robust? |
| 14:05 |
jcamins |
Robust like... the way everything ground to a halt when LC shut down their website the other day? Yeah... |
| 14:05 |
jcamins |
I can translate for you, if you like: "web pages with URLs." |
| 14:05 |
bshum |
dbwells: I think it was noted during the development but I'm not sure what the result was. kmlussier / ESI would know best, but I think it needs more development to solve. |
| 14:05 |
rfrasur |
well....robust as in LOTS of authorities |
| 14:05 |
jcamins |
Oh, I was thinking robust as in "can't fail." |
| 14:05 |
dbwells |
bshum: Well, what I am seeing seems to stem from the fact that browsing includes both 'Title Proper' fields, and 'Title Proper (Browse)' fields. |
| 14:06 |
rfrasur |
everything can fail :D |
| 14:06 |
rfrasur |
no. everything WILL fail. |
| 14:06 |
jcamins |
And usually right when you have to prepare reports for management. |
| 14:06 |
rfrasur |
inevitably |
| 14:07 |
kmlussier |
dbwells: That's right. We noticed the trailing punctuation issue and would like to change it. But it does require more development that wasn't covered under our project. |
| 14:07 |
bshum |
dbwells: Huh... I don't have a title proper (browse) in my production DB.... |
| 14:07 |
kmlussier |
IIRC, when you are using authority records, it isn't as noticeable with author or subject browsing. But authorities don't help much with a title browse. |
| 14:07 |
* bshum |
checks clean master |
| 14:08 |
bshum |
Gah, wth |
| 14:08 |
kmlussier |
I've noticed the same issue in autosuggest too. |
| 14:08 |
dbwells |
kmlussier: I am actually less concerned about the trailing punctuation, and more concerned about the duplication. Is there a reason we have both "Title Proper" and "Title Proper (Browse)" set as browseable fields, or is that just a mistake? |
| 14:10 |
kmlussier |
dbwells: Ah, that's something I don't remember seeing. |
| 14:10 |
dbwells |
Maybe it is a non-filing issue or something? |
| 14:12 |
bshum |
Huh |
| 14:12 |
senator |
dbwells: they definitely don't both need to be set as browseable fields |
| 14:12 |
senator |
that's a mistake in the seed data i suppose |
| 14:12 |
bshum |
The upgrade SQL didn't add title proper (browse) |
| 14:12 |
bshum |
Which is why I don't see it in my production database |
| 14:12 |
senator |
i'll look back and see if both were even meant to survive, or just title proper alone |
| 14:13 |
bshum |
So if it's meant to live, that's missing from the upgrade SQL |
| 14:15 |
rfrasur |
This next one is "The inevitability of open access" https://docs.google.com/document/d/1Ho3FMLfP_q2xVjtdBDPKZXCuiT11gSTW8LovfM8kk9U/edit?usp=sharing (then I'm going home). |
| 14:22 |
jeff |
"You hear that Mr. Anderson? That is the sound of inevitibility." |
| 14:22 |
gmcharlt |
:) |
| 14:24 |
rfrasur |
jeff++ |
| 14:26 |
jcamins |
Kind of a bad time to be talking about the inevitability of open access. |
| 14:27 |
jcamins |
It was what, yesterday, that Science released their study of how peer review in open access journals is shameful? |
| 14:28 |
jcamins |
Non-OA journals are probably equally shameful, but at least the argument for non-OA isn't "openness improves transparency." |
| 14:31 |
gmcharlt |
jcamins: given that the author of that paper neglected to submit it to any proprietary journals, who can tell? |
| 14:31 |
gmcharlt |
at the very least, Science comes off as rather self-serving |
| 14:32 |
jcamins |
gmcharlt: yeah, as I said, non-OA journals are probably just as bad, but if >50% of the journals submitted to accepted it for publication, the issue should not be OA vs non-OA, it should be "how do we make scholarship work at all?" |
| 14:33 |
rfrasur |
jcamins: that's been a running joke today...we're talking about this and THAT was on the news this morning. |
| 14:33 |
gmcharlt |
jcamins: possibly a revamping of the peer review process |
| 14:33 |
rfrasur |
(not a funny joke...an ironic joke) |
| 14:33 |
gmcharlt |
around the notion that it's a continuous action of the community, not a once-and-done-to-get-pubished thing |
| 14:34 |
rfrasur |
gmcharlt++ |
| 14:34 |
* rfrasur |
hasn't read the Science article, but will. |
| 14:34 |
jcamins |
gmcharlt: yeah, and probably some serious tenure reform, which is why it won't get fixed any time soon. |
| 14:34 |
gmcharlt |
some links for light reading |
| 14:34 |
gmcharlt |
http://www.michaeleisen.org/blog/?p=1439 |
| 14:35 |
gmcharlt |
https://plus.google.com/u/0/109377556796183035206/posts/CRHeCAtQqGq |
| 14:35 |
gmcharlt |
http://svpow.com/2013/10/03/john-bohannons-peer-review-sting-against-science/ |
| 14:35 |
gmcharlt |
not that I have been following this or anything ;) |
| 14:36 |
jcamins |
gmcharlt: I only saw it because the headline crossed my RSS feeds. I'm actually fairly disinterested, having concluded long ago that scholarship is pretty hopeless. |
| 14:39 |
|
krvmga joined #evergreen |
| 14:40 |
rfrasur |
He's talking about "post publication review." |
| 14:41 |
* rfrasur |
loves the phrase "systematic crawling of the literature." |
| 14:41 |
rfrasur |
yes please |
| 14:42 |
mrpeters |
question -- is inactivity a potential cause for open-ils.auth to die off around the same time every day? |
| 14:43 |
tsbere |
mrpeters: I assume that too much activity would be more problematic. Otherwise it would die off every night, wouldn't it? |
| 14:43 |
jeff |
open-ils.auth shouldn't "die" due to inactivity, but what are you seeing? |
| 14:43 |
mrpeters |
looking at a system that isn't "live" yet, but seeing some staff use...auth just dies around noon everyday. wondering if people going to lunch or something is causing the service to stop listening |
| 14:43 |
mrpeters |
tsbere: that's true |
| 14:43 |
* mrpeters |
thinks the values for drones, etc. may be stock |
| 14:44 |
mrpeters |
might need to be increased |
| 14:44 |
jeff |
mrpeters: are there external symptoms (people can't use the system), or are you just looking at a log entry saying that a process exited/etc? |
| 14:44 |
mrpeters |
jeff: staff client login fails with the same type of alert that you'd get if you miskeyed your pw |
| 14:46 |
tsbere |
mrpeters: Too many bad password attempts in a short period of time causing lockout? |
| 14:46 |
mrpeters |
would that cause auth to die? |
| 14:46 |
jeff |
mrpeters: And what do the logs say around that time? |
| 14:46 |
tsbere |
Shouldn't kill auth, but that symptom would happen |
| 14:47 |
mrpeters |
someone hammers it with the wrong password over and over |
| 14:47 |
mrpeters |
well, the thing is, ejabberdctl connected-users says auth is gone |
| 14:47 |
tsbere |
Ok, that would be an indicator of a problem, yea |
| 14:47 |
tsbere |
Is the listener still running at that point? |
| 14:47 |
mrpeters |
let me sanitize these logs |
| 14:49 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "open-ils.auth dying off" (29 lines) at http://paste.evergreen-ils.org/26 |
| 14:49 |
jeff |
mrpeters: In your troubleshooting, I'd start with... how long has this pattern gone on? two days, a week? Any changes during that time? Any other interesting things / errors near that time? |
| 14:49 |
mrpeters |
jeff: its been happening since implementation |
| 14:49 |
mrpeters |
we got called in about a week ago on it |
| 14:49 |
mrpeters |
i've got a lot of log digging to go, i mostly wondered if inactivity would cause that listener or drone to die off |
| 14:50 |
jeff |
Nope, shouldn't. Good luck in your investigation. :-) |
| 14:50 |
mrpeters |
thanks jeff |
| 14:50 |
mrpeters |
will let everyone know what i figure out, for the logs |
| 14:51 |
tsbere |
mrpeters: Is the *router* auth the only one gone? Or is the listener gone? If the latter, is the listener process still running, just not connected? The latter can happen if something kicks it off of ejabberd, such as a protocol level error... |
| 14:55 |
|
yboston left #evergreen |
| 14:55 |
|
yboston joined #evergreen |
| 14:59 |
mrpeters |
tsbere: good question, let me confirm |
| 14:59 |
mrpeters |
hmm, what do the listener procs look like in ejabberd-ctl |
| 15:00 |
dbwells |
So, my failed attempt at searching Google for 'mods32' did manage to find some random SpiceJet Flight which apparently involves time travel (departs tomorrow, arrives TODAY). https://www.google.com/search?q=mod32 |
| 15:00 |
tsbere |
mrpeters: opensrf private.localhost/open-ils.auth_listener_HOSTNAME_TIMESTAMP_PID I think |
| 15:01 |
dbwells |
For anyone who wants to repeat today, for some reason. |
| 15:01 |
mrpeters |
weird....the app servers show both open-ils.auth Listener and Drone running |
| 15:03 |
mrpeters |
don |
| 15:03 |
tsbere |
mrpeters: The router will drop the service if it can't talk to the last listener. Anything talking to ejabberd can be kicked off by a XMPP-level error... |
| 15:03 |
tsbere |
or if something else logs in with the same resource ID |
| 15:04 |
mrpeters |
oops....don't see any auth_listener processes connected to the brick head's connected-users |
| 15:04 |
mrpeters |
so, it would seem the listener dies first, then the router kills the process off |
| 15:05 |
tsbere |
mrpeters: I would check the ejabberd logs, see if you can see what killed the listener's connection |
| 15:06 |
mrpeters |
will do. thanks |
| 15:06 |
mrpeters |
best practice question -- the brick heads here only have opensrf.settings running. Would it be better practice for auth to run there than the app servers? |
| 15:08 |
tsbere |
the only best practice I know on that front is "you should only run settings on one box" |
| 15:09 |
tsbere |
Though "running cstore, rstore, pcrud, and storage on a drone that has a direct link to the DB server if you have one" isn't bad either... |
| 15:10 |
jeffdavis |
mrpeters: FWIW we run settings and auth on our brick heasds |
| 15:11 |
tsbere |
mrpeters: If auth is dieing on *multiple* drones within a short period of time I would assume a failed attempt being repeated until no drones are left....which might indicate an attack, actually... |
| 15:12 |
mrpeters |
i'd highly doubt an attack....possible, but highly doubtful. logs don't seem to indicate it. |
| 15:13 |
tsbere |
If you can take down a service with only a few calls, killing one listener with each as the router loops through them, it might not look like an attack at all |
| 15:15 |
mrpeters |
jabber logs don't seem to indicate anything about the service dying |
| 15:16 |
mrpeters |
lots of accepted legacy authentication and close sessions, but |
| 15:16 |
tsbere |
mrpeters: The two most common issues I have seen were "too much data" and "malformed XML", at least on the XMPP side |
| 15:16 |
mrpeters |
you'd see something like that in the ejabberd.log you say? |
| 15:17 |
mrpeters |
no instances of those |
| 15:17 |
* paxed |
ponders how hard it would be to implement "wiki"-like help, like in Koha... |
| 15:17 |
* mrpeters |
debates just upping the drones for auth, but also debates moving auth to the brick head because thats how I've always had succcess |
| 15:18 |
mrpeters |
its just weird to me that the listener and drone still show up in a "ps aux | grep auth" |
| 15:18 |
mrpeters |
but dont show as connected to jabber |
| 15:18 |
tsbere |
mrpeters: I doubt moving to the brickhead would help. *something* is kicking it off of jabber, you need to find out what. |
| 15:19 |
mrpeters |
maybe jabber logs aren't set at high enough verbosity |
| 15:50 |
pinesol_green |
[evergreen|Kathy Lussier] Move some release notes to core docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1d2326> |
| 16:33 |
|
mrpeters left #evergreen |
| 16:38 |
|
rfrasur joined #evergreen |
| 16:39 |
dbwells |
senator: I see your browse fix branch. Is it your opinion that no upgrade script is necessary? I'm inclined to agree, since it only affects those who installed fresh from master/beta1 after the branch was merged, which should be very few people. |
| 16:41 |
senator |
dbwells: yes |
| 16:42 |
senator |
sorry i got into other things and didn't push that earlier |
| 16:42 |
senator |
bug 1235452 |
| 16:42 |
pinesol_green |
Launchpad bug 1235452 in Evergreen "Remove unnecessary Title Proper (Browse) index from config.metabib_field" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1235452 |
| 16:43 |
dbwells |
senator: no problem, will push right away. While your thinking about it (or maybe you aren't), do you know if there is a reason we don't run chopPunctuation on the titleNonfiling field? |
| 16:44 |
|
smyers_ joined #evergreen |
| 16:45 |
dbwells |
senator: I think I'll open a separate bug about that, but it would clean up the trailing punctuation from the title browse, I think. |
| 16:50 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Remove unnecessary Title Proper (Browse) index from config.metabib_field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a2112a> |
| 16:51 |
senator |
dbwells: makes sense. can't think of a particular reason why chopPunctuation isn't applied to titleNonfiling |
| 17:05 |
|
mdriscoll left #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:22 |
bshum |
paxed: It isn't the same thing, but I've long wanted to work on getting some stock html help files in place. |
| 17:22 |
bshum |
Like described in http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:custom_help |
| 17:23 |
bshum |
So that the evergreen help action actually does something |
| 17:23 |
bshum |
Being a wiki would make it easier to edit though for end-users |
| 17:24 |
paxed |
bshum: i was thinking of having YAOUS for opac.wikihelp -> http://wiki.evergreen-ils.org/wiki/$VERSION/$LOCALE/$TEMPLATENAME#section or something. |
| 17:25 |
paxed |
and clicking on "Help" in OPAC would go to that url (replacing the placeholders). |
| 17:26 |
paxed |
i really like how in Koha it's easy to edit the help. it's like a wiki, but on local server. |
| 17:27 |
paxed |
same should apply to the staff client helps. |
