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.
Tuesday, April 8, 2014
Wednesday, April 2, 2014
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.
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.
Tuesday, April 1, 2014
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?
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.
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.
Sunday, March 30, 2014
(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.
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.
Wednesday, March 26, 2014
(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.
Monday, March 24, 2014
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.
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.
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.
Subscribe to:
Posts (Atom)