"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
What Can We Do About Our Legacy Data?
1. D I A N E H I L L M A N N
C A T A L O G I N G N O R M S I G
A L A A N N U A L 2 0 1 5 S A N F R A N C I S C O
WHAT CAN WE DO
ABOUT OUR LEGACY?
6/27/15 ALA 2015 Cataloging Norms
2. MORE QUESTIONS THAN ANSWERS
• How do we think we’ll use the legacy MARC data?
• Will we map once and discard the old data?
• This was the usual data migration path for ILS data
• Will we continue to maintain older data ‘just in
case’?
• How will the changes in sharing paradigms affect
how some important functions are managed?
6/27/15 ALA 2015 Cataloging Norms
3. WHAT WILL WE USE LEGACY DATA
FOR?
• Have we agreed yet on what functions we want to
support?
• Local discovery services?
• Circulation?
• ILL?
• What else?
• What does expansion of sharing into the larger data
world buy us?
6/27/15 ALA 2015 Cataloging Norms
4. IS EXPOSING LINKED DATA THE SAME
AS SHARING DATA?
• Do we know what sharing partners will want?
• What if they’re not using the same schema we are using?
• Is consensus necessary? Can’t we expose everything and
let others pick and choose?
• Do contractual agreements and licenses still hold sway
when we stop exchanging ‘records’?
• What about those still tied to MARC? Can we still
include them? How can we accomplish that?
6/27/15 ALA 2015 Cataloging Norms
6. THE OLD SHARING MODEL
• Data passes through a central cache, where
identity management and quality control occur
• Caches at either end follow agreed upon standards
to participate
• System of transaction charges supports the central
functions
6/27/15 ALA 2015 Cataloging Norms
8. THE NEW SHARING MODEL
• Some exchange of data between local cache and
central cache may happen much as before, but
the local cache is likely to have more choices for
data acquisition
• Local caches expose data for use by other
downstream users, bypassing the central cache’s
identity management, quality control and fees
• ‘New’ business models replace the old transaction
based charges
• Smaller services may spring up to support some of these
functions for local caches
6/27/15 ALA 2015 Cataloging Norms
9. DO WE KNOW WHERE WE’RE GOING?
• Will we expect to ‘choose’ a schema and bring
everything with us into that schema?
• Will new ILSs emerge to assist with that?
• What if we choose badly? Can we have a
makeover?
• Does it make sense to retain the legacy MARC data
in a common cache? Or perhaps many local
caches?
• Can this strategy future proof our decision-making?
6/27/15 ALA 2015 Cataloging Norms
10. LEGACY AS VALUE
• How do we maintain the value of our legacy data if
our new data doesn’t integrate well with it?
• How will we avoid losing data in the process of
transforming it?
6/27/15 ALA 2015 Cataloging Norms
11. WHAT ABOUT MULTI-MEDIA?
• How much should requirements for new media,
ebooks, etc., drive our requirements?
• What about other languages and scripts?
• Can simple solutions work for the entire array of
more complex materials and versions?
• Do we all need to be using the same schema and
doing the same thing? Can we still share data if we
don’t?
6/27/15 ALA 2015 Cataloging Norms
12. OPTIONS TO CONSIDER
• Bring the legacy records with us into new systems
• Keep them as MARC or map them to new schema and toss
the MARC?
• Park the MARC, retain it as cache, just in case we need to
re-do the mapping?
• Does the solution depend on whether we can map
MARC easily into something and back without
significant loss?
6/27/15 ALA 2015 Cataloging Norms
13. WHERE DO MAPPING & PROFILES FIT?
• Who will do the mapping? Will one map work for all
of us and our various needs?
• Why are application profiles useful, and how do we
manage and share them
• Can we manage and share maps as we do other
resources (like vocabularies, for instance?)
6/27/15 ALA 2015 Cataloging Norms
14. TRANSITION ...
• ... Not very comfortable
• ... Not without significant challenges
• We will prevail!
Contact: Diane I. Hillmann
Email: metadata.maven@gmail.com
6/27/15 ALA 2015 Cataloging Norms