Continuing the subject of seeing things from a new perspective, I thought I would talk about data models…. again. If you remember, last year at ALA Annual, I attending a conference on metadata where the speaker talked about data models and that xml is dying. From what I understood at the time, metadata was presented as being comprised as discreet parts (structural, administrative, descriptive, etc.) that form a data model as illustrated as a graph as seen below.
Even today, I’m really not sure I understand what this presenter was trying to communicate in terms of what a data model is. But I think I have a better idea today thanks to a course that I recently signed up for called, “Introduction to Metadata”.
The first lesson was on data models. We are hopefully all aware that it is crucial to ask questions such as “why”, “when”, “who”, “where”, “how” and the like. The answers to these questions provide context about a resource that helps users identify, select, find and obtain the right resource. In the lesson, the data model was defined as the “conceptual underpinning for organizing, describing and managing resources through metadata.” This is an extremely broad definition. To help pin this down, the instructor explained that the data model is a very high level view of the entities (or those that have a role in the intellectual content) and the relationships between those entities. The instructor was clear to note that data models are communication tools used to help check assumptions about how and when metadata is being used by users. At first, I was a little confused. Was the instructor speaking about a database and an ER diagram? Actually the relationships between the entities can be documented using ER diagram methods to express cardinality, obligation or attributes. However, this doesn’t mean you design a relational database that is also the data model. It is necessary to remain at a very highly abstract level. For me, it came down to what or who are the conceptual players in such and such a project and how do those players relate to each other? I don’t want to ruin the course if you plan on taking it, so I’ll stop there and return to my point on new perspectives.
This exercise was fantastic. It is not that I had never heard of data models (obviously). It is not something I hadn’t considered on and off in my job. However, at work many of my projects come with requirements and expectations already laid out. In other words, this high level data model has already been developed and it is my job to find the metadata standard and best practices appropriate to that model. I think this might be a common drawback to working in a large institution where tasks of one project are often distributed throughout the organization. After this exercise for the class, I received a new project where the high level conceptual thought was already done. Instead of going straight into the details, I took a brief step back to look at what a data model might look like. I gathered what pieces I knew about the project, users, the players involved and the possible relationships of those players. I created my own sketched data model. From there, I looked into a registry of possible metadata fields with such requirements as “repeatable”, “required”, “text”, “controlled by vocabulary”, etc. My data model wasn’t exactly what was already in place. However, I found that all this conceptual work provided a better understanding of the larger context to my project. It allowed me to envision different possibilities at the higher abstract level. This helped especially in seeing in the development of the details in the metadata best practices could be affected in different ways. As the say, the devil is in the details.
The exercise of creating a data model is extremely helpful. It helps you envision more of the entire picture of a project. This can include even the lifecycle of metadata or how metadata will be used by the various players and according to certain relationships. This helps to determine what standards to use as well as what best practices to implement for that project and users. But what this course communicated more clearly than the presenter at ALA last year is that the data model resides at the highest level of abstraction. The discussion of metadata standards, what elements to use, controlled vocabularies is already too detailed to be part of the data model; though of course these discussions flow from the data model. For me this made sense, namely to think about the problem at a high conceptual level to understand the nature of a project, the different players and the relationships between them.
I guess all of this is to say that even in our field there’s always room to learn and discover new approaches to metadata. These new perspectives bring creativity to your job and also help you do your job better. The instructor, Grace Agnew, will be publishing a book based on this course on metadata. I would recommend it!