Identifier Element

Have been a member of her team, I knew Identifier was in good hands. The format of the Identifier was clear and concise allowing for a descriptive and unique string for each image. The string was easy to create and indexing was done without any problems.

Excellent job, Jessica!

Format Element

As a fellow member of Team Jessica, I had absolute faith that Jessica would produce an excellent set of guidelines for her Format element. Adding this element was as easy as 10 right clicks, viewing properties, and then going to town on the format drop down in Omeka.

Good job, Jessica!

Description Element

Gregg had a difficult guideline to write but I think he knocked it out of the park. The examples he used provided me with a great template of what information I needed to include and what I should avoid. It was time consuming, perhaps equal to the other elements I’ve done so far combined, but that is to be expected. Each image is unique so a new narrative must be created each time. What would’ve made the description a little bit easier is if Ole Miss had an organized roster from the 1975 season posted somewhere. After a lot of searching I was unable to find it so the descriptions of their players had to go by number only.

My previous post on my blog is something that I hope helps my fellow classmates. It certainly made my descriptions of the Alabama-Texas game much better. I want to give a shout out to Gregg for doing a great job with his guideline.

Handy Resource for Indexing

Due to the character constraints of Twitter, I decided to post this here. I found a link to the stat sheet from the 2010 National Championship Game, which is going to help you identify which play is seen in your images. Jules was commenting on how frustrating it is that multiple people have the same number on the roster. So which #4 for University of Texas is seen trying to tackle Mark Ingram? Well that’d be Aaron Williams, the sophomore DB, as the other #4s, both Freshman, are not listed on the stat sheet indicating they likely did not play in that game.

Link: http://www.sports-reference.com/cfb/boxscores/2010-01-07-alabama.html

Link for 1975 season (wasn’t as useful for me because Ole Miss didn’t bother to make their 1975 roster public it seems): http://www.sports-reference.com/cfb/conferences/sec/1975.html

Hope this helps!

Date.Modified Element

I entered the Date.Created and Date.Modified elements back to back. Perhaps I should explain my process better to make that statement make sense. My indexing workflow was done element by element, adding the information into a field then moving on to the next image to add that same information into that record. In other words, I entered the Date.Created and Date.Modified into a record and then did so for my next image. The Date.Modified instructions were clear and I was able to get through this without issue. There are no improvements that could be made to the guidelines, without rebelling against the Dublin Core governing body.

Nicely done, Hali!

Date.Created Element

The guidelines for the Date.Created element were easy to follow. I located the information without trouble and entered it using the correct format. If I were to make a complaint it would be using a European style date format, but I’d have to take that up with Dublin Core, not the classmate teaching me how to enter this element.

Thanks, Kate!

Coverage.Spatial

The guidelines for the Coverage.Spatial element were detailed and helpful. I didn’t have any issues at all using them and I completed the Map & Dublin Core sections fairly quickly. I appreciated the links on the guidelines to the 1975 Alabama season Wikipedia page; it made for easy address searching. If I were to make a suggestion, I would have added the link to the 2010 National Championship game or the Rose Bowl Wikipedia. However, I don’t think it is a necessary addition, having to click a few more times to find the Rose Bowl address is very much a 1st World Problem.

Good job, Charity! Thanks for making this easy.

Image Indexing

I think I may do a series of short posts about my experience/thoughts on describing each element. I certainly don’t want to give offense with any criticism but if I give feedback maybe the next set of students taking Metadata will be able to find my blog and get some useful advice? Who knows. It would certainly be embarrassing if I said something like “Oh this element guide was super easy” and it turns out I did it all incorrectly. This series of posts could make me look like a fool, but I think it could be a good exercise so I’ll do it anyway.

Item Relation Answer

Debey sent me a tweet and posted on my element’s wiki page asking for some clarification regarding what she needs to put in the Item ID to create these relations. Twitter is limited in character space and it is going to be easier to use graphics to illustrate what I’m talking about. To clarify, I’m not picking on Debey by citing her question here; I am grateful to be asked. Maybe this will help more classmates who haven’t gotten this far in the indexing assignment. At the very least, it is one less topic I have to brainstorm to come up with.

I have been doing a poor job of checking twitter the past two weeks so if you need to ask me for clarification please email me or check the TENacious cohort’s Facebook group. But I’ll try to check Twitter daily leading up to next Thursday.

On to the graphic and explanation.

The blue arrow is the item ID for the record I am currently editing. The item ID for this item is actually just 77. It isn’t #77, Item #77, or Item 77; it is just the number 77. It took some experimenting to find this out, believe you me.

The red arrow is where I entered the item number for 77’s two relations, 76 & 78.

The brown(?) arrow, or whatever the hell color I picked, is where you select “play-sequence”.

Relation Arrows