Classmate James Mitchell, in his recent blog, Socially Constructed Metadata? poked at the nature of metadata creation and raised some interesting ideas about the notion of whether constructed metadata reflects objective realities, or is merely reflective of the conditioning, experiences, and perceptions of its creator. While ostensibly focusing on the technical issues of metadata interoperability, I was far more intrigued by the possible issues presented by the conflicting ideas of metadata creators themselves.
Having been brought up largely in the history field, the question of objective vs. subjective reality and the quest for accurate description of events or objects is one that I am fairly familiar with. Historiography, a standard class for the undergraduate history student, deals with the idea of author bias (i.e. experiences, perspectives, moral and social values, language, etc...), and causes one to question the ability to take sources at face value due to them always being viewed through the lens of a biased observer. Postmodern perspectives will even question our ability to ascertain the "truth" of events with any certainty, as any record of the event is inevitably interpreted through the inherent perspective or bias of the recorder.
Applying these same ideas to the field of metadata, another field of seemingly-objective description in the hands of biased describers, and one can ask the same questions, and ostensibly arrive at some of the same conclusions. Whether one believes in the objectivity or relativity of constructed metadata, however, I think that simply exploring these issues should help us to be aware that we all bring innate preconceptions, prejudices, bias, and perspectives with us to the description table. Understanding that is an important part of overcoming our differing perspectives and striving toward a greater degree of consistency, uniformity, and objectivity in the work that we do.
Tuesday, January 14, 2014
Monday, January 13, 2014
Metadata: Metauseful or Metacrap?
The notion of widespread use of descriptive metadata for everything from webpages and search engines to digital media and online stores is undoubtedly an information organizer’s dream. All manner of internet navigation being guided by the use of accurate and consistent metadata would streamline search processes, eliminate undesirable results, and bring some semblance of order to the world of chaos that can often characterize the web.
As all of us have doubtlessly experienced, however, such ideas belong to the realm of fantasy. Web searches are messy, retrieving millions of results, with most users lacking the time or endurance to parse for relevant entries after the fire couple of pages. Sometimes we are deliberately led astray, receiving hits for sites that clearly have nothing to do with the item being searched for. Why does this happen? Why has the potential of metadata failed to bring order to the digital environment when its possibilities are so promising?
I find that journalist Cory Doctorow’s 2001 essay, "Metacrap: Putting the torch to seven straw-men of the meta-utopia,” provides a fairly succinct, accurate, and humorous summary of the reasons why the meta-dreamland is one not likely to ever reach the shores of reality. I won’t summarize the whole of the essay here, but will comment on a couple of points he makes.
For me, one of the more problematic areas that Doctorow discusses is the misuse of metadata for the purpose of attracting our attention. Whether malicious and outright false, or simply exaggerating or “enhancing” the properties of an object or site, the fact is that metadata on the internet, at times, takes on all the properties of intrusive and misleading advertising we’ve witnessed across other forms of media. From mail spam with maliciously-intended titles to the deliberate misuse of high priority/relevance metadata terms, the digital environment is anxiously competing for our attention. That the purposeful misuse of terms destroys the integrity of the metadata in question is of no concern to the creator, so long as it gets us to their site/product. A sad result of this trend is that website metadata fields are virtually ignored by most major search engines of today, depriving internet users of a tool that could have been invaluable in enabling expedient and highly accurate search results.
Another area of the essay I found particularly relatable dealt with the laziness of people contributing to inferior quality of metadata. Sometimes it is simple negligence or omission of information, sometimes it is not taking a few moments to ensure that the entered data is correct. Either way, the “casual” approach to metadata can play a significant role in compromising its quality. In my work for a digital archive in the local area, I was struck by the difference between the quality of metadata used by the archive itself, and the lack thereof in the document repository utilized elsewhere by the company to house all its current files. The lack of: standard naming protocols, visible dates, file naming methods, attribution of the content creator, and even of a standard file format spells N-I-G-H-T-M-A-R-E for the person eventually responsible for collecting and archiving the documents. Establishing such protocols and standards beforehand, and ensuring that content creators understand and follow them, would have averted much future work.
“Metacrap” is a good read, and won’t take but a few minutes of your time, so be sure to check out the link provided above. I know this article has been popular with my fellow LS 566 travelers. Would love to hear some of your thoughts and insights on whether the meta-utopia is truly as unachievable as Doctorow would have us believe. If you’re not of the SLIS crowd, your opinions and insights are equally welcome, as it’s always great to hear how people outside the field view the topic.
As all of us have doubtlessly experienced, however, such ideas belong to the realm of fantasy. Web searches are messy, retrieving millions of results, with most users lacking the time or endurance to parse for relevant entries after the fire couple of pages. Sometimes we are deliberately led astray, receiving hits for sites that clearly have nothing to do with the item being searched for. Why does this happen? Why has the potential of metadata failed to bring order to the digital environment when its possibilities are so promising?
I find that journalist Cory Doctorow’s 2001 essay, "Metacrap: Putting the torch to seven straw-men of the meta-utopia,” provides a fairly succinct, accurate, and humorous summary of the reasons why the meta-dreamland is one not likely to ever reach the shores of reality. I won’t summarize the whole of the essay here, but will comment on a couple of points he makes.
For me, one of the more problematic areas that Doctorow discusses is the misuse of metadata for the purpose of attracting our attention. Whether malicious and outright false, or simply exaggerating or “enhancing” the properties of an object or site, the fact is that metadata on the internet, at times, takes on all the properties of intrusive and misleading advertising we’ve witnessed across other forms of media. From mail spam with maliciously-intended titles to the deliberate misuse of high priority/relevance metadata terms, the digital environment is anxiously competing for our attention. That the purposeful misuse of terms destroys the integrity of the metadata in question is of no concern to the creator, so long as it gets us to their site/product. A sad result of this trend is that website metadata fields are virtually ignored by most major search engines of today, depriving internet users of a tool that could have been invaluable in enabling expedient and highly accurate search results.
Another area of the essay I found particularly relatable dealt with the laziness of people contributing to inferior quality of metadata. Sometimes it is simple negligence or omission of information, sometimes it is not taking a few moments to ensure that the entered data is correct. Either way, the “casual” approach to metadata can play a significant role in compromising its quality. In my work for a digital archive in the local area, I was struck by the difference between the quality of metadata used by the archive itself, and the lack thereof in the document repository utilized elsewhere by the company to house all its current files. The lack of: standard naming protocols, visible dates, file naming methods, attribution of the content creator, and even of a standard file format spells N-I-G-H-T-M-A-R-E for the person eventually responsible for collecting and archiving the documents. Establishing such protocols and standards beforehand, and ensuring that content creators understand and follow them, would have averted much future work.
“Metacrap” is a good read, and won’t take but a few minutes of your time, so be sure to check out the link provided above. I know this article has been popular with my fellow LS 566 travelers. Would love to hear some of your thoughts and insights on whether the meta-utopia is truly as unachievable as Doctorow would have us believe. If you’re not of the SLIS crowd, your opinions and insights are equally welcome, as it’s always great to hear how people outside the field view the topic.
Thursday, January 9, 2014
Cataloging vs. Metadata?
Drawing from my relatively meager knowledge of metadata, at this point, I gather it's a fairly common question as to how the concept differs from cataloging. Both are methods of assigning descriptive data to an object using prescribed standards for the purpose of facilitating the location and collocation (placing like items together) of said items. While cataloging is commonly used in reference to libraries and the records of their collections, and metadata often seems applied in relation to digital media, I find myself questioning how much of this is due to traditional associations and naming practices. There is certainly no reason why the information contained in a library catalog could not be considered metadata, but is the application of the term cataloging to non-library media equally acceptable?
Are cataloging and metadata interchangeable ideas, or are they unique and distinct in their form and function? I have seen it mentioned that the word "metadata" is employed simply to make the idea of cataloging more acceptable to types of people that would otherwise look down upon the activity. Does this sound plausible? For what reasons would someone find the notion of "cataloging" unappealing, but not have similar qualms about "creating metadata?" I'd love to hear your thoughts.
Wednesday, January 8, 2014
A Renewed Excuse to Blog
Spring Semester is here, and with it comes a reason to pick the blog back up off the floor, a class on Metadata. For those unfamiliar with the topic, metadata is commonly defined as simply being "data about data." Though the definition is lacking, the concept is not an easy one to describe. Metadata encompasses the various information that describes specific items or objects (often digital), such as: who created it, what format it is in, how many pages it has, physical dimensions, the title, and much more. Though metadata is not exclusive to digital formats and an online environment (our textbook suggests that information such as that found on the outside of grocery packaging can be considered metadata), that is often the medium in which we discuss it. For simplicity's sake, however, and for most of the purpose of my posts, let's consider metadata as the descriptive information about a digital object, such as a digital image or an mp3 file (this latter format I hope to explore much further in future posts).
I am grateful for the excuse to start posting again. I have a tendency to feel that, lacking anything significant, or scholarly, to say, there is nothing that I am able to contribute. Here's hoping that I can prove myself wrong.
Also, please feel free to follow me on Twitter @jdkeyes_1.
I am grateful for the excuse to start posting again. I have a tendency to feel that, lacking anything significant, or scholarly, to say, there is nothing that I am able to contribute. Here's hoping that I can prove myself wrong.
Also, please feel free to follow me on Twitter @jdkeyes_1.
Thursday, April 25, 2013
Dewey...or Dewey not?
I recently read an article on the School Library Journal website that mentioned the impending Common Core school standards, and whether Dewey Decimal Classification (DDC) remains the best fit for school libraries implementing them (for the full article, go to In Light of Common Core, Seeking Ways to Circumvent Dewey). While the debate over using Dewey is nothing new to the library field (it has been controversial almost since its inception), it has nonetheless been a mainstay of many public and school libraries across the country. However, recent trends have seen some libraries begin to move away from the vaunted classification scheme in favor of other schemes, including classifying by genre.
A good breakdown of the arguments pro- and anti-Dewey can be found at the AASL Blog (Dewey vs. Genre Shelving...the Conversation Continues Here). Arguments in favor of DDC point out its logical structure (designed to divide all knowledge down into distinct categories), the openness of the system to alteration and revision, and its familiarity to users across the world. Arguments against DDC tend to not dismiss the classification scheme altogether, but instead advocate a hybrid approach, where libraries tailor the organization of their resources according to the needs of their users. In some cases, this is simply the separation of sections of popular subjects for easier location, while for other libraries, this is the complete reorganization of items into subject categories. It seems pretty clear to most proponents on both sides, that the likelihood of a completely new classification scheme being implemented on a widespread level is fairly unlikely. Most libraries simply lack the resources to undertake such a complete overhaul and re-organization.
As someone who grew up with the Dewey system, and who uses it on a daily basis in his own library, I often see these types of debates as librarians trying to "re-invent the wheel" to an extent. There are no doubts that Dewey has faults: it relies on patrons being able to locate call numbers in order to find the subjects they want, the placement of specific types of books can often be unclear (do books about artists go into the Art section, or Biography?), and while flexible, that flexibility is often gained through the use of more and more decimal placings, which increases complexity for librarian and patron alike. That said, its advantages in terms of its ubiquitous use (libraries across the world utilize it), consistency, logical organization, and familiarity make its elimination as the classification scheme of choice unlikely.
Frankly, I don't even see the arguments against Dewey to really even favor the scrapping of the system. One of Dewey's great features is that it is a system that can be altered and modified and still work pretty well. The use of Fiction (F or Fic), Juvenile Fiction (J, JF, J Fic, etc..), and Picture Books (PB, or often E, for Easy) designations is not inherent to the Dewey system, but is seen in widespread use across public and school libraries, with little negative affect to the classification of non-fiction titles. There is no real reason that libraries cannot extend this modification scheme further, as some of the "anti-Dewey" proponents seem to be advocating. I think the bigger issue is whether we want most libraries to be utilizing the same exact classification scheme, to ensure consistency for a patron from library to library, or if we are willing to allow individual libraries to tailor organizational schemes to the specific needs of their patrons. And that is an interesting question, does the library owe more to the needs of its local community, or to conformity and consistency with the rest of its field?
A good breakdown of the arguments pro- and anti-Dewey can be found at the AASL Blog (Dewey vs. Genre Shelving...the Conversation Continues Here). Arguments in favor of DDC point out its logical structure (designed to divide all knowledge down into distinct categories), the openness of the system to alteration and revision, and its familiarity to users across the world. Arguments against DDC tend to not dismiss the classification scheme altogether, but instead advocate a hybrid approach, where libraries tailor the organization of their resources according to the needs of their users. In some cases, this is simply the separation of sections of popular subjects for easier location, while for other libraries, this is the complete reorganization of items into subject categories. It seems pretty clear to most proponents on both sides, that the likelihood of a completely new classification scheme being implemented on a widespread level is fairly unlikely. Most libraries simply lack the resources to undertake such a complete overhaul and re-organization.
As someone who grew up with the Dewey system, and who uses it on a daily basis in his own library, I often see these types of debates as librarians trying to "re-invent the wheel" to an extent. There are no doubts that Dewey has faults: it relies on patrons being able to locate call numbers in order to find the subjects they want, the placement of specific types of books can often be unclear (do books about artists go into the Art section, or Biography?), and while flexible, that flexibility is often gained through the use of more and more decimal placings, which increases complexity for librarian and patron alike. That said, its advantages in terms of its ubiquitous use (libraries across the world utilize it), consistency, logical organization, and familiarity make its elimination as the classification scheme of choice unlikely.
Frankly, I don't even see the arguments against Dewey to really even favor the scrapping of the system. One of Dewey's great features is that it is a system that can be altered and modified and still work pretty well. The use of Fiction (F or Fic), Juvenile Fiction (J, JF, J Fic, etc..), and Picture Books (PB, or often E, for Easy) designations is not inherent to the Dewey system, but is seen in widespread use across public and school libraries, with little negative affect to the classification of non-fiction titles. There is no real reason that libraries cannot extend this modification scheme further, as some of the "anti-Dewey" proponents seem to be advocating. I think the bigger issue is whether we want most libraries to be utilizing the same exact classification scheme, to ensure consistency for a patron from library to library, or if we are willing to allow individual libraries to tailor organizational schemes to the specific needs of their patrons. And that is an interesting question, does the library owe more to the needs of its local community, or to conformity and consistency with the rest of its field?
Dewey vs. genre shelving…the conversation
continues here. 2013. AASL blog (February 15). http://www.aasl.ala.org/aaslblog/?p=3461
(accessed 4/24/13).
Harris, Christopher. 2013. In light of
common core, seeking ways to circumvent Dewey. The Digital Shift. School Library Journal website (March
25). http://www.thedigitalshift.com/2013/03/opinion/the-next-big-thing/tipping-a-sacred-cow-the-next-big-thing/
(accessed 4/24/13).
Tuesday, April 16, 2013
Librarians: ...or not to code?
Of a rather different flavor than the article I mentioned in last week's post, another recent article I came across, Why You Should Not Learn HTML, takes a rather opposing view of the necessity of librarians acquiring programming skills.
My first thoughts, before even reading the article, were "Why would ANYONE actually advocate against librarians developing useful computer and programming skills in this day and age?" My next thoughts were to naturally assume (incorrectly, of course) that the author was clearly a bit of a reactionary; a stodgy, "old school" librarian still clinging to sliding cart catalogs and cursing the day that electronics invaded the library world. As it turns out, the author, Roy Tennant, has been involved with information technology for over 20 years, is a Senior Program Officer for the largest online library cooperative in the world (OCLC), has helped develop several digital libraries, and has even written several books dealing with computer programming, including one on HTML Needless to say, I was a bit confused, and intrigued, by the reasons he might have for telling us not to learn HTML.
The main point of the article seems to be less that librarians should not learn HTML, and more that all librarians do not need to learn HTML. Arguments used to support this position include: the availability of software programs that will do the necessary coding for you, the superiority of professional coding to amateur coding, and the problems and complications that arise from amateur coders trying to develop items from scratch ("reinventing the wheel"). These factors considered, Tennant does believe it is good practice for all young librarians to establish a base of programming skills that they can build from, and that coding skills such as HTML are vital to any librarian looking to write software or web code. Those cases aside, however, he lets the rest of the library world off the hook. If you haven't learned HTML, if you don't need to learn it, and you don't want to learn it, then don't bother.
I do find that there is some merit to the notion that not all librarians NEED to learn HTML. Programming is not an easy skill to learn, no matter how "basic" the language, and there are going to be a fair share of people for which learning HTML is going to produce more frustration than it ever will benefit. There are also some for which an HTML coding base will never be a necessity in their professional lives, and thus would not be worth the hassle of trying to learn.
That said, there are definite benefits to learning even the slightest bit of HTML coding. Simply understanding the syntax and language, or how to identify problems with such, can enable one to troubleshoot problems that even software programs (i.e. Dreamweaver or other WYSIWYG interface) create. Additionally, it seems pretty short-sighted to leave coding knowledge only to those who write software, or only to professionals, since amateurs cannot necessarily create the same quality of product. It is just continuing to concede the more technical elements of information technology to professionals outside the library field, which further confines librarians to physical libraries, a trend that should be seen as very disturbing to anyone considering the rate at which digital information (and books) continues to be available.
Sorry Mr. Tennant, I disagree. To give people a pass to not actively engage an aspect of the technical reality we live in is an invitation to irrelevance. Learn HTML boys and girls.
My first thoughts, before even reading the article, were "Why would ANYONE actually advocate against librarians developing useful computer and programming skills in this day and age?" My next thoughts were to naturally assume (incorrectly, of course) that the author was clearly a bit of a reactionary; a stodgy, "old school" librarian still clinging to sliding cart catalogs and cursing the day that electronics invaded the library world. As it turns out, the author, Roy Tennant, has been involved with information technology for over 20 years, is a Senior Program Officer for the largest online library cooperative in the world (OCLC), has helped develop several digital libraries, and has even written several books dealing with computer programming, including one on HTML Needless to say, I was a bit confused, and intrigued, by the reasons he might have for telling us not to learn HTML.
The main point of the article seems to be less that librarians should not learn HTML, and more that all librarians do not need to learn HTML. Arguments used to support this position include: the availability of software programs that will do the necessary coding for you, the superiority of professional coding to amateur coding, and the problems and complications that arise from amateur coders trying to develop items from scratch ("reinventing the wheel"). These factors considered, Tennant does believe it is good practice for all young librarians to establish a base of programming skills that they can build from, and that coding skills such as HTML are vital to any librarian looking to write software or web code. Those cases aside, however, he lets the rest of the library world off the hook. If you haven't learned HTML, if you don't need to learn it, and you don't want to learn it, then don't bother.
I do find that there is some merit to the notion that not all librarians NEED to learn HTML. Programming is not an easy skill to learn, no matter how "basic" the language, and there are going to be a fair share of people for which learning HTML is going to produce more frustration than it ever will benefit. There are also some for which an HTML coding base will never be a necessity in their professional lives, and thus would not be worth the hassle of trying to learn.
That said, there are definite benefits to learning even the slightest bit of HTML coding. Simply understanding the syntax and language, or how to identify problems with such, can enable one to troubleshoot problems that even software programs (i.e. Dreamweaver or other WYSIWYG interface) create. Additionally, it seems pretty short-sighted to leave coding knowledge only to those who write software, or only to professionals, since amateurs cannot necessarily create the same quality of product. It is just continuing to concede the more technical elements of information technology to professionals outside the library field, which further confines librarians to physical libraries, a trend that should be seen as very disturbing to anyone considering the rate at which digital information (and books) continues to be available.
Sorry Mr. Tennant, I disagree. To give people a pass to not actively engage an aspect of the technical reality we live in is an invitation to irrelevance. Learn HTML boys and girls.
Tennant, Roy. 2013. Why you should not learn HTML. The Digital Shift web page, Library Journal website. http://www.thedigitalshift.com/2013/03/roy-tennant-digital-libraries/why-you-should-not-learn-html/
Tuesday, April 9, 2013
Librarians: To Code...
I have long been fascinated by computers. The time in my youth that I wasn't out practicing my pitching in the backyard, shooting hoops in the driveway, playing soccer with my sisters, or playing Nintendo, I often spent fiddling around on my parents' computer.
Those were the good old days when the only Windows version was 3.1, and most computers still ran DOS as a default operating system. For a lot of kids, computer gaming just wasn't worth the hassle, as every game had a different requirement for not just memory, but specific memory configurations. One game would require a certain amount of conventional (standard) memory and extended memory (or XMS), while another would lose the extended memory parameter and instead need expanded memory (or EMS). All these setups required the careful editing of the system start up and configuration files and adjustment of how certain pieces of hardware were loaded by the computer. Essentially, it was a giant invitation to completely and utterly crash my parents' hard drive in the interest of the latest Front Page Sports Baseball game, or Sid Meier's Colonization, before the advent of internet tech support or Geek Squad, and I loved it. To my parents' credit, if they ever knew what I was doing (and I suspect they probably did), they allowed me to experiment, fiddle, make my mistakes, and correct them, fostering a love and knowledge of computer technology from a fairly early age.
Unfortunately, the advent of operating systems such as Windows 95 ended a lot of the need for such types of rudimentary programming, and most of my computer experience since then has consisted of various types of troubleshooting, and building newer and better hardware systems to feed my gaming needs. As my Information Technology class has shown me this semester, however, I am a complete novice when it comes to programming and coding. With a fire having promptly been lit under my rear end, I am determined to make amends for years of neglect to my computer skills, but have been left a bit overwhelmed by the variety of coding languages out there to learn. Additionally, one may question how much coding knowledge a future librarian may need to have.
A recent article on Library Journal's Digital Shift website, entitled Cracking the Code: Librarians Acquiring Essential Coding Skills, addresses the topic of librarians, of all skill levels, wading into the programming world. As the article points out, the modern librarian uses computer technology almost constantly, whether in catalog or article databases, websites, multimedia presentations, or any of the countless other resources that the internet places at our disposal. A solid programming base can not only "make day-to-day tasks easier," through efficient use of coding, but can also help in making changes for the benefit of all potential library users. There are some interesting projects mentioned throughout the article, about librarians that are already putting their programming skills to work, as well as some fantastic resources for anyone looking to get some basic coding skills. As for me, I think it's time to get back to Code Academy.
For the record, my mother always told me I should have gone into computers as an undergrad. Mom, as usual, you were right.
Those were the good old days when the only Windows version was 3.1, and most computers still ran DOS as a default operating system. For a lot of kids, computer gaming just wasn't worth the hassle, as every game had a different requirement for not just memory, but specific memory configurations. One game would require a certain amount of conventional (standard) memory and extended memory (or XMS), while another would lose the extended memory parameter and instead need expanded memory (or EMS). All these setups required the careful editing of the system start up and configuration files and adjustment of how certain pieces of hardware were loaded by the computer. Essentially, it was a giant invitation to completely and utterly crash my parents' hard drive in the interest of the latest Front Page Sports Baseball game, or Sid Meier's Colonization, before the advent of internet tech support or Geek Squad, and I loved it. To my parents' credit, if they ever knew what I was doing (and I suspect they probably did), they allowed me to experiment, fiddle, make my mistakes, and correct them, fostering a love and knowledge of computer technology from a fairly early age.
Unfortunately, the advent of operating systems such as Windows 95 ended a lot of the need for such types of rudimentary programming, and most of my computer experience since then has consisted of various types of troubleshooting, and building newer and better hardware systems to feed my gaming needs. As my Information Technology class has shown me this semester, however, I am a complete novice when it comes to programming and coding. With a fire having promptly been lit under my rear end, I am determined to make amends for years of neglect to my computer skills, but have been left a bit overwhelmed by the variety of coding languages out there to learn. Additionally, one may question how much coding knowledge a future librarian may need to have.
A recent article on Library Journal's Digital Shift website, entitled Cracking the Code: Librarians Acquiring Essential Coding Skills, addresses the topic of librarians, of all skill levels, wading into the programming world. As the article points out, the modern librarian uses computer technology almost constantly, whether in catalog or article databases, websites, multimedia presentations, or any of the countless other resources that the internet places at our disposal. A solid programming base can not only "make day-to-day tasks easier," through efficient use of coding, but can also help in making changes for the benefit of all potential library users. There are some interesting projects mentioned throughout the article, about librarians that are already putting their programming skills to work, as well as some fantastic resources for anyone looking to get some basic coding skills. As for me, I think it's time to get back to Code Academy.
For the record, my mother always told me I should have gone into computers as an undergrad. Mom, as usual, you were right.
Enis, Matt. 2013. Cracking the code: Librarians acquiring essential coding skills. The Digital Shift web page, Library Journal Website. http://www.thedigitalshift.com/2013/03/software/cracking-the-code/ (last accessed 4/9/13).
Subscribe to:
Posts (Atom)