Interesting thought: movement away from MARC means we have opportunity to decide what to keep and what to give away from current practice.— Erin Leach (@erinaleach) May 5, 2016
How do we decide what to keep from current practice given that 'we've always done it this way' will likely not be a compelling argument?— Erin Leach (@erinaleach) May 5, 2016
There is much about BIBFRAME and the post-MARC world that I don't understand. And until I attended this meeting, I was pretty sure I wouldn't wade into this discussion because I had nothing smart to add.
But now I do.
Building a new encoding standard is really amazing. I doubt many people really think of it that way because it's such nuanced work. Honestly, I don't think about how amazing it is most of the time. I mean, I quit the BIBFRAME list because it was so far over my head as to be useful to me. So the wonder of standards creation is lost on me most of the time.
The part about building an encoding standard that excites me most is that it gives us the opportunity to radically reconsider our current practises. What parts of our current practices are so important that we want to preserve it and what parts no longer serve us? What new practices could we incorporate to better serve our user communities?
I hope that as the metadata creation community builds out and implements BIBFRAME that we don't just try to map MARC fields into BIBFRAME elements and create what might essentially be considered MARC2.0. I hope that the community takes the time to consider what MARC fields are essential in helping users complete the tasks that brought them to the online catalog in the first place.
This evaluation and decision-making process requires the metadata creation community to think about who it considers its users and what they might require in order to successfully navigate the online catalog. I desperately hope this means consulting with actual library users in order to devise user tasks and use cases based on actual user needs as opposed to talking about a monolithic user.
This evaluation and decision-making process also requires the metadata creation community to have a difficult conversation about administrative metadata and about the extent to which the metadata community itself is a user. What I think we need to wrestle with as a community is the fact that while the metadata community is a user, we are not the primary user. We should not put our needs first and we definitely shouldn't cling to old ways of doing things because they suit our needs. Instead, I would argue that the metadata creation community should identify the minimum amount of administrative metadata required to successfully complete our work.
As we build this new encoding standard, I hope that we decide to use this opportunity to radically reconsider our metadata creation process. And when we do, I hope our benchmark for which practises to continue and which to stop are based entirely on end user needs and not on our own.