Hey guys,
New member here. I wanted to address this point by Jeff:
" Open-source, collaborative ventures like FOILO must necessarily base
much of their development around current and legacy MARC data, not
largely hypothetical data models like BIBFRAME."
Quick background: I'm a partner in Index Data and I have played a role
in articulating the technology vision for FOLIO and guiding the
execution of the project towards that vision. As part of that role, and
because I'm a metadata nerd, I spent a lot of time thinking and talking
to people about the role of metadata in day to day library workflows, as
well as where things might be headed. Karen had the patience of an angel
with my stupid questions. Index Data has also been working with the LoC
and others for years on prototyping and building out tools and
approaches to working with BIBFRAME and other technologies. I think we
probably built the world's first -- and possibly the last --
SRU-->SPARQL gateway, but that's another story. I offer this as the
perspective of a developer undertaking a substantial new LSP project,
and having to deal with the questions posed by the BIBFRAME movement,
for lack of a better term.
I knew one thing going into FOLIO with absolute certainty: Contrary to
Jeff's point, we must at all cost avoid basing our development around
MARC data, thereby making it harder for people to pursue and support
emerging and future approaches. MARC *has* to be supported, sure,
because it's likely not going away in our lifetime, but to start a
greenfield LSP project and assume that MARC and, more importantly,
traditional MARC-centric workflows would remain dominant, would be
reckless and irresponsible in my view.
The following are what I would say are the guiding ideas behind our
emerging work in FOLIO as it pertains to this conversation:
1) As others have observed, we already live in a world where we have to
deal with myriads of data formats, approaches, and modes of operation
when it comes to bibliographic metadata. If there was ever a time when
we expected that FRBR, RDA, or BIBFRAME would lead to a single,
well-defined approach with the incredibly focus of purpose, success and
longevity of MARC, surely that time has passed. It's a messy, unruly
world out there, and our software had better be ready to adapt.
2) Libraries and catalogers will not "adopt" BIBFRAME on their own. They
must challenge their vendors and developers to do so. Workflows in a
BIBFRAME (etc) universe must be simpler and easier, to allow for
shrinking staff budgets. What is lacking is a shared vision or
understanding of what adoption *means*. I think we can get better at
articulating this as a community. In FOLIO, we respond with defensive
programming -- we try to be prepared for any eventuality. But this is
not optimal, and it would be a hopeless proposition for any legacy
vendor looking to get into the game while riding a pile of technical debt.
3) BIBFRAME isn't just a MARC replacement. This is essential, and I feel
that conversations often trip over themselves here. BIBFRAME challenges
assumptions about how metadata is created and shared, and the role of
shared utilities. We must move from legacy notions of "copy cataloging"
to approaches that favor true sharing and re-use rather than minting
redundant copies of information all over the place. I believe that
BIBFRAME and LOD in general challenges us to move from copy cataloging
to variations of copying by reference. Developers call the principle DRY
(Don't Repeat Yourself). Going back to point 2, this ONLY works if the
software supports it, and makes it easy and seamless to work in this
way. But it also means that organizations like the LoC and others need
to stand up and host dependable, quality metadata for us to link to
(this is contentious, because reliance on shared utilities is risky. I
personally think it's hard to avoid, but it's an interesting discussion).
4) Nobody knows the 'right' way to do BIBFRAME in an LSP today. We've
got people who have been brave and who have experimented -- I bet some
of them have been successful -- but I would venture that best practices
are still to be determined. To be honest, I am not sure best practices
will EVER be established (see point 1 above). For FOLIO, this means
whatever we do had better be fixable without tearing the whole system to
pieces. So a part of our modular approach is to make the bibliographic
infrastructure itself replaceable.
There are some aspects of BIBFRAME that really resonate with us in
FOLIO. We like the entity model (works/instances) which feels pragmatic
and well aimed at where libraries live and breathe (we get instances of
stuff into the hands of users). We like that it challenges us to not
think about the LSP as the "system of record" for everything, but to
explore what it means to have data curated in different places while
still leaving it useful. This feels 'right' to me if I look at the
practicalities of where data originates and lives today.
The bibliographic infrastructure that we're building for FOLIO will be
based on interlinked entities that can be based on MARC source records,
BIBFRAME entities maintained locally or remotely, or other stuff. The
notion of dealing with data that is curated elsewhere actually dovetails
really nicely with another ambition, which is to break down some of the
conceptual differences between traditional print catalogs and electronic
knowledge bases. BIBFRAME introduces a satisfying granularity to that
model (you have to be prepared for everything) and the whole thing comes
together pretty nicely as a set of abstract interfaces. Much will need
to be resolved as we move forward, and part of the game is ensuring
fallback positions if your assumptions don't hold water or if the global
infrastructure doesn't emerge. There will no doubt be those people who
just want to load a bunch of MARC records into FOLIO and be done with
it. :-)
I hope this clarifies things as far as FOLIO is concerned.. I'm happy to
discuss further offline or here. Note, I'm a member of the FOLIO
community interested in these questions, but don't speak for FOLIO more
than anyone else.
--Sebastian
|