 |
 |
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