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.