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