Print

Print


Widely adopted means? By whom?

What if some people use MARC, some use MARC+schema.org, some use
BIBFRAME, some use RDA in RDF, others use Dublin Core, still others use
the DPLA data format, yet all exchange data? Would that be a failure?

If your answer is "yes" then you consider what we have today a failure.
I suspect you are looking too narrowly at "replacement for MARC" -
there's already a lot of different metadata being created in the GLAM world.

Failure could be better defined by technical availability; the big
barrier to any metadata creation is having systems that ingest and
produce that metadata. Systems are the weak link in the whole library
eco-system. I see system creation and deployment as the thorniest
problem that libraries face. I'm less concerned about the format of the
metadata than the fact that libraries can hardly afford to participate
in modern data exchange and no one seems to be working to solve that.
There are some good open source efforts, but not much coordination of
them on a large enough scale. That's where success could come from.

I think you're looking at the wrong end of the telescope, but that's me.

kc


On 2/1/17 12:19 PM, Jeff Edmunds wrote:
> Failure = failure to be widely accepted or adopted, and thus
> subsequently abandoned after an extraordinary amount of time,
> attention, and hand-wringing devoted to it.
>
>
> >Well, before you go further you had better have a solid definition of
> >"failure" that your audience at least understands, even if it doesn't
> >agree to it.
> >
> >kc
>
>
>
> On 2/1/17 7:45 AM, Jeff Edmunds wrote:
> > All,
> >
> > Next month I'll be giving a presentation entitled "Life after MARC?:
> The Future of Discovery." One of the central theses of the talk is
> that, unlike MARC, BIBFRAME will never be widely adopted. I would be
> very curious to hear arguments countering my key points:
> >
> > 1) Unlike its stature in the Age of MARC, the Library of Congress
> lacks the authority to impose its standards or practices on the
> bibliographic metadata ecosystem. LC is no longer the chief source of
> bibliographic metadata, and the influence on the ecosystem of the
> bibliographic metadata it generates is minimal. The most likely allies
> of LC in moving BIBFRAME forward--large academic or public libraries
> with experienced cataloging staff--are shifting resources AWAY from
> cataloging and into other areas (digital humanities, assessment,
> student engagement, open access, etc.).
> >
> > 2) The technical infrastructure of current ILS, discovery,
> next-generation, etc. platforms does not support BIBFRAME and there is
> no market incentive to change. 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.
> >
> > 3) BIBFRAME in a production environment is wildly impractical: the
> BIBFLOW Project, although it officially ended in 2016, has issued no
> substantive final report of which I am aware. Does one exist?
> >
> > 4) BIBFRAME is highly conceptual, top-heavy, and too complicated to
> be understood and effectively implemented by most libraries (cf. the
> failure of many librarties to adopt RDA over AACR2). The people
> talking about BIBFRAME (various PCC committees, etc.) are not creating
> BIBFRAME-compliant metadata; they are merely talking about it.
> >
> > 5) Discovery of library (and archival, etc.) materials no longer
> runs primarily on bibliographic metadata; it runs on megadata, which I
> define as a complicated mess of metadata, full text, and big data
> (including personalization data). As a result, there is less need for,
> and appreciation of, quality metadata.
> >
> > Counterarguments are welcome, either on- or off-list.
> >
> > Thank you,
> >
> > Jeff
>
> >--
> >Karen Coyle
> >[log in to unmask] http://kcoyle.net
> >[log in to unmask] http://kcoyle.net
> >m: +1-510-435-8234
> >skype: kcoylenet/+1-510-984-3600
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600