The whole point--as I see it--is to teach them how to approach any set of
rules for inputting data into a database.
We start our students in the core InfoOrg course--they build their own
information organization system from the ground up. This includes
identifying the users, user information needs, identify the objects to be
organized--including object attributes which are then translated into
metadata elements. These elements then become the basis for fields in the
database and as they do this they must address the four user tasks as
specified in FRBR (find, identify, select, obtain). They then create input
rules for those fields--this includes designating a chief source of
information for the data, how the data is to be formatted, what to do should
data not be present (scenarios, etc.). They also create a classification
system, thesaurus, and a very simply name authority database. Over the
course of the semester they are writing what is essentially a technical
manual for their system, complete with discussions on fundamental IO
concepts (e.g., metadata, classification, authority control, field indexing
specifications, etc. )
Students then electing to take my cataloging course come to it with this
experience of having built their own system so I begin by describing how
they will know learn how to catalog using someone else's system (i.e., the
"cataloging enterprise")--one that has already in place a set of input
rules, an encoding scheme, etc. This is a much more complicated and
sophisticated system, to be sure, but they catch on pretty well and are able
to apply the concepts and practices.
My experience is that too often we divorce AACR2 and RDA from the entirety
of the cataloging process and make them out to be some sort of mysterious
uncontrollable beasts. Once students make the connection that AACR2 is
really just a must more dense version of the simple rules they created for
their own system they relax and are able to navigate the set more easily.
The bottom line is that data going into a field in a database needs structure.
Furthermore, all databases should be based on a conceptual model--in this
case FRBR provides that model. FRBR is itself based on the
entity-relationship model used for data modeling. (See Maxwell's discussion
in chapter 2 of his book "FRBR: a guide for the perplexed" in which he
discusses Peter Chen's database modeling technique introduced in 1976).
We have information resources/entities, these resources have
connections/relationships to each other. We "illustrate" this
entity-relationship model via the creation of surrogate records in a database.
Clear as mud, right?