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  June 2014

BIBFRAME June 2014

Subject:

Re: Problems in source data

From:

"[log in to unmask]" <[log in to unmask]>

Reply-To:

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

Date:

Mon, 30 Jun 2014 11:13:00 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (59 lines)

I apologize for the length of this response, but I think these are two slightly different cases, and each of them is different from the discussion of core metadata…

Speaking from (but not _for_) my own institution, I think we draw ancillary resources into a presentation in the "last mile" for a couple of reasons:

1) They're subsidiary. They're helpful enhancements to the presentation of a resource, but without them, the presentation would still be helpful. Without metadata enabling basic selection and retrieval, the presentation wouldn't be very helpful. I realize that the line here isn't totally bright: some patrons may very well elect to retrieve a certain resource based on its table of contents, for example. 

2) They're not "ours". The situation around our rights to store that information isn't always totally clear, at least to me. {grin} We can't make a wholesale duplication of, say, book jacket images, because our contract forbids it. Perhaps we may cache them, to a certain extent. And for each such kind of sidecar service, the terms often vary considerably.

3) They have a cost to maintain. We wouldn't necessarily want to store that information even if we could, because we might rather use those resources for information that is of more importance locally.

As for link resolvers: I think we have to consider that some of the motivation for link resolvers revolves around the management, not of references, but of intellectual property. It's useful to indirect retrieval of some resources through specialized proxies because their providers (e.g. journal publishers) will only provide those resources to _some_ people who ask them for it (those who have paid, directly or indirectly) and only when certain credentials are presented. That's not to claim that there aren't other reasons for those systems, but I would suggest that in a purely open-access world, indexes and link resolvers (and the market in which they are traded) would look rather different than they do: they would look much more like the rest of the Web.

There's another, more technical point here. It's one of the reasons it's not really feasible to maintain a "stateless catalog", at least not right now, if we want to fulfill the expectations of discovery held by most library users. We can effectively load book images at the last minute because we don't search them, and we don't integrate that data (the images) within a set of search results. Those of us who need to integrate local catalog results with external search results (perhaps from journal index services) often find that it's very difficult to, for example, unify faceting information between the two, or be sure that subject headings are useful across both, or the like. Of course, we must do those things over the kind of metadata Bibframe intends to express. It's much, _much_ more practical to do that when you don't have to include the cost of backend network transactions in the expense of answering a search request. 

So we need to make some kind of adjustable balance between freshness of data and "liveness" of action, and that's where many think caching and similar techniques should come into play. (For the technically-minded: Apache Stanbol's EntityHub system for storing RDF representations is a nice example of this kind of balance in a tool. It provides for local indexes that can be searched very quickly in front of network-retrieval backends, and it caches retrieved results when possible.)

---
A. Soroka
The University of Virginia Library

On Jun 30, 2014, at 10:28 AM, Charles Pennell <[log in to unmask]> wrote:

> But isn't this what we all do now with Syndetics content (book jackets, TOC, summaries), pointers to Google books, as well as those from OCA, Hathi, and other sources, and with our link resolvers and knowledgebases.  This is pretty much non-mediated Web-based data that we haul up at the point of display, seemingly with some success.  Is it that we trust those sources that we pay for but not those that are provided as a public service?  Even when the creator/provider is LC, NLM, and other "trusted" bodies?
> 
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
> 
> 
> On Sun, Jun 29, 2014 at 8:15 AM, [log in to unmask] <[log in to unmask]> wrote:
> It's hard for me to imagine that those using linked library data will be putting what is retrieved from the network directly in front of their patrons without intervention. That's not really technically feasible, whatever the desire may be.
> 
> We will need to be guided by the Web architecture and use a design with caching. If you cache remote linked data resources locally (and if you intend to give your patrons a reasonable experience, you will be caching) you can certainly make emendations into or out of the cache, processing data in whatever ways you see fit.
> 
> ---
> A. Soroka
> The University of Virginia Library
> 
> On Jun 28, 2014, at 12:23 PM, J. McRee Elrod <[log in to unmask]> wrote:
> 
> > If/when our displays are created from remote linked data, what do we
> > do about problems with the source data?  For example, missing
> > (Fictitious character) and animal species qualifiers?
> >
> > Many want logical consistency in their displays.
> >
> >
> >   __       __   J. McRee (Mac) Elrod ([log in to unmask])
> >  {__  |   /     Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
> >  ___} |__ \__________________________________________________________
> 
> 
> 
> -- 
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
> North Carolina State University

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

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