Wednesday, August 18, 2010

Skip this if you are not interested in Metadata

Apologies to vegetarians, but to me Metadata is the "meat and bones" of the project. It's not the gravy, the fun artistic part (images, design, etc.) of our online projects, but it sets the structure. As with our accessCeramics project, selecting Metadata for graffiti and street art has been a challenge. If at all possible, we like to ground our Metadata for projects within an approved data standard schema as it adds validity and a type of scholarly seriousness to our decisions (well, almost.) We decided on elements from VRA Core 4.0 that we thought would capture the information we are after without bogging down the students in their field study. Plus, portions of the information will be guess work or simply not available. For example, students may not be able to discern correctly whether a graffiti "throw up" was made with spray paint, permanent markers, etc. And the support structure for graffiti or street art (subway train, wall, sidewalk) is just as intrinsic a part of the art as is the medium in which it is created. We've decided to create one non-VRA Core 4.0 field titled "Support", as we felt it did not fit well under the "Materials" VRA Core 4.0 field. (At least not for our purposes.) The main intent of this project is not to create an online, searchable database. It is an experiment in using mobile devices and social software to collect examples in the field that can then be scrutinized and critiqued for the possible importance of "location" in this style of art. Now that we have decided on the Metadata, Jeremy will add it to a web interface which he will create. He will make a post about that process when he is finished.

Metadata Element Set for LC Graffiti and Street Art Project
Elements chosen from VRA Core 4.0 data standard schema
R = Required field for our project
NR = Non-required field for our project
Work Type (R)
Measurement (R)
Support (R) (non-VRA Core4 Element)
Relation (R)
Technique (NR)
Agent (NR)
Inscription (NR)
sub-element: Location (of inscription)
Subject (NR)
Description (NR)



Monday, August 9, 2010

Storing Metadata on Flickr

A Boy and His Dog, by Julie Martin
One goal we're really shooting for in this project is to have all the image metadata "live" on Flickr. But we want more than the standard metadata Flickr offers with each image (title, description, EXIF data). We want to be able to choose our own metadata schema, or use a standard like VRA Core 4 or Dublin Core. Fortunately Flickr provides the architecture for this in the form of machine tags.

Unlike typical Flickr tags, machine tags have a three part structure, with the format namespace:field=value. The namespace can be thought of as a unifier, or a common element in all images in a collection. And the field=value part is just that: you determine field and add the value.

 To provide an example of how this can work, I decided to make a quick and dirty image collection of the public art around my neighborhood in Lake Oswego, OR. So for about an hour, I rode my bike around town, took pictures of art, and scribbled each work's artist and title in a notepad. I then uploaded the images to Flickr, and "cataloged" them with machine tags (you can enter them on a Flickr image page, just like regular tags). For example, the work in the image above is called "A Boy and His Dog" by the artist Julie Martin. The machine tags look like this:

lakeoswegoart:title="A Boy and His Dog"

lakeoswegoart:artist="Julie Martin"

On the Flickr image page, you can see the tags above by clicking "show machine tags". I chose the namespace "lakeoswegoart" because it hadn't been used in Flickr (you can check here), and I wanted something unique so when I construct the API query, it's limited to Flickr images with machine tags containing the namespace "lakeoswegoart".

So the Lake Oswego public art page I made is pretty basic (here's the source code). First it uses flickr.photos.search to return a result set of images that have a machine tag with the namespace "lakeoswegoart". The thumbnail images are then displayed on the left side. When you click on a thumbnail, the image id of that thumbnail is sent off to a php script (source code), which uses flickr.photos.getInfo to get all the tags of that image. The script parses the xml response from Flickr, reformats the machine tags into a basic "field: value" display, and returns a large image with the metadata to the right side of the main page. But the point is this: everything (images, metadata) lives on Flickr. The little bit of code just pulls it all together.

There are plenty of other ways to make queries on machine tags in Flickr, and we'll cover them in this blog as the project evolves. It should be noted that machine tags are also being used in really interesting ways for semantic web purposes. The music site lastfm provides machine tags for users to tag their images of specific concerts, which are then gathered into their site (in this case the tag is likely a unique identifier in lastfm's database). Thus far we're taking a more "traditional" librarian/visual resources approach to use machine tags to catalog images. Just like with Places, Flickr has provided the infrastructure for projects like this. We (and others) just need to take advantage of it.

Wednesday, August 4, 2010

Flickr Privacy Settings, or Why Aren't the Images Showing Up?!?!?!

Image above: "I Want Privacy!" by bejealousofme
In order to get everyone ready for the field work in New York, Margo gave her students the following assignment:

1. create a Flickr account
2. take a picture of a piece of public art
3. add that image to Flickr, tag it with lcnyc, and map it


In the meantime, I wrote a very basic proof of concept page to grab the images and locations from Flickr, and put them on a Google Map. Nothing too fancy here...just hopefully an opportunity to give the students a sense of where we're headed with the bigger project, and to iron out any wrinkles we stumble upon before the real work starts.

Well, sure enough, we encountered some puzzling situations. A few images that seemingly had been done correctly on Flickr accounts were not showing up on the proof of concept page. After a fair amount of tinkering around, we discovered a few things about Flickr settings that had a direct effect upon whether an image would be included in an API query. In no particular order, here they are:

1. Who can see this photo? - Flickr users can set their images to be viewed by anyone, only people of their choosing (friends and contacts), or only themselves. For unauthenticated API queries, images should be set so that anyone can see them (we knew this already, but figured it was worth mentioning here).

figure 1
2. Is the image hidden from public search? - Just because an image is public doesn't mean it will be included in search results. Users can opt to hide their public images from public searches (figure 1), which can be a problem if you're hoping to retrieve those images in an API or regular query. For our purposes we want images to be both public and available for public searches.




3. How many images does my Flickr account need until my images appear in search results? - OK, this isn't a privacy setting, but was a tricky one nonetheless. In order for images to show up on searches, an account must have at least 5 publicly available/searchable images. Thanks to Kaye Blankenship for finding this in the Flickr FAQ.

figure 2
4. Who will be able to see your stuff on a map? - This was a bit of a stumper for a while...just because you map a public (and public-searchable) image on Flickr doesn't mean that the mapping is public. This can be problematic if you're using any of the "places" API methods (like flickr.places.placesForTags). Coordinates/mapping has its own privacy setting, which Flickr users can set at the point of mapping images (figure 2).



The folks at Flickr are smart for implementing these various privacy settings, as they all serve important purposes. We just have to be aware of them when trying to build digital image collections, and set our images accordingly.