Print

Print


"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."
Well put, Shawne.  May I quote you?
I may have to take some refresher courses at UNT now.

-Jennifer Parsons



On Sat, Jan 10, 2009 at 11:47 AM, Shawne Miksa <[log in to unmask]> wrote:

> 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?
>