At 05:16 PM 1/1/2009, Diane I. Hillmann wrote:
Three new and important
vocabularies from RDA have been registered:
RDA Content Type:
http://metadataregistry.org/vocabulary/show/id/45.html
RDA Carrier Type:
http://metadataregistry.org/vocabulary/show/id/46.html
RDA Media Type:
http://metadataregistry.org/vocabulary/show/id/37.html
Thank you, Diane. These are indeed significant additions to the
registry.
[snip] I think your comments about the different structures of
these vocabularies are interesting, but (as I indicate below) I think we
need to get behind the vocabularies -- yes, there is something behind the
curtain here.
All of these vocabularies are up
to date as of the Oct. 31, 2008 text available in the constituency review
documents.
I'm not aware of any subsequent changes, so this should be current; it is
possible that changes may be made at the March JSC meeting, but I would
not anticipate anything extensive.
One of the questions I've been
posing to all and sundry about all this is that of the usability of the
vocabularies without definitions.
My understanding was that all the values in these three elements were to
be defined in the Glossary. Did you check there? In general,
however, you are correct that we have not defined every term in all the
embedded vocabularies; in principle we agree that it should be done, but
have not been able to complete the task.
My contention is that they're
better than nothing, but won't lead to the consistency we're looking for
without definitions, scope notes, and alternative
terms.
I agree, and I hope that, now that the vocabularies are in the registry,
we can enhance the content to include such information more
consistently.
Karen Coyle and I were messing
around with this idea sometime (maybe a year?) ago, and came up with an
addition to the carrier type vocabulary that illustrated what it could
look like (it's in the Registry Sandbox):
http://sandbox.metadataregistry.org/concept/show/id/517.html. I do
think that looking at something fully fleshed out serves to illustrate
nicely the paucity of the current Carrier Type
vocabulary.
In general, I agree that we need to develop procedures for enhancing the
registry with new values or additional content for established
values. For example, the "values" that we have given are
names for the categories, but we recognize that they may not be
the best terms for display to users, and we were hoping that the
existence of the registry would allow others to do further work on a
display vocabulary.
In this particular case, however, there is a problem with your proposed
addition. These three elements are not in fact independent
elements; as I said before, there is something behind the
curtain.
The other question is how these
vocabularies should be enhanced and extended. Shortly (we hope) the
Registry team will announce some enhanced functionality that will add the
ability for interested parties to discuss enhancements, at the concept or
term level, in ways that can lead to some consensus based proposals for
missing pieces or extensions.
The JSC needs to be a part of this discussion. While we welcome the
assistance of the entire community, this is RDA content and we are
responsible for that. There needs to be some sort of authorization
and editorial review mechanism included in the process.
Unfortunately the RDA text gives
instructions that limit the kinds of other kinds of "bottom up"
options to determine from usage where the vocabularies need to be
extended. The instructions for when no current term from the
vocabularies are available come straight from MARC-- one gets to use
"other" or in some cases, "unspecified."
Wouldn't it make more sense to allow catalogers to fill in what they
think it should be, as free text, so that the data could be mined on a
regular basis to see what the needs are in the community? Even
errors, where there IS a term but the cataloger didn't recognize that the
chosen text term should have been something else, helps establish the
kinds of alternative labels that help the next person down the
road. "Other" and "Unspecified" are dead ends
and should be unceremoniously rejected (they will not--repeat NOT--be
added to the vocabularies while I have breath).
There needs to be a discussion at some stage about the most appropriate
value to record when none of the "authorized" values
applies. In general, RDA declares that all vocabularies are open
and that "unauthorized" terms may be used when none of the
"authorized" terms is applicable; and we definitely welcome
some process that will feed the "unauthorized" terms used by
catalogers into the editorial process. This should eliminate the
need for "other".
Our assumption has been that the best practice was always to record
something for each applicable data element; this would at least
confirm that the element was applicable, even if no appropriate value had
been recorded. What I think I am hearing from Karen and Diane is
that omitting the element is preferable. We need to get a consensus
on what the best practice is here.
And, finally, I want to look behind the curtain and make some
suggestions.
As I noted, the three elements in question are not independently
defined. They are based on the RDA-ONIX Framework for Resource
Categorization. This is described at:
http://www.collectionscanada.gc.ca/jsc/rdaonixann.html
and the specifications are available at:
http://www.collectionscanada.gc.ca/jsc/working2.html#chair-10
This framework defines a number of attributes that may be used to
categorize bibliographic resources, and provides vocabularies for the
most important of those attributes.
The three RDA elements are precoordinated categories based on the
combined values or two or more of the RDA-ONIX attributes. Details are
available at:
http://www.collectionscanada.gc.ca/jsc/docs/5rda-parta-categorization.pdf
Thus the RDA values for these elements are in fact defined by a
corresponding set of property-value pairs from the RDA-ONIX
Framework. Any new value added to the RDA elements must (a) must be
defined in terms of the appropriate set of RDA-ONIX property-value pairs
and (b) must have a different definition from all the other values for
the element. [Note: (b) was not the case for the sample new value that
Karen proposed in the sandbox.]
Further, I would note that the recently proposed replacement for the GMD
in the International Standard Bibliographic Description (ISBD) is also
based on the RDA-ONIX Framework, but uses different sets of
property-value pairs to provided a different set of precoordinated
categories.
Given this, I suggest:
1. The RDA-ONIX element set (attributes) and vocabularies should be
registered in the same way as you have done for the RDA elements and
vocabularies. This would have two benefits. First, some of us
have argued to the JSC that we should not record values for
precoordinated categories in our resource descriptions, but rather should
record the values (preferably in coded form) for each of the RDA-ONIX
attributes. This allows maximum flexibility for postcoordinate
slicing and dicing records based on a rich and consistently defined set
of characteristics, and I'm sorry that the idea wasn't raised in the
discussions on MARC21 implementation of RDA. Second, the RDA-ONIX
vocabularies would be available as the basis for editorial work on the
RDA vocabularies.
2. Part of the specification for each RDA value should be their
underlying RDA-ONIX property-value pairs. This allows precise
definition of each category and makes it much easier to determine whether
a proposed value is in fact a new category in terms of the
Framework. I suspect that it will also provide the data needed to
deal with the hierarchical relationship issues that Diane raised earlier
in her message.
3. Once the ISBD revision is finalized, I would like to see it too
registered and its values defined in terms of the appropriate RDA-ONIX
property-value pairs. This may allow some relationships to be
established between these values and the RDA values; this would be
beneficial because, unlike RDA, the ISBD is designed for display to
users, and some of the terminology is clearly preferable to their RDA
equivalents (if it is possible to establish the equivalence).
Thanks again for all the work and thought that has gone into the registry
so far. I hope that this helps suggest some ways to build on that
work.
John
Attig
ALA Rep to
the JSC