Faces in Aperture

By letting my computer grind over the 41,243 pictures in the media database overnight, Aperture produced previews and thumbnails of all media, whether tif, jpeg, raw, movie, very convenient. But it also analyzed the pics for facial features. You begin to build the lineup by clicking on any picture where Aperture has detected a face, and giving it a name.

Confirming Pedja

Once you have added a person, you can click on his/her face and then confirm other pictures of that person. Here I’m going through pix of Pedja. As you confirm or reject pix, the choices improve.

Actual photos including Pedja

The usefulness comes when you switch to the actual photos including the person. We can see a life history of the person in all of their contexts, and since this information is semi-automatically derived, we’re able to build out a person-centric view of the images that would otherwise take hours (likely days) to do.

As I’m going through the pix, Aperture makes it easy to add missing faces as I come across them. Just click on the pic and hit the N key, the dialog comes up and Aperture attempts to find faces in the shot. You can easily add more facial regions, as I’ve done in this example.

Adding missing faces

If a person is in your address book, their details are automagically linked, very handy. You can limit suggestions to a specific project. This is critical if your Aperture library contains many different projects – personal, weddings, trips, work – you can imagine what a mess of faces this would cause.

Kitchen area on Bastille Day, 2001

Archaeological Faces: Of course, it would be fabulous if we could use Aperture to recognize archaeological features automagically. Imagine being able to point Aperture at a set of pictures and have it analyze them for features like fire installations, obsidian caches and the like. Maybe someday.

For now, Aperture is a great tool for humanizing the massive image collection with relative ease. It’ll be another few sessions before I’ll know if the data we get out of Aperture is worth the time it takes to identify Faces (and soon, Places), but so far, it’s looking good.

Here’s a video of the process in action:

Processing Pipeline in DropBox

It’s taken us a while to get this going, but the process works very well. We use DropBox for handling all of our files. If you don’t, you should check it out, it’s an amazing tool for collaboration, syncing your life and backing up your stuff.

Thanks to DropBox, any file in the pipeline can be viewed from the web, iPhone, iPad, or laptop, and is always in sync.

LHOTH on the iPhone

The Pipeline

1) Unprocessed: Any Source file that we want to add to the database goes here. It’s a staging area. Any team member can easily get to the file and see it, open it, check it out.

2) For Review: Team member figures out who needs to provide input on the source document and contacts the person for their review. For example, I (Michael) may want Ruth to review a document to make sure it’s the right version, or to agree on which fields we want to map. Nico Tripcevich may be asked to review spatial data for the purposes of linking maps to the database. After review, the database team will process the source doc to prepare it for integration in the database, and move this file to the In Process folder. If changes need to be made to the original (if DATA is changed, that is), then the original is copied to the Archive folder.

3) In Process: Actively worked on source docs. These docs are linked to the database, using Filemaker 11′s new recurring import feature.

4) Ready for Grinding: Once a source file is completely processed, it’s ready to be transformed into Event data as RDF. We fondly call this meat grinding, as in making sausage from the data. Our mapping process produces open data that can be output in a variety of formats. We use XML, but we can output reports, Excel spreadsheets, or prepare the data to be visualized in a relational database.

5) Archive: Process sources are archived, along with their original companions and the mapping instructions, assuring full empirical provenance.

Last Note on DropBox: We love the fact that DropBox automagically versions all documents, including the database, so if we ever make a mistake (ok, when we make mistakes), we can roll back files to previous versions. Sweet!

DropBox versioning of a file in the processing pipeline

UC Berkeley MediaHUB: Adding or Updating Files from Michael Ashley on Vimeo.

I am attempting to hand knit data from some 3000 images or so taken in 1999. Like most metadata projects of old, there’s a lot of munging that needs to get done to make this great resource of cool images useful to anyone. Making progress, though. Here’s a couple things I figured out in my manual natural language processing escapade.

Mavili and onlooking workers, photo by Casey Gordon

About 64% of the 1999 images have captions. There are 4483 images, and I’ve been able to revive metadata for 2851 of them so far. This is not to say all is lost. A lot of images are people, parties, a couple trips here and there. Plus, we shot find (artifacts) by including the label and may not have ‘slated’ the image in the log. Well, this at least is my working theory.

This all said, I am going to use 1999 as a base model for the semantic linking we want to achieve between people, things, and media in places. To do this, I am working out how to grind up the data into these lovely packages. I feel compelled to do this old school style, the algorithm is my brain, eyes and hands.

Here’s an example of the fun. In 1999, we used a field called context, which later became Area, such as the BACH area, or the Dig House. Doing some quick analysis, here’s the list of variations of contexts that needs to be cleaned up:

1999 Contexts

The variations will be nice to grind over for ‘Did you mean: Dig House?’ later, but for now, I’m working to rationalize the terms to a master list of places across the site and off. My favorites here are asterisk *, some offsite mudmaking, and EFES (the place, not the beer).

The idea of embedding, interweaving, entangling and otherwise linking the data and media from archaeological excavations with their interpretation and meaningful presentation in an open access sharable platform has long been an ambition of those of us working in the digital documentation of archaeological research and the public presentation of cultural heritage.

Working in collaboration with the contributors, archaeological project managers, publishers and information technologists, we devised a content licensing agreement that makes it possible for the primary research media and data, combined with the monograph texts, to be freely and openly accessible in perpetuity.

The aim of our project, Last House on the Hill (LHotH), is to holistically reconstitute the rich multimedia and primary research data with the impressive texts of the monograph, the printed final report of the Berkeley Archaeologists at Çatalhöyük (BACH) project, in which a team from UC Berkeley excavated a group of Neolithic 9000-year old buildings at this famous cultural heritage location in Central Anatolia, Turkey.

The UCLA Cotsen Institute of Archaeology, who will be publishing our printed report entitled House Lives, have decided to give up on supplemental media (CD-ROMs and DVD-ROMs) in favor of on-line digital versions of their publications. We, as archaeologists who have long been involved in digital documentation and publication of archaeology and cultural heritage were delighted with this news.

We felt that these media had a limited lifespan, not only because they could easily go missing, but also because of their regular need for migration due to physical degradation and the inevitable (unless carefully archived) obsolescence of their software. We were also aware of the disadvantages of read-only CD-ROM media, as with the printed word, of offering a definitive closed narrative, whereas we feel that the narratives about archaeology, history, cultural heritage, and the past – including those about the data themselves – should be anything but closed, but should always be open for expansion, critique, and modification.

The online digital mirror of House Lives that is presented in this paper – entitled the Last House on the Hill project – is one which goes much further than to bring together supplemental materials along with digital versions of the published texts. Its ambition, one which we have long wished to satisfy, is to embed, interweave, entangle and otherwise link the data and media from the archaeological excavations with their interpretation and meaningful presentation in an open access, sharable platform. The project brings together the published text, complete project database (including all media formats such as photographs, videos, maps, line drawings), related data and media outside the direct domain of the BACH project, along with recontextualised presentations of the data.

We are achieving this through an event-centered database structure built in Filemaker that is conceptually based on a CIDOC-CRM compatible implementation ontology. As a web publishing platform we are exploring the open source Omeka, in order to provide access, transparency and open-endedness to what is normally the closed and final process of monograph publication.

The architecture and content management practices with which the Last House on the Hill has been constructed will act, we think, as a model and an encouragement for our archaeologist colleagues to share their work with the public for the long-term. Our attitude to sharing our knowledge with the public in which we make the process of our archaeological interpretation transparent in order to engage them more intensively in our work, and our attitude to breaking the strict bondage of the empirical data is, we feel, very close to that of the Çatalhöyük team as a whole, who have made all of their data and media accessible through Creative Commons 3.0 licensing.

Here is my work of today: an overview and analysis of the Omeka tools and plugins with some notes on their potential for our purposes.

THEMES:

The original Omeka themes are pretty basic, nothing exciting.

 The theme that OKAPI developed is very nice. The graphics is attractive and makes the content look more dynamic.  Particularly: http://www.ars-synthetica.net/archive/  

The page of the pathways is very beautiful:   http://www.ars-synthetica.net/archive/pathways.   There is this “floating” diagram that actually don’t link to anything (is it a flash?) BUT if there was a way yo make it link to actual content (which I believe is totally doable) that would be EXTREMELY interesting starting from our diagram/mind-map…. it opens extremely attractive possibilities of developing each branch of the mind-map etc…

The theme is available as a downloadable package from the omeka site:

http://omeka.org/download/packages/

BROWSING and SEARCHING TOOLS:

Browsing tools are ok, limited to one category at a time as any standard website. You can build different categories according to your type of content, so it is good. Here is an example of a browsing page: http://www.digitalamherst.org/items/tags?sort=alpha

Search is ok. Here a good example of advanced search: http://archive.poyi.org/search

PLUGINS:

1) The contribute plugin is quite cool. It allows a user to contribute with its own story, images and additional information. 

How it works.  You just fill in a form that allows you to upload a file, locate the file easily through the googlemap functionality integrated, provide information about yourself, submit. Then you can browse all contributes by story, image, by map, or by tag. Pretty cool. 

For the idea of “developing narratives” it is a very attractive functionality.

A good example is here:  http://hurricanearchive.org/contribute/

2) the ExhibitBuilder plugin is a very interesting tool. Also graphically it has good possibilities. It allows you to build narratives around specific stories or topics, gathering viedos, images and texts together with at least a two levels menu for accessing it (exhibit page –> themes of the exhibition pages –> single pages). The pages can have be build quite freely. 

 Good examples are:

 1)  http://gulaghistory.org/exhibits/days-and-lives/suffering/3  This is a good example of an exhibit with sibling pages (… sorry for the painful example

 2) http://objectofhistory.org/activity/.   This is particularly nice as a teaching tool for the friendly interface of dragging/dropping available items to build your own exhibit. I BELIEVE that it can be made more sophisticated with more than 6 items. Example: Ruth is teaching a class and wants the students to create their own exhibit and content based on the available media from the project without allowing students to login with administrative privileges. 

3) The IPaper plugin is an embedded viewer for images. It works very well with a great zoom-in. Here a good example:

http://content.mnhs.org/maps/items/show/59  

In this same page there is another nice functionality. If you look at the picture above the Ipaper viewer there is the bar on the right “Item information” you can show info or hide them.

4) the new plugins CSV Import and OAI-PMH Harvester are the only tools that I see that can import items in mass. CSVImport imports comma separated value database files, it can import thousands of records at once. OAI-PMH allows you to import files from the OAI-PMH. No examples found…

5) Dropbox plugin allows you to upload large amount of data in your omeka archive without worrying of size. Files uploaded with dropbox can be associated with an item. But they don’t say what type of file you can upload and what you can do with it.

6) The Geolocation plugin works with googlemaps and allows you to easily insert a map and locate an item onto a map. A map can be also searched.

OBSERVATIONS and LIMITS:

This paragraph is for sure a combination of Omeka’s limits and my limits. In the sense that there are possible tricks or tools that my non completely developed abilities as a geek may have missed along the way during this my survey. 

I have seen all the featured omeka projects and most of the projects powered by omeka from this page: http://omeka.org/codex/View_Sites_Powered_by_Omeka. 

1) One of the main problems that I see is the management of a complex database structure:

Need to check CSV Import. I guess that it doesn’t allow the level of complexity that we need. I guess it only imports flat tables, how to rebuild the relations in omeka I have no idea. My opinion is that the database in filemaker cannot be integrated into omeka. But again, this has to be verified.

2) The presentation of the items, collections, and exhibitions at the end of the day, looks always pretty “flat”. This is a common trait that I have noticed in all the websites implemented with omeka. I see that some better graphic solutions and plug-ins altogether give you the possibility of creating richer pages, but this still don’t change the general feeling that you are dealing with a “limited asset management” platform.

3) I find the platform very good from the front-end perspective of a non-expert or non-advanced user and for dissemination and teaching purposes is perfect. Less so for the need of really integrating ad displaying a complex documentation based on a structured db platform. 

Non-Cidoc based but beautiful interface:  http://pahma.berkeley.edu/delphi/

Non-Cidoc based, not beautiful, but complex ontology at the base:  http://orange.sims.berkeley.edu/cgi-bin/flamenco.cgi

cidoc-based:  http://www.cs.vu.nl/STITCH/links.html

cidoc-based:  http://www.archimuse.com/mw2003/papers/hunter/hunter.html

cidoc-based:  http://ochre.lib.uchicago.edu/index_files/Page794.htm (Developed at the University of Chicago to integrate cultural heritage data—within one research project or across many different projects).

Some readings:

Access to Heritage Resources Using What, Where, When, and Who: http://www.archimuse.com/mw2007/papers/buckland/buckland.html

A very interesting analysis of the meaning of the words “document” and “documentation” as intended from metaphisics to information science:  http://people.ischool.berkeley.edu/~buckland/whatdoc.html

ONTOLOGY-BASED ACCESS TO DIGITIZED
CULTURAL HERITAGE AND ARCHIVAL COLLECTIONS: http://www.ncd.matf.bg.ac.yu/casopis/12/NCD12009.pdf

Here is a larger version of this chart

Let me know what you think

To try to express this idea of the three layers in the path from database to narrative, I have re-drawn yet again our figure 6 of VAST 2009.

For a larger version of this chart

After the chat that Michael and I had on Monday and because I need to make a figure about LHotH for my Household Archaeology paper , I have worked on another mind-map of how we are configuring LHotH as Dastabase Narrtative in Manovich’s sense.

From my Household Archaeology article: “Manovich pointed out that the opposition of database and narrative is a symbiotic one. Databases have a data structure which contrasts to the algorithmic structure of a narrative. Endless narrative interfaces  can be drawn from the same database, as we are doing with the Last House on the Hill. The potential of the database narrative concept is the creation of a complex, fluid – even ephemeral – web of alternating interfaces/narratives, as Manovich himself created in his SoftCinema…….The archaeological project (BACH)  itself is considered the central node, the original event that brought together people, places, things and media, and gave origin to the complex network of information about the project. …..The narratives are drawn out of the database through the filter of the alternating perspectives or standpoints of people, places, things, and media, which enable the re-contextualizing and remixing of the content in the database.

To put the narratives that are drawn from the data into an interface (or more elegantly – “outerface”)  framework that is appropriate to the multiscalar study of social practice in Neolithic households and neighborhoods for which the BACH project itself was designed, groups of events have been identified at the core of the structure of the opus: the events in archaeological (Neolithic) time and the subsequent formation of the archaeological record, and the recent events linked to the BACH excavation project. Out of this structure an endless configuration of people, places and things can be created as vignettes or narratives, seen as juxtapositions of image and text or video montage or text alone.”

I really need you feedback on whether I have got this right, asap if poss since I have to send in the figures as of yesterday!

The next task is to create a figure – actually a set of  four figures, masquerading as one, thats show a narrative using the same data (F.634) created through each of the filter: people, places, things, and media.

I am rationalizing to myself that I am killing a number of birds with oine stone since – in addition to the Household Archaeology article – this has to be done for CIA and VAST as well as the projects as a whole.