{"id":341,"date":"2012-10-26T11:01:44","date_gmt":"2012-10-26T16:01:44","guid":{"rendered":"http:\/\/managemetadata.com\/blog\/?p=341"},"modified":"2012-10-26T11:05:53","modified_gmt":"2012-10-26T16:05:53","slug":"big-words","status":"publish","type":"post","link":"https:\/\/managemetadata.com\/blog\/2012\/10\/26\/big-words\/","title":{"rendered":"Big Words"},"content":{"rendered":"

\ufeffI saw the announcement a few weeks ago about the demise of MARBI and the creation of the new ALCTS\/LITA Metadata Standards Committee<\/a>. My first reaction was \u2018uh oh,\u2019 and I flashed back to the beginnings of the DCMI Usage Board. The DCUB still exists, but in a sort of limbo, as DCMI reorganizes itself after the recent change of leadership.<\/p>\n

I was a charter member, and, with Rebecca Guenther, wrote up the original proposal for the organization of the group. It was based to some extent on MARBI–not a surprise, since Rebecca and I were veterans of that group. But there were some ambiguities in the plan for the UB that came back to bite us over the next few years–primarily having to do with essential questions about what the group was supposed to be doing, and how to accomplish its goals. These difficulties had little to do with the organizational aspects–how many members, questions of voting (which changed over time), or issues of documentation and dissemination, all of which were settled fairly easily when the group was set up (and can be found here<\/a>.)<\/p>\n

It struck me as I was reading the announcement, that it might be useful for me to revisit some of the issues that came up with the DCMI Usage Board while I was a member, and think about whether they are relevant to the new ALCTS\/LITA Metadata Standards Committee. I hope this perspective may be useful for ALCTS and LITA as they get this committee going, because, frankly, I see dragons all over the place. [I should emphasize here that these are personal opinions, and don\u2019t represent any position of the DCMI Executive group, of which I am a member.]<\/p>\n

So, here\u2019s a quote from the announcement describing the Committee\u2019s responsibilities:<\/p>\n

\u201cThe ALCTS\/LITA Metadata Standards Committee will play a leadership role in the creation and development of metadata standards for bibliographic information. The Committee will review and evaluate proposed standards; recommend approval of standards in conformity with ALA policy; establish a mechanism for the continuing review of standards (including the monitoring of further development); provide commentary on the content of various implementations of standards to concerned agencies; and maintain liaison with concerned units within ALA and relevant outside agencies.\u201d<\/em><\/p><\/blockquote>\n

I see a lot of big and important words in this paragraph, and would like to see some of them defined more carefully for this new context. For instance, what does \u2018a leadership role in the creation and development of metadata standards\u2019 really mean? The prospective committee members are folks who have day jobs and are likely to meet in person twice a year (perhaps in multiple meetings) at each ALA meeting, but they have been given an enormous brief, or so it seems.<\/p>\n

First of all, what is a \u2018standard\u2019? Are \u2018standards\u2019 in this context only those which have been vetted by a standards body like NISO or ISO? Some \u2018standards\u2019 that are in relatively broad use in the bibliographic environment are in fact developed within the walls of just one institution (e.g., LC\u2019s MODS, MADS, etc.) and though they may eventually acquire some mechanism for user participation, their definition as standards is largely self-declared by their managing institution. For that matter, how about metadata element sets developed by international bodies, like IFLA, or W3C, or Dublin Core? ALA is a voting member of NISO, which suggests to me that a clear definition of what a standard IS will be an essential step, even before an examination of the notion of what a \u2018leadership role\u2019 might be.<\/p>\n

Then there\u2019s the notion that standards (however defined) will be proposed to this committee for review and evaluation. Proposed by whom? Reviewed by what criteria, and evaluated by what mechanism?<\/p>\n

For the DCUB, the brief of the group changed over time, as DCMI grew and shifted focus. At first, the UB\u2019s brief was the review of proposals for new metadata terms. That turned out to be far more difficult than it seemed on the surface, because in order to evaluate those proposals, there first needed to be criteria for evaluation. Eventually it became clear that there were an infinite number of elements desired by an ever increasing number of communities, and whether any or all of these should be part of what was supposed to be a general set of properties became an issue. Finally, after much discussion, it was determined that the Dublin Core was not going to be the arbiter of all terms desired by all people, and the UB stopped reviewing proposals for new terms.<\/p>\n

Another historical tidbit illustrates a possible pitfall. At one point (I\u2019m afraid I can\u2019t remember the timing on this), the UB was approached by a public broadcasting group that was developing a metadata schema based on Dublin Core, and they wanted us to review what they\u2019d done and give them some feedback. So, the UB looked over what they\u2019d done, and provided them with feedback–mostly about how they\u2019d structured their schema, rather than the specific terms they used.<\/p>\n

Some time later, it was pointed out to me that the Wikipedia entry on PBCore said that the UB had \u2018reviewed\u2019 their schema, in a manner implying that we\u2019d given some stamp of approval, which we had certainly not done. Wikipedia being what it is, I went in and clarified the statement. You can probably see what I added by checking out the Wikipedia entry<\/a>, and you might want to look at some of the PBCore vocabularies in the Open Metadata Registry Sandbox (this is a good example<\/a>, but you\u2019ll note that they didn\u2019t get beyond \u201cA\u201d)<\/p>\n

The RDA effort is a classic case of how much more difficult it is to develop standards than it seems at the start–and also how important process and timeliness are to the eventual determination of who will actually use the standard. The RDA development effort was started long enough ago that during the long process of development — originally begun as a classic closed-door-experts-only effort — the whole world changed.<\/p>\n

In 2007, as part of that process, I got involved in the effort to build the vocabularies necessary for RDA to be used in a Semantic Web environment, in parallel with the continuing development of the guidance instruction and under the aegis of the DCMI\/RDA Task Group (now the DCMI Bibliographic Metadata Task Group<\/a>). The completion of that work<\/a> (since 2009 in the hands of the JSC for review and publication), has stalled, as the JSC spends their limited time entertaining proposals for changing the guidelines that they just recently finished. Meanwhile, time continues to march ever onward, and many of those who were once waiting for the RDA vocabularies to be completed have concluded that they may never be, and have started looking elsewhere for metadata element sets.<\/p>\n

In the meantime LC itself began it\u2019s BibFrame project<\/a> roughly two years ago. That effort, as it\u2019s been described so far, seems unlikely to consider RDA as a significant part of its \u2018solution\u2019. Various other large users and purveyors of bibliographic data have begun to use a variety of build-your-own schemas to expose their data as linked data, the (somewhat) New Big Thing. It\u2019s illustrative to note that these don\u2019t tend to use RDA properties.<\/p>\n

There was a time that MARC ruled the library world, and there\u2019s still a nostalgia in some quarters for that world of many certainties and fewer choices. That time isn\u2019t coming back, no matter how many new committees we set up to try to control the new, chaotic world of bibliographic data. The fact is that our world is moving too fast, and in our anxiety to get things \u2018right\u2019 we continue to build and maintain cumbersome \u2018standards\u2019 using complex processes that no longer work for us. We\u2019re still trying to insist that the \u2018continuing review\u2019, \u2018evaluation\u2019 and \u2018recommendation\u2019 processes have clear value, but a realistic look at the current environment suggests that they may no longer be of value, or even possible.<\/p>\n

I have no inside knowledge of how all this will come out, but I\u2019d be much happier if the new ALCTS\/LITA Metadata Standards Committee either receives or builds for itself a much clearer and achievable set of goals and tasks than they seem to have been given.<\/p>\n

It\u2019s a jungle out there.<\/p>\n","protected":false},"excerpt":{"rendered":"

\ufeffI saw the announcement a few weeks ago about the demise of MARBI and the creation of the new ALCTS\/LITA Metadata Standards Committee. My first reaction was \u2018uh oh,\u2019 and I flashed back to the beginnings of the DCMI Usage Board. The DCUB still exists, but in a sort of limbo, as DCMI reorganizes itself […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,7],"tags":[],"class_list":["post-341","post","type-post","status-publish","format-standard","hentry","category-linked-data","category-rda"],"_links":{"self":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/341","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/comments?post=341"}],"version-history":[{"count":3,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/341\/revisions"}],"predecessor-version":[{"id":344,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/341\/revisions\/344"}],"wp:attachment":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/media?parent=341"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/categories?post=341"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/tags?post=341"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}