Time |
Nick |
Message |
01:34 |
|
b_bonner joined #evergreen |
01:35 |
|
mtcarlson_away joined #evergreen |
01:50 |
|
linuxhiker joined #evergreen |
01:51 |
|
b_bonner joined #evergreen |
01:51 |
|
mtcarlson_away joined #evergreen |
02:33 |
|
DPearl joined #evergreen |
07:44 |
|
rjackson-isl joined #evergreen |
08:08 |
|
cjohnson joined #evergreen |
08:16 |
|
cjohnson left #evergreen |
08:18 |
|
cjohnson joined #evergreen |
08:29 |
|
collum joined #evergreen |
08:32 |
|
akilsdonk joined #evergreen |
08:39 |
|
timf joined #evergreen |
08:47 |
|
mmorgan1 joined #evergreen |
08:47 |
|
mmorgan1 left #evergreen |
08:47 |
|
mmorgan joined #evergreen |
08:56 |
|
rfrasur joined #evergreen |
08:58 |
|
ericar joined #evergreen |
09:03 |
bshum |
@coin |
09:03 |
pinesol_green |
bshum: tails |
09:03 |
bshum |
kmlussier: --^ |
09:04 |
csharp |
@developer |
09:04 |
pinesol_green |
csharp: Communication:10, BigPicture:11, DetailOriented:16, KungFu:14, GetsStuffDone:7, FlakeFactor:13, JavaAvoidance:10 |
09:04 |
kmlussier |
bshum: You need to give me some forewarning next time so I know what heads and tails are. |
09:04 |
kmlussier |
@librarian |
09:04 |
pinesol_green |
kmlussier: Management:10, Cataloging:12, Acquisitions:14, Reference:11, Circulation:16, Systems:15, Research:6, Custodial:9 |
09:04 |
csharp |
heads I win, tails you lose |
09:05 |
bshum |
kmlussier: I was merely showing you how to approach decisions involving two paths. |
09:05 |
csharp |
@roulette |
09:05 |
pinesol_green |
*BANG* Hey, who put a blank in here?! |
09:05 |
* pinesol_green |
reloads and spins the chambers. |
09:05 |
bshum |
:) |
09:05 |
jboyer-isl |
Sigh. Has anyone seen this on a 2.5 release: open-ils.storage.action.hold_request.copy_targeter: Use of uninitialized value $min_prox in anonymous hash ({}) at /usr/local/share/perl/5.14.2/OpenILS/Application/Storage/Publisher/action.pm line 1641. |
09:05 |
bshum |
Yes, ignore it. |
09:06 |
jboyer-isl |
That line is deep into the new_hold_targter |
09:06 |
csharp |
jboyer-isl: yes - I've seen that on our 2.5.1 test server |
09:06 |
jboyer-isl |
sub |
09:06 |
jboyer-isl |
For every single hold processed? |
09:06 |
csharp |
bshum: is there a bug on it? |
09:06 |
jboyer-isl |
I was really looking forward to moving to 2.5 because I thought there would be so many fewer worthless errors. :( |
09:06 |
csharp |
jboyer-isl: have you run 'autogen.sh -u' on your utility (holds targeter) server? |
09:07 |
bshum |
csharp: I think dbs might have worked on quieting down some of those (there used to be LOTS more noise) but I'm not sure where we are today. |
09:07 |
jboyer-isl |
I doubt it. I'm not the one that set it up. |
09:07 |
* csharp |
looks forward to a day when autogen.sh is no longer necessary for anything |
09:07 |
rfrasur |
kmlussier: I received our invoice today. ty |
09:08 |
bshum |
It has something to do with all those new custom hold targeting stuff not being fully fleshed out of box. I think. |
09:08 |
jboyer-isl |
csharp: I have no idea why it (and apache?!) are necessary on a utility server. I hear we're running the same setup, essentially, do you know why off hand? |
09:08 |
bshum |
But generally it's just noise. |
09:08 |
kmlussier |
rfrasur: yw. I'm happy to invoice you anytime you want. |
09:08 |
kmlussier |
Next time, you can just make the check out to kmlussier. |
09:08 |
csharp |
jboyer-isl: apache is strictly not necessary - just part of the standard stack |
09:09 |
csharp |
s/strictly not/not strictly/ |
09:09 |
rfrasur |
kmlussier: I figured ;) |
09:09 |
jboyer-isl |
From my POV, it's it |
09:09 |
jboyer-isl |
's not necessary, then it IS "strictly not" ;) |
09:09 |
csharp |
jboyer-isl: autogen -u refreshes the OU proximity table |
09:10 |
csharp |
it is otherwise not necessary at all as far as I know |
09:10 |
* csharp |
defers to berick or eeevil for details ;-) |
09:10 |
jboyer-isl |
csharp: I knew it did something like that, but I thought it's output was just for the brick heads. I should read more about it probably. |
09:11 |
csharp |
jboyer-isl: it definitely doesn't conform to the "one program/one purpose" ideal of UNIX servers ;-) |
09:15 |
berick |
we keep getting closer and closer to no longer needing autogen |
09:15 |
csharp |
it seems to me that the proximity table refresh could be transformed into a DB trigger that fires each time you add/change an OU |
09:15 |
csharp |
berick++ |
09:17 |
berick |
we could probably kill it in a hackaway if there was concerted effort |
09:18 |
* csharp |
would totally participate in that |
09:31 |
|
tsbere joined #evergreen |
09:40 |
|
afterl joined #evergreen |
09:51 |
dbs |
@dice 1d2 |
09:51 |
pinesol_green |
dbs: Error: Dice can't have fewer than 3 sides. |
09:51 |
dbs |
So much for flipping a coin |
09:55 |
* berick |
pats self on back for completing an #action item |
09:56 |
dbs |
Hey, who wants to respond to sec.measureapple.ca's message to open-ils-feedback "to confrim[sic] your Billing Information records."? We certainly don't want to lose our Apple account. |
09:56 |
|
yboston joined #evergreen |
09:58 |
rfrasur |
Somebody can teach pinesol_green to play ddakji. It'd work as a two sided dice. |
09:59 |
berick |
@eightball is a two-sided dice the same as a coin? |
09:59 |
pinesol_green |
berick: It is so. |
10:00 |
rfrasur |
It is. |
10:04 |
* tsbere |
has an XDM D2, which is in fact a coin, but has been told that a coin flip and a die roll work too differently and that D2 should thus be done more as a "even vs odd on a D6" to avoid bias in how the coin started >_> |
10:05 |
jcamins |
tsbere: you can also use a 4-sided dice. |
10:05 |
jcamins |
*die |
10:06 |
tsbere |
Interestingly, the set we were using at the time had no D4. Probably why I was told to use a D6 and go Even/Odd instead. |
10:06 |
bradl |
some conversations only happen in #evergreen |
10:08 |
* berick |
notes that flipping a cat has similar landing-side biases |
10:08 |
* rfrasur |
should note that googling Korean words that you know phonetically but not the exact spelling can lead to interesting results. |
10:08 |
rfrasur |
berick++ |
10:09 |
dbs |
berick: depends on the state of the cat |
10:09 |
dbs |
badly decomposed cat may land heads-up _and_ tails-up |
10:10 |
rfrasur |
ew |
10:10 |
rfrasur |
funny but ew |
10:10 |
csharp |
dbs: I would reply to sec.measure, but I'm too busy entering my credit card information for this 2.5 Million British Pounds that we won from their e-mail drawing |
10:10 |
* dbs |
apologizes, but he has been working with latex for the first time ever for the past weekend and is feeling punchy |
10:10 |
berick |
dbs: of course! the only coin that lands on both sides |
10:11 |
jeff |
dbs: you're supposed to work in a well-ventilated area when dealing with that stuff! |
10:11 |
dbs |
s/working with latex/& directly/ |
10:11 |
rfrasur |
(all the jokes and none of the appropriate) |
10:11 |
dbs |
jeff++ |
10:11 |
dbs |
rfrasur++ |
10:12 |
csharp |
I read the LaTeX site after your post on G+, dbs, and was interested to learn that it's supposed to be pronounced "Lay-Tech", not "lay-tex" |
10:12 |
jcamins |
dbs: how have you avoided LaTeX? |
10:13 |
csharp |
I then rolled my eyes at F/LOSS product naming weirdness (e.g. "Gah-NU") |
10:13 |
rfrasur |
csharp++ |
10:14 |
jcamins |
dbs: until now, of course. |
10:14 |
|
kbeswick joined #evergreen |
10:14 |
* csharp |
adds notes to evergreen-ils.org on pronunciation "effergruhn-illls" |
10:14 |
dbs |
jcamins: never submitted a paper to a math/science/engineering conference before |
10:14 |
jeff |
csharp: little-known-fact: the preferred pronunciation of Evergreen is .. nevermind, you beat me to it. |
10:14 |
csharp |
hah |
10:15 |
* rfrasur |
chuckles |
10:15 |
jeff |
you are likely to be eaten by an ever gruhn. |
10:15 |
csharp |
we need an umlaut over one of the e's |
10:15 |
dbs |
jumped from LaTeX-like markup on the commodore 64 to WordPerfect w/ reveal codes to straight-up WYSWIWYG stuff, then back to SGML/XML things like DocBook, then abstracted out to AsciiDoc, now working closer to the source |
10:16 |
dbs |
circle of doc life |
10:17 |
csharp |
@quote add < dbs> jumped from LaTeX-like markup on the commodore 64 to WordPerfect w/ reveal codes to straight-up WYSWIWYG stuff, then back to SGML/XML things like DocBook, then abstracted out to AsciiDoc, now working closer to the source - circle of doc life |
10:17 |
pinesol_green |
csharp: The operation succeeded. Quote #73 added. |
10:18 |
* rfrasur |
now has lion king music playing in internal playlist |
10:20 |
|
Dyrcona joined #evergreen |
10:24 |
* Dyrcona |
is having a sick day but signed in to chat with bshum if he is paying attention and has some time. |
10:25 |
bshum |
Dyrcona: Paying attention? Sure..... |
10:33 |
rfrasur |
yboston: can you link me to the agenda from the last DIG meeting? |
10:35 |
yboston |
Here is the agenda for last week's meeting, it was updated by remingtron http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140109-agenda |
10:35 |
rfrasur |
thanks |
10:56 |
|
mcooper joined #evergreen |
11:20 |
|
dMiller__ joined #evergreen |
11:45 |
|
gsams joined #evergreen |
11:57 |
csharp |
@quote random |
11:57 |
pinesol_green |
csharp: Quote #43: "commit 4755baac: There's tears in my coffee. These are not tears of joy." (added by gmcharlt at 05:36 PM, January 25, 2013) |
11:58 |
|
afterl1 joined #evergreen |
12:00 |
|
afterl2 joined #evergreen |
12:02 |
|
mcooper joined #evergreen |
12:20 |
csharp |
@dunno |
12:20 |
pinesol_green |
csharp: Beyond here be dragons. |
12:26 |
|
mrpeters joined #evergreen |
12:33 |
|
smyers joined #evergreen |
12:37 |
csharp |
so if you wake up on a Monday and think "Hey, I think I'll run all my monthly reports concurrently right now", resist that urge. |
12:38 |
csharp |
we have someone who just fired off like 6 concurrent item list reports and my aNag app is a buzzin' |
12:42 |
jeff |
closest i can come is that we did do a big mass-update of items several months back. the first Tuesday after the batch update, some scheduled reports exhausted memory on the jasperreports server's java vm while generating the PDF reports with barcodes to be e-mailed. |
12:43 |
gsams |
I suppose I'm lucky that our server seems to be very capable of handling our small groups reporting needs. |
12:44 |
csharp |
we have a dedicated server to run clark and two RO databases connected via pgpool |
12:45 |
csharp |
I may need to tweak the load balancing since our beefier DB server seems to get nearly all the queries |
12:45 |
csharp |
jeff: I can totally see that happening for PINES |
12:46 |
gsams |
ah, we are small enough to operate on a single server here. Though i do dream of upgrades... |
12:46 |
gsams |
eventually it will happen for us, we are attracting the attention of larger libraries. |
12:49 |
csharp |
gsams++ |
13:10 |
kmlussier |
gsams++ indeed |
13:11 |
sseng_ |
when doing a "Browse the Catalog" search, what is the significance of a result being bolded? for example, when doing a Titles starging with "concerto", the fifth result down (out of 10) is bolded, and uncertain of what that implies. thanks! |
13:13 |
kmlussier |
sseng: That's where you landed alphabetically in the list. |
13:14 |
kmlussier |
Or, I should say, where your search terms landed alphabetically in the list. |
13:14 |
sseng |
kmlussier: ah ok, got it, that makes sense, thanks! |
13:25 |
|
Sato`kun joined #evergreen |
13:25 |
|
kbeswick joined #evergreen |
14:00 |
rfrasur |
(adobe digital editions deserve all the hate they receive) |
14:00 |
dbs |
More hate, actually |
14:00 |
rfrasur |
true, but I'm trying to be nice. |
14:01 |
* rfrasur |
has to reprimand an employee later so am doing attitude moderation. |
14:03 |
|
keynote2k joined #evergreen |
14:13 |
gsams |
Anyone out there move a lot of new books from one shelving location to another regularly? |
14:15 |
rfrasur |
not recently...but in the past, yes. |
14:16 |
dbs |
gsams: from time to time |
14:16 |
gsams |
rfrasur: We have a library joining soon that moves approximately 1500+ items a month from new to regular shelving. |
14:16 |
* dbs |
warms up http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=shortlog;h=refs/heads/feature/move_to_storage_2_4 in preparation |
14:17 |
gsams |
I'm not sure about the time it takes to make that transition, I was hoping someone had an idea |
14:17 |
rfrasur |
We move about 200 or so in that same time period. |
14:17 |
rfrasur |
I guess it depends on their workflow. |
14:17 |
rfrasur |
And the number of employees doing it. |
14:17 |
dbs |
gsams: ^ implements a web page where staff can log in, browse to the page in question (like "Move to Storage"), and then scan barcode after barcode and have it update the location for each item |
14:17 |
rfrasur |
dbs: that's a great idea. |
14:17 |
Dyrcona |
gsams: Are you concerned more about the time it takes to physically move the copies or the Evergreen database implications? |
14:18 |
rfrasur |
good point, Dyrcona. |
14:18 |
dbs |
rfrasur: yeah, it helps track that the items actually moved there |
14:18 |
gsams |
It was the time it takes to go through the process of updating it in Evergreen. |
14:18 |
Dyrcona |
We usually handle the database side of things using collection-based stat cats on the copies. |
14:19 |
Dyrcona |
Our libraires will tell us to put summer reading in storage for instance. |
14:19 |
rfrasur |
gsams, I think dbs' solution would work better for that many items. |
14:19 |
dbs |
a direct UPDATE clause is easy enough if it's a whole collection at once |
14:19 |
Dyrcona |
We run a SQL to make the change and note the changed copies in a custom table: mvlc.changed_copies or some such. |
14:20 |
Dyrcona |
The extra table makes it easy to undo later. |
14:20 |
gsams |
dbs: that solution of yours seems the best option, and one that would probably work best for them. I have no idea how to implement it though. |
14:21 |
Dyrcona |
It could also be done by scanning the copies into item status and transferring them to a bucket. (I think that is possible.) |
14:21 |
gsams |
I usually work in small enough amounts that I can make the changes in Item Status |
14:22 |
dbs |
gsams: way I did it is just a couple of files - one template, and one JS file - for each "Move to" location. lots of copy-paste there |
14:22 |
Dyrcona |
The bucket would be handy so staff can choose the records and then tell you to do the copies in bucket X. |
14:23 |
csharp |
backup_tables++ |
14:23 |
csharp |
I forgot to do that once and that was the time I needed to have done it |
14:24 |
csharp |
fortunately we had a backup that allowed me to undo it :-/ |
14:24 |
dbs |
gsams: if you look at http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commitdiff;h=a6b0e35e3ce30557c91685d5dafcae6840f3705c then the pertinent bits to change are the strings and the copy.location(), volume.owning_lib(), and copy.circ_lib() calls |
14:25 |
dbs |
And then you just pop open hostname/eg/cat/moveto/lal_circ (or whatever you called it) in a web browser, log in, and scan away |
14:25 |
bshum |
dbs: That's pretty neat. |
14:25 |
csharp |
dbs++ |
14:25 |
gsams |
dbs++ |
14:26 |
dbs |
the owning_lib / circ_lib calls were only because we were moving items to a different library entirely in that case |
14:26 |
gsams |
that might be doable for me. I'll have to play around with it a bit I think |
14:26 |
csharp |
that's definitely something I would have been able to make use of recently |
14:26 |
jeff |
Another option that we use (in a slightly different scenario) where every item is going in or out of "storage" is to have everything (such as Holiday Music) in a distinct location, and toggling the attributes (holdable, opac visible) and name on the location. |
14:26 |
* dbs |
has mentioned this a few times in mailing list contexts, but never really explained it so clearly |
14:26 |
jeff |
dbs++ |
14:27 |
bshum |
jeff: That's kind of what I was thinking too. Most times people say, we want X new location and then we want to move everything into that new location... and I just go change up the label. |
14:27 |
dbs |
hah, there is that approach too :) |
14:27 |
bshum |
Sometimes people are too literal. |
14:28 |
csharp |
yeah - that's our preferred approach too |
14:28 |
csharp |
however, I had a great use case for dbs's interface here |
14:28 |
dbs |
In our case we've done it for big weeding projects (both "move into storage" and "delete!") and also "move subset of stuff into new library", so the hands-on is desired |
14:29 |
csharp |
one of our libs was remodeling and needed to temporarily move *some* of each collection into cold storage |
14:31 |
gsams |
The library in question is currently on III and was trying to estimate the impact on their workflow |
14:31 |
gsams |
dbs++ |
14:31 |
gsams |
Dyrcona++ |
14:31 |
Dyrcona |
gsams: Anyone moving from one system to another should be prepared to change their workflow. |
14:32 |
gsams |
oh yes, the director is familiar with Evergreen already, but it was in a smaller library context. |
14:32 |
gsams |
She is doing the work well ahead of schedule thankfully |
14:47 |
csharp |
so is a system usable while the reingest step is running? or is it better to wait until that's done to reconnect clients to the DB? |
14:48 |
csharp |
I have plenty of time for it (especially using pingest.pl from Dyrcona) in my window this weekend |
14:48 |
csharp |
just wanted to know what others have done |
14:49 |
Dyrcona |
csharp: It is usable, but I usually start the ingest when things are quieter, such as night time when lbraries are closed. |
14:49 |
|
Bmagic joined #evergreen |
14:49 |
csharp |
well the system is completely down as far as our libraries are concerned |
14:50 |
Bmagic |
Where does the staff client get the dropdown list of "depth" in the user permissions UI? |
14:50 |
csharp |
I'm just trying to figure out when we should start plugging things back in and doing full out testing |
14:50 |
bshum |
My understanding is that while reingests happen, you can search or whatever, but your results will vary significantly depending on which bibs have or haven't been ingested yet. |
14:51 |
csharp |
Bmagic: config.org_unit_type? (not looking - that's from memory) |
14:51 |
csharp |
org_type, maybe |
14:51 |
csharp |
bshum: okay -that's good to know |
14:51 |
bshum |
It's probably actor.org_unit_type |
14:51 |
csharp |
Bmagic: yeah bshum's right - it's actor.org_unit_type |
14:52 |
Bmagic |
csharp: That is what I thought, does the staff client cache that somehow, It's showing stuff that is not in the database (we recently deleted them) |
14:52 |
bshum |
csharp: I've left my system running before while reingests happened. But I'm like Dyrcona and tend to stick to off hours. |
14:52 |
bshum |
csharp: The other thing I tend to do is vacuum my tables after reingests |
14:52 |
csharp |
yeah - I'll be doing that too |
14:53 |
bshum |
Since there's churn in the metabib tables and I like to keep things tidy. The vacuum lock does kill things, depending on the type of vacuum you pick. |
14:53 |
bshum |
So for that reason I tend not to turn on Evergreen till after I finish all my tasks. |
14:53 |
csharp |
yeah, I'm moving to GIN indexes for the metabib tables too, so it sounds like vacuum becomes way more important with those |
14:54 |
csharp |
that makes sense, I'm just trying to figure out if we can keep moving or if we just need to sit around for the 20+ hours our reingest will take |
14:55 |
csharp |
+ VACUUM ANALYZE |
14:55 |
csharp |
well, it may be a shorter time - the hardware I'm testing on is about 1/4 the power of our production hardware |
14:57 |
rfrasur |
(the sign that you've become a real manager/administrator is when you can tell an employee that you have no desire to fire them though they might technically deserve it, tell them that you've been grooming them for a full-time position, make them cry and NOT cry yourself) |
15:22 |
jeff |
SIP2 is not a suitable means for vendors to validate patrons. :P |
15:22 |
jeff |
(despite this, many vendors like to use it) |
15:23 |
Dyrcona |
SIP2 is not a suitable means for anything. |
15:24 |
_bott_ |
Dyrcona++ |
15:24 |
_bott_ |
that needs to be stored as a quote |
15:27 |
jeff |
I'm not comfortable with any scenario which involves an electronic resources vendor requesting and storing patron passwords. :P |
15:30 |
Dyrcona |
jeff: I'll wager that your patrons are not as bothered about it as you are. |
15:30 |
jeff |
I'm sure. |
15:31 |
jeff |
"we wanted you to be able to access $content, so we gave this company access to your checkouts, holds, home address, phone number, and... well, pretty much we gave them access to everything that we give you access to." |
15:31 |
* jeff |
growls |
15:32 |
jboyer-isl |
jeff: You never told us you work at Facebook! ;) |
15:33 |
jeff |
"But don't worry -- in theory, they'll never actually pay attention to that data we're sending them, and this is "not an issue with their 100+ partners thus far" |
15:33 |
jeff |
oops. messed up my quoting there. you get the point. |
15:33 |
jeff |
anyway. ranting to clear my head before attempting an alternative approach. |
15:34 |
jeff |
sorry to subject y'all to it. :-) |
15:35 |
csharp |
@quote add < Dyrcona> SIP2 is not a suitable means for anything. |
15:35 |
pinesol_green |
csharp: The operation succeeded. Quote #74 added. |
15:36 |
csharp |
jeff++ |
15:36 |
jeffdavis |
jeff: do your contracts with vendors using SIP include language about patron privacy/protection of personal info? |
15:36 |
csharp |
@quote search sip2 |
15:36 |
pinesol_green |
csharp: 1 found: #74: "< Dyrcona> SIP2 is not a suitable means for..." |
15:37 |
Dyrcona |
@quote search marc |
15:37 |
pinesol_green |
Dyrcona: 3 found: #38: "<jcamins> At least your MARC frameworks aren't...", #46: "<_bott_> Try restarting apache. not a...", and #52: "<dbs> MARC is not machine readable." |
15:37 |
csharp |
in our case all the SIP vendor agreements are between the individual libraries and the vendor |
15:37 |
jeff |
jeffdavis: currently we do not use SIP2 for vendor authentication. I'll know more about contracts if we ever do start using SIP2 with a vendor... which (*growl*, again) is likely soon. |
15:38 |
Dyrcona |
@quote get 46 |
15:38 |
pinesol_green |
Dyrcona: Quote #46: "<_bott_> Try restarting apache. not a cataloger, but I speak enough MARC to be fun at parties" (added by gmcharlt at 11:43 AM, March 15, 2013) |
15:38 |
csharp |
_bott_++ |
15:39 |
_bott_ |
Not sure where that "Try restarting apache." came from. The original started "I am not a cataloger..." |
15:40 |
Dyrcona |
@quote get 45 |
15:40 |
pinesol_green |
Dyrcona: Quote #45: "<senator> this isn't twitter, @jeff doesn't mean what you think it means" (added by bshum at 11:40 AM, March 05, 2013) |
15:41 |
Dyrcona |
Uh-oh. |
15:41 |
|
bshum joined #evergreen |
15:41 |
|
kmlussier joined #evergreen |
15:41 |
|
mceraso joined #evergreen |
15:41 |
_bott_ |
Are the quotes stored in MARC? |
15:42 |
csharp |
that would definitely explain it ;-) |
15:42 |
gmcharlt |
yes. *somebody* has to use the MARC Format for Community Information! |
15:42 |
rfrasur |
@hate MARC |
15:42 |
pinesol_green |
rfrasur: But rfrasur already hates MARC! |
15:42 |
rfrasur |
yes, yes I do |
15:43 |
Dyrcona |
gmcharlt: We used to on Horizon, but no one was maintaining the database, so the committee (naturally there was a committee) voted to drop the records because Google. |
15:44 |
Dyrcona |
This was 7 or 8 years ago. |
15:45 |
Dyrcona |
Leave it to me to respond to a humorous line with an earnest answer. :) |
15:45 |
gmcharlt |
there is probably a joke somewhere concerning death dates in authority records that are applied to CI records |
15:47 |
_bott_ |
I fear that MARC was a humorous suggestion that someone took seriously. |
15:48 |
gmcharlt |
_bott_: well, I'm not quite sure about the feasibility of Linked Data or XML-based metadata formats in the 1960s... ;) |
15:48 |
rfrasur |
No, I think that it's something that very serious people took very seriously. That's why very serious people should always be balanced by not so serious people. |
15:50 |
csharp |
@quote add < _bott_> I fear that MARC was a humorous suggestion that someone took seriously. |
15:50 |
pinesol_green |
csharp: The operation succeeded. Quote #75 added. |
15:50 |
csharp |
and now we have 4 MARC quotes |
15:53 |
|
bshum joined #evergreen |
15:53 |
|
kmlussier joined #evergreen |
15:53 |
|
mceraso joined #evergreen |
15:53 |
csharp |
@quote get 46 |
15:53 |
pinesol_green |
csharp: Quote #46: "<_bott_> I am not a cataloger, but I speak enough MARC to be fun at parties" (added by gmcharlt at 11:43 AM, March 15, 2013) |
15:53 |
csharp |
repaired! |
15:54 |
_bott_ |
csharp++ |
15:54 |
_bott_ |
I know I'll sleep better tonight |
15:54 |
rfrasur |
I'm glad MARC isn't sentient. |
15:55 |
* rfrasur |
would feel kinda bad. |
16:01 |
Dyrcona |
MARC is great for transmitting data on tape that will be printed onto card stock, not much use for anything else. |
16:01 |
dbs |
@quote search MARC |
16:01 |
pinesol_green |
dbs: 4 found: #38: "<jcamins> At least your MARC frameworks aren't...", #46: "<_bott_> I am not a cataloger, but I speak...", #52: "<dbs> MARC is not machine readable.", and #75: "< _bott_> I fear that MARC was a humorous..." |
16:03 |
rfrasur |
ooo, Dyrcona. That sounds like it'd be a great way to catalog our materials. I can see it now. The coolest wooden cabinets with cute little draws that you can pull out and set right on a table. It'd be like browsing the shelves, but you could sit down. You could have different ones, too. Subject catalogs and title catalogs...and author. Just imagine the possibilities. |
16:03 |
dbs |
Hipster-driven discovery systems |
16:03 |
Dyrcona |
rfrasur: :p |
16:04 |
rfrasur |
No, dbs. If it's in library land. It must be HDDS, and you must never ever actually explain what the acronym stands for until a person reaches the 33rd level of the lodge. |
16:04 |
rfrasur |
I mean, library. |
16:05 |
Dyrcona |
What is this, Scientology? |
16:05 |
* Dyrcona |
didn't know he was joining a cult. |
16:05 |
rfrasur |
Library Scientology |
16:06 |
_bott_ |
Bibliotology? |
16:06 |
rfrasur |
Dyrcona, nobody ever knows til they start passing out the koolaid. |
16:08 |
rfrasur |
btw, I'm flying on Southwest to the conference. Am wondering if designated airports might just be suggestions now. |
16:13 |
|
bshum joined #evergreen |
16:13 |
|
kmlussier joined #evergreen |
16:13 |
|
mceraso joined #evergreen |
16:23 |
gsams |
dbs: I am playing with the shelving location changer at the moment, and I believe I have the proper changes in place but it keeps prompting me to login and not making any changes. |
16:34 |
|
stevenyvr2 joined #evergreen |
16:35 |
|
stevenyvr joined #evergreen |
16:36 |
|
stevenyvr2 left #evergreen |
16:39 |
dbs |
gsams: so you can log in, and it prompts you when you enter a barcode? |
16:41 |
gsams |
dbs: I log in, scan a barcode, and it prompts me to log in again. I've tried a few different users. |
16:41 |
Dyrcona |
gsams: Cookies enabled in your browser? |
16:42 |
dbs |
gsams: https://? |
16:42 |
* Dyrcona |
is just guessing. |
16:42 |
dbs |
gsams: and also, if you changed the name of the lal_circ.tt2 file you'll need to change the <form method="get" action="/eg/cat/moveto/lal_circ"> line in the tt2 file |
16:43 |
dbs |
Dyrcona could be right |
16:43 |
dbs |
Also, those users will need cataloguer-type permissions |
16:45 |
gsams |
I'm showing cookies as enabled, and I see 2 for that site in particular |
16:46 |
dbs |
gsams: https:// ? |
16:46 |
dbs |
that is, https://hostname/eg/cat/moveto/blah rather than http://hostname/... |
16:47 |
gsams |
that was it |
16:47 |
gsams |
works as intended, wasn't paying attention |
16:48 |
gsams |
dbs++ |
16:48 |
gsams |
Dyrcona++ |
16:48 |
dbs |
heh, I didn't mention that bit in my overview before :) |
17:10 |
|
mmorgan left #evergreen |
17:33 |
|
dcook joined #evergreen |
17:53 |
|
mcooper joined #evergreen |
19:48 |
Dyrcona |
@quote random |
19:48 |
pinesol_green |
Dyrcona: Quote #58: "<groucho> Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read." (added by Dyrcona at 11:31 AM, June 15, 2013) |
20:18 |
|
afterl2 left #evergreen |
23:25 |
|
stevenyvr2 joined #evergreen |
23:25 |
|
stevenyvr2 left #evergreen |
23:38 |
kmlussier |
@coin |
23:38 |
pinesol_green |
kmlussier: tails |