[CODE4LIB] Vacancy at the University of York - Digital Library Systems Developer
Dear all, We are currently advertising for a Digital Library Systems Developer at the University of York to work on our latest JISC enhancement project 'YODL-ING'. The post is fixed-term for 18 months. Further details here: https://www22.i-grasp.com/fe/tpl_YorkUni01.asp?newms=jjid=24975 Closing date Wednesday 13 May, interviews scheduled for 4 June. There's more information about York Digital Library (YODL) on our web site, or just get in touch with any questions: http://www.york.ac.uk/library/electroniclibrary/yorkdigitallibraryyodl/ Best, Julie -- Julie Allinson ja...@york.ac.uk Digital Library Manager University Library Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 434083 skype: j.allinson web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm --
Re: [CODE4LIB] Serials Solutions Summon
Andrew Nagy wrote: Summon is really more than an NGC as we are selling it as a service - a unified discovery service. This means that it is a single repository of the library's content ( subscription content, catalog records, IR data, etc.). Federated search is not apart of Summon Well, if we understand federated to mean bringing stuff together by searching all of it at once, then it is, as opposed to broadcast searching, a term you used later in this sentence. As in, Origin: 1665–75; L foederātus leagued together, allied, equiv. to foeder- (nom. s. foedus) league from http://dictionary.reference.com/search?q=federated It is, though, a great *breakthrough* in the area of federated search, which is why we ordered an onsite demo immediately on hearing about this product. But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products -- Yitzchak Schaffer Systems Manager Touro College Libraries 33 West 23rd Street New York, NY 10010 Tel (212) 463-0400 x5230 Fax (212) 627-3197 Email yitzc...@touro.edu Twitter /torahsyslib
Re: [CODE4LIB] Serials Solutions Summon
I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ Sorry if my English didn't good enough to well explain my idea -- Ronachai Pratanaphon. Yitzchak Schaffer writes: Andrew Nagy wrote: Summon is really more than an NGC as we are selling it as a service - a unified discovery service. This means that it is a single repository of the library's content ( subscription content, catalog records, IR data, etc.). Federated search is not apart of Summon Well, if we understand federated to mean bringing stuff together by searching all of it at once, then it is, as opposed to broadcast searching, a term you used later in this sentence. As in, Origin: 1665?75; L foeder?tus leagued together, allied, equiv. to foeder- (nom. s. foedus) league from http://dictionary.reference.com/search?q=federated It is, though, a great *breakthrough* in the area of federated search, which is why we ordered an onsite demo immediately on hearing about this product. But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products -- Yitzchak Schaffer Systems Manager Touro College Libraries 33 West 23rd Street New York, NY 10010 Tel (212) 463-0400 x5230 Fax (212) 627-3197 Email yitzc...@touro.edu Twitter /torahsyslib
Re: [CODE4LIB] Serials Solutions Summon
Sorry, but, me too! Rob On Tue, 21 Apr 2009, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. _/|_ ___ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ Sorry if my English didn't good enough to well explain my idea -- Ronachai Pratanaphon. Yitzchak Schaffer writes: Andrew Nagy wrote: Summon is really more than an NGC as we are selling it as a service - a unified discovery service. This means that it is a single repository of the library's content ( subscription content, catalog records, IR data, etc.). Federated search is not apart of Summon Well, if we understand federated to mean bringing stuff together by searching all of it at once, then it is, as opposed to broadcast searching, a term you used later in this sentence. As in, Origin: 1665?75; L foeder?tus leagued together, allied, equiv. to foeder- (nom. s. foedus) league from http://dictionary.reference.com/search?q=federated It is, though, a great *breakthrough* in the area of federated search, which is why we ordered an onsite demo immediately on hearing about this product. But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products -- Yitzchak Schaffer Systems Manager Touro College Libraries 33 West 23rd Street New York, NY 10010 Tel (212) 463-0400 x5230 Fax (212) 627-3197 Email yitzc...@touro.edu Twitter /torahsyslib
Re: [CODE4LIB] Serials Solutions Summon
On Apr 21, 2009, at 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. Yes, to me, the quoted phases above are synonymous. But I believe we are also seeing a new type of index manifesting itself, and this new index has yet to be named. Specifically, I'm thinking of the index where various types of content is aggregated into a single index and then queried. For example, instead of providing a federated search against one or more library catalogs, a Z39.50 accessible journal article index, a local cache of harvested OAI content, etc., I think we are beginning to see all of these content silos (and others) brought together into a single (Solr/ Lucene) index and searched simultaneously. I'm not sure, but I think this is how Summon works. -- Eric Lease Morgan Head, Digital Access and Information Architecture Department Hesburgh Libraries, University of Notre Dame
Re: [CODE4LIB] Serials Solutions Summon
Both the terms federated searching and meta-searching are often used ambiguously to refer to both of these techniques. I've been trying to use broadcast search and local index to be clear about which technique I'm talking about. (I used to say 'cross-search' for 'broadcast search', but I think 'broadcast search' is more clear). Jonathan Yitzchak Schaffer wrote: Andrew Nagy wrote: Summon is really more than an NGC as we are selling it as a service - a unified discovery service. This means that it is a single repository of the library's content ( subscription content, catalog records, IR data, etc.). Federated search is not apart of Summon Well, if we understand federated to mean bringing stuff together by searching all of it at once, then it is, as opposed to broadcast searching, a term you used later in this sentence. As in, Origin: 1665–75; L foederātus leagued together, allied, equiv. to foeder- (nom. s. foedus) league from http://dictionary.reference.com/search?q=federated It is, though, a great *breakthrough* in the area of federated search, which is why we ordered an onsite demo immediately on hearing about this product. But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products
Re: [CODE4LIB] Serials Solutions Summon
But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products It's a relationship, so anything is possible. But easily? That would depend on who was doing it. I also agree that federated search doesn't suit Summon well. The natively-indexed content is key. -- -- | Karen G. Schneider | Community Librarian | Equinox Software Inc. The Evergreen Experts | Toll-free: 1.877.Open.ILS (1.877.673.6457) x712 | k...@esilibrary.com | Web: http://www.esilibrary.com | Be a part of the Evergreen International Conference, May 20-22, 2009! | http://www.lyrasis.org/evergreen
Re: [CODE4LIB] Serials Solutions Summon
Eric, How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? Sounds like good PR to me, rather than a revolution ;) Rob On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into But I believe we are also seeing a new type of index manifesting itself, and this new index has yet to be named. Specifically, I'm thinking of the index where various types of content is aggregated into a single index and then queried. For example, instead of providing a federated search against one or more library catalogs, a Z39.50 accessible journal article index, a local cache of harvested OAI content, etc., I think we are beginning to see all of these content silos (and others) brought together into a single (Solr/ Lucene) index and searched simultaneously. I'm not sure, but I think this is how Summon works.
Re: [CODE4LIB] Serials Solutions Summon
Eric Lease Morgan writes: On Apr 21, 2009, at 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. Yes, to me, the quoted phases above are synonymous. But I believe we are also seeing a new type of index manifesting itself, and this new index has yet to be named. Specifically, I'm thinking of the index where various types of content is aggregated into a single index and then queried. For example, instead of providing a federated search against one or more library catalogs, a Z39.50 accessible journal article index, a local cache of harvested OAI content, etc., I think we are beginning to see all of these content silos (and others) brought together into a single (Solr/ Lucene) index and searched simultaneously. Ah yes. You won't be surprised to hear that we are doing the same thing with Zebra. For this, we use the less than exciting term local indexes. _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ I have an ugly tendency to blame all my failings on others. It's something I picked up from my parents -- Matt Wedel.
Re: [CODE4LIB] Serials Solutions Summon
Karen Schneider wrote: But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products It's a relationship, so anything is possible. But easily? That would depend on who was doing it. I think in point of fact SerialSolution is doing a LOT of work to keep the feeds from the vendors flowing, keep the data updated, deal with errors, normalize it to some extent so it can all live in an index together. It's good SerialSolutions has set the precedent, so it may be possible for other entities to duplicate those relationships. (I am VERY curious about whether SerSol is paying publishers for metadata or getting it for free). But unless you are a large consortium, I think it's going to be more cost effective to pay SerSol (or another vendor) to wrangle all that metadata, than to try and do it yourself. It _would_ be great if SerSol would actually give you (if you were subscribed) a feed of their harvested and normalized metadata, so you could still pay them to collect and normalize it, but then use it for your own purposes outside of Summon. I hope SerSol will consider this down the line, if Summon is succesful. Jonathan
Re: [CODE4LIB] Serials Solutions Summon
On Apr 21, 2009, at 10:55 AM, Dr R. Sanderson wrote: How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? This new type of index is not any different in functionality from a well-implemented OAI service provider with the exception of the type of content it contains. While OAI is/was popular, it was never really embraced by the commercial journal article indexers (Cambridge Scientific Abstracts, Web of Science, etc.) nor the commercial journal article publishers (Springer, Elsevier, etc.). Consequently their scholarly and in high demand content was not indexable. I think, but I'm not sure, Serials Solutions has made deals with such publishers to aggregate their content into a single whole and provide a more unified search interface it. We can see similar things in regards to OCLC and WorldCat. Maybe these new indexes could be called mega indexes against traditional library content. Personally, such a thing is part of what I have been advocating as the content of next generation library catalogs. [1] [1] http://www.library.nd.edu/daiad/morgan/musings/ngc-in-15-minutes/ -- Eric Lease Morgan University of Notre Dame
Re: [CODE4LIB] Serials Solutions Summon
Well, I'm pretty sure we haven't settled at all on the terminology, but here's how I use the terms: Federated Search - I use this to mean a search where the query is sent against a number of disparate resources; it doesn't matter if they are local or not. I don't use broadcast or distributed search as terms at all. With LibraryFind, we generally describe it as a cross-collection discovery tool; I like this description because it differentiates between a broad discovery (i.e. across collections) approach and a focused discovery (i.e. deeply within a collection) approach, which is a useful distinction both from a systems side and from a user side. Ok, I'm sure that now just added more complexity to things. -- jaf == Jeremy Frumkin Assistant Dean / Chief Technology Strategist University of Arizona Libraries frumk...@u.library.arizona.edu +1 520.307.4548 == -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Mike Taylor Sent: Tuesday, April 21, 2009 7:41 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. _/|_ ___ /o ) \/ Mike Taylorm...@indexdata.com http://www.miketaylor.org.uk )_v__/\ Sorry if my English didn't good enough to well explain my idea -- Ronachai Pratanaphon. Yitzchak Schaffer writes: Andrew Nagy wrote: Summon is really more than an NGC as we are selling it as a service - a unified discovery service. This means that it is a single repository of the library's content ( subscription content, catalog records, IR data, etc.). Federated search is not apart of Summon Well, if we understand federated to mean bringing stuff together by searching all of it at once, then it is, as opposed to broadcast searching, a term you used later in this sentence. As in, Origin: 1665?75; L foeder?tus leagued together, allied, equiv. to foeder- (nom. s. foedus) league from http://dictionary.reference.com/search?q=federated It is, though, a great *breakthrough* in the area of federated search, which is why we ordered an onsite demo immediately on hearing about this product. But I don't think I was clear with my question in any case; it occurs to me now that my true question wasn't code-related, but seeing Summon on the conf agenda prompted me to bring it up here. Namely: has anyone investigated whether the arrangements SerSol has with content vendors are easily duplicable by institutions for home-baked/potential OSS products -- Yitzchak Schaffer Systems Manager Touro College Libraries 33 West 23rd Street New York, NY 10010 Tel (212) 463-0400 x5230 Fax (212) 627-3197 Email yitzc...@touro.edu Twitter /torahsyslib
Re: [CODE4LIB] Serials Solutions Summon
On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:55 AM, Dr R. Sanderson wrote: How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? This new type of index is not any different in functionality from a well-implemented OAI service provider with the exception of the type of content it contains. Not even the type of content, just the source of the content. Eg SS have come to an agreement with the publishers to use their content, and they've stuffed it all in one big index with a nice interface. NTSH, Move Along... Rob
Re: [CODE4LIB] Serials Solutions Summon
On 04/21/2009 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. We've occasionally tried to disambiguate those terms for some purposes around here and realized that, if most people use them synonymously, they're synonyms. You can define differences between meta-, federated, and broadcast search, but every discussion on the topic will be punctuated by people asking, Wait, what's the difference again? We've started using unified index or local index for stuff we get in advance, load here, and search in place; and good old metasearch for stuff scattered in umpteen different locations to which we send searches on demand and collate results. -- Thomas Dowling tdowl...@ohiolink.edu
[CODE4LIB] CALL FOR TUTORIAL PROPOSALS: DC-2009 Conference
Dear all, Apologies for cross-posting. Dublin Core-2009 Conference invites proposals for the Tutorial to be held in Seoul, Korea from 12 to 16 October 2009. We wish to include both Introductory and Advanced tutorials in the program, and would welcome proposals in both categories as described below. Thank you, mj --- *Introductory Tutorials* A half-day introductory tutorial stream is envisaged for the Monday before the main conference (12 October 2009). It is expected that this will be comprised of two sessions of two hours. The purpose of this stream is to give new participants a thorough grounding in the Dublin Core Metadata Initiative. In particular, the tutorials should cover: • the development and focus of DCMI • the Dublin Core Metadata Element Set • the Dublin Core Abstract Model, its role and key concepts • the Singapore Framework, and the development and use of Dublin Core Application --- *Profiles* Support for attendance will be provided to presenters of introductory tutorials. Proposals are invited from individuals, indicating the topics they would cover, relevant experience, and the learning approach. Joint proposals covering the all the desired material are particularly encouraged. --- *Advanced Tutorials* DC-2009 will focus on linked data and the enabling of the Semantic Web. Conference participants will explore the conceptual and practical issues in breaking the constraints of data silos and connecting pieces of data, information, and knowledge. Proposals for advanced tutorials are invited that would explore practice issues related to this theme. It is envisaged that advanced tutorials would be offered twice, on the Monday (12 October 2009) and Friday (16 October 2009), and proposals for both half and full day tutorials are welcome. No direct support will be provided to advanced tutorial presenters, but revenue will be split between the Conference and the presenters. (Registration for half day tutorials will be US$100, for full day tutorials US$200). --- *Submission and selection process* The language for all tutorials will be English. Proposals should be submitted by 15 May 2009 to the Tutorial Chairs, John Roberts (john.robe...@archives.govt.nz) and Heesop Kim (hee...@mail.knu.ac.kr). Please feel free to contact us with any queries regarding this call. Successful proposals will be advised by 22 June 2009, in line with notification of paper acceptance for the main conference. It is expected that tutorial presenters will provide handout materials by 11 September 2009 in time for copying and inclusion in conference material for delegates. Authors of tutorial materials need to agree to grant DCMI a perpetual, non-exclusive licence to use, copy and distribute the material and/or create adaptations or derivatives from the material in any medium for any purpose and without fee or royalty. --- *The full Call for Proposals - DC 2009 Conference Tutorials is available at: * http://dublincore.org/workshops/dc2009/dc-2009-cftut.shtmhttp://dublincore.org/workshops/dc2009/dc-2009-cftut.shtml --- Myung-Ja MJ Han Metadata Librarian 220 Main Library University of Illinois at Urbana Champaign 1408 W. Gregory Dr. (MC-522) Urbana, IL 61801 217-333-9515 (Main Library) 217-244-7809 (Grainger)
Re: [CODE4LIB] Serials Solutions Summon
From: Thomas Dowling tdowl...@ohiolink.edu You can define differences between meta-, federated, and broadcast search, but every discussion on the topic will be punctuated by people asking, Wait, what's the difference again? Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. --Ray
Re: [CODE4LIB] Serials Solutions Summon
Even though Summon is marketed as a Serial Solutions system, I tend to think of it more as coming from Proquest (the parent company, of course). Summon goes a bit beyond what Proquest and CSA have done in the past, loading outside publisher data, your local catalog records, and some other nice data (no small thing, mind you). But, like Rob and Mike, I tend to see this as an evolutionary step for a database aggregator like Proquest rather than a revolutionary one. Obviously, database aggregators like Proquest, OCLC, and Ebsco are well positioned to do this kind of work. The problem, though, is that they are also competitors. At some point, if you want to have a truly unified local index of _all_ of your database, you're going to have to cross aggregator lines. What happens then? --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Dr R. Sanderson [azar...@liverpool.ac.uk] Sent: Tuesday, April 21, 2009 8:14 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:55 AM, Dr R. Sanderson wrote: How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? This new type of index is not any different in functionality from a well-implemented OAI service provider with the exception of the type of content it contains. Not even the type of content, just the source of the content. Eg SS have come to an agreement with the publishers to use their content, and they've stuffed it all in one big index with a nice interface. NTSH, Move Along... Rob
Re: [CODE4LIB] Serials Solutions Summon
I've noticed that reference and instructional librarians (at least in published literature) tend to use the term federated search more often than others. And by that they mean a broadcast search, not what Ray and many others mean by that term. Library technology folk tend to use the other terms more often. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Ray Denenberg, Library of Congress [r...@loc.gov] Sent: Tuesday, April 21, 2009 8:28 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon From: Thomas Dowling tdowl...@ohiolink.edu You can define differences between meta-, federated, and broadcast search, but every discussion on the topic will be punctuated by people asking, Wait, what's the difference again? Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. --Ray
Re: [CODE4LIB] Serials Solutions Summon
Ray Denenberg, Library of Congress writes: From: Thomas Dowling tdowl...@ohiolink.edu You can define differences between meta-, federated, and broadcast search, but every discussion on the topic will be punctuated by people asking, Wait, what's the difference again? Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database. I don't think that's a hard concept and I don't think it is a trivial distinction. Either it IS a hard concept, or you didn't describe it properly -- because I still don't get exactly what is going on here. Are you using federated to mean which Thomas and I (independently) are calling local indexes? _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ ... about as similar as two completely dissimilar things in a pod -- Black Adder.
[CODE4LIB] Code4libNYC Upcoming Meeting - April 22
-- Forwarded message -- From: Kevin Reiss kevin.re...@gmail.com Date: Sun, Apr 12, 2009 at 2:16 PM Subject: [code4libnycsig-l] Upcoming Meeting - April 22 To: code4libnycsig-l code4libnycsi...@list.metro.org Hi List Members, The code4libnyc SIG will hold our next meeting on Wednesday, April 22nd between 10:00 a.m. and 12 noon at the METRO offices at 57 E. 11th Street in Manhattan near Union Square. We plan to have a roundtable discussion and some short, informal presentations from SIG members. We will be discussing the recent Code4lib National Conference that took place in late February in Providence, Rhode Island [http://code4lib.org/conference/2009/]. One of the development team members for Omeka Project [http://omeka.org/] , Jeremy Boggs, also plans to join us for the discussion giving members an opportunity to ask questions and find out what the future has in store that emerging piece of open source web publishing software aimed at Museums, Libraries, and Archives. Please send a brief RSVP note to myself at kevin.re...@gmail.com if you know you will be attending so we can provide METRO with an estimate of how many attendees to expect. Walk-ins are also welcome so if you decide at the last minute you can get away from work and want to drop by please do not hesitate. If there is something you know you'd like to present or discuss with the group ahead of time also please let me know so we have an idea how to best structure our time on the 22nd. Regards, Kevin Reiss Co-moderator, code4libnyc METRO SIG http://www.metro.org/collaborate/index.php/Code4libNYC
Re: [CODE4LIB] Serials Solutions Summon
Thomas Dowling wrote: We've occasionally tried to disambiguate those terms for some purposes around here and realized that, if most people use them synonymously, they're synonyms. You can define differences between meta-, federated, and broadcast search, but every discussion on the topic will be punctuated by people asking, Wait, what's the difference again? That's why I like broadcast search though. Broadcast is very hard to use to mean a local index, and once explained once will probably stick. 'Broadcast' inherently means 'going out' to do your search, right? Similarly, local index. I avoid using federated or meta to refer to one of these techniques specifically, because they are subject to so much confusion. But since these techniques are different in some crucial ways, we DO need ways to talk about them. I suggest broadcast search and local index (or local meta-index). Jonathan
Re: [CODE4LIB] Serials Solutions Summon
Ray Denenberg, Library of Congress wrote: Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. For at least 10 years vendors in the library market have been selling us products called federated search which are in fact distributed/broadcast search products. If you want to reclaim the term federated to mean a local index, I think you have a losing battle in front of you. So I'm sticking with broadcast search and local index. Sometimes you need to use terms invented more recently when the older terms have been used ambiguously or contradictorily. To me, understanding the two different techniques and their differences is more important than the terminology -- it's just important that the terminology be understood.
Re: [CODE4LIB] Serials Solutions Summon
There was some discussion along these lines over on the FederatedSearchBlog, which if you didn't see you might want to peruse... http://federatedsearchblog.com/2009/03/19/beyond-federated-search/ http://federatedsearchblog.com/2009/03/20/beyond-federated-search-the-conversation-continues/ http://federatedsearchblog.com/2009/03/30/beyond-federated-search-%E2%80%93-winning-the-battle-and-losing-the-war/ Carl Carl Grant President Ex Libris North America 1350 E Touhy Avenue, Suite 200 E Des Plaines, IL 60018 T: 847-227-2615 (Toll Free: 800-762-6300) F: 847-296-5636 M: 540-449-2418 W: www.exlibrisgroup.com E: carl.gr...@exlibrisgroup.com Skype: carl_grant On Apr 21, 2009, at 10:33 AM, Walker, David wrote: Even though Summon is marketed as a Serial Solutions system, I tend to think of it more as coming from Proquest (the parent company, of course). Summon goes a bit beyond what Proquest and CSA have done in the past, loading outside publisher data, your local catalog records, and some other nice data (no small thing, mind you). But, like Rob and Mike, I tend to see this as an evolutionary step for a database aggregator like Proquest rather than a revolutionary one. Obviously, database aggregators like Proquest, OCLC, and Ebsco are well positioned to do this kind of work. The problem, though, is that they are also competitors. At some point, if you want to have a truly unified local index of _all_ of your database, you're going to have to cross aggregator lines. What happens then? --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Dr R. Sanderson [azar...@liverpool.ac.uk] Sent: Tuesday, April 21, 2009 8:14 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:55 AM, Dr R. Sanderson wrote: How is this 'new type' of index any different from an index of OAI- PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? This new type of index is not any different in functionality from a well-implemented OAI service provider with the exception of the type of content it contains. Not even the type of content, just the source of the content. Eg SS have come to an agreement with the publishers to use their content, and they've stuffed it all in one big index with a nice interface. NTSH, Move Along... Rob
[CODE4LIB] What do we call it? (was: Serials Solutions Summon)
On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If anyone could summarise, I'd be grateful. Yes, to me, the quoted phases above are synonymous. But I believe we are also seeing a new type of index manifesting itself, and this new index has yet to be named. Specifically, I'm thinking of the index where various types of content is aggregated into a single index and then queried. [trimmed] Wouldn't this just a union catalog? Now, you might want to differentiate between what's being joined -- multiple types of content all at one location vs. the same type of content at multiple locations. (or both varying). I don't think any of the terms mentioned really show that distinction, however. We normally use 'heterogeneous' in the science to refer to more than one type of data object, but it's really superflous in our field, as there are very few forms of federated search where you'd have two repositories of similar data -- maybe for browse objects (movies, pre-rendered images), but those are typically viewed as supplementary metadata, and not the object of primary importance. - Joe Hourcle Principal Software Engineer Solar Data Analysis Center Goddard Space Flight Center
Re: [CODE4LIB] Serials Solutions Summon
From one of the Federated Search vendor's perspective... It seems in the broader web world we in the library world have lost metasearch. That has become the province of those systems (mamma, dogpile, etc.) which search the big web search engines (G,Y,M, etc.) primarily for shoppers and travelers (kayak, mobissimo, etc.) and so on. One of the original differences between these engines and the library/information world ones was that they presented results by Source - not combined. This is still evident in a fashion in the travel sites where you can start multiple search sessions on the individual sites. We use Federated Search for what we do in the library/information space. It equates directly to Jonathan's Broadcast Search which was the original term I used when talking about it about 10 years ago. Broadcast is more descriptive, and I prefer it, but it seems an uphill struggle to get it accepted. Fed Search has the problem of Ray's definition of Federated, to mean a bunch of things brought together. It can be broadcast search (real time searching of remote Sources and aggregation of a virtual result set), or searching of a local (to the searcher) index which is composed of material federated from multiple Sources at some previous time. We tend to use the term Aggregate Index for this (and for the Summon-type index) Mixed content is almost a given, so that is not an issue. And Federated Search systems have to undertake in real time the normalization and other tasks that Summon will be (presumably) putting into its aggregate index. A problem in terminology we come across is the use of local (notice my careful caveat in its use above). It is used to mean local to the searcher (as in the aggregate/meta index above), or it is used to mean local to the original documents (i.e. at the native Source). I can't imagine this has done more than confirm that there is no agreed terminology - which we sort of all knew. So we just do a lot of explaining - with pictures - to people. Peter Noerr Dr Peter Noerr CTO, MuseGlobal, Inc. +1 415 896 6873 (office) +1 415 793 6547 (mobile) www.museglobal.com -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Tuesday, April 21, 2009 08:59 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon Ray Denenberg, Library of Congress wrote: Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. For at least 10 years vendors in the library market have been selling us products called federated search which are in fact distributed/broadcast search products. If you want to reclaim the term federated to mean a local index, I think you have a losing battle in front of you. So I'm sticking with broadcast search and local index. Sometimes you need to use terms invented more recently when the older terms have been used ambiguously or contradictorily. To me, understanding the two different techniques and their differences is more important than the terminology -- it's just important that the terminology be understood.
Re: [CODE4LIB] Serials Solutions Summon
Jonathan: I think you've cut to the chase on this one and seen the potential. I went to one of the roll out presentations at Midwinter on Summon, and was quite impressed. As someone who *was* an aggregator of metadata in the recent past (NSDL in the early part of this decade), I can attest to the fact that making disparate metadata play well together is not an easy task. The benefit of doing it the way Summon does it is threefold: 1. They are dealing directly with each provider, and saving the libraries from having to do this (this is not a small thing, trust me) 2. They recognize the need and the potential for normalizing and improving the metadata in aggregate (which is generally cheaper, and vastly improves the behavior and possibilities for the data) 3. Because they also have data on what journals any particular library customer has subscribed to, they can customize the product for each library, ensuring that the library's users aren't served a bunch of results that they ultimately can't access. This very much the kind of thing that my colleagues at NSDL were trying to do, but for a lot of reasons (largely political, unfortunately) were never able to realize. There will be lots of challenges for them as they move forward with this, and I for one will be watching closely. I did speak to Peter McCracken after the Midwinter presentation, and pointed out that they might find dealing with personal names a challenge they might want to take up sooner, rather than later--remember they have both article metadata and library metadata being presented together, with vastly different conventions for names ... Diane Jonathan Rochkind wrote: Dr R. Sanderson wrote: Eric, How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? Sounds like good PR to me, rather than a revolution ;) I don't know about revolution. But your right that this _approach_ is similar to an OAI-PMH approach sure. But getting this approach to actually work reliably and succesfully with published scholarly articles -- is NOT easy. Most of these publishers and aggregators do not have OAI-PMH feeds. (And even if they did, the typical OAI-PMH feed supplying only OAI-DC data does NOT provide sufficient structured metadata for a search of scholarly content). Most of them do not share their metadata freely. You need to have an individual relationship with each one, and you need workflow in place on your end to make sure you have updated metadata for each one, and you need to deal with the inevitable bugs and bad data from the publishers and vendors, and you need to do some normalizing so that they can all actually live together in an index that works for the user. This is not an easy thing to do. I believe that some library consortiums have long histories of trying to do this (OhioLink?); some have given up and no longer try to do it (CDL I think?), because it's very expensive and difficult to do right. If SerialSolutions has succeeded in doing it so it works well, and can provide it an affordable cost -- this will, in my opinion be huge. It's not the basic technology of having a local index that's revolutionary. It's, potentially, applying that technology to this particular case, and actually having it produce something that works well for end-users, and being able to do it at an affordable cost. But certainly you don't have to be SerialSolutions to do this. I hope that the product succeeds, and I hope that it gets 'competitors' (library consortial and other vendors) so we have options. But if it was so easy to do affordably, we'd have it already, right? Jonathan Rob On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:40 AM, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into But I believe we are also seeing a new type of index manifesting itself, and this new index has yet to be named. Specifically, I'm thinking of the index where various types of content is aggregated into a single index and then queried. For example, instead of providing a federated search against one or more library catalogs, a Z39.50 accessible journal article index, a local cache of harvested OAI content, etc., I think we are beginning to see all of these content silos (and others) brought together into a single (Solr/ Lucene) index and searched simultaneously. I'm not sure, but I think this is how Summon works.
Re: [CODE4LIB] Serials Solutions Summon
I think I like your term aggregated index even better than local index, thanks Peter. You're right that local can be confusing as far as local to WHAT. So that's my new choice of terminology with the highest chance of being understood and least chance of being misconstrued: broadcast search vs. aggregated index. As we've discovered in this thread, if you say federated search without qualification, different people _will_ have different ideas of what you're talking about, as apparently the phrase has been historically used differently by different people/communities. I think broadcast search and aggregated index are specific enough that it would be harder for reasonable people to misconstrue -- and don't (yet?) have a history of being used to refer to different things by different people. So it's what I'm going to use. Jonathan Peter Noerr wrote: From one of the Federated Search vendor's perspective... It seems in the broader web world we in the library world have lost metasearch. That has become the province of those systems (mamma, dogpile, etc.) which search the big web search engines (G,Y,M, etc.) primarily for shoppers and travelers (kayak, mobissimo, etc.) and so on. One of the original differences between these engines and the library/information world ones was that they presented results by Source - not combined. This is still evident in a fashion in the travel sites where you can start multiple search sessions on the individual sites. We use Federated Search for what we do in the library/information space. It equates directly to Jonathan's Broadcast Search which was the original term I used when talking about it about 10 years ago. Broadcast is more descriptive, and I prefer it, but it seems an uphill struggle to get it accepted. Fed Search has the problem of Ray's definition of Federated, to mean a bunch of things brought together. It can be broadcast search (real time searching of remote Sources and aggregation of a virtual result set), or searching of a local (to the searcher) index which is composed of material federated from multiple Sources at some previous time. We tend to use the term Aggregate Index for this (and for the Summon-type index) Mixed content is almost a given, so that is not an issue. And Federated Search systems have to undertake in real time the normalization and other tasks that Summon will be (presumably) putting into its aggregate index. A problem in terminology we come across is the use of local (notice my careful caveat in its use above). It is used to mean local to the searcher (as in the aggregate/meta index above), or it is used to mean local to the original documents (i.e. at the native Source). I can't imagine this has done more than confirm that there is no agreed terminology - which we sort of all knew. So we just do a lot of explaining - with pictures - to people. Peter Noerr Dr Peter Noerr CTO, MuseGlobal, Inc. +1 415 896 6873 (office) +1 415 793 6547 (mobile) www.museglobal.com -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Tuesday, April 21, 2009 08:59 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon Ray Denenberg, Library of Congress wrote: Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. For at least 10 years vendors in the library market have been selling us products called federated search which are in fact distributed/broadcast search products. If you want to reclaim the term federated to mean a local index, I think you have a losing battle in front of you. So I'm sticking with broadcast search and local index. Sometimes you need to use terms invented more recently when the older terms have been used ambiguously or contradictorily. To me, understanding the two different techniques and their differences is more important than the terminology -- it's just important that the terminology be understood.
Re: [CODE4LIB] Serials Solutions Summon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 21, 2009, at 11:02 AM, Jonathan Rochkind wrote: It _would_ be great if SerSol would actually give you (if you were subscribed) a feed of their harvested and normalized metadata, so you could still pay them to collect and normalize it, but then use it for your own purposes outside of Summon. I hope SerSol will consider this down the line, if Summon is succesful. I don't think it is part of SerSol's business model to offer a feed of the full metadata it aggregates, but it does seem to be part of the business model to offer an API upon which you could put your own interface to the underlying aggregated data. On Apr 21, 2009, at 12:35 PM, Joe Hourcle wrote: Wouldn't this just a union catalog? Catalog is such a loaded term that I wouldn't want to touch it... ;-) Peter - -- Peter Murrayhttp://www.pandc.org/peter/work/ Assistant Director, New Service Development tel:+1-614-728-3600;ext=338 OhioLINK: the Ohio Library and Information NetworkColumbus, Ohio The Disruptive Library Technology Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Ask me how you can start digitally signing your email. iEYEARECAAYFAknuC9EACgkQ4+t4qSfPIHIhuACgsVi/3EvjwgvRw9leoj0JzjWL yTwAnjBGmJnjrIvdoVe39mcihZB6nkjJ =XLA8 -END PGP SIGNATURE-
Re: [CODE4LIB] Serials Solutions Summon
From: Jonathan Rochkind rochk...@jhu.edu If you want to reclaim the term federated to mean a local index, I think you have a losing battle in front of you. It's not a battle I plan to pursue, I don't fight battles anymore. I just feel obligated to observe that when vocabulary is tinkered with in this fashion -- and I did notice, probably more than ten years ago, that federated was being manipulated -- it makes it difficult to express modeling concepts when definitions are a moving target. In the future, vendors should be more careful about messing around with established definitions. If you don't like the federated model (the old one), don't redefine the term, find a new term. The old term could someday come in handy for expressing why you don't like that model, but it's useless if nobody agrees what it means. --Ray
Re: [CODE4LIB] Serials Solutions Summon
Peter Murray wrote: I don't think it is part of SerSol's business model to offer a feed of the full metadata it aggregates, but it does seem to be part of the business model to offer an API upon which you could put your own interface to the underlying aggregated data. Yep, it's not presently, but I'm hoping that in the future they expand to that business model as well. I think it's feasible. An API on which you can act on their index is great. But actually having the data to re-index yourself in exactly the way you wanted would give you even more power (if you wanted to do the more work to get it). And would still be worth paying SerSol for, for the work of aggregating and normalizing the data. Jonathan
Re: [CODE4LIB] Serials Solutions Summon
It is possible for a consortium to build the same sort of service as Serials Solutions. Besides the OhioLink example, we've been doing that in Ontario for the last 7 years or so - aggregating ejournal content (15 million articles), abstract and index databases (over 100 now in partnership with Proquest), ebooks (about 50,000 commercial ebooks and 170,000 plus digitized ebooks from the Open Content Alliance). It is a significant effort to deal with all the data feeds but as publishers migrate their production processes to XML we're finding that it is getting a little easier each year. We aggregate everything in a single XML database from a company called MarkLogic. The biggest issues we struggle with are currency - it's never as fast as the publisher site though it isn't far behind when things are working well - and quality control - the publisher production processes are shifting to XML but the quality of the data varies. But hey, it's a library, and these are age-old issues present even in the print world. Alan On 4/21/09 2:13 PM, Jonathan Rochkind rochk...@jhu.edu wrote: Peter Murray wrote: I don't think it is part of SerSol's business model to offer a feed of the full metadata it aggregates, but it does seem to be part of the business model to offer an API upon which you could put your own interface to the underlying aggregated data. Yep, it's not presently, but I'm hoping that in the future they expand to that business model as well. I think it's feasible. An API on which you can act on their index is great. But actually having the data to re-index yourself in exactly the way you wanted would give you even more power (if you wanted to do the more work to get it). And would still be worth paying SerSol for, for the work of aggregating and normalizing the data. Jonathan
Re: [CODE4LIB] Serials Solutions Summon
Agree. When you step outside libraryland and into corporate/enterprise IT (thinking Autonomy, FAST, etc.) then federated search is often used to refer to aggregated local indexing of distinct databases. Jason -- Jason Stirnaman Digital Projects Librarian/School of Medicine Support A.R. Dykes Library, University of Kansas Medical Center jstirna...@kumc.edu 913-588-7319 On 4/21/2009 at 12:56 PM, in message 49ee08d3.7010...@jhu.edu, Jonathan Rochkind rochk...@jhu.edu wrote: I think I like your term aggregated index even better than local index, thanks Peter. You're right that local can be confusing as far as local to WHAT. So that's my new choice of terminology with the highest chance of being understood and least chance of being misconstrued: broadcast search vs. aggregated index. As we've discovered in this thread, if you say federated search without qualification, different people _will_ have different ideas of what you're talking about, as apparently the phrase has been historically used differently by different people/communities. I think broadcast search and aggregated index are specific enough that it would be harder for reasonable people to misconstrue -- and don't (yet?) have a history of being used to refer to different things by different people. So it's what I'm going to use. Jonathan Peter Noerr wrote: From one of the Federated Search vendor's perspective... It seems in the broader web world we in the library world have lost metasearch. That has become the province of those systems (mamma, dogpile, etc.) which search the big web search engines (G,Y,M, etc.) primarily for shoppers and travelers (kayak, mobissimo, etc.) and so on. One of the original differences between these engines and the library/information world ones was that they presented results by Source - not combined. This is still evident in a fashion in the travel sites where you can start multiple search sessions on the individual sites. We use Federated Search for what we do in the library/information space. It equates directly to Jonathan's Broadcast Search which was the original term I used when talking about it about 10 years ago. Broadcast is more descriptive, and I prefer it, but it seems an uphill struggle to get it accepted. Fed Search has the problem of Ray's definition of Federated, to mean a bunch of things brought together. It can be broadcast search (real time searching of remote Sources and aggregation of a virtual result set), or searching of a local (to the searcher) index which is composed of material federated from multiple Sources at some previous time. We tend to use the term Aggregate Index for this (and for the Summon-type index) Mixed content is almost a given, so that is not an issue. And Federated Search systems have to undertake in real time the normalization and other tasks that Summon will be (presumably) putting into its aggregate index. A problem in terminology we come across is the use of local (notice my careful caveat in its use above). It is used to mean local to the searcher (as in the aggregate/meta index above), or it is used to mean local to the original documents (i.e. at the native Source). I can't imagine this has done more than confirm that there is no agreed terminology - which we sort of all knew. So we just do a lot of explaining - with pictures - to people. Peter Noerr Dr Peter Noerr CTO, MuseGlobal, Inc. +1 415 896 6873 (office) +1 415 793 6547 (mobile) www.museglobal.com -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Tuesday, April 21, 2009 08:59 To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Serials Solutions Summon Ray Denenberg, Library of Congress wrote: Leaving aside metasearch and broadcast search (terms invented more recently) it is a shame if federated has really lost its distinction fromdistributed. Historically, a federated database is one that integrates multiple (autonomous) databases so it is in effect a virtual distributed database, though a single database.I don't think that's a hard concept and I don't think it is a trivial distinction. For at least 10 years vendors in the library market have been selling us products called federated search which are in fact distributed/broadcast search products. If you want to reclaim the term federated to mean a local index, I think you have a losing battle in front of you. So I'm sticking with broadcast search and local index. Sometimes you need to use terms invented more recently when the older terms have been used ambiguously or contradictorily. To me, understanding the two different techniques and their differences is more important than the terminology -- it's just important that the terminology be understood.
[CODE4LIB] Fwd: Job Posting - Digital Initiatives Metadata Librarian - University of Vermont
*Digital Initiatives Metadata Librarian /Library Assistant Professor - University of Vermont Libraries* The University of Vermont Libraries' Center for Digital Initiatives (CDI, http://cdi.uvm.edu/) seeks a detail-oriented, innovative, and energetic librarian for the position of Digital Initiatives Metadata Librarian. The Institute for Museum and Library Services has recently awarded the University of Vermont a 24-month grant to continue development of the Libraries' digital initiatives. The main goal of this grant is to build a user community for the CDI that will engage as active participants in the development of the CDI and the content and services it provides. The Digital Initiatives Metadata Librarian will provide expertise and leadership in the creation and maintenance of metadata for digital content acquired or created by the CDI. The Digital Initiatives Metadata Librarian will help to develop, refine, and implement policies, procedures, workflows, and metadata standards for the CDI; manage digitization projects; and participate in the overall management of the CDI.* * *RESPONSIBILITIES:* Provides expertise and leadership in the creation and maintenance of metadata for digital content acquired or created by the CDI; provides descriptive, technical, and structural metadata for digital content; evaluates and maintains quality control of metadata operations; trains and supports metadata staff; maintains documentation on metadata best practices; analyzes metadata needs and provides estimated metadata costs and timeline for proposed projects; designs, implements, and manages project workflows;collaborates with CDI and Libraries staff in selection of digital projects and content; participates in the management of the CDI; promotes and reports on CDI activities to local, regional, and national communities; represents the CDI in professional and campus organizations and initiatives. *REQUIRED QUALIFICATIONS:* Master's degree from an ALA-accredited program or foreign equivalent; experience with metadata work on digital projects; experience with XML.; experience with standards-based non-MARC metadata schemas, such as Dublin Core, MODS, METS, EAD and TEI; knowledge of MARC; familiarity with controlled vocabularies, such as LCSH, AAT, LCTGM, GNIS, and TGN; demonstrated project management experience; excellent attention to detail; ability to work independently and in a team environment; excellent interpersonal and communication skills; commitment to professional achievement and growth; commitment to diversity and inclusion. *PREFERRED QUALIFICATIONS*: Working knowledge of digital asset management systems; demonstrated understanding of preservation metadata, such as PREMIS; experience in crosswalking, normalizing, and transforming xml metadata; working knowledge of XSLT. *SALARY AND APPLICATION INFORMATION:* Qualifications should merit appointment at the rank of library assistant professor (non-tenure track). Salary is commensurate with experience, not less than $49,191 for this position. Benefit package includes TIAA/CREF or alternate plan, managed health care plan, and 22 days of annual paid vacation. Review of applications will begin on May 8, 2009 and will continue until position is filled. Anticipated start date is August 15, 2009. Apply on line at http://www.uvmjobs.com http://www.uvmjobs.com/ with letter of application, vita, and names and contact information for three professional references. Job Requisition Number = 032645. Questions about the position may be directed to the chair of the search committee at chris.bu...@uvm.edu The University of Vermont is an AA/EO employer. - End forwarded message - - End forwarded message - *Digital Initiatives Metadata Librarian /Library Assistant Professor - University of Vermont Libraries* The University of Vermont Libraries' Center for Digital Initiatives (CDI, http://cdi.uvm.edu/) seeks a detail-oriented, innovative, and energetic librarian for the position of Digital Initiatives Metadata Librarian. The Institute for Museum and Library Services has recently awarded the University of Vermont a 24-month grant to continue development of the Libraries' digital initiatives. The main goal of this grant is to build a user community for the CDI that will engage as active participants in the development of the CDI and the content and services it provides. The Digital Initiatives Metadata Librarian will provide expertise and leadership in the creation and maintenance of metadata for digital content acquired or created by the CDI. The Digital Initiatives Metadata Librarian will help to develop, refine, and implement policies, procedures, workflows, and metadata standards for the CDI; manage digitization projects; and participate in the overall management of the CDI.* * *RESPONSIBILITIES:* Provides expertise and leadership in the creation and maintenance of metadata for digital content acquired or created by
