In the course of indexing football images, there are three particular elements I have difficulty with on a consistent basis. Those three are the Subject, Description, and Title elements. My problems with them all stem from the same root: I know relatively little about football. Unusual, I know, for someone who grew up in the state of Alabama (and who attends the University of Alabama), but it's true nonetheless. I don't really like football. Never could get into it. So where most people who see this image would find something they instantly recognize and can make sense of, the first possible description to pop into my head was: "Both teams pursue as referee holding invisible football attempts escape." Obviously, that's not the correct description. Unfortunately, because of the way the shot is staged, I'm not entirely sure what is. I can identify a number of the players in the image, but I have no idea precisely who the ball-carrier for the play is, beyond a supposition based on the facings of the various players.
Likewise, my first thought for describing this image was "Lucy van Pelt (14, Alabama) fools Charlie Brown (10, Alabama) yet again." With the Subject element of course including Hoaxes, Charles Schultz, and Performance Art.
Admittedly, that probably wasn't as bad as my first idea for a description for this: "Referee scratches his own crotch, both teams panic." The accompanying title being, of course: "Iron Bowl 75 Referee Scratches Crotch, Both Teams Panic."
It doesn't take a genuis to realize that none of these titles, descriptions, or subject identifiers are what the client would want, but beyond the case of the one my impulse suggested a Peanuts reference for, I have little to no clue as to what is actually going on in these images. Like the person who assign a video of a Sprint Cup race at Talladega in the following fashion: "Dozens of men drive in circles on same stretch of road for hours, most refusing to stop for directions," there's a sense in which the description is, technically apt. There is also, as in that case, a much greater sense in which the description is entirely wrong.
In that sense, I was hoping for some help or feedback. Anyone more sports-savvy than I (read: anyone at all) want to offer feedback or suggestions? They would be greatly appreciated. For now, beyond putting up the actual identifications of the relevant players, I'm inclined to leave these alone until I can get help deciphering them. Which, I suppose, makes it an excellent time to try indexing some DePol engravings.
Thursday, May 1, 2014
Further Adventures in Indexing while Editing
While looking at another of my images, it occurred to me that another item was lacking in our guideline for Player Names: specifically, the ability to use identification acquired in related images to serve in an image in which the identification may be made.
The reason I mention it is that this image is clearly the companion-piece to the image I discussed in my last post, occuring moments apart (as confirmed by timestamp). The reason this is relevant to my last post is that in the earlier image in the sequence, a player obscured in the later image is visible, and the helmet the ball carrier (I think? He seems to be the focal point of the images.) had lost is so rotated in the air that his number may be ascertained. As such, I am adding a line to clarify that helmets do not have to currently be on the player's head to be used for identification, should a better source of identification be lacking. I'll also be adding to the guideline that where relational data may be ascertained, identification in any of the related images is sufficient for identification in the others.
The reason I mention it is that this image is clearly the companion-piece to the image I discussed in my last post, occuring moments apart (as confirmed by timestamp). The reason this is relevant to my last post is that in the earlier image in the sequence, a player obscured in the later image is visible, and the helmet the ball carrier (I think? He seems to be the focal point of the images.) had lost is so rotated in the air that his number may be ascertained. As such, I am adding a line to clarify that helmets do not have to currently be on the player's head to be used for identification, should a better source of identification be lacking. I'll also be adding to the guideline that where relational data may be ascertained, identification in any of the related images is sufficient for identification in the others.
More Issues in Indexing: It's Deja Vu All Over Again
For a third instance, the conflict between the Abstract and Description Elements in our repository have left me at something of an impasse. As with the image mentioned in my last post two posts, this image I am indexing leaves something to be desired in terms of identifiable players. Several are identifiable, but a number of the players at the core of the action are problematic. Given how many of my images have this problem thus far, I am inclined to decide that part of the Abstract Element guideline's wording leaves something to be desired. Fortunately for me, I co-administrate that guideline. As such, I can edit it to resolve the problem.
My first thought in this instance was to edit to the guideline, by adding to the notes section, the following:
Additionally, in some instances, because the guidelines for the Description, Title, and Subject elements require key players involved in the action of the image to be identified. In those instances, where a reasonable supposition of an obscured number may be made for a key player (i.e., the ball-carrier or the blocker tackling them), then that supposed number may be used to identify the player.
In such cases, the player's name should be entered in a manner indicating the suppositional nature of the identification. As such, in those cases, the name should be entered as follows:
Last, First (supp.)
That way, users may know the identification is not certain.
However, as we are dealing with metadata content, I realized that would only identify them as an entirely different entity than entering the name the standard way. As such I am removing the section beginning with "In such cases," and just indicating they should identify them as if it were certain.
My first thought in this instance was to edit to the guideline, by adding to the notes section, the following:
Additionally, in some instances, because the guidelines for the Description, Title, and Subject elements require key players involved in the action of the image to be identified. In those instances, where a reasonable supposition of an obscured number may be made for a key player (i.e., the ball-carrier or the blocker tackling them), then that supposed number may be used to identify the player.
In such cases, the player's name should be entered in a manner indicating the suppositional nature of the identification. As such, in those cases, the name should be entered as follows:
Last, First (supp.)
That way, users may know the identification is not certain.
However, as we are dealing with metadata content, I realized that would only identify them as an entirely different entity than entering the name the standard way. As such I am removing the section beginning with "In such cases," and just indicating they should identify them as if it were certain.
More Issues in Indexing: Different Image, Same Problem
Those who've read my previous post will know that I had problems with filling in the description section of one of my images. Unfortunately, I ran into another instance of this same problem in another image I was responsible for indexing. In this case, I can successfully identify a number of the players in the image, but not the ball carrier. His helmet, which would normally present his number, has been knocked free. Similarly, one of the players tackling him is obscured by a teammate.
Issues in Indexing: When Guidelines Contradict
As with everyone in my LS 566 class, I have been working upon indexing a handful each of DePol Engravings and UA Football images. This was going fairly well, up until I read the Guidelines for the Description Element. In particular, the section that gave me pause was this one: "Additionally, the players involved should be included (include the name,
number, and team in parentheses if visible), as well as the action
(punt, pass, interception, etc.) and any relevant contextual information
(down, statistics, importance of the game, etc.). IMPORTANT:
This information will be available in the Abstract section, so make sure
you index the Player Names Element before you index this one!"
That might seem odd, given that it's a sensible set of guidelines to describe an image of a football game. The reason it occurred to me that this could be an issue was that I knew our guidelines for the Abstract element had this line, "Partially covered or covered numbers will make a player unidentifiable and will be excluded from the data entered," in it. The combination of the two mean that in images where no Abstract may be assigned, then neither can a Description.
Upon checking back over the images I was tasked with indexing, I discovered further that I am responsible for just such an image. This image contains two players. The numbers on each player's jersey are obscured. The Auburn player's number is obscured by the fact that he is partially out of frame, while the ball-carrier's number is obscured on the front of his jersey by his hands and on his helmet by the glare of the stadium lights. Given that, by the guidelines-as-written, the only description I can give this 1) require knowledge of football that I lack (I don't know if this is a run, a pass, a kick return or what) and 2) are vague in the extreme. As in, "Alabama player carries ball while referee watches on," vague.
As such, I would be grateful for any help or clarifications that could be offered for this image.
That might seem odd, given that it's a sensible set of guidelines to describe an image of a football game. The reason it occurred to me that this could be an issue was that I knew our guidelines for the Abstract element had this line, "Partially covered or covered numbers will make a player unidentifiable and will be excluded from the data entered," in it. The combination of the two mean that in images where no Abstract may be assigned, then neither can a Description.
Upon checking back over the images I was tasked with indexing, I discovered further that I am responsible for just such an image. This image contains two players. The numbers on each player's jersey are obscured. The Auburn player's number is obscured by the fact that he is partially out of frame, while the ball-carrier's number is obscured on the front of his jersey by his hands and on his helmet by the glare of the stadium lights. Given that, by the guidelines-as-written, the only description I can give this 1) require knowledge of football that I lack (I don't know if this is a run, a pass, a kick return or what) and 2) are vague in the extreme. As in, "Alabama player carries ball while referee watches on," vague.
As such, I would be grateful for any help or clarifications that could be offered for this image.
Wednesday, April 9, 2014
A Tale of Two Explications: SCORM Explanations Past and Present
While reading up on what SCORM was, I noticed that Rustici software's one-minute overview of it had a note in its header signifying that their new SCORM Explained page provided more information. Clicking that link, I found myself taken to a splash page of sorts for their newer explanation. On it, it seemed that the writer took significant efforts to dumb down his previous one-minute overview, adding analogies, a colorful bar graph, and removing virtually all technical language. Whereas the prior overview explained and attempted to clarify far more than the new splash page does, it also provided less detailed technical and business-related information than the company's SCORM Explained page did overall.
Past the splash page, the new page provides information and context about it from a business and technical perspective, as well a glossary of SCORM-related terms. While it is certainly informative, it also lacks the elegance and ease of digestibility of the simple overview presented by the previous page. Within two paragraphs the overview explains that SCORM is a particular way of constructing Learning Management Systems and educational content in order to allow interoperability between SCORM conformant systems. The second says it is the industry standard for this, and then proceeds to present an analogy of DVD format compatibility to explain SCORM's funciton. It follows this up with a red and blue bar graph (simply titled "thegraph") with images of clocks and dollar signs pasted over each bar, indicating content integration's costs before and after SCORM. The graph lists no units, sets no scale whatsoever, and otherwise does nothing to indicate its particulars but its somewhat ham-fisted assertion that: BIG RED BAR BAD! MANY CLOCKS AND DOLLARS COST. SMALL BLUE BAR BETTER. LESS CLOCKS. LESS DOLLARS.
Past the splash page, the new page provides information and context about it from a business and technical perspective, as well a glossary of SCORM-related terms. While it is certainly informative, it also lacks the elegance and ease of digestibility of the simple overview presented by the previous page. Within two paragraphs the overview explains that SCORM is a particular way of constructing Learning Management Systems and educational content in order to allow interoperability between SCORM conformant systems. The second says it is the industry standard for this, and then proceeds to present an analogy of DVD format compatibility to explain SCORM's funciton. It follows this up with a red and blue bar graph (simply titled "thegraph") with images of clocks and dollar signs pasted over each bar, indicating content integration's costs before and after SCORM. The graph lists no units, sets no scale whatsoever, and otherwise does nothing to indicate its particulars but its somewhat ham-fisted assertion that: BIG RED BAR BAD! MANY CLOCKS AND DOLLARS COST. SMALL BLUE BAR BETTER. LESS CLOCKS. LESS DOLLARS.
Works Cited
“One Minute Scorm Overview for Anyone.” SCORM.com. http://scorm.com/scorm-explained/one-minute-scorm-overview/
“Scorm Explained.” SCORM.com. http://scorm.com/scorm-explained/
Educational Objects via digitally-archived articles.
This may be an odd way to open a post, but while reading Norm Friesen's explanation of Educational Objects, I noted something that struck me as quite interesting. Specifically, the version of the document to which we were directed was a copy of the page which had been stored via the electronic archiving efforts of the internet archive's Wayback Machine. I found it fascinating, given the frequency with which scholarly articles are locked behind paywalls and the like, that a publicly available source such as the Wayback Machine would have a copy stored in their records. It makes me curious as to what the copyright entanglements that might crop up as a result of it. Likewise, I wonder if the service's operators had simply worked out an accord in their reproduction of the content.
Moving on from that curiosity, however, I should dig into the meat of the article itself. In it, Friesen examines the definition of an educational object. He begins by citing the Learning Technology Standards Committee's definition: "any entity, digital or non-digital, which can be used, re-used or referenced during technology supported learning." He goes on to point out that such definition is often replaced with a narrower one based upon the sort of programming which granted the concept its name. He proceeds to denote three characteristics of objects:
Moving on from that curiosity, however, I should dig into the meat of the article itself. In it, Friesen examines the definition of an educational object. He begins by citing the Learning Technology Standards Committee's definition: "any entity, digital or non-digital, which can be used, re-used or referenced during technology supported learning." He goes on to point out that such definition is often replaced with a narrower one based upon the sort of programming which granted the concept its name. He proceeds to denote three characteristics of objects:
- Discoverable: able to be discovered, accessed or searched due to the metadata which describes and categorizes it.
- Modular: able to be adapted by outside parties without assistance of its originators, yet nonetheless able to stand on its own.
- Interoperable: in a general sense, workable with a variety of hardware and software. in a specific sense, that of the ability for programs and their components to cooperate and share data.
Work Cited
Friesen, Norm. “What Are Educational Objects?” Interactive Learning Environments 9, no. 3 (Dec. 2001): 1. http://web.archive.org/web/20041015064204/http:/www.careo.org/documents/objects.html (accessed April 9, 2014).
Subscribe to:
Posts (Atom)