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:

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

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