Indexing Project: The search for perfect metadata

One of the struggles I've experienced in indexing my assigned digital images has been determining how much time to allocate to working on each record. Since this is a "Final Project" for a class, there's a natural tendency to spend quite a bit more time on the process, and ensure that every field is entered "perfectly," although I don't find that this is indicative of the way we are likely to encounter metadata creation in a professional environment. Certainly, in my day-to-day role as a school librarian, I don't have the spare time to get "too fine" with my cataloging backlog (I hardly have the time to catalog at all), nor did my experience at JPL, entering and describing documents in a digital repository, give me an excess of time to really pore over and deeply research the individual entries. Real-world metadata description often puts a premium on speed that is definitely absent from class exercises to a certain extent. That's not to say that emphasis isn't also placed on the accuracy and quality of entries, but these facets all need to be balanced when entering data in a work environment.

Now, this isn't to say that I didn't put a grade A effort into my image description. As someone who over-thinks, over-writes, and then over-thinks some more, I bellyached plenty over my fifteen assigned images. But at a certain point, I also recognized (and thanks to the sentiments of Dr. MacCall), that there isn't going to be perfection in our entries, and that the subjective nature of much of object description means that there are always going to be ways in which entries could be improved or tweaked. There is also the reality, beyond our control to an extent, that those searching through our records are going to be thinking of terms, phrases, and descriptive terms that are wholly different than those we conceived of, and it is difficult to ensure that all such perspectives are properly represented in our metadata entries.

I think there's a trend in our culture to think that doing something "well enough," or accepting "less than perfect" signifies laziness, a lack of ambition, or an acceptance of mediocrity. While it's true that we don't want to produce poor quality metadata, it's important not to lose sight of what it is we're producing. Metadata is a tool, a representation of a work utilized to find a desired information resource. It is meant to be USED. In order for that to happen, however, we need to be willing to "cut the cord," and let it come to life. In doing so, and turning it over for users to scrutinize, we may discover points for improvement and editing that we never would have considered on our own. It's a learning process, and one that we should approach humbly, open-minded, and with an ability to adapt. Don't get so concerned with creating excellent metadata, that you really end up creating no metadata. For an over-thinker like me, this is a tremendous challenge, but one I will continue to apply myself to meeting as I gain more and more experience with metadata, cataloging, and other descriptive processes.

This will be my last blog for LS 566, Metadata...I really just can't believe Mr. Anti-Social Media managed to crank out 42 this semester! If you've been following my posts, I appreciate you taking the time, and thanks for those that have left comments. Best of luck to the rest of my SLIS compadres in their future studies and professional endeavors.

Ephemerality and the web

So there I am, just about ready to present my digital repository for Metadata class...well, scratch that, I had been done with my presentation materials for a bit of time in advance, but like with everything, I tweak, edit, revise and redo right up til the end. As I surf back over to Northwestern University's World War II Poster Collection, my chosen repository, I am met with a startling discovery...it's GONE! Ok, not gone completely, but it would appear that after 17 years, the decision was made to finally migrate the old repository over to a new software platform, wiping out quite a bit of the existing metadata from the looks of it, and instantly negating any of the information I was prepared to present on the collection. Surely I am not the first student this has happened to, and we have all certainly encountered the ephemeral nature of content on the web at some point, with favorite sites there one moment and gone forever just a few days later.

It is inevitable that any online content meant to last for an extended period of time (is that an oxymoron?) will undergo changes and transitions at some point in its life cycle. Guessing the specific reasons for such changes is a fairly interesting exercise, and is definitely informed by a lot of what I learned during this semester. For the World War II Poster Collection, the interface is now more modern, the navigation options more intuitive, and the overall aesthetic is definitely of a higher quality. That's certainly of benefit to the site just on visual and presentation improvements. Beyond that, there are undoubtedly changes "under the hood" that have made a change in software and style warranted. How does the site handle linked data, and is it now designed to be integrated with other NWU online collections? What types of elements or features are now usable, or desired, that may not have been possible to represent in the old software? Will these changes allow the collection to be harvested by sites such as DPLA? Will the metadata records still be converted from their original MARC format, or will they be built as original records from the ground up? What schema will it follow? What content standards will it use? As the collection's migration still seems in its infant stages, it will be interesting to follow the progression of how its metadata records are built, how items will be grouped, structured, and searched for, and what extra features (if any) will be implemented. 

This whole experience has definitely been an educational one for me. While my professor can attest to my panic upon first realizing my repository had been reborn, there is definitely a lesson to be learned in terms of the need to be flexible, adaptable, and open to changes in the world of metadata, as well as the online environment as a whole. That may seem like an obvious characteristic to some, but I think we sometimes take for granted the nature of the information we pull from the web on a daily basis, and the ability to continue doing so day after day. At the least, I got a really great glimpse at a pretty interesting digital collection of World War II-related posters and some of the technical aspects related to its presentation and use of metadata, and now I get to see the whole process started anew. 

When do I use the Relation element?

Yesterday, I blogged about beginning our digital image indexing, and made some predictions as to which metadata elements might be a bit of a breeze, and which ones might throw me for a loop. While I've already gone through and finished up the indexing for a good portion of the elements, a few of the more time-intensive ones have been cast aside for the time being (subject, description, title), and one I just really don't know what to do with...the Relation element.

Relation is usually used to indicate associations of an item with other items. This theoretically could be for a variety of reasons: part of the same collection, part of a specifically constructed series, created by the same person, having the same context. The problem is trying to figure out exactly what type of relation should be applied to my images (if any), and to a certain extent, where do I draw the line in determining what is "related" to them.

In my football images, for example, I have 5 that were taken during the 1975 Alabama/Mississippi (Ole Miss) game. Now do these images relate to all images taken from that 1975 Alabama/Mississippi game? One could possibly make an argument that they do, although the enormity of including all such images is daunting. Do they relate to the immediate grouping of 5 that were my assigned images? Not necessarily, as their only common thread in that regard is that I am their indexer (which I will humbly recognize as not significant).

How about my John DePol images? According to a reference sheet we have, many of them belong to broad groupings and categories, such as "Books" or "blk_arch." Should I mention all the other images from such groupings under Relation? Again, the scope of images involved makes this a potentially frightening proposition to consider repeating several times.

So when SHOULD we use Relation and what exactly should we use it for? Hopefully some kind souls, including Relation guideline people, can swing by and shed some light for us.

The Great Digital Image Indexing Phase Begins

We've moved past guidelines and are on to indexing our assigned images. I'll be looking at 10 football images (5 from 1975, 5 from 2010) and 5 art images from the DePol Collection., which have already been uploaded to the Omeka Repository. As I approach the indexing process, it is interesting to guess which elements might be easiest to enter, and which are going to be a bit more on the challenging side. It reminds me of the same debate over which elements I wanted to work with, and which I didn't.

Elements I think MAY be simpler to deal with:
Date Created and Date Modified-My own elements (for the DePol Collection), the temporal information for both creation and modification/digitization should be pretty easy to locate and enter.
Source-Seems to relate to derivation of the digital image. Has a drop-down menu, BIG plus.
Identifier-Depends on the specific guidelines, but this may be something like the image's unique file name.
Rights-I see another drop-down menu, at least for football. I like drop-down menus.
Format-File formats are easy to find, and particulars such as the resolution are located in the file properties.
Type-Generally standard categories of resource types from which to choose.

Elements that MAY NOT be so simple to deal with:
Title-Will really be sticking to the guidelines for this one. I don't relish trying to think up titles on my own-creativity NOT a strong suit.
Subject-Errrr....depends how much flexibility we have in the guidelines. There are a LOT of subjects out there. Good controlled vocabulary will make things much simpler though. I feel much more comfortable on the football images with this one than the art images. I love art, but am anything but an expert at it.
Description-More for the art images than the football images. See above about art expertise (lack thereof).
Abstract-Summary of the resource...I have major issues with brevity in my writing.
Relation-Many of these images are related to each other, so it will be interesting to see how this element is handled in the guidelines.

So there are my predictions going into the indexing process. We'll just have to see what ends up being more challenging than expected, what is simpler than expected, and which elements just gave me a headache. I have a lot of faith in my classmates and their guidelines, however, so am really looking forward to this aspect of the project. I think it will be informational, and maybe even a little enjoyable.

Resource description and the one-to-one principle

One of the fundamental challenges in using metadata to describe digitized images and objects is discerning exactly what it is you are describing. This isn't necessarily in a "I have no idea what that's a picture of" sense (though there's also that problem), but more so in determining which version of an object you are entering information for. For example, if you have a digital picture of the Mona Lisa, what types of information would you expect to be displayed as metadata? For some, perhaps many, myself included, we would expect to see the title "Mona Lisa," the creator or artist listed as "Leonardo da Vinci," or "Da Vinci, Leonardo"...we might even expect to see dimensions for the original painting, information about the materials utilized, and a date in the 1500s. Easy enough, right?

If we were to take that same digital image, however, and then use it on our website, blog, or in a school assignment, what would we cite? More than likely, we would be listing the site we took the image from, the date it was copyrighted, and perhaps even who the rights of the image belonged to. Here's were metadata for digital items starts to get complicated, because that image of the Mona Lisa is actually a distinctly different entity than the Mona Lisa itself. Both have unique creators, formats, sizes/dimensions, creation dates, and locations, among other descriptive information. You can see why this may start to get confusing for metadata creators and users alike.

The principle that guides us (sort of) through this confusing situation is known as the One-to-One Principle. According to the DCMI Wiki, the One-to-One Principle "dictates that a metadata description should refer to just one resource." The Wiki goes on to elaborate that the principle was created to ensure "that distinct resources be identified, distinguished, and described separately, as in the case of the original "Mona Lisa", created in 1506 by Leonardo da Vinci, and a photograph of "Mona Lisa" created in 2008 by John Smith" (I really did pick the Mona Lisa at random, honest). The point seems fairly clear, however, digital images of original materials should have metadata that reflects the digital image's creation, not that of the object being captured. The reasons for this are fairly compelling, actually, as it provides attribution of the digital image to the person and circumstances that actually created it. If we were to ignore this contribution, and focus on the original object, we actually obliterate the digital image as a distinct informational object. When we consider the proliferation of digital and digitized documents, ensuring that we preserve the integrity of distinct informational objects should be of prime importance.

In practice, however, the One-to-One Principle may not be so cut and dried. The DCMI Wiki makes the point that the notion can be very subjective, and indeed, it is sometimes difficult to determine what exactly constitutes a unique resource. Beyond those technicalities, however, there is also the problem that conforming to the principle can sometimes be confusing for users. Does someone looking for a picture of the Mona Lisa want to see the details of John Smith's photograph, or do they want the details of the famous da Vinci canvas? Do the preferences of the user really matter in describing information resources (be careful, consider why we do it in the first place). Is there a way to reflect both sets of information, without overloading users (some metadata elements can serve the purpose, but there's a limit to what you probably should include in them)? What do you think about the merits of the One-to-One Principle? What information do you want to see when you are browsing through digital items?

Viewing description through different lenses

One of the really intriguing aspects about this current semester has been the opportunity to view the description of information resources through the differing perspectives of three different classes. Cataloging, Metadata, and Archival Arrangement and Description may come at the process of resource description from different motivations and viewpoints, but are all ultimately concerned with identifying what a resource is, and enabling its access by outside users.

Cataloging is the most technical and complex of the three courses. It is in some ways the most traditional descriptive process of the field, carrying on the legacy of inventorying, classification, and ordering that has been a hallmark of libraries for centuries. Though having undergone a significant, recent change in the cataloging rules that now guide the practice, cataloging's attachment to the MARC standard keep it a relatively formulaic and predictable practice. Employment of cataloging processes requires an understanding of specific tag locations, subfields, indicators, and an understanding of specific content standards and data entry formats. While a knowledge of these protocols and features can make cataloging a relatively more difficult, or time-consuming, description method, it also tends to produce catalogs and indexes that are relatively cohesive and consistent, resulting in relatively accurate searches. Though the new RDA cataloging rules place more focus on the relationships between information resources, cataloging has traditionally focused on description of single items.

Archival description, on the other hand, has tended to be a bit more flexible, conceptually. Having undergone cycles of emphasis which included: simple inventories, item-level descriptions, to the more common collection-level finding aids, archival description has tended to focus on how to adequately identify and provide access to aggregations and collections of resources, rather than single items. For archival purposes, data such as the context of creation, provenance, and function for information resources has often outweighed their content in importance, as well as the relationship of those resources to each other and the collection as a whole. While archival description has codified its practices in standards semi-derived from the world of library cataloging, there is more flexibility in how they tend to be implemented. Like library cataloging, the ascendancy of digital documents and information resources will signal some pretty significant changes to archival descriptive practices in the future.

As for Metadata, well, in many ways it is a concept that encompasses both of the others. In a very general way, metadata is the essence of what library cataloging and archival description are about, but in another sense, it represents part of the future for both practices. Digital metadata bears the advantage of not being bound to specific encoding standards, content standards, or software platforms, making it an incredibly flexible and simple tool to utilize. By the same token, it can be made as rigorous and specific in its scope as a user or corporate entity desires, thereby retaining the degree of control and consistency that one would expect to find in a library catalog, for instance. Features such as the ability to easily link data or images make it especially valuable to archives and special collections, providing users the ability to visually explore the relationships between items, rather than hunt for them in stored boxes.

Despite the obvious advantages, however, the big question mark is whether institutions will buy into a collective metadata system (e.g. the Semantic Web) in the same way that they have for MARC and linked cataloging. Can libraries make the big jump from MARC and corporate catalogs to a shared, centralized metadata system? Can it similarly interlink the holdings and records of archives and special collections? Interesting times ahead seeking out the answers to these questions, that's for sure.

Title metadata for unnamed photographs

A classmate recently blogged about some of his struggles tackling the Title metadata element for use with the football photographs repository we will be indexing. The images in question were photographs taken from University of Alabama football games during the 1975 and 2009 seasons. Now the Title element would normally seem to be one of the easier tags to provide information for, but when you actually consider the nature of most photographs, most are not likely to possess an official title. As the same classmate pointed out while advocating for the use of the Title element on this project, a title (name) is a core element in providing identity to an object, but it also plays a role in facilitating discovery and retrieval of the item in an online environment. In the absence of a pre-defined title, then, creating a suitable name for an item becomes an extremely important part of the indexing process.

Creating a unique title is definitely not an exact science. Trying to get too creative or interpretive in the forming of a title can make the item relatively inaccessible, or confusing, for potential searchers. On the other hand, getting too descriptive with a title can flood what should be a relatively simple access point with too much detail and information. On the whole, however, I believe that in this type of situation, a descriptive title is probably the best method of assigning a title, if not necessarily the simplest. Providing details such as specific player number or names can be a very useful aspect of a title, such as: "Greg McElroy throws pass versus Florida International." Trying to discern where to draw the line where including player names and numbers can be difficult, though, when facing group shots where no specific player is the focus of the photograph. Additionally, if multiple photographs of the same player performing an action are present in the collection, further information will be needed in order to disambiguate them.

This issue is a pretty intriguing problem, and it's even something that any of us with personal photo collections that we are trying to name can relate to. I will be interested to see how these issues are sorted out in the indexing guidelines.

Naming a metadata element

You'd think that the name of a metadata element would be one of the easiest aspects of creating guidelines for that element. It's just a name--something that should be fairly obvious, like: Subject, Title, Author, Creator, or Publisher. When working with an element dealing with dates, it would make sense that it just be called...Date...right? Such a dilemma was far from my mind as I began browsing the class Wikispaces site that will house our indexing guidelines; that is, until I saw that my element had been initially entered into the list as Date Created. No big deal, right? Just change it! On further reflection, however, and a quick perusal of the information provided to us with which to index our images, I discovered that choosing a name for an element is not as simple and painless as I first thought.

So here's what I'm working with. The digitized DePol art images that I am creating the date-related indexing guidelines for have one piece of temporal information included, the date that the digital image was created. In theory, I have three options to choose from in naming my element: Date, Date Created, or Date Digitized.

Date is the generic name used in the Dublin Core metadata scheme. Its lack of specificity is also one of its strengths, as nearly any type of date-related information can be included under this element, while Date Created and Date Digitized are narrow in scope. This could be advantageous were any other temporal information to be added to the image metadata at a later time. There are also perhaps less concerns with Date being aggregated into other catalogs or repositories, should the need arise, since it is the standard method of naming the element. On the very negative side, there's no real way of discerning what is actually being represented by the Date element, depending upon how many dates are present, and the nature of the metadata being included.

Date Digitized is another good candidate, as we are dealing with the digitized version of a physical art image. In many ways, this name best fits the nature of the object being described. On the flip side, if we are treating the digital images as distinct entities apart from the physical images, then Date Digitized seems to be too derivative a concept. It is possible there may be concerns with interoperability of this name in contexts outside the immediate repository we are indexing for (though I believe Digitized is often used as a qualifier/modifier for Date). Further, use of this element name would likely necessitate the creation of separate metadata element for any other types of dates that may need to be added later.

Date Created has pros and cons fairly similar to Date Digitized. It is narrow in scope, lacking versatility, and again trends away from the standardized name utilized for this type of element (though, again, can often be used as a valid modifier). While Date Digitized best reflects the images in relationship to the original content, Date Created treats the digital images as unique, and distinct, entities, and therefore perhaps better embodies the spirit of the one-to-one principle (e.g. similar information resources should be identified, distinguished, and described as separate entities).

As of right now, I think I am still stuck between Date and Date Created, with the primary consideration really being the possibility of needing to enter other dates at a later time. Minus that consideration, Date Created is preferable due to its greater specificity as to the context of the date being entered. What do you think? Are there other considerations that I have not yet taken into account?

(Mis) Understanding the Semantic Web, Part III

After blundering my way through two blogs on the Semantic Web, I think that I at least have been able to separate some of the concepts from the techno-babble, and have achieved a better understanding of what is being referred to, and what the goal of the project is. Providing a better explanation than I would be able to, however, is Semantic Web guru, and W3C Chairman of Linked Data and Web Payments Initiatives, Manu Sporny, who created this excellent video that should cover most of the basics for any of us still struggling with what Semantic Web is:

So we're trying to create webs of data that allow machines to more properly interpret and "understand" the meaning of webpages and information resources, and their relationship to each other, all the while greatly improving their ability to retrieve just what we're looking for. This is all necessary, as Dr. MacCall points out, because computers are "dumb de dumb dumb dumb."

It all sounds like a pretty noble goal in trying to help bring greater order and efficiency to the web, though the big question is probably whether there is enough buy-in to make it a reality. There's undoubtedly a whole lot of "under the hood" type information that I'm not even going to attempt to touch, but hopefully some of you have gained a better understanding of this topic, like I have, over this series of posts. I at least won't be getting a "deer in the headlights" look the next time I'm reading about Semantic Web in my SLIS readings.

(Mis) Understanding the Semantic Web, Part II

In my last post, I took a quick look at the idea of the Semantic Web, as well as some impressions I've gained from readings as to what the concept truly represents. In this second post on Semantic Web, I will be gathering some definitions and descriptions of the topic--some helpful, some perhaps not--that will hopefully start bringing some clarity to the topic for me and any of you that are also trying to unwind the infospeak it's often shrouded in.

Wikipedia describes Semantic Web as a "collaborative movement" which "aims at converting the current web, dominated by unstructured and semi-structured documents into a 'web of data.'" This process "extends the network of hyperlinked human-readable web pages by inserting machine-readable metadata about pages and how they are related to each other, enabling automated agents to access the Web more intelligently and perform tasks on behalf of users."

The World Wide Web Consortium (W3C) identifies the concept as a "Web of linked data...technologies [that] enable people to create data stores on the Web, build vocabularies, and write rules for handling data." The goal of Semantic web is "to enable computers to do more useful work and to develop systems that can support trusted interactions over the network."

Steven Miller, in Metadata for Digital Collections, uses an earlier Wikipedia entry for Semantic Web as his definition, citing it as "a group of methods and technologies to allow machines to understand the meaning--or "semantics" of information on the World Wide Web" (2014, 304).

Arlene G. Taylor and Daniel N. Joudrey, in The Organization of Information, characterize the Semantic Web as an entity where "data on the Web will be defined semantically and linked to relevant data for the purpose of more effective discovery of information..." (2009, 17). They additionally state that Semantic Web will allow information to be "defined in such a way that its meaning or semantics can be discernible, shared, and processed by automated tools as well  as by people" (2009, 112).

While these descriptions trend toward the overly general, there are at least some commonalities that can help us start piecing together enough information to gain a sense as to what Semantic Web is. Linked data, resource discovery, and data readability are all concepts that are fairly straight-forward to understand, even if the overriding idea of semantics is a bit ambiguous. Based on the context of the other concepts, we can perhaps jump to the assumption that semantics is referring to the underlying meaning of data, a notion that humans are fairly capable of deciphering, but computers are pretty terrible at (i.e. did my search REALLY result in 9 million RELEVANT hits?). If we accept that idea, then maybe we can cobble together a fairly general definition for Semantic Web:
Linked data and associated technologies that are employed to aid machines in discerning the meaning of information, or data, on the web, in order to more effectively facilitate the discovery and retrieval of information resources.

There's undoubtedly quite a bit more to Semantic Web than that, but hopefully we're on the right track. In the final part of this 3-part blog, we'll see if we can hone in on this concept in a little bit more detail.


Joudrey, Daniel N., and Arlene G. Taylor. 2008. The organization of information 3rd ed. Westport, Connecticut: Libraries Unlimited.

Miller, Steven J. 2011. Metadata for digital collections : a how-to-do-it manual. New York : Neal-Schuman Publishers.

(Mis) Understanding the Semantic Web, Part I

The information world throws around a lot of concepts and terminology that can be confusing for those outside the field (let's face it, they confuse a lot of us within the field as well). The Semantic Web is one of those concepts that I seem to run into quite often during class reading, and while the term does seem to be talked about, and referred to, quite often, I can't say that it's one I've seen defined in terms that your average internet/computer user would understand, or at least be able to simply explain. Even my attempts to use Google searches for strings such as "What the heck is Semantic Web?," or "I don't understand Semantic Web," or even "Semantic Web for Dummies" hasn't turned up much help (unless I want to buy the book Semantic Web for Dummies). So just what is the Semantic Web, and why the heck should we care? 

Piecing together the title at least creates an expectation of what the Semantic Web may be about. Web is immediately identifiable with the internet as a whole, perhaps more specifically in its role as facilitating linking between information resources. Semantics...well, that usually deals with the concept of meaning. Ok, good building blocks, I suppose, but not a great deal else to go on. 

Some of my (possibly wrong) impressions of Semantic Web based on readings I've done include:

-improvement of web interoperability

-emphasis on linked data and metadata

-a certain degree of standardization (format? programming languages?)

-there are allegedly some "great" things that can be done with it

-most people will work with the external manifestations of it rather than the "under the hood" aspects

In the hopes of improving clarity and understanding of this topic, and verifying whether I'm anywhere close to the mark, next time we'll look at exploring some definitions and descriptions of Semantic Web to see if we can start honing in on what it really is.

Putting together my indexing guidelines

Now that decisions have been made regarding the usefulness of our individual metadata elements to the class indexing project, the next task is to create guidelines for the use of our element. While the implementation and use of the Date element would seem to be rather straight-forward, there are still some questions to sort out, such as what date formats should be utilized and the scope of the instructions I will need to include. On the latter topic, this mostly relates to my concern in whether I simply provide instructions for information that I know will be represented, or do I try to set-up guidelines for other contingencies. For example, though the Date element is likely to be restricted to describing dates concerning image creation and digitization for this project, with specific dates associated for each, do I include formatting guidelines for information such as date ranges, even though it is unlikely to be used in conjunction with the Date element in this project?

Dr. MacCall gave my first draft of these guidelines some pretty good feedback, and influenced me to not try to overstep the bounds of my element in the context of this project, so I have tried to pass on information that will only pertain to the specific needs of the Date element. Further, while I always feel it necessary to justify and support my writing, where possible, I was encouraged to keep the indexing instructions as simple and minimal as possible, in order to allow indexers to find the relevant information they need quickly. As such, additional information has been moved to the "Notes" section of my guidelines. I know that there is still some tweaking and editing to go, but think that I'm at least on the right track with this second version of instructions for using the Date element. Feedback is definitely welcome.

DC.Date

Label: Date

Description: The Date element is utilized to identify temporal information associated with the life cycle of a resource, including (but not limited to) its creation and digitization.

Required: No

Repeatable: Yes

Guidelines:  

Dates should be entered as specifically as possible.

If portions of the date are not known, the indexer should use the level of specificity that matches the amount of temporal information that is known.

Full Date: YYYY-MM-DD

Month and Year: YYYY-MM

Year: YYYY

Examples:

Full Date: YYYY-MM-DD

                Ex. Date=”2014-03-20”

Month and Year: YYYY-MM

                Ex. Date=”2014-03”

Year: YYYY

                Ex. Date=”2014”

                               

Notes:

Date entry follows the format prescribed in the W3C Date and Time Formats http://www.w3.org/TR/NOTE-datetime and the sections for “Years” and “Calendar Dates” under ISO 8601.

The use of other formats may not be prohibited by the software, but can prove problematic to both human and artificial users alike. Please conform to the above guidelines to ensure consistency in data entry and presentation, and allow for potential aggregation of data into other discovery services and catalogs.

Making sense of the metadata world

Having come into my LIS program from the perspective of an elementary school librarian, I had expected to have my view of the field open up drastically, and learn about concepts I had never been exposed to before. Metadata was one of those concepts, which even for the first year or so of my studies boiled down inside my head to "it's like cataloging, but, not for books, right?" Needless to say, my Metadata class has opened my eyes a great deal as to the versatility of the metadata concept, and the numerous tools, ideas, and structures that are associated with it. But still, for someone who is focusing in on mastering the understanding of Dublin Core elements and their uses, there is a minefield of confusion and frustration as concepts and aspects of metadata pile upon each other in my mind. Schema, descriptive standards, content standards, digitization standards, left-side, right-side, refinements, qualifiers, MODS, MADS, LCSH, EAD, VRA, MeSH...the list goes on and on, with my sometimes overwhelmed brain trying to sort it all out and make sense of it all.

My LS 566 classmate, Michele, has posted an excellent recent blog entitled "Big Picture," which tackles some of the concepts listed above, and helps to break down some of the distinctions between the various types of standards and how they are used, as well as listing some examples of each. I found the post to be extremely helpful in developing and reinforcing my own understanding of many of these various ideas, and would highly recommend giving it a look. As for metadata's adherence to the EHAA (Everything Has An Acronym) standard that similarly bogs down the field of education I currently work in, well, that probably can't be helped. 

Dublin Core: Identifier Element

Though I have already been assigned my personal element for our class Digital Indexing Project, I've felt compelled to spend some extra time browsing through the other DC elements to get a better understanding of what they all do. Possibly one of the more underestimated elements, especially in the digital environment, is the Identifier tag, which contains unique identifying information for a particular resource. There are a wide variety of possible identifiers, including: ISBN numbers, file names, accession numbers, and URLs, and each can help play a role in helping users to locate the exact specific document or resource that they are searching for.

One of the more useful classes of identifiers that may show up in this metadata field are those known as DOIs, or Digital Object Identifiers. To help explain what a DOI does, consider the much experienced-scenario of a user having finally found the information research they've been searching for, and when they click on the link to reach it...Object Not Found HTTP 404. Don't you hate that? To help avoid such frustration, some information resources possess a DOI, which is a unique character string by which the resource can be searched for and found, wherever in the ether of the web it may have moved to. While not all informational objects possess a DOI, the practice is becoming increasingly common, especially with items such as journal articles.

For another take on the Identifier element, head over to my classmate Kasie's blog, where she provides some brief information as well as some helpful links on the topic.

Metadata Survivor

Had a real interesting experience in my Metadata class tonight, as we all made our pitches for why the elements assigned to us should be considered and utilized for the collection. Date, my element, which can cover a wide variety of temporal information related to an object, as discussed in an earlier post, made the cut...as did most of the elements. The notable castaways included Contributor, for which a strong case just could not be made for inclusion, as well as Language. These will likely be replaced by elements covering identification of the responsible indexing or entry person for the metadata, as well as one considering the football players likely to be found in the Bama football images we are describing.

It was intriguing to hear the wide variety of justifications and possible uses for elements provided by my classmates, and was an excellent opportunity to think critically about the importance of specific elements to the description of digital collections. I also found it challenging to consider the ways in considering the employment of elements when using digitized objects versus ones that are born digital, and how that distinction can alter the usefulness of those elements. This has been a very educational project so far, and we're just getting started on it. More to come as we get further along.

Controlled Vocabulary

One of the topics that I find myself returning to again and again in examining metadata and cataloging is controlled vocabulary. Broadly described by Steven J. Miller in our textbook, Metadata for Digital Collections, controlled vocabulary is "any standardized list of terms that have been selected for consistent use in describing or indexing information resources" (2011, 129). By ensuring the consistent use of terms to describe information objects, a metadata creator can more easily facilitate their retrieval by potential users. While the idea of a controlled vocabulary is nearly synonymous, for librarians, with tools such as LCSH (the Library of Congress Subject Headings), there are a variety of types and forms, including: lists, thesauri, taxonomies, and classification schemes, among others.

Trying to distinguish between the different types of controlled vocabularies can be daunting, even for information professionals, so any resource that can facilitate understanding is greatly appreciated. For those of you interested in learning more about the differences between these various descriptive tools, my LS 566 classmate, Cassandra, recently posted a blog that included a very helpful link, entitled Controlling your Language: A Directory of Metadata Vocabularies. Courtesy of Jisc Digital Media, this guide walks you through the basics of controlled vocabularies, and also describes the important features and uses of the major types that may be encountered. It's a quick read, and definitely worthwhile if you have interest in subject description, so be sure to check it out if you have some time to spare.

Miller, Steven J. 2011. Metadata for digital collections : a how-to-do-it manual / Steven J. Miller. n.p.: New York : Neal-Schuman Publishers, c2011., 2011. University of Alabama Libraries’ Classic Catalog, EBSCOhost (accessed March 11, 2014).

But wait...there's so much more

A little help from Organization Monkey for this entry.

Marie Kennedy, http://orgmonkey.net/?p=266, Jul 13, 2008

One of the real eye-openers for me as part of the SLIS Program at the University of Alabama, and through my LS 566 Metadata class, has been a recognition of the incredible opportunities that await library and information professionals in the Digital Age. Digital archives and records repositories, online libraries, digital image and music collections...the needs for information organization in the online environment are countless. Understanding the principles of information description, and being able to apply them, whether it be to a traditional OPAC catalog, or to any variety of metadata formats, will only become more useful as more and more information migrates into exclusively digital forms. Now, trying to make sure that people see the value in bringing human organization to all that data, and trying to dispel the archaic notion that librarian=person behind desk in building...well, that's another matter.

Metadata Games

There's no question that metadata is around us wherever we go in the digital world. Whether it is the personal information that notes our virtual journey to a site, the administrative metadata embedded onto a webpage, or the descriptive metadata that tells us about a selected informational object, we are adrift in a sea of metadata. Now, it is even there for us when we're ready to unwind and do something fun, in the form of Metadata Games. The product of cooperative efforts from organizations including Dartmouth College's Tiltfactor Game Laboratory, the National Endowment for the Humanities, and the American Council of Learned Societies, Metadata Games provides aspiring metadata creators and taggers the opportunity to help construct real metadata descriptions for real digitally archived material in the form of several pieces of interactive software. By drawing on the elements of crowd-sourcing and mobile gaming, Metadata Games seeks to use the population-at-large to solve the problem of description-less digital collections. It is definitely an interesting idea, though questions about ensuring traditional descriptive practices such as specific-entry and controlled vocabulary certainly abound.

Guidelines for Metadata Creation

Being responsible for metadata creation can be a bit daunting at times, even if many of us are involved in the practice on an almost daily basis. I suppose much of that depends on the context, as when we're doing it during our daily work tasks, or in the comfort of our homes, it's part of an intuitive routine, while as part of a class assignment, it is something that you are definitely going to be assessed on, and you have to make sure it is done correctly. Since practices and requirements for creating metadata can vary wildly from situation to situation, it's good to have some solid guidelines to refer back to every now and again.

My LS 566 classmate, Tamara, recently blogged about some "Practical Principles for Metadata Creation and Maintenance," as passed on by the J. Paul Getty Trust. Though the emphasis of the guidelines seem geared more toward institutional and corporate metadata creation, there is still insight to be gained for all types of metadata creators, and they are definitely worth a look as we begin to approach our imaging project.

Choosing a Digital Repository

In addition to the Digital Imaging project talked about over the last few blogs, I will also be responsible for the presentation of a digital repository in my LS 566 Metadata class. Now there are a ton of really great digital repositories out there across the web, covering a wide variety of subject matter, and differing greatly in the manner in which images are presented and described, so the task of choosing just one can be a little bit overwhelming. Also a consideration is the requirements for our presentation, which include identifying information such as: the metadata schema and content standards utilized, any digitization standards noted, and features like whether the metadata records are included in any online catalogs or aggregators. This means that any "ideal" choice for this assignment will probably include quite a bit of detailed, "under-the-hood" type information on the site itself, or at least be prominent enough that those characteristics would be mentioned by any outside sources discussing the site. So how to go about choosing?

With the aid of a few links from our professor, I was off in search of a good digital image repository. As someone who has an avid interest in history, I was hoping to find something with a distinctly historical bent, maybe with pictures from the Civil War, or a similar era. After a few keyword searches, though, I came up with a collection that sounded fairly intriguing, housing a variety of governmental posters from World War II. The World War II Poster Collection from the Government and Geographic Information and Data Services Department at the Northwestern University Library (isn't that a mouthful?) is a digital collection of over 300 posters issued by various governmental agencies during the period of the second World War that were intended to help maintain the morale and resolve of the American people during that great conflict. I always find it interesting to see the values and priorities that were emphasized in documents from the past, so the process of browsing through this repository has been an interesting experience so far. Also interesting, from a library and information studies perspective, is the integration of the collection's records with the cataloging systems of both Northwestern University, as well as OCLC. Taking a closer look at the mechanics underlying these records, and the makeup of the repository, will be a big part of my assignment going forward, and I will be sure to post my progress in this direction.

If you've never taken a look at World War II posters before, they are definitely an interesting part of Americana, so take a few minutes to browse if you get a chance.

On Subject Description: "Ofness and Aboutness"

One of the major challenges that catalogers and metadata creators confront in subject description is in identifying the intended meaning behind the object being examined. While many books, images, and recordings are relatively straight-forward in the themes and topics they explore, there are also many instances in which the intended meaning of the object is distinctly different that its superficial characteristics. George Orwell's Animal Farm, for instance, is superficially the tale of animal interaction on a fictional farm, though the meaning behind this story is a satire and critique of the Russian Revolution and the totalitarianism of the Soviet Union. In the cataloging and metadata world, these distinctions represent the difference between the "ofness" of a work, and the "aboutness" of a work. Being able to identify both is a key component in ensuring that a bibliographic item is correctly described.

For a slightly different look at this topic, check out this recent post from one of my LS 566 classmates, which examines "ofness" and "aboutness" in the context of a Pablo Picasso painting, as well as some links providing a bit more insight into the subject.

Looking at my assigned Dublin Core elements

Date, Creator, Contributor...these will be the Dublin Core elements that my two groupmates and I will be responsible for as part of our LS 566-Metadata digital imaging assignment. It's a pretty interesting grouping, being fairly straight-forward in the type of information being inputted-there's not a huge amount of room for interpretation as opposed to something like the Subject field. Nevertheless, these are some fields where consistency in data entry will be supremely important, as the lack of uniform dating, or author names, for instance, can really wreak havoc for users of the collection. As part of our first task for the assignment, my group was asked to look at the three elements and to discern whether they would be appropriate, or necessary, for the needs of the collection being described. I've included my brief thoughts below.

Date (Art Images)-This is the element I am personally responsible for, and one that I discussed in a little more depth during an earlier blog post. Date would seem to be an essential metadata element for nearly any collection, and is likely to have multiple uses in the description of digital art images, including: item creation date and the date of digitization, as well as the copyright date. The foremost considerations for using the Date element will be the use of a consistent format for date entries, and the question of how the dates can be best associated with the information they represent. The use of qualifiers or refinements, where possible, should significantly help with the latter.

Creator (Football Images)-The Creator element represents the individual or corporate entity responsible for the creation of the item being described, such as the: author, photographer, or artist. This would also seem to be an obvious element to be utilized in the description of digital images, so long as the specific photographer(s) are known. As with Date, the issue of controlling entry terms to ensure consistency will be one of the important considerations when working with the element. Determining a standard order by which Creator names will be inputted would go a long way toward easing our work with this element.

Contributor (Football Images)-My group struggled with trying to determine the relevance of this element to our project. Commonly used for persons or entities such as illustrators, translators, or anyone responsible for adding to the content being described, Contributor may not be needed when dealing with this collection of digital photographs. It is possible that a person responsible for graphically editing the content of the photos, or perhaps their digitization, could be listed under this element, if their identity is known.

So there is a brief rundown if what I will be working on for the digital imaging project. It should be an interesting experience, and I'm especially looking forward to looking at using some elements that will be requiring a bit of authority control in their entry. Looking forward to hearing about how the rest of the class feels about their assigned elements.

Dublin Core: Format

Having officially submitted my ranked list of Dublin Core elements to our professor for assignment, I was more than a little surprised about some of the less obvious ones that managed to squirm their way up toward the top of my list. Date, as I discussed last blog, ended up being my first choice, but the equally unexpected Format element did not follow too far behind. Now when you normally hear the word "format" in the Digital Age, the idea of specific types of computer files is probably something that comes to mind - Word documents, Powerpoint presentations, mp3s, mpegs, and jpegs all being notable examples we encounter daily. It's a safe bet that a Format element is likely to include this type of technical information, but as I discovered, it also goes beyond that in its task of helping to describe the nature of an informational resource.

The Dublin Core Format element aids metadata creators in providing a location for the specific physical and digital qualities an information resource to be described. For digital items, this includes details such as: file formats, programming languages, file sizes, digital dimensions (i.e. resolution), and encoding standards. When describing physical materials, Format would similarly describe information such as: physical dimensions, duration, and the specific medium carrying the resource (i.e. audio cassette, 35mm photograph). Like many of the Dublin Core elements, Format also has several refinements, or qualifiers, that can enable a greater specificity in the level of description, including: IMT (Internet Media Type), Extent, and Medium.

While this type of description may seem to be more on the mundane side than something like the Subject tag, it nevertheless still plays a vital role in the information that it conveys to users. Knowledge of specific file formats or encoding standards, for example, can alert users to the need for certain types of software in order to access the desired information resource. Description of the physical extent or medium for an item can similarly help a user decide whether a specific information object adequately fits criteria they are looking for. Format is thus a fairly integral aspect of describing both digital and physical materials, and an intriguing possibility to work with.

Dublin Core: Date

As I'm going about trying to order the DC elements I would like to work with, it is interesting to see some of the complexity, and problems, with elements that would appear to be fairly straight-forward and simple. Take the Date element for instance...not a real difficult item to wrap your head around, right? Just put the copyright date or something? Well, no, it's not quite THAT simple. Dublin Core actually allows several qualifiers to be used in conjunction with Date, such as: Created, Valid, Available, Issued, and Modified, in order to modify the type of temporal information that can be entered in a metadata record. Thus, you can use DateIssued for something like the publication year for a work, or DateCreated for when an electronic document was first generated if needing more specificity than the general Date element can provide.

Another consideration for the entry of date information includes the exact format or sequence with which it is entered into a record. For example, today's date can be described:

February 23, 2014

February 23, '14

Feb 23, 2014

23 February, 2014

2/23/14

2/23/2014

23/2/14

23/2/2014

2-23-14

2.23.14

And that just scratches the surface of variations possible, not to mention factoring in foreign languages. So which format does a metadata creator use to ensure that the date is adequately understood by potential users? Accounting for regional differences in date presentation, and the fact that computers can't even interpret some of the variations, there is no perfect solution. The W3CDTF encoding scheme is one possible solution, and prescribes the use of the YYYY-MM-DD format for single dates. Whichever method is settled upon by the metadata creator, however, the importance of consistency in date entry can not be overstated. 

What Dublin Core element would YOU like to work with?

Our digital imaging project has been assigned, and we've got Dublin Core elements spinning around in our head. But what to choose, what to choose?

Like many of my LS 566 classmates, I'm currently trying to figure out how to make some sense out of ranking the 15 Dublin Core elements in order of preference to work with for our big semester project. A whole Dublin Core element all to myself, should be easy right? Pick the easy one you dolt! Well, some of them are theoretically simpler than others, but they all have their wrinkles and quirks, and I don't foresee any one path carrying significantly less work than any other...not that that is a great way of going about choosing to begin with.

So, what do we have to work with here...I know I left a list of Dublin Core elements lying around here somewhere.

Voila!:

-Title

-Creator

-Subject

-Description

-Publisher

-Contributor

-Date

-Type

-Format

-Identifier

-Source

-Language

-Relation

-Coverage

-Rights

If I'm going to be spending a lot of time on this project, and I have no reason to suspect I won't, then I might as well get my money's worth and pick something I'm actually interested in working with. Subject is an obvious choice, right off the bat, as I have enjoyed subject description in the past, and am always fascinated with trying to figure out what an item is about. Perhaps I can bring some elements of controlled vocabulary to it as well?

Title is pretty straightforward, but when dealing with items that don't necessarily have an already-defined title, it posits the chance of complications.

Creator...oooo, there's another one where some possibility of vocabulary control exists.

Lot of tough choices ahead, but I'm sure there will be some extremely valuable experience going along with any element I ultimately get assigned. What would you pick?

On the importance of subject description

In my last blog, I touched a little bit on some of the basic differences between keyword and subject searches. For the library field, the notions of controlled vocabulary and subject headings have been under scrutiny and debate for some time, owing to the proliferation of natural language searching and the still-present difficulty in helping users understand how to properly use a catalog subject search. Two articles I recently encountered for my cataloging class break down some of the reasons why subject headings retain an important place in the library catalog, and suggest what part they might still play in the growing digital information world.

The first article, by Arlene Taylor and Tina Gross, entitled, “What Have We Got to Lose? The Effect of Controlled Vocabulary on Keyword Searching Results,” points to the important role that subject headings and subject searches play in facilitating retrieval of relevant resources for catalog users. Subject headings not only provide a controlled method for searching, but also function indirectly through showing up via keyword searches. According to the study done by Taylor and Gross, if the subject entry were to be eliminated from the catalog, or withdrawn from keyword searches, approximately one-third of related resources would fail to provide hits. This is a significant number of items that would elude the user’s search. Additionally, since the terms in question are located in the subject field, they are more likely to provide quality resources as relate to the user’s search of terms found in, say, the summary field, or table of contents (which are sometimes entered into a record). This isn’t to completely discard keyword searching, however. Users appear to have difficulty understanding how to search for controlled-vocabulary subjects, at times, or may not know exactly which terms to utilize for a given search. As keyword searches are easier, in some ways, to understand, they are sometimes preferred by users. So it is not so much a matter of choosing keyword searches or controlled vocabulary searches, rather it is ensuring that we infuse the precision of the latter into the usability of the former.

In “On the Subject of Subjects,” Arlene Taylor further advocates for the importance of utilizing subject headings and controlled vocabularies, as well as extending their use into the electronic domain and the Internet. Taylor points out that despite the pre-eminence of keyword searches for use by Internet users, keywords continue to be a poor option where precision of search results are desired. Not only does controlled vocabulary counteract this through the notion of specific entry, but it also serves to increase the possible search parameters for a user through the relating of broader and narrower terms for a subject, as well as synonyms, near synonyms, and other valid variations. Controlled, subject-based description does is not without its faults, however. Taylor expresses that there is certainly a place for keyword-based techniques, owing to their simplicity, lower cost to create, ease of maintenance (automated), and ability to stay current. What is advocated for the digital environment is a system in which less important, ephemeral resources can be indexed automatically using keyword-technologies, while those intended for long-term use can fall under controlled vocabulary systems. 

It is interesting to note that since the latter article’s publication almost 20 years ago, subject-based vocabulary control does not seem to have taken a strong foothold in the online environment, and likely for very obvious reasons - cost, speed, currency, and the ability to automate. While resources such as WorldCat and the Digital Public Library of America, among others, show the possibilities that online, linked resources can accomplish with controlled vocabularies, the world of digital information in general exhibits a pretty low degree of accurate description, much to the chagrin of searchers and their millions upon millions of hits. Is there a better way? Surely now that Pandora's box has been ripped open, it will be all but impossible to stuff it back in.

-Gross, T, and AG Taylor. n.d. "What have we got to lose? The effect of controlled vocabulary on keyword searching results." College & Research Libraries 66, no. 3: 212-230. Social Sciences Citation Index, EBSCOhost (accessed February 18, 2014).

-Taylor, Arlene G., 1941-. 1995. "On the subject of subjects." Journal Of Academic Librarianship 21, 484-491. Education Full Text (H.W. Wilson), EBSCOhost (accessed February 18, 2014).

Keyword versus Subject Searching

One of the major differences between a controlled metadata system like a library catalog, and the search engines that we utilize every day on the internet, is the way in which subject metadata is created, indexed, and searched for. A library catalog, for instance, runs on the idea of a controlled vocabulary, whereby items are allocated pre-defined subject headings by human catalogers (e.g. History--Byzantine Empire). This gives the item a fairly detailed and accurate description, and facilitates the reliable search and retrieval of information resources that library users are familiar with. Search engines, on the other hand, largely rely on automated indexing, and utilize a keyword, or natural language, style of search (e.g. "What year did Jesse Owens win his gold medals?"). The difference between the two systems is fairly well reflected in the results one will see for a typical internet search - millions of hits, and the retrieval of an extraordinary amount of web sites that have absolutely no relevance to the original search...oh, and don't forget porn sites. This blog entry isn't to make a claim in favor of one or the other, for it is a gross simplification. Both controlled vocabulary, subject-based searches, as well as keyword natural language types have their role in the metadata world, and their relative strengths and weaknesses.

If the differences between keyword and subject searches are new to you, the George Mason University Libraries provides a fairly helpful guide that notes the differences between the two search methods, and the instances in which each should be used. While the information pertains mostly to the use keyword and subject searches in a library catalog, they can be equally applied to online resources, discovery services, and search engines.  There is also a brief, but helpful, section on how to use Boolean operators (AND, OR, NOT, etc...) to get the most out of complex searches. Searching may seem to be a very basic skill, but there are actually quite a few tricks that are useful for those looking to spend more time reading relevant articles and pages, and less time browsing pages upon pages of irrelevant search results. With more and more information resources moving into the digital environment, the ability to quickly and efficiently search for specific items will only become more valuable.

Digital Public Library

A classmate of mine posted a recent blog discussing the Digital Public Library of America, or DPLA. Though I'd seen the DPLA referenced here and there in articles read for other classes, I never really took the time to check it out until now. Having now rectified that oversight, I can say that the DPLA looks to be a fantastic resource, combining some of the best elements one would expect to see in an online library: picture galleries, archival collections, and, of course, a vast number of digitized books from some of the more noteworthy institutions across the United States. Additionally, the DPLA boasts features that give the collection a distinctly modern and digital flavor: apps, games, virtual bookshelves, discovery services, and yes, even a way to make historical Lolcats.

One area that is of particular interest in scanning the DPLA is viewing the way that item records and metadata are utilized. While books, electronic documents, archival resources, and visual media all are normally described using different standards and protocols, the DPLA brings all its resources under a unified internal metadata schema. Unlike some other schema, however, DPLA's also appears to integrate a number of controlled vocabularies and thesauri, which means that the system retains some of the precision in search and retrieval that one would expect to find in other vocabulary-controlled systems, like a library catalog. Though undoubtedly far from perfect, I think the DPLA represents some interesting possibilities for the potential of library-type collections in an online environment, bringing together some of the structured, organized, and controlled features of library collections, with the vast amount of information and interactivity available in the digital world.

The Ins and Outs of File Naming

While metadata can often come in forms that are increasingly technical and complicated, there are also many forms that are simple to use and understand, and encountered by many of us on an almost daily basis. However, even simplicity and accessibility provide no guarantee that metadata will be used properly, as is evidenced by a form of metadata we are almost all familiar with, and commonly misuse...electronic file names. Rather than take full advantage of this gem of an organizational, and retrieval, tool for our computers and devices, we instead clog up document folders with endless batches of "Untitled" documents, and incredibly useful file descriptions such as "receipt", "Agenda," or "list." If you, like me, have failed to show adequate appreciation for this easy-to-use metadata tool, then take heart that the State Library of North Carolina has come to rescue us with a series of four short videos on File Naming Guidelines.

The SLNC covers a variety of basic topics related to file naming, including: why it is important, how to alter existing file names, and some best practices to follow, as well as some to avoid. Though some of the information is fairly intuitive and already familiar to users, the videos do provide suggestions and warnings that otherwise may not have been considered. For example, failing to create unique file names for automatically-named files (i.e. digital photos uploaded from a camera) could lead to important files or documents being overwritten and lost, though most modern operating systems have some measure of protection against such an eventuality. Also of interest are the suggestions for characters to avoid in creating file names, including: most special characters (e.g. !, ?, /, $, and the like due to their use in programming languages), spaces (the underscore special character is an acceptable alternative), and capital letters (software often makes no distinction between case). Among the best practices I found most helpful was the recommendation to include a consistently formatted date in file names, which can provide valuable context when searching through old files.

Though not discussed in the videos, I feel that the guidelines provided would also be particularly useful to organizations concerned with long-term preservation, or storage, of electronic files. Naming practices have a considerable impact on the ability of an archivist or records custodian to make sense of the original use, function, organization, and order of electronic documents. Absent a logical and consistent naming scheme, attempts to organize the documents into a meaningful collection can be severely compromised.