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 13:09:36 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (39 lines)

I think the point I'm taking away here is a reminder that there are different boundaries for metadata management in different organizations (and that those boundaries actually extend into the metadata itself, as a matter of provenance and responsibility), all kinds of workflows for managing metadata, and therefore varying needs for varying techniques (including caching).

Personally, my hope is that we can satisfy many of those technical needs by relying on architecture that already exists and is well-proven (starting with the Web itself and Linked Data across it). I haven't heard anything in this discussion that would tell me otherwise, which makes me quite happy. Whether a given presentation at a given institution is generated entirely dynamically or entirely from local records, or in some middle wise (which seems much more likely to me) doesn't seem to me to be at stake, because that will always be a local question informed by local desires and resources.

---
A. Soroka
The University of Virginia Library

On Jun 30, 2014, at 12:39 PM, Charles Pennell <[log in to unmask]> wrote:

> Tables of contents are as much core metadata as any of the "controlled vocabulary" data, since they provide so much free-text subject fodder for patron searches in our catalogs.  This explains why we often cache this data to enable search against it in spite of its non-presence in our physical record structure.  One might also argue that linked NAF (but not SAF, which only appears in its controlled state) data could be subsidiary, since these are primarily controlled vocabulary for personal, corporate or meeting names already on board in other parts of bibliographic description, such as in author or publisher statements and notes.  Useful for collocation yes, and perhaps for strictly "author" searches, but not required for presentation.  OCLC has certainly argued in the past that descriptive metadata is not necessarily "ours" and indeed linked data has the potential to make it possible to simply haul descriptive metadata out of WorldCat for display in our local catalog, if we haven't already given over to the utility for direct provision of our catalog (e.g., WCL).  This would solve the problem of maintaining serial records through their life cycle, assuming that CONSER and/or utility members are maintaining serial records in the utility better than we are within our local catalogs.  We need to widen our consideration of linked data to encompass descriptive metadata as well.
> 
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
> 
> 
> On Mon, Jun 30, 2014 at 11:34 AM, Karen Coyle <[log in to unmask]> wrote:
> On 6/30/14, 8:13 AM, [log in to unmask] wrote:
> 
> 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.
> For me, this would have been point #1. There's a big difference between pulling something in for display only vs. data that you intend to use for search or some other decision-making. I suspect that this could be the reasoning behind the "common abstraction layer" in BIBFRAME, although I don't believe I've seen it explained in that way. In fact, the motivation behind the CAL is still a bit of a mystery to me -- the documentation explains what it is, but not why. I'd very much like to hear the why from anyone who feels they understand it.
> 
> kc
> 
> -- 
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
> 
> 
> 
> -- 
> 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

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