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]
> m: 1-510-435-8234
> skype: kcoylenet

Charley Pennell
Principal Cataloger
NCSU Libraries
North Carolina State University