Showing posts with label class project. Show all posts
Showing posts with label class project. Show all posts

Sunday, April 26, 2015

Forward or lateral? A question about passing

I think I'm basically done with my photos, but I still have one where I'm not sure about the subjects. This photo shows the quarterback (Todd, 14) passing the ball, but I am unable to tell whether it's a forward pass or a lateral.  There just isn't enough information in the picture--mainly because it doesn't show who is receiving the pass.

All I've got is the QB passing to somebody while offensive players run toward him and another player defends him.  Another Alabama player is on the ground off to the left.  The news story says that Todd had the ball more than once in some of the scoring drives, so I can't assume this is the first pass of the play. It's not part of a sequence, so I can't get context there, either, though based on the numbering sequence, it's probably this play in the 3rd quarter where Todd passes twice:

"Todd passed for 10 yards to Brown to the Tennessee 28, Calvin Culliver ran five yards, Todd ran nine to the 12, Taylor ran six to the four. Alabama was penalized five yards, and Todd scored from the nine." (Tuscaloosa News, Oct. 19, 1975)

Generic "passing" isn't one of the subject choices, so I have to either choose "lateral" or "forward pass" or leave it out entirely.  Leaving it out doesn't seem right since the subject of the picture is obviously some kind of passing, so I've chosen "lateral" basically because the players are kind of spread out, so I think it's not a "line of scrimmage" situation.  I'm not totally comfortable with my choice, though.

Christy's subject descriptions are awesome (thank you for providing those, Christy!), but they aren't enough to help me sort out this photo. Could someone look at it and tell me what you think on the lateral vs. forward situation?

http://omeka.slis.ua.edu/ls566-spring2015/alabama-football-images/admin/items/show/id/26

Figuring out what's going on in those photos

So, I think I have all my images pretty much figured out and described.  (Anyone who actually knows anything about football is totally welcome to check out my descriptions and send me feedback if I misidentified anything. I know everyone's busy finishing up, so big thanks in advance if anyone does this.)

The biggest help by far for me was reading the newspaper articles.  People with actual knowledge of the game describe the major plays in a way that makes it possible not only to understand what went on in the game, but also to actually match the photos to specific plays.  It's super helpful to learn, for example, that a certain player was only on the field in the second half of the game, that a specific scoring drive was dominated by certain players, or the yard line where a play ended.

One Tuscaloosa News article described a play like this:  "Davis had the big play in the drive, running 31 yards to the Tennessee nine. Davis broke over guard, raced to the left sideline, and dragged Tennessee players along the way." Lo and behold, one of my photo sequences shows Davis racing along the very edge of the field, pursued by Tennessee players in what is obviously a huge run; the background shows that it was significant yardage and the entry tunnel in the background of the first photo places it at either the Tennessee 40 or the Alabama 35, based on photos of Legion Field.  I'm fairly confident from this that I've identified the exact play shown in this photo.

One more hint for the old newspapers:  they're scanned from microfilm, so sometimes the pages are sideways.  I zoomed in as far as I could, then used the Windows snipping tool (though any screenshot tool will work) to grab images of the articles, pasted them into Word and then rotated them 90 degrees.  End result:  readable articles.

Here's a list of useful links for anyone still trying to identify plays:



Saturday, April 18, 2015

Omeka delete worries: how to make a quick backup

This is in response to Becca's post about Omeka's incredibly user-unfriendly delete button.  First, ouch, Becca, I'm sorry you had to re-do your work.  I've been afraid of accidentally clicking that delete button from the start, but I had no idea it wouldn't even offer a "cancel" or "are you sure" choice.  However, Becca's experience has prompted me to look for a back-up plan so I don't have to re-do all my work if I accidentally hit delete.  And it turns out there IS a way!  So I'm sharing it with everyone so we can give ourselves a fighting chance against Omeka.

Directions for backing up your work:

  1. Log in to Omeka.
  2. Click on Collections in the left-hand sidebar.
  3. Locate your collection and click on the number to the far right (Total number of items).
  4. At the bottom of the page, click dcmes-xml.
  5. It will download a file.  
  6. Open this file in Notepad and save as text.  It's messy but all the information is there and it will give you something to copy and paste from.
  7. Alternative:  If you have Notepad++ installed, you can right click on the file and "Edit in Notepad++" which is a little bit easier to read.
I don't see a way to load this back into Omeka, but at least you can copy/paste all your data. 
Is it perfect? No. Is it better than starting from scratch?  Yes!

Click here to download your file.

View the XML using Notepad++

Here's what it looks like in plain Notepad.  Messy but serviceable!

Sunday, April 12, 2015

The real McCoy?

So I'm working my way through indexing my 2009 images and find I have some that include Texas player number 12.  The roster at http://www.cfbstats.com/2009/team/703/roster.html for Texas for the whole 2009 season shows two players with number 12, Colt McCoy (QB) and Earl Thomas (Safety).  The roster at Rolltide.com lists number 12 as the QB, Colt McCoy, and Earl Thomas as 1D.  My extremely shaky understanding of the rules suggests to me that if I see number 12 in a photo, it will be McCoy, and Thomas would be assigned a different number for the game ("1D" is a just a mystery).

However, in my photo series MFB_Texas09_KG01640 through ...1643, number 12 is engaged in tackling-type play, uncharacteristic of a QB.  The jersey name is completely obscured.  I checked some of the other photos from this game that are in classmates' collections, and there is at least one shot displaying number 12 with the name showing very clearly:  Thomas.  Therefore, I'm going with Thomas, Earl (Texas) for my player name for number 12.

I'm satisfied with my identification here, especially now that I've looked up actual photos of the two players, but totally confused now on the player number and name thing.  Can anyone give me some good hints on how I'm supposed to know which player I'm looking at if I have only a jersey number and I can't trust the roster?  Also, does anyone have a picture of Colt McCoy in your photo group?  If so, what's his jersey number?

Saturday, April 11, 2015

Thoughts on the final version of the Rights element

I originally viewed the Rights element purely in the context of basic Dublin Core. However, it turned out that Omeka could handle extended versions of the element.  This meant that the project could make use of the following choices:
  • Rights: Simple Dublin Core
  • Rights Holder: "A person or organization owning or managing rights over the resource.
  • Access Rights: "Information about who can access the resource or an indication of its security status. Access Rights may include information regarding access or restrictions based on privacy, security, or other policies."
I considered the possible benefits of using the extended elements and checked to see what my own library and others have done in the context of the Online Archive of California. In the end, though, I decided that the rights situation of these images is best expressed through one simple statement, residing in the basic Rights element. This will help to ensure that the rights information comes through cleanly if the images are harvested or migrated to a different system and leaves the details regarding licensing and permission to be worked out by direct communication between the would-be user and the Bryant Museum.  It also allows for use of the Simple Vocab feature in Omeka, so data entry will be quick, easy, and uniform.

This is what I proposed for the Rights element (just approved by Dr. MacCall, hooray!):

1. Use the basic Rights element.
2. Simple vocab:  All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing by contacting the Paul W. Bryant Museum (http://bryantmuseum.com/).

Even though the link doesn't actually link, I thought it would be good to have it in there so users could just copy and paste it (or highlight and click "go to ...").  I chose the base URL rather than the contact page, as that is probably the least likely to change.

Wednesday, April 8, 2015

Can the Rights element be optional?

Dr. MacCall posed the following question in a comment on my previous post about the Rights element:  "One last question? In what circumstances would this element be optional?"

Obviously, in one sense the answer is "anytime someone wants it to be--this is Dublin Core, so naturally it's optional," but that doesn't really get to the heart of the question, which is really "when might it be appropriate or acceptable for this element to be absent?"

The Dublin Core Metadata Initiative has this to say:  "If the rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource." Based on this, I can think of various circumstances where one might leave it out:

  1. Content that will never be made public.  However, in this circumstance someone still holds the rights. This element might also be a good place for a statement clarifying why the content must remain private.  If the content is merely embargoed, even if it's for a period of decades, that, too, is related to rights management and would be appropriately noted in Rights.
  2. Content where the rights are in dispute.  It is understandable that a library would not want to take sides or state inaccurate information about this content.  However, rather than leaving it blank, it might be better to simply state "Rights under review" so that anyone wanting to use the image would not either assume it is freely available or expect to be able to license the rights easily.
  3. Orphan works.  In the case of works where it can be assumed that copyright applies but the rightsholder is impossible to identify or contact, it would seem simplest to just leave off the rights information.  However, that does no favors to would-be users. Better to state that the item is an orphan work or use a phrase like "additional research required."
  4. Content where the rights are unknown.  Again there would be the temptation to simply say nothing, but again it would be better to warn users that the rights situation is murky.  "Usage rights undetermined; users are advised to conduct further research" might work in this case.
  5. Open access content.  There is a temptation here to think that there are no rights to worry about. However, even open access content frequently comes with restrictions related to attribution or non-commercial use that should be firmly stated.
  6. Freely available or public domain content.  You could probably leave off the rights statement here, but why make your users do the copyright math or guess at the status when you could just tell them?
  7. A rushed or understaffed project, or cases where content has been migrated from a different system.  In this situation, it might be acceptable to not have the Rights information listed immediately.  However, it would still be important to make addition of that element part of a planned later phase of the project.
  8. The exact same rights information applies to everything in the library.  In this case, the digital library could probably get away with a blanket rights statement that is prominently displayed. However, the moment the content is harvested into another system, that blanket statement is lost.  A further problem could be a blanket statement on the front page that doesn't show on individual pages, so users coming directly to a content page from a search engine wouldn't see it.
To me, the Rights element has two important purposes.  One is to help protect the rightsholder from infringing uses of their content.  The other is to inform the user of the rights status of the content and, if possible, make it easy for them to request permission to use it.  By always clearly explaining the intellectual property rights of items in digital collections, even if that status is unknown, libraries can help make their patrons aware that not all content is freely available to use in any way they like, and guide them toward ethical habits of use.  The constant reminder also serves to highlight the issue of copyright extensions and how changes in the law can have a real effect on how everyone is allowed to use and re-use creative content.

In the end, although I can think of lots of situations in which the Rights element could be left out, but none in which it doesn't seem to me that it would be better to have it in there.  However, perhaps I am overthinking this and there is an obvious situation I'm overlooking.  What does everyone else think? Dr. MacCall, would you care to weigh in?

Thursday, April 2, 2015

On football familiarity, or lack thereof

Several of us have now confessed to being football-challenged and nervous about being able to do a good job of describing images that just look like a jumble of people in brightly-colored uniforms. I'm in awe of people who can look at an image and somehow divine which team is "offensive" and which is "defensive" and know whether the ball is being thrown, received, or otherwise. I very much appreciate the kind efforts of my fellow classmates to help us out with useful links (shout out to Library Corner for posting those tools!), and I agree with Metadata for Breakfast that there is certainly no guarantee that we'll work with familiar subjects out in the real world, so, yes, it's good experience.

However, I couldn't help wondering if there is a class project that would present a more level playing field (ha!).  What if the project were something that was likely to be quite difficult to everyone? Would intramural ultimate frisbee images from several years ago be hard enough? What about a jai alai image collection? Or maybe we should go in the other direction and have images everyone can understand:  LOLcats.  In fact, I hereby suggest that next year's class, and all classes thereafter, get to use funny cat and dog pictures. Problem solved!



Rights: Your new favorite element

Why will this be your new favorite?  Because as long as the client approves this language, it will be the easiest required element in this project!  I think I've got this down to one statement that you can copy and paste into the "Rights" box for every image.  My only question is whether there should be a second (also easy!) Rights entry with a link to the Museum's contact page.  Dr. MacCall implied in an email that we could just say "by contacting the Paul W. Bryant Museum," but I'm worried that it's not enough.

What do you all think?  Is it enough?  Should we also link to the museum? Is there a significant risk that the museum will someday make changes to its site that break that URL? Is it worse to provide less information up front or to risk having potentially outdated information in our records that we'd have to contend with later (if this was a professional project)?

I'll note here that there is a variation where we just embed the link into the Rights statement. However, when I did this I noticed that the linked text was noticeably lighter than the rest of the statement. I'll paste snips of the two variations below so you can all judge the aesthetics.

Label
Rights

Element Description
This element states the various property rights associated with the resource, including intellectual property rights.

Required?
Yes

Repeatable?
Maybe

Guidelines for Creation of Content
Use the following statement:  
All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing by contacting the Paul W. Bryant Museum.

This is the HTML that could go in the second Rights field:  
<a href="http://bryantmuseum.ua.edu/direction.cfm?dir=contact" target="_blank">Contact the Paul W. Bryant Museum</a>

Examples
All images use the exact wording and HTML code above.

Notes
The Rights statement may be pasted directly into Omeka. To make the second Rights field, you need to paste in the HTML code and check the "Use HTML" box.








Saturday, March 28, 2015

More Thoughts on the Rights Element

The Rights Element is one of the most straightforward of the elements in terms of what it should contain and why it is there.  By definition, it simply "includes a statement about various property rights associated with the resource, including intellectual property rights." Operationally, it establishes who the rightsholder is and frequently offers contact information for prospective users.

I looked over the guidelines linked from our wiki and I think the CARLI version is probably the most straightforward and applicable to our project.  The left side is simply labeled "Rights" and the right side is both non-threatening in tone and clear in its intent and directions.  I particularly like the second example:
All rights held by William Rainey Harper College Archives. For permission to reproduce, distribute, or otherwise use this image, please contact Firstname Lastname at xxx@harpercollege.edu.
Here is an actual example from the Great Lakes Digital Collection (Newberry Library):
Rights All rights reserved by the Newberry Library. Permission to reproduce in any format must be requested in writing. Contact Photoduplication Department, Newberry Library, 60 W. Walton St., Chicago, IL 60610. Phone: 312-255-3566. E-mail: photoduplication@newberry.org
I think this would translate into one simple statement that could be used for every image, something like:
Rights All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing. Contact [appropriate department at UA, phone: ____, email:____ ]
Right now I'm trying to find out what department that will actually be.  Several departments seem to hold licensing rights to images and trademarks:  Office of University Advancement, University Athletics, Hoole Library, even the Office of Archaeological Research. I've requested clarification on ownership from the client.

In the meantime, how is this looking to everyone?  Feedback welcome!

Thursday, March 26, 2015

A Different Kind of Controlled Vocabulary

I read Adam's post about his difficult element, Relation, and it also made me think about some of the other elements that require descriptions that don't necessarily have a straightforward controlled vocabulary to use.  How do you achieve consistency of description while still retaining the freedom that allows those less-controlled elements to serve as a useful complement to the more-controlled elements?

For example, if Subject requires a CV that limits it to specific words and phrases like "Tackling" and "Quarterback sack," description might fill in the gaps with keyword-heavy phrases describing the play in more detail. The job of the Relation element would be to link the images of this play, perhaps from the beginning of an attempted tackle through another player's attempt to block and ending with a successful sack.

As long as all the image catalogers are using basically the same style for these elements, all will be well.  However, if one describer says "Auburn Right Tackle Smith launches himself" and another says "Tiger offensive lineman number 89 attempts sack" while a third says "Auburn player tries to stop Alabama players by using interpretive dance," then it's not as useful.  And I'm going to admit right up front that that third describer is probably me, so I'm concerned about holding up my part of the job when it comes to actually describing these images according to the rules!

That got me to thinking about newspaper and magazine writing, and it occurred to me that they use style guides.  So maybe there's a football writing style guide out there that could help all of us to be consistent yet creative and thorough in our descriptions?  I looked around and there are some possible choices.  Maybe the owners of the more descriptive elements would be kind to the football-challenged among us and consider making a style guide recommended practice for our digital library.  Here are a few examples, but there are probably more out there, or the owners of the appropriate elements might just list some suggested terminology and style:






Sunday, March 15, 2015

Rights Element: Firm but friendly

Now that the Rights Element has safely retained its place on the island, I'm starting to think about what it should contain.  Dr. MacCall made a very interesting point in class, that the Rights Element needs to be carefully balanced.  There's an inherent conflict in placing images in a digital library, available to the world--if we didn't want people to enjoy and use the images, we wouldn't go to the time, effort, and expense of making them available; on the other hand, we have to protect the copyright of the images, the wishes of the rightsholder, and the possible revenue stream use of the images might generate.  Therefore, the language in the Rights Element needs to be firm and clear, yet welcoming.

In thinking about this element, I can see that repeatability probably aids clarity.  A simple copyright statement stands alone, and is clear and neutral. Information for actually contacting the Bryant Museum or the University of Alabama regarding permission is best handled through a link to the contact page for easier maintenance.  But what about that welcoming part?

Tonya helpfully provided a link to the Minnesota Digital Library guidelines in this post, and they are clear and simple.  However, I found their Rights example to be a little off-putting from the user perspective: "This image may not be reproduced for any reason without the express written consent...." It's clear, it's firm, but it's not very friendly. I wonder if it would be better to phrase it more like "Interested in using this image? Express written permission is required for all uses. Please contact ... "

What do you all think?  Is it more important to invite usage or to discourage unauthorized usage? Can both be accomplished?

Thursday, March 5, 2015

The Rights Element connected to the Source Element

(Edited now that I think I have a better grip on Source, "the most ambiguous, misunderstood, and misused of the 15 core elements.")

Last night I was discussing our assigned project elements with my course group, which includes Adam, Amy, and Katie.  I find it interesting how our different elements interact.  In particular, I think my element, Rights, could be related to Katie's element, Source.

Over in her blog, Katie wonders whether Source will be useful for this project, primarily because we don't yet know if all images will have an identifiable source, or if we'll be given more detailed information regarding the original images our images are derived from (our 2009 images were likely born digital, but the images from 1975 would have an original somewhere).  Her question has a lot of bearing on my element, too, because the Rights for each image may be based on whatever rules govern use of the Source.

Our textbook defines the Rights element quite simply as "'Information about rights held in and over the resource' ... [including] intellectual property rights."  Depending on circumstances, the Rights element might hold a very simple statement like "Copyright (c)2009 Paul W. Bryant Museum" but it could also include restrictions on use, such as "Written permission required" or "Noncommercial reuse only."

Importantly, the Rights may vary depending on whether someone wants to use the digital surrogate or needs to use a higher-resolution copy or get access to the original photograph or slide.  Alternatively, the Rights may not vary from original to digital copy, but whatever Rights govern the original may also govern the copy. The Rights element, like many Dublin Core elements, may also contain information pertaining to the original image as well as to the digital version.  In any of these cases, the data in the Source element would help to both clarify and validate the Rights information.