Summit Catalog
Committee-Steering Team
November 6, 2006
Teleconference
Members attending via phone:
Lewis and Clark: Mark Dahl
Southern
Consortium staff: Nancy Nathanson
1. Welcome and
introductions
Welcome
and introductions.
2. Working
group nominations
The Steering Team reviewed the results of the recent
survey for nominations to the SCC Working Groups for 2006/2007. They looked for a solid mix of interests and
expertise from the nominations to be on each working group.
The
Data Harvesting Working Group (explore Summit’s potential as a source of data for
the purpose of developing improved services and informing decisions made by
member libraries and the consortium) will have the following members:
Corey
Murata,
Claudia
Weston,
Julie
Miller, Eastern
Mike
Spalti,
Mark
Dahl,
Mark
Kibbey,
1
member from Summit Borrowing Committee
1
member from Summit Collection Development and Management Committee
The
Short Term Changes to Summit Search Interface Working Group (evaluate current
Bill
Kelm,
Carla
Pealer,
Gary
Markham,
Kirstin
Hierholzer,
Kate
Rubick,
Kate
Cleland-Sipfle, Southern
Marilyn
Von Seggern,
The
Duplicate (Records) Reduction Working Group (develop technical, policy, and
workflow recommendations to prevent and eliminate duplicate bibliographic
records) will have the following members:
Friday
Valentine,
Diana
Brooking,
Tom
Larsen,
Carol
Drost,
Daniel
CannCasciato,
Michael
Boock,
Marcia
Bianchi,
The
Next Generation Summit Search Interface Working Group ( explore and evaluate
various options for providing “next generation” catalog functionality, which
could include such features as relevance based searching, faceted browsing,
enriched records…) will have the following members:
Janet
Crum,
Joe
Kiegel,
Michaela
Brenner,
Diane
Sotak,
Lori
Robare,
Terry
Reese,
Laura
Zeigen,
Sara
Brownmiller,
The
resource sharing program manager will be available as a consultant to all four
working groups. In particular,
Mark
Dahl will send an email to the SCC list with the final list of working group
members. The Steering Team members will
convene their respective groups with an introductory email. It was suggested that a request for a leader
of the working group be made at the time of the first contact or the working
group may want to meet first over the phone to appoint a leader. The working groups from last year used online
tools to share documents and worked remotely more of the time. There is no money for travel. Nancy Nathanson has already put up webpages
for each working group.
3. Timeline for
each working group – any group may
ask for a two week extension if circumstances mean that they won’t be finished
with their work by their due date.
Data
Harvesting Working Group –Their charge is to do research and then write a
report for SCC making recommendations based on the research by March 1, 2007
Short-term
Changes Working Group – Their charge is both research and implementation. The research should be completed by March 1,
2007. Implementation will proceed after
that. The Steering Team will need to
review their recommendations before they go out to the greater community. The Group should send their recommendations
to the Steering Team in early
February. February 1 – February 15 will
be the review period. The Steering Team
will make comments immediately so that the report can go out to the whole SCC
for additional comments and revisions.
Duplicate
Reduction Working Group – This group will make its recommendations by
Next
Generation Working Group – Their charge is to do research and submit a report
with various options to SCC by
4. Liaison
reports – no comments or responses to
any queries.
5. Next SCC meeting – After all of the reports have been submitted and background information can be sent out. Probably in late March or early April.
6. Proposal for link resolver router
Janet drafted the following enhancement request for the Steering Team’s comments and suggestions.
The Orbis Cascade Alliance Catalog Committee proposes that INN-Reach be enhanced as follows:
1. The
2. Users of the INN-Reach catalog, upon clicking a button or link to access link resolver functionality, should be routed to their local institution's link resolver. If the user were prompted to authenticate, the user could be routed automatically to the resolver of their home institution. But it may be preferable to instead offer the user a menu of participating institutions that have link resolvers. This method would allow users to choose the link resolver they wished to use, which might not be the one associated with their home library. It would also eliminate the need for the user to authenticate before accessing link resolver functionality. Finally, this method would provide a graceful way to handle institutions that don't have link resolvers. Those institutions simply wouldn't be listed on the menu.
Some
of the comments were as follows: It was
suggested that it would be good to only have to select a link resolver once
during a session. It could be stored in
a cookie for that session. It would also
be nice to have IP recognition integrated in the product, as long as it could
be easily overridden.
Next meeting: We will have another phone meeting the 1st
week in December.
Minutes: Marcia Bianchi