LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


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:

Re: Inbound Linked Data (no BIBFRAME required?)

From:

"Murray, Ronald" <[log in to unmask]>

Reply-To:

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

Date:

Mon, 6 Feb 2017 14:12:06 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (145 lines)

Jeff:

It might be helpful to all of us if you expressed the facts youıve
gathered, along with your opinions, within a better articulated framework
for discussing and predicting whether an innovation like BIBFRAME will
fail or not. Why donıt you make your way through Everett Rogersı social
science masterwork, "Diffusion of Innovations:²

     Rogers, Everett M. 2014. Diffusion of innovations, 5th edition: Free
Press.
     (If thatıs you at Penn State, your libraries have many editions of
this work)

Parties trying to make sense of what is going on with the BIBFRAME process
will find Rogerıs approach useful for sorting out the welter of social,
technical, and institutional interests that are in play (e.g., top-down
vs. bottom-up, rich description vs. minimal description, linked data for
linked dataıs sake, etc.).

Hereıs a short and sweet summary of Rogersı work:

     https://www.enablingchange.com.au/Summary_Diffusion_Theory.pdf


After engaging Rogersı combination of theory + cookbook for
success/failure, you should be able to figure out exactly how to enhance
BIBFRAME's adoption and how to delay it. Sad to say, many of the delaying
factors are presently operative due to ­ well, you tell us.

Ron Murray




On 2/6/17, 1:03 PM, "Bibliographic Framework Transition Initiative Forum
on behalf of Jeff Edmunds" <[log in to unmask] on behalf of
[log in to unmask]> wrote:

>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

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