[CODE4LIB] onboarding developers coming from industry
Dear Code4Libbers, We have a new developer starting soon that’s coming from industry with no experience in libraries. We're interested in hearing about any strategies or training methods you’ve found successful in introducing developers from other areas to the quirkiness of library tech – things like MARC, proxy servers, Z39.50, catalogue knowledgebases, e-resources access, etc. Do you have any successes or advice to share? For those of you in academic libraries, we also are interested in strategies for getting someone new oriented to the academic environment. Thanks so much! Jenn --- Jenn Riley Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques McGill University Library | Bibliothèque Université McGill 3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 | Montréal (QC) Canada H3A 0C9 (514) 398-3642 jenn.ri...@mcgill.ca
Re: [CODE4LIB] code4lib registration repercussions?
I think Mark is on to something. Was this one of the years CODE4LIB used DLF for registration? I recall DLF having a similar issue due to the company they contracted with for registration a few years back - at least one DLF registrant got caught out by it. As I recall, DLF changed registration vendors after that. Louisa should be able to confirm and as Mark says, provide moire information. Jenn --- Jenn Riley Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques McGill University Library | Bibliothèque Université McGill 3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 | Montréal (QC) Canada H3A 0C9 (514) 398-3642 jenn.ri...@mcgill.ca On 2015-03-13 11:41 AM, Mark A. Matienzo mark.matie...@gmail.com wrote: Becky, Brad, I passed on links to this thread to Louisa Kwasigroch at DLF, who may be able to let you know if any other registered attendees had this issue. Cheers, Mark -- Mark A. Matienzo m...@matienzo.org Director of Technology, Digital Public Library of America On Fri, Mar 13, 2015 at 11:26 AM, Becky Yoose b.yo...@gmail.com wrote: Hi Brad, If there was an option for an annual subscription for ACTIVE as part of the registration process, I'm wondering why this wasn't brought up during the registration period. What you are describing would have been suspicious to anyone signing up for the conference. If I remember correctly, DLF was the one who handled the fiances for 2013, so if someone from DLF is on the list, can they doublecheck to see if there was anything like Brad described below? Thanks, Becky On Fri, Mar 13, 2015 at 10:17 AM, Brad Busenius bbusen...@uchicago.edu wrote: They are separate charges. WithdrawalACT*Council is probably the charge for the conference. I probably have that one too. The Active charge came later as an annual subscription. They used the conference registration as a way to trick people into opting in to their unrelated service. I assume most people noticed this and opted out. I did not notice and therefore did not opt out. That's what I think happened, anyhow. I am looking for confirmation on this. I've had to piece things together. Brad On 3/12/15 7:48 PM, Becky Yoose wrote: A follow-up - the charge name that is listed on my statement for 2013 registration is WithdrawalACT*Council on Library which is different than what you have listed in your statement. :-( Thanks, Becky Sent from the ball and chain On Mar 12, 2015 7:22 PM, Becky Yoose b.yo...@gmail.com wrote: Hello Brad, I'm sorry to hear about the suspicious charges! Per your request, I checked the history of the the account I used to pay for 2013 and did not find a reoccurring charge like the one you described. I wonder what happened with your account... Thanks, Becky Sent from the ball and chain On Mar 12, 2015 7:09 PM, Brad Busenius bbusen...@uchicago.edu wrote: Hi everybody, I hope this is the right place to inquire about this. I have some information about a possible problem with the company handling registration for code4lib. I recently noticed a suspicious charge on my credit card for the amount of $64.95. The charge showed up as ACT*ACTIVE-NETWORK. After some investigation I found out this was from a company called ACTIVE Network, LLC. Apparently this company handles registration for events. To my dismay I found out that I had been charged for this annually since 2013. I'm very embarrassed that 1. I didn't notice this during the registration process and 2. I didn't catch the charges earlier. Anyhow, after a quick email search I found something surprising; I had received emails from this company at my /work/ email address. I never noticed the emails because they looked like junkmail, however, upon reviewing them I discovered that at some point I had supposedly registered for a free trial that ended after a month, at which point I was automatically enrolled into an annual subscription. Needless to say, I//did /not/ ever sign up for any trial or subscription, at least not to my knowledge. Since I have only used my personal credit card for work purposes 3 times, it was easy to tie this to code4lib 2013. I looked at my receipt for code4lib 2013 and saw that something called RegOnline (owned by Lanyon Solutions Inc) was used to process my event registration. Though I'm not sure this is the same company, RegOnline, Lanyon Solutions Inc, and ACTIVE Network, LLC all share the same physical address. I suspect these three companies are one and the same and will refer to them as ACTIVE Network, LLC for the rest of this email. I did a little investigating and found out that ACTIVE Network, LLC. uses unscrupulous business practices to trick people into singing up for their annual subscription. The crux of this is an automatic opt-in they employ while
Re: [CODE4LIB] state of the art in virtual shelf browse?
Thanks, everyone, for the links to interesting implementations. It's definitely given me some inspiration as we start to think about this possibility. I'll give my 2 cents (Canadian, that's $0.016 US today, sorry!) on a few of Sean's questions below - the ones we've actually given any thought to yet. We're at the 'hey, this is probably something we should look into' phase right now, so naturally we haven't covered all of these things. On 2015-01-28 9:29 AM, Sean Hannan shan...@jhu.edu wrote: Where is the feature demand originating? Staff? Faculty? Students? Grad students? Undergrad students? (Not to exclude publics or special libraries, but this seems to be an academic catalog feature, when it shows up.) This has come up for us as we start (as other academic libraries are) to think about remimagined libraries of the future and the possibility of a smaller on-site collection with remote or on-site but not browsable storage comes up for consideration, and what that would mean for faculty (especially) who find value in browsing shelves. We're not committed to any of this yet - right now it's just a thought experiment of what it would mean. What is the level of familiarity with library/library services/library systems for those that request this feature? I try very hard to encourage my tech folks not to worry about that. If it's a documented user need or helps us strategically in some other way then we need to have it on the table of things we work on. I can communicate how hard it will be as part of the priorities discussion, and if it's a priority, it's a priority, and we move forward. I encourage and reward 'cool, let's work on that and solve an interesting problem' over 'is this really necessary, do those folks asking us know what we're talking about?' My apologies if I've read too much into your question, though! Is implementing shelf browse an attempt to work around some other catalog deficiency (e.g. weak subject cataloging)? Does the corpus have the cataloging data to support such a feature? (A lot of ebook packages do not have call numbers, for example.) What¹s the percentage? Is that reasonable? I'm actually wondering if there are better ways to do thematic browsing than call number, but I know most (all?) do implement this as a literal shelf/call # browse. But there are probably other possibilities that could meet the serendipity need that could be worth exploring. How do you plan on tracking use of the feature? What would you consider to be a success rate? 20% of sessions? 5%? 1%? At what point do you sunset the feature? Expand upon it? I struggle with questions like this because I think they're unfair - frankly, our organizations don't typically ask questions like this about e.g. an advanced search or title browse or journal a-z list, so asking it for THIS feature puts a standard up that we don't use for other things. Now, I'm all about assessment and collecting lots of data and ongoing review, but we work on that for *everything*. Sure, we'll put some thought into this but it's very unlikely something we decide is a priority is going to get a sunset clause put into it at the beginning when we have all sorts of legacy stuff that's limping along but of less utility. We always look at our offerings to decide what stays and what goes, and we'd do that for this too. But it's not in the culture of our organization to set strict metrics like this before implementation, and frankly I think we shouldn't do that. I want the flexibility going forward to shift priorities as the landscape changes. For better or for worse, library services are more than math problems. :-) Jenn --- Jenn Riley Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques McGill University Library | Bibliothèque Université McGill 3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 | Montréal (QC) Canada H3A 0C9 (514) 398-3642 jenn.ri...@mcgill.ca
[CODE4LIB] state of the art in virtual shelf browse?
At my library, we're starting to think about virtual shelf browsing options. Who's doing a really good job with this now? What organizations can I look to for state of the art implementations for inspiration? Thanks for any suggestions. Jenn --- Jenn Riley Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques McGill University Library | Bibliothèque Université McGill 3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 | Montréal (QC) Canada H3A 0C9 (514) 398-3642 jenn.ri...@mcgill.ca
[CODE4LIB] non-kb based openurl from ILS
Hi everyone, We use Aleph for our back end ILS and WorldCat Local as our discovery layer. We'd previously maintained both the OCLC KB and the SFX KB, but under the principle of not maintaining data in two places we've retired SFX. We started out just shadowing records for e-books and e-journals in Aleph, but are now wondering what it would look like to continue to have those records available in Aleph and find a way to have them link out. The URLs in these (currently shadowed) records go to SFX, and trying to redirect or batch update those looks like a no-go based on the difficulty of matching up the SFX and OCLC KB data. So we'd have to hide those URLs and find another way to get the user from the Aleph search result to the electronic version of that item. In this scenario we're considering a 'find full text' button in Aleph that sends an OpenURL request through to the OCLC link resolver. It's basically old-skool OpenURL as before KBs existed. Or how OpenURL works from an AI database. We think it's possible to do this in Aleph piggybacking on how the SFX requests were constructed and sent, but would like to talk with others who have done this or something similar through Aleph, if there are any. Anyone have any experience with this? Or words of advice? Jenn --- Jenn Riley Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques McGill University Library | Bibliothèque Université McGill 3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 | Montréal (QC) Canada H3A 0C9 (514) 398-3642 jenn.ri...@mcgill.ca
Re: [CODE4LIB] non-kb based openurl from ILS
Oops, sorry for being oblique! Right now we have records for ebooks and
ejournals in Aleph completely hidden from users ('shadowed' as we call it
here), so they're not retrieved in searches. We did this because we knew
the links in them werent going to work once we shut off SFX. If we had
OpenURL working in Aleph going through the OCLC KB we'd unshadow these
records and make them available to users again.
This all assumes the records can get into Aleph in the first place which
is a separate issue, for which our approach and painful decisions are too
complicated to get into here. :-)
Does that help?
Jenn
On 2014-07-14 2:50 PM, Harper, Cynthia char...@vts.edu wrote:
Sorry if this is too basic, but I'm not sure what you mean by shadowing
records in Aleph - does that mean you'd just have brief records in Aleph
which are loaded from an OCLC kb export? But that sounds like your second
option, adding a linkout... I just don't know the shadowing
terminology.
Cindy Harper
char...@vts.edu
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Jenn Riley
Sent: Monday, July 14, 2014 1:54 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] non-kb based openurl from ILS
Hi everyone,
We use Aleph for our back end ILS and WorldCat Local as our discovery
layer. We'd previously maintained both the OCLC KB and the SFX KB, but
under the principle of not maintaining data in two places we've retired
SFX. We started out just shadowing records for e-books and e-journals in
Aleph, but are now wondering what it would look like to continue to have
those records available in Aleph and find a way to have them link out.
The URLs in these (currently shadowed) records go to SFX, and trying to
redirect or batch update those looks like a no-go based on the difficulty
of matching up the SFX and OCLC KB data. So we'd have to hide those URLs
and find another way to get the user from the Aleph search result to the
electronic version of that item.
In this scenario we're considering a 'find full text' button in Aleph
that sends an OpenURL request through to the OCLC link resolver. It's
basically old-skool OpenURL as before KBs existed. Or how OpenURL works
from an AI database.
We think it's possible to do this in Aleph piggybacking on how the SFX
requests were constructed and sent, but would like to talk with others
who have done this or something similar through Aleph, if there are any.
Anyone have any experience with this? Or words of advice?
Jenn
---
Jenn Riley
Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives numériques
McGill University Library | Bibliothèque Université McGill
3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9 |
Montréal (QC) Canada H3A 0C9
(514) 398-3642
jenn.ri...@mcgill.ca
Re: [CODE4LIB] non-kb based openurl from ILS
Ah, good angle, and worth investigating. Thanks!
Jenn
On 2014-07-14 8:54 PM, Karen Coombs librarywebc...@gmail.com wrote:
Jenn,
The WorldCat knowledge base has an API. For ebooks and ejournals should be
able to query the API by the ISBN/ISSN to see if there is a match in the
WorldCat knowledge base and the url(s) for that item. Before I joined
OCLC,
I played with the idea of doing something similar to this using a
javascript and php proxy script in order to link to e-content from the
record for the print version of the item in a library catalog.
Karen
On Mon, Jul 14, 2014 at 3:26 PM, Harper, Cynthia char...@vts.edu wrote:
Yes that helps - we call it suppressed.
Your post inspired me to research changing from our old-style III link
resolver to OCLC KB. So far, fun with pubget...
Cindy
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Jenn Riley
Sent: Monday, July 14, 2014 3:05 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] non-kb based openurl from ILS
Oops, sorry for being oblique! Right now we have records for ebooks and
ejournals in Aleph completely hidden from users ('shadowed' as we call
it
here), so they're not retrieved in searches. We did this because we knew
the links in them werent going to work once we shut off SFX. If we had
OpenURL working in Aleph going through the OCLC KB we'd unshadow these
records and make them available to users again.
This all assumes the records can get into Aleph in the first place which
is a separate issue, for which our approach and painful decisions are
too
complicated to get into here. :-)
Does that help?
Jenn
On 2014-07-14 2:50 PM, Harper, Cynthia char...@vts.edu wrote:
Sorry if this is too basic, but I'm not sure what you mean by
shadowing
records in Aleph - does that mean you'd just have brief records in
Aleph which are loaded from an OCLC kb export? But that sounds like
your second option, adding a linkout... I just don't know the
shadowing
terminology.
Cindy Harper
char...@vts.edu
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Jenn Riley
Sent: Monday, July 14, 2014 1:54 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] non-kb based openurl from ILS
Hi everyone,
We use Aleph for our back end ILS and WorldCat Local as our discovery
layer. We'd previously maintained both the OCLC KB and the SFX KB, but
under the principle of not maintaining data in two places we've retired
SFX. We started out just shadowing records for e-books and e-journals
in Aleph, but are now wondering what it would look like to continue to
have those records available in Aleph and find a way to have them link
out.
The URLs in these (currently shadowed) records go to SFX, and trying to
redirect or batch update those looks like a no-go based on the
difficulty of matching up the SFX and OCLC KB data. So we'd have to
hide those URLs and find another way to get the user from the Aleph
search result to the electronic version of that item.
In this scenario we're considering a 'find full text' button in Aleph
that sends an OpenURL request through to the OCLC link resolver. It's
basically old-skool OpenURL as before KBs existed. Or how OpenURL works
from an AI database.
We think it's possible to do this in Aleph piggybacking on how the SFX
requests were constructed and sent, but would like to talk with others
who have done this or something similar through Aleph, if there are
any.
Anyone have any experience with this? Or words of advice?
Jenn
---
Jenn Riley
Associate Dean, Digital Initiatives | Vice Doyenne, Initiatives
numériques
McGill University Library | Bibliothèque Université McGill
3459 McTavish Street | 3459, rue McTavish Montreal, QC, Canada H3A 0C9
| Montréal (QC) Canada H3A 0C9
(514) 398-3642
jenn.ri...@mcgill.ca
Re: [CODE4LIB] LOC Authority Data
Thanks for the link, Roy. I hadn't taken the time to look this far into the Grid Services terms of use. One thing stuck out to me, though. What does Library members that do ***all*** their cataloging with an OCLC subscription mean? The all part is what doesn't make sense to me on first read. Thanks, Jenn Jenn Riley Metadata Librarian Digital Library Program Indiana University - Bloomington Wells Library W501 (812) 856-5759 www.dlib.indiana.edu Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com -Original Message- From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of Roy Tennant Sent: Tuesday, September 30, 2008 4:30 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] LOC Authority Data Actually, member is more appropriate, and it is not presently behind any sort of wall in its current experimental mode, but it could become part of the WorldCat Grid Services which are free to the folks listed here: http://worldcat.org/devnet/wiki/SearchAPIWhoCanUse With other audience groups yet to be determined (could still be free for some groups/purposes, we don't know yet). Actually distributing the data is another issue, since in most cases it is not ours. Roy On 9/30/08 9/30/08 € 12:23 PM, Ross Singer [EMAIL PROTECTED] wrote: s/customer/partner/ Also, in the case of what the thread was initially calling for, what would be the legalities of redistributing this data? -Ross. On Tue, Sep 30, 2008 at 3:22 PM, Ross Singer [EMAIL PROTECTED] wrote: I'm going to go out on a limb here and assume you need to be an OCLC customer to benefit from this? -Ross. On Tue, Sep 30, 2008 at 3:01 PM, Houghton,Andrew [EMAIL PROTECTED] wrote: From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of Ross Singer Sent: Monday, September 29, 2008 7:45 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] LOC Authority Data Also, I noticed another dump on the IA of Library of Congress updates since the initial Bisson load. http://www.archive.org/details/marc_loc_updates In typical IA fashion, it's incredibly difficult to know what the hell this stuff is, though. -Ross. If you just looking for access to the LCSH authority data, you can access it through our Terminology Services project. The data in our SRW server was updated to the 2008-09-17 weekly update from LC. The SRW server is located at the URI: http://tspilot.oclc.org/lcsh/ Looking for access to other authority files: FASThttp://tspilot.oclc.org/fast/ GSAFD http://tspilot.oclc.org/gsafd/ MeSHhttp://tspilot.oclc.org/mesh/ TGM I http://tspilot.oclc.org/lctgm/ TGM II http://tspilot.oclc.org/gmgpc/ Andy. --
