100% agree that descriptive metadata is a key part of the linked/semantic
data ecosystem.

Sharing  assertions about the value of some attribute of the described
entity, and forming beliefs the correct value is one of the most useful
ways to improve the quality of such descriptions.

Another potential boon to descriptive metadata can be achieved through
"default" inheritance of certain attributes of "more abstract" FRBR-ish
entities by "less abstract" ones- for example,  the title of an expression
might by default be the same as the title of the work it expresses.

The "subjects" of the second edition of a work might likewise by default be
likewise derived those of a prior edition. (There are plausible arguments
against considering non works as having subjects; thus this might be
considered to be default inheritance of a property between two works).

I should note that basic RDF(S) and OWL semantics don't provide for default
inheritance, though there are non monotonic extensions.

[I should note that Allen Renear has strong opinions on inheritance in FRBR
- see e.g. ; I believe his objections in
that paper were primarily based on the incoherence of treating the
relationships between FRBR group 1 entities as monotonic subclassing,
though I think he may have addressed related issues in later work]

Named identities records currently serve a slightly different object[ive]
to controlled subjects; subject headings provide more terms for the search
to bite on, as well as serving to group items together; if 4XX (not
serials) terms were also indexed then both would provide a lesser boost to

Also, subdivided subject headings may or may not appear in authorized forms
(only subdivided headings occurring more than a certain number of times in
the LC catalog are added to the "file".
Also,  the only available study on user understanding of subject headings
indicated a ~50% accuracy level on a paraphrase task for technical service
respondents- the study has methodological issues, so the results may not
generalize to generation )

On Jun 30, 2014 12:41 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]
>> m: 1-510-435-8234
>> skype: kcoylenet
> --
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
> North Carolina State University