"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."*
[snip]
"Clear as mud, right?"
lol, yes this can be at times the most challenging concept to a generation
of some at least (students range from 20 somethings to grandparents in my
classes) who only want to comprehend "tagging" everything in their life oh
and yes Google.
Overall, I have found a good majority of our students interested and
motivated in cataloging courses, many of whom are also school library media
focused, but who are looking ahead into their careers 5, 10 years from now
too.
Cheers,
Karen
Karen Weaver, MLS
Adjunct Instructor, Cataloging & Classification
The iSchool at Drexel University
College of Information Science & Technology
Philadelphia PA
email: [log in to unmask]
Electronic Resources Statistician
Duquesne University, Gumberg Library
Pittsburgh PA
email: [log in to unmask]
On Sat, Jan 10, 2009 at 12:47 PM, 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?
>
|