LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  February 2017

BIBFRAME February 2017

Subject:

BIBFRAME in FOLIO

From:

Sebastian Hammer <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Thu, 2 Feb 2017 12:07:29 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (108 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager