(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).