I wonder how the well a modular approach would work where each “item type” had it’s own standard identifiers, rather than trying to cram everything into one rule set (which leads to abstract identification). This would compartmentalize the “standardization” to a specific item type and perhaps allow for more direct and clear identification by SMEs of that specific item type.

This may also lead to simplificaiton where libraries would only need to understand the item types they deal with directly.

In the end we’ve all used MARC21 differently to best describe our varied holdings – due to MARC21s “approximate” nature I really don’t see a universal application that will cover all cases. We’ll all have to dig ourselves out of the corner we’ve painted ourselves into with MARC21 and the more we stuff in the worse it gets.

@Caren: I found that sometimes order of repeatable elements is relevant and sometimes it is not. Do you have more on repeatable fields?

Overall, it is my impression that attempts to describe these data structures in terms of databases and database-type concepts(such as Codd’s
normalization) may not be the most fruitful path to follow.

My impression of MARC is that what it maps to most closely would be the way in which we construct and make use of objects in the more pure O-O programming
languages, such as Smalltalk and Self.

One way of looking at that shift is that data/database type constructs tend to concentrate on the \nouns\ of the given information. The formation of MARC
itself is attempting to supply both the \nouns\ and something like a \verb\ form (or at least a gerund) as well. This noun/verb form (data and the
integral means of accessing it) is very much what objects offer.

I think there may be two consequences to following this path. Firstly, if the goal of a user/translator of MARC is to do something helpful with it within
a program, it might be best to consider moving from a standard RDBMS to an Object-based RDBMS. Secondly, if the goal is to serialize the MARC data in a
different form, such as XML (perhaps in OWL), it might be best to first transform the data into an object form, then work out how to serialize that
object.

Using objects as an intermediary in this way may seem to be either a distraction or an additional task. However, the goal of O-O has never been to, say,
make computers work faster. It has always been about finding better ways for humans to conceive of complex systems. MARC might be a good place to make use
of these tools.

cheers,
Scott

At the end you say, “… armed with this knowledge we might decide to greatly trim or radically transform the data elements that we carry with us into the future.”

We may begin to trim the needed data elements immediately and not wait until we are fully-armed with this knowledge. We can create a simple bibliographic model that can begin to capture or propose those elements (with definitions) that would allow us to create services for users. Among them may be identifiers of various sorts, titles, publication as an event, etc. That said, you have given us all a great start. Thank you.