On Nov 26, 2014, at 2:47 PM, Bowers, Kate A. <[log in to unmask]> wrote:
Just some food for thought, which will be the lowest-calorie offering over the holidays...Centralization inhibits agility. It also leads to vanilla being the only flavor on offer. It’s possible that a shared standard may be developed, but isn’t interoperability a better goal than universality?Have a safe and happy Thanksgiving!KateKate BowersCollections Services Archivist for Metadata, Systems, and StandardsHarvard University Archives617.496.2713voice: (617) 384-7787fax: (617) 495-8011Twitter: @k8_bowers
I applaud the effort that NLM is taking on, as well as the work done by LC, but these efforts also servie to point out a great gap that exists in our community -- that we have no coordinated way to create our essential standards. No single institution has the capacity to manage a community-wide standards effort. Ideally, work on a new metadata standard would include representatives of a wide range of interested parties covering traditional libraries (from public libraries to research libraries), a range of material types, archival interests, digital libraries, and at least some of the partners with whom these groups might exchange data (publishers, database providers, and the web). It would include both subject experts and technology experts. It would also naturally include those who do or might create the systems that would use the technology. That mechanism is lacking.
In 2012, when the BIBFRAME initiative was announced, I proposed a model for the development of a new data carrier:http://kcoyle.blogspot.com/2012/03/can-libraries-change.html. While aimed at BIBFRAME, it could really be applied to any standard in our community. Looking now at the diagram in that post, I can already see where it should be amplified to include a broader list of interested parties. The main thrust of the idea, however, was that we need coordination between our content standards (cataloging rules), our technical standards (MARC, BIBFRAME, MODS, etc.), and the standards maintenance process (creation, versioning, updating). Today I would add a number of related data-sharing partners, from publishers to Amazon to Wikipedia.
I don't think anyone can question that we are in an environment where data is shared over a wide range of communities and users. It makes little sense to create standards in isolation. We do so NOT because we don't understand or don't care, but because the needed standards process has not be developed, and it hasn't been developed, at least in part, because it is a very expensive prospect.
I don't have a solution, but I also cannot have much faith in the current standards in progress. There's a fundamental gap that needs to be filled so that we can develop successful standards with broad usage.
kcOn 11/26/14 6:52 AM, Victoria Mueller wrote:Excellent point Nancy. We look forward to the progress as a community also!
Vicki———Victoria MuellerSenior Information Architect and Systems Librarian, Zepheira
On Nov 26, 2014, at 9:48 AM, Fallgren, Nancy (NIH/NLM) [E] <[log in to unmask]> wrote:
Thanks, Tom.Just a comment to manage expectations J -- Whatever we draft for this experiment as a BF core vocabulary will be just a starting point for further development of that core (so, good enough to use for proof of concept, but not nearly final). It will take broader input to agree on a BF core vocab that will be useful to the entire cultural heritage community. If just the library cataloging community invests in developing a BF core vocabulary, then we won’t have progressed from the insularity we currently have with MARC.-NancyNancy J. FallgrenMetadata Specialist LibrarianCataloging and Metadata Management SectionTechnical Services DivisionNational Library of MedicineNancy,I really look forward to hearing more about this! I am particularly interested to see what is regarded as the “core BIBFRAME vocabulary”.Thanks,
Tom---Thomas MeehanHead of Current CataloguingLibrary ServicesUniversity College LondonGower StreetLondon WC1E 6BT
--Karen Coylem: +1-510-435-8234skype: kcoylenet/+1-510-984-3600