Launch!

From Dumbo neighborhood, NYC. 

At long last we're ready to launch our site. Thanks to everyone who was involved...especially the students who made it happen. In addition, major kudos are due to our interim library director Mark Dahl, our designer extraordinaire Anneliese Dehner, and Bryan Alexander from NITLE who got Margo thinking about using mobile devices in higher education.

Hopefully this experimental project can inspire others to do something similar....what are your ideas for documenting neighborhoods, cities, etc. with images? We're certainly going to take ideas from this experience and apply them to future digital initiatives at Watzek Library.

Please contact me (jeremym@lclark.edu) or Margo (margolou@gmail.com) if you have questions or ideas related to our project.

Project Development Update: Fun with Flickr Places & Google Maps

Taken by Kaye Blankenship
in the Nolita  neighborhood
(Flickr page).

On of our big goals of the project is to have different New York City neighborhood views. This would take advantage of two really useful Flickr API methods:

• flickr.places.getChildrenWithPhotosPublic - this lets us ask the question, "Can you please give us a list of NYC neighborhoods that have photos that meet our conditions?" This is great for building the UI, as we can incorporate this neighborhood list into our site.
• flickr.photos.search - given our neighborhood list, we can now ask, "Can you please give us a list of images from a certain neighborhood that meet our conditions?" This will constitute the foundation for our neighborhood pages.

Speaking of, we have a very rough functional mockup of a neighborhood view here. We'll make it fit into our design framework over the forthcoming weeks. For now, there's one aspect of the mockup that is worth noting.

Mainly, the Google Map markers can serve as navigation: if you were interested in a particular point on the map, you can click the marker, and get the image and metadata in the "large image" area of the page. It's sort of like having enhanced Google Maps info windows. This can work because the Google Maps API and programming is all javascript. It's pretty common to write code so that clicking on a marker will open a window, but it's just as easy to make the clicking initiate some jQuery code (which is also javascript) to use AJAX, manipulate the DOM, etc. So if all you cared about was viewing images based on location, you can do that. This may be a subtle point, but I think it's neat. It's worth noting that clicking on a thumbnail image can serve as navigation as well: the large image and metadata will appear, and the map marker turns green.

So, at this point, we still have a bit to go to reach the finish line. With that said, we're optimistic about where things are headed. As things progress, we'll post more.

Hunting down Graffiti and Street Art images in NYC

The students arrived in the city the first week of September and the search for graffiti was on almost immediately. It was serendipitous that on our first "outdoor" field trip to the High Line, we spotted graffiti from the elevated park that proclaimed "the city is our canvas."

The students were on the lookout for graffiti and street art throughout the five boroughs of New York City. It could be any size, any type (tag, mural, throw-up, piece, etc.) and it could be located anywhere. They could photograph as much as they wanted, but would be responsible for uploading at least 5 to 10 images to our Flickr site. Students were also assigned the task of creating their own Blackbook (a graffiti writer's sketchbook) during the semester-long program and to create their own personal "tag" as a design project after they developed more of a sense of what tags looked like throughout the city.

Students used a combination of smart phones and digital cameras to collect the images. If their apparatus did not have GPS, Jeremy created instructions for geo-mapping the image after it was uploaded to Flickr.

The students were asked to catalog their uploaded images in Catalogr, a software program designed by Jeremy. We had a short set of metadata and drop-down menu's for them to use in the process. Though the process of uploading images to Flickr and cataloging to Catalogr had many steps, the students found their way through the process with the help of tutorial videos and printed instructions without any major problems.

The images collected to date are varied, number about 300, and, according to Jeremy, are located in 37 different neighborhoods in the city.

Work on a website to display the images according to our metadata fields and locations continues.

Collected images & data

Image taken by Hilary Tijan

It has been a while since our last post. During that time, Margo and her students have been in New York City fulfilling their various requirements for the study abroad program. They've also collected and uploaded nearly 300 images to Flickr. Many of the images have already been mapped and cataloged, so we now have a healthy set of images and data that will serve as the foundation of our site. Huge kudos and thanks to Margo and all her students for their hard work!

Next we'll start developing the site by generating mockups, putting some basic code foundations in place, testing the Flickr API queries with our new data, and working with the latest version of the Google Maps API. So stay tuned....more developments coming soon.

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)

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.

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.