Despite having to start our meeting several hours late due to an early winter snowstorm, we got our project off to a fantastic start at our recent kickoff meeting at Zuni, December 8-9, 2009. Jim Enote hosted us in the new media room at the A:shiwi A:wan Museum and Heritage Center. In a very productive few hours, we managed to discuss many of the essential first steps, and we ironed out several important issues.
A nontechnical discussion of the technological side of our project:
Robin Boast started off the meeting by explaining his ideas about how we can build the back-end of the collaborative catalog system. One of the main constraints is that we have to work with the existing collections management systems in the partner museums. Coincidentally, three out of the four content partners use the ARGUS system, but we might have a challenging time getting the ARGUS database to connect with the collaborative catalog. Robin's idea is to use the Web access module of ARGUS to do this, but whether this is going to work like we need it to remains an unanswered question. Robin also spent some time explaining the concept of 'information push' to us-- basically another consideration for us is that things in the museums' catalogs change as well, so we need to figure out how to keep the information in our collaborative catalog updated, without having to 'pull' the updates all the time. How do we reverse the model so that the content partners push the information? Robin's answer was to use a new tool called Web Hooks, which are (as far as I can tell) a mini-program designed to pay attention to things that are happening in a database. When a certain event occurs (such as an object record's 'remarks' field being updated with new information), this mini-program knows to take a specific action (in this case, sending the updated information along to update the collaborative catalog records). Or at least that's how I understand it.
Essentially we are building three things that are all part of this 'collaborative catalog': 1) a script to format the content coming into the collaborative catalog system from outside museum partners; 2) the actual system, which will be housed on a server at AAMHC in Zuni, and will function essentially like a local, closed database; 3) the Web Hooks 'pub-sub' protocol (publish-subscribe) that pushes information back and forth. In all likelihood, the aspects of our project that will be the most portable and adaptable to other situations are #1 and #3.
Evaluations, or what would success look like?
Understandably, IMLS is very interested in concrete measurements for project success, so one of our challenges is to figure out a means of measuring what our project is doing. They call this 'outcomes-based evaluation'-- basically, as a team we decide what outcomes would mean that we're accomplishing what we set out to accomplish, and then we figure out how to measure those outcomes. One of IMLS's recommendations is that we select a few primary activities from our project that have discrete outputs or outcomes, then evaluate those. These would be something like 1) the system at Zuni, 2) the Web Hooks scripts/ protocols, and 3) the leadership workshop that we plan on doing at the end of our second year of funding, where we present our system and methods to interested folks from other museums and tribes.
While we were discussing evaluations, the question of "what would success look like?" was put on the table. Jim Enote, the director of the AAMHC, talked about wanting schools and artists to use the system, and to be able to expand and extend it to other places and institutions (such as the National Parks & Monuments). He also spoke eloquently about the sense of hopelessness that people feel at Zuni when thinking about Zuni objects in other places, since the objects were taken and people don't know where they are. He said that this contributes to bad feelings about museums. Projects like ours are a really important part of closing the loop.
The protocols of sharing - ideas & discussion
An important part of our meeting was our discussion about the protocols of sharing information, using the appropriate protections for Zuni intellectual property -- we all agree that these protections & protocols are an important element of our project, but exactly what form they will take and what they will look like must be worked out. We had a lengthy discussion and came up with several ideas that we would like to put into practice, and see if they work. Obviously we will need to set up something and test it to see whether our ideas work the way we want them to.
What emerged from our discussion was a 'moderated' sort of system where the appropriate religious leaders would review the object information coming into the database at AAMHC and make a determination about whether specific objects can be accessed by all Zunis, only certain groups, or only religious leaders. For the objects that are accessible by everyone at Zuni, the system will allow comments, feedback, and corrections (I particularly liked Robert Breunig's idea to have a "things the museum would like to know", which I thought could also be called a "set the record straight" tab).
The steps in the process, as we see it:
- cultural advisors decide which objects can be shared at Zuni, and they set permissions for access to objects
- Zuni users come in to AAMHC & interact with catalog, adding text, audio, video, etc.
- individual set levels of access to their comments
- ie. Zuni community only | museum staff only | staff and public (just ideas)
Our idea was to have a "parking lot" / "holding area" / "filter" where Zuni cultural advisors can monitor information coming into and out of the database. The question about how much work this filter will be was raised, and not exactly answered. We will want to phase into this, to see how it works and to see whether we need to rethink this setup.
We discussed for some time whether these comments should also be reviewed before being sent along to the outside museums, since we wouldn't want sensitive information to be inadvertently made public through our system. On the other hand, the task of reviewing (possibly) hundreds of comments about hundreds of objects is pretty intimidating. We do not yet know if people will make mistakes with sensitive information, but one decision we made was to make it as clear as we can that a user's comments can be either "Public" or "For Zunis Only", and each user will have to establish who can access their comments-- letting the community self-regulate. One idea that I had was to make the place where users enter "Public comments" be an entirely separate place in the interface (rather than setting access each time a user enters a comment).
Another method that might keep users careful about sharing sensitive information would be for the system to attach a user's name to all of their comments, and to not allow anonymous commenting. We want to be careful with that, though, because we also want people to know that this is a safe place to talk about objects, and a concern about doing it this way is that people might be discouraged from commenting if their name is attached to their comments.
All in all, this was a very productive meeting in my opinion. Thank you to everyone who made the trek and braved the snowy weather!