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:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  February 2017

BIBFRAME February 2017

Subject:

Re: Inbound Linked Data (no BIBFRAME required?)

From:

Jeff Edmunds <[log in to unmask]>

Reply-To:

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

Date:

Mon, 6 Feb 2017 13:03:54 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (107 lines)

Steve,

When a library posts a job with the position title “Bayesian
Probabilistic Model of Algorithmic Metadata Manager,” let me know. ;)

Seriously though, I understand that my statements about linked
*everything* can seem like a straw person argument. But the point I’m
trying to make is that I question the added value libraries will bring
to the current information ecosystem simply by exposing and sharing
their metadata, especially when the resources they point to are often
proprietary and not accessible to the public.

As our participation in the Google Books project taught us, the
collections of large academic research libraries overlap heavily--we all
have the same stuff. As a result, we all have the same metadata. The
same is certainly true of most public and school libraries in the US.
There are titles EVERYONE has. Will exposing metadata for these
resources add value for users?

Of course there are innumerable local unique collections. Ironically,
these are the ones that are the least-described (i.e. for which the
least amount of granular metadata is available; see "More Product, Less
Process: Revamping Traditional Archival Processing" by Mark A. Greene
and Dennis Meissner). These would have to be fully cataloged (and fully
digitized if access, rather than simply discovery, were an issue) for
them to add value in a LOD ecosystem. I don’t see that happening.

So the evolution and scenario you describe are fine. Maybe there will be
folks in libraries who “curate a series of algorithms that define how
information is retrieved and used locally at the point of need.” But
someone, somewhere, has to create the metadata underpinning the system;
someone, somewhere, has to perform the authority (or if you prefer,
identity management) work that is crucial for linked data to work. And
someone, somewhere has to pay for all this. For me, this is where things
break down. As Martynus said in the Failure thread, “there are no
technical obstacles for the success of BIBFRAME, only economic and
political ones.” In my view, those obstacles are insurmountable, and
that's precisely why I posited that "BIBFRAME will fail."

Thanks,

Jeff



On Mon, 6 Feb 2017 16:32:47 +0000, Stephen Meyer
<[log in to unmask]> wrote:

>
>On Feb 6, 2017, at 8:57 AM, Jeff Edmunds
<[log in to unmask]<mailto:[log in to unmask]>> wrote:
>
>But for the sake of argument let’s imagine that every library worldwide
>has implemented (to a greater or lesser degree) the principles of
Linked
>Open Data and shared (to a greater or lesser degree) its metadata in
>some fairly standardized way using more-or-less agreed upon
vocabularies
>and schemas. I would argue that in an online world in which everything
>is linked to everything else, NOTHING is contextualized. Everything has
>been effectively robbed of context. Cf. the Six Degrees of Kevin Bacon.
>
>Jeff, this feels very much like a straw person argument. None of the
examples that have been held up (Google's knowledge cards, Bibliothèque
nationale de France, our simple cards) link everything to everything.
>
>I do appreciate this discussion, though, so let me pose something to
you as a cataloger. Might there be a new role for cataloging here?
Specifically, I see a possibility in a Linked Data environment in which
the cataloger takes on the metadata equivalent to the role of the
bibliographer or selector. Rather that managing metadata through the
direct editing of catalog records (irrespective of
supervision/delegation), a cataloger curates a series of algorithms that
define how information is retrieved and used locally at the point of
need. A selector does not read every title purchased despite some
patrons' thoughts to the contrary.
>
>For example, it could be the policy of a given cataloging department to
trust or not trust data points from Wikipedia derived Linked Data sets.
Or it needn't be so stark: to trust only certain data elements from
DBpedia or Wikidata (just the facts, please!). Or maybe given an Art
History related call number range for a title, check to see if Getty
Vocabularies has any info about the main or added entries? Or given a
sound recording material type, is this an album and does that
MusicBrainz has more detailed track and performer info than my MARC
records?
>
>It is not hard to imagine an interface in which these kinds of trusted
data source negotiations are managed simply by using URI domains and
ontology/vocabulary predicates. It is a rather profound shift admittedly
to move from the model of total control when editing/loading every
record locally to something that feels like a Bayesian probabilistic
model of algorithmic metadata management. But the major paradigm shift
here may be in the role of staff rather than the focus on RDF triples
and the way we store the bytes.
>
>There is a natural transition path or roadmap if we focus on authority
control and Linked Data rather than just merely shifting to RDF
serializations. Again, to bring the discussion back to the list topic,
this would suggest that BIBFRAME will be more successful to the extent
that it is the RDF foundation for an extensible metadata environment.
Pragmatically, a BIBFRAME'd catalog should include sameAs assertions,
i.e., it should include actual links, but smartly chosen ones.
>
>-Steve
>

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