AAMHC's new website!

Well, it may not be all that new, but it's new to me, and I think it's just smashing! Curtis and Jim have done a lovely job of putting this together -- well done!


And they have a page that talks about our project--
http://www.ashiwi-museum.org/kechibawa.html

I particularly like this explanation of what we're doing:

"Emerging technologies may be able to help us experience the beauty of some items without having to pay the expense of maintaining or curating the items. Whatever direction we take to respectfully deal with thousands of Zuni items that were taken from Zuni, this project will help us shape the discussion so we can make the best-informed decisions possible. "

"Archaeology and Accountability" on Native America Calling

Jim Enote, one of our project collaborators at the A:shiwi A:wan Museum and Heritage Center was featured on the call-in radio program Native America Calling several days ago. From their website:

"Thursday, January 21, 2010
Archaeology and Accountability:
Archaeology, ethics and Native Americans have never quite seen eye-to-eye. But this trio may be forging a less antagonistic approach towards one another these days. Ancient Indian artifacts are still hot selling items and ancient Indian burial grounds and graves are still being robbed. But the archaeological field is showing signs of a willingness to collaborate in new and more ethical ways when it comes to Native views and beliefs. Is archaeology ready to be accountable to Native folks? Guests include Jim Enote (Zuni) Director/A:shiwi A:wan Museum and Janine Bowechop (Makah) Director/Makah Cultural and Research Center."

Listen here

Press release - announcing the grant award

For Immediate Use

Shaena Engle, engle@gseis.ucla.edu

(310) 206-5951

UCLA DEPARTMENT OF INFORMATION STUDIES AWARDED $ 351 , 398 GRANT FROM THE INSTITUTE OF MUSEUM AND LIBRARY SERVICES

UCLA’s Department of Information Studies, housed in the Graduate School of Education and Information Studies (GSE&IS), was awarded a $351,398 grant from the federal Institute of Museum and Library Services (IMLS). The new project, "Creating Collaborative Catalogs," will partner Information Studies students and faculty with the A:shiwi A:wan Museum and Heritage Center in Zuni, New Mexico, to create a collaborative catalog enabling people from Native communities to view, learn about, and comment on objects currently housed in the Denver Museum of Nature and Science, the Denver Art Museum, the Museum of Northern Arizona, and Cambridge University Museum of Archaeology and Anthropology.

“The project brings museums and source communities closer together to develop and share knowledge about culturally-significant museum collections in culturally-appropriate ways,” said Information Studies Assistant Professor Ramesh Srinivasan, principal investigator for the project. This project represents an important step forward in museum-community collaboration, allowing tribes to begin setting the record straight while keeping intellectual property protections around some areas of traditional knowledge. To learn more about the “Creating Collaborative Catalogs” project, please visit http://www.collaborativecatalogs.blogspot.com

“We believe that museums and libraries play an important role in building a competitive workforce and engaged citizenry. We are equally confident that these institutions will elevate museum and library practice through this work,” said Anne-Imelda M. Radice, director of IMLS.

The UCLA Graduate School of Education & Information Studies (GSE&IS) includes two departments - the Department of Education and the Department of Information Studies. Together, the two departments embody the school's commitment to understand and improve educational practice and policy and information systems and policy in a diverse society. GSE&IS’s academic programs bring together faculties and students committed to expanding the range of knowledge in education, information science and associated disciplines. Its professional programs seek to develop librarians, teachers, administrators and information professionals within the enriched context of a research university.

The largest museum and library joint grant program administered by IMLS, National Leadership Grants support projects that will advance the ability of museums and libraries to preserve culture, heritage, and knowledge while enhancing learning. This year’s National Leadership Grant recipients will generate new tools, research, models, services, practices, and alliances that will positively impact both the awarded institution and the nation.

The Institute of Museum and Library Services is the primary source of federal support for the nation’s 123,000 libraries and 17,500 museums. The Institute's mission is to create strong libraries and museums that connect people to information and ideas. The Institute works at the national level and in coordination with state and local organizations to sustain heritage, culture, and knowledge; enhance learning and innovation; and support professional development. To learn more about the Institute, please visit www.imls.gov.

Musings about IMLS Reviewer's Feedback

Looking through the extensive feedback that our proposal got from the reviewers, it seemed like a good idea to extract some of their suggestions, and respond to them as we move forward into this first phase of the grant. We made some decisions in the kickoff meeting that I think speak to some of the suggestions our reviewers made -- those are noted below. There are also a few suggestions from reviewers that we did not discuss, but which still might be important to consider.

1. "reassess their partners to include a technology partner"

Response: it would seem that we didn't make it clear enough how much a 'technology partner' Robin at Cambridge is. We are planning to hire an Argus consultant/specialist, and I think that between Robin and that person, we'll have plenty of assistance on the technology side.

2. "a pilot phase using a free wiki service that would enable them to step through the process and workflow of how this resource will work when it is delivered. It may be that they do not need to build anything - that they would get 80-90% of the way there with an existing tool"

Response: Again, we may not have framed what we are doing correctly, since I think they misunderstood us. The main thing that we are building is not a tool-to-create-a-catalog (since as far as I know we're using a customized Filemaker Pro interface -- in this case the tool already exists). What we're building, ie. where there is no existing tool, is the tool that will connect the catalogs together and allow them to share information and update as changes are made -- which Robin thinks can be done with Web Hooks. Building a test catalog via a wiki seems (to me at least) like it will a lot of work, without much benefit to building what we hope to build.

3. "I would like to see a much more detailed functional spec of the architecture they are proposing because I don't feel that they have thought this through. I don't doubt they can custom-build the application but it would be better to use existing software and put more focus on process and workflow for the delivered system. I'd rather see something in the proposal that talks about selecting or building a solution based on functional requirements. There is no description of any standards they would use, except XML- it would be helpful to know that they are proposing an interoperable system. I'd like to see the applicants provide a risk assessment, a plan for sustainability and backup/archive."

Response: I think that we're coming closer to figuring out the architecture of what we're proposing -- we did a great job of starting on that during the kickoff meeting. However, I'm not sure I understand the functional requirements part -- in some respects we are still figuring those out. Comments, anyone?

4. "The proposal is close to meeting the needs of the program, however there's no indication of how standard and interoperable this will be and how applicable it would be outside of the defined ethnic group. It would be good to see some addressing of how this might create a model for a broad array of ethnic groups."

Response: I'll leave the standards issue for someone else to comment on (Robin?), but I think that our emphasis on the leadership workshop towards the end of the grant term addresses his/her concern about the applicability of this to other ethnic groups besides the Zuni. Besides showing off what we've done, our goal in hosting a workshop like that is to work out ways to apply what we've done to other situations, and hopefully create other collaborations between other museums and source communities.

5. "Should this grant be awarded, I would like to make the suggestion that some thought is given to even wider applicability of the collaborative catalog idea, possibly making such a framework widely usable/applicable to a broad spectrum of cultural artifacts."

Response: See above. Although I'm not sure what he/she means by a 'broad spectrum' of cultural artifacts.

6. "Sustainability: Extensibility might be the more interesting question here - adding more content, including more repositories, broadening the reach to other tribal communities. I think the first is probably and the latter two more challenging. Again, it's not clear how the application will work with other collections management systems than Argus. And I don't know how broadly applicable the best practices will be."

Response: The fact that several of our partners use the Argus system was a coincidence, but one that we can hopefully take advantage of. And just to clarify, not every content partner uses Argus -- the Cambridge University Museum of Archaeology and Anthropology has their own custom-built collections management system. I'm hoping that this is where the advantage of using a tool that is as adaptable as WebHooks will be to our advantage.

Also, extensibility is certainly our goal, although I think an important shift is not to develop this into one large repository that covers multiple tribes, but rather to empower other tribes and museums to establish other collaborative catalogs, that are themselves situated in the hands of the tribes (and subject to their own intellectual property protections). I think that this might highlight the differences between our approach, and the approach that many other museum consortiums are taking. Our goal is not to create some massive, aggregated dataset about objects, but rather to think carefully about what collections will be the most interesting to the Zuni people (obviously Zuni objects will be at the top of that list), and develop a system that gives them more control over how knowledge and understanding is established around those objects. Adding more tribes & more museum partners isn't exactly in line with this vision. However, working to develop other collaborative catalogs with other tribal and museum partners is certainly one of our goals in hosting the Leadership Workshop, sometime towards the end of 2011, we hope!

7. "I'm also wondering about the wider applicability of the protocols for working with other communities. There might be a gap between what is appropriate for collaboration with the Zunis and with some other tribe. The applicant might also consider the reception of the protocols for dealing with Native American records that the Society of American Archivists is discussing. The archival community is divided over the implications - it's entirely possible that what results from this project could be met with a variety of questions that the museum profession will want to discuss."

Response: I quite agree! It is critically important for knowledge institutions (like museums, libraries, and archives) to consider the importance of the kind of protocols we are trying to establish within our project. From the beginning, approaching our research in a culturally-appropriate manner has been a key part of for the success of our project. Allowing tribes to control what we believe is their intellectual property reflects a much-needed philosophical shift in creating collaborations with source communities. Perhaps not all museums are as prepared to regard their collections information in this way, but (in my opinion, at least) unless museums start to approach source communities with this kind of willingess to protect traditional knowledge, they will have a much more challenging time building meaningful collaborations with those communities.

(I've written lots more on this issue of intellectual property protocols in our project in this article: Becvar, Katherine M., and Ramesh Srinivasan. 2009. Indigenous knowledge and culturally-responsive methods in information research. Library Quarterly 79(4): 421-442.)

What are Web Hooks?

(And how are they relevant to our project?)

'Web Hooks' are an idea that describes an entire range of small programs/applications that go out and trigger other programs to do something (and that 'something' is defined by the user).

Paypal is an example of this process, specifically their "instant payment notification." When something happens (ie. a customer pays you), Paypal sends a notification to a URL that you have specified (that in turn can connect to your server in charge of inventory and shipping stuff). The Web Hook provides the connection between the event (getting paid) and the output (shipping stuff).

Web Hooks are different than RSS feeds. In theory, RSS feeds work because you say "I'm interested in this" when you subscribe to the feed, and when new stuff is posted, the RSS feed 'feeds' it to you. In reality, RSS feeds work because your computer constantly checks, and checks, and checks. This constant checking is often called 'polling'. This is not "information push", not yet.

But now that feeds are being 'consumed' by applications & servers, not just human users, we need something that works better-- something that doesn't require that constant checking for new and interesting info goodies. Essentially Web Hooks allow different web-based programs to talk to each other and work together.

So how would we use Web Hooks for our project? Ideally, it would work like this-- we would have it set up so that when someone has entered or updated a 'public' entry in the Collaborative Catalog, the Web Hook would grab that update, and push it over to the catalog of the museum where from which that record came. (right Robin?) Sounds easy when you say it fast!

A couple of challenges:

-- Three out of the four content partners use the ARGUS system. We don't yet know for sure that we can set up a Web Hook with ARGUS, since ARGUS doesn't really connect with the Internet very well. Robin hopes that we can make this work using the Web Module of ARGUS. Here's hoping!

-- How will this work with our protocols of sharing? We have to strike a balance between getting people to contribute to the catalogue (ensuring that they feel comfortable doing so), and keeping the necessary protections on certain areas of knowledge. The fact that the process is automated via Web Hooks makes it much, much easier to get Zuni voices in the catalogs of the outside museums, but we have to be careful that we structure it so that non-public knowledge stays put at Zuni. It's a familiar challenge-- making sure the technological structure reflects the cultural needs.

More information on Web Hooks (and some jargon) can be found in this slide presentation by Jeff Lindsay, "Web Hooks and the Programmable World of Tomorrow"; and in the Web Hooks blog.

Use Rights Brainstorming

One conversation from our kickoff meeting which is worth continuing is our discussion about creating a use rights agreement. Chip Colwell-Chanthaphonh raised the issue, saying that he thinks it is important to create something simple and straightforward, granting the AAMHC and the Zuni tribe free access to use the material in the catalog, provided that the DNMS (or whichever institution) and the photographer are acknowledged.

Also, the point was raised that we may need to include something in the use agreement about the copyrights of individual artists, since some of our partners (most notably, the Denver Museum of Art) are contributing objects made by known, and often living, artists who still retain copyrights to their work.

Jim Enote also pointed out that we might want to put in an additional caveat that Zuni tribe gets to review what is being published based on the comments that they have shared. However, this is not so straightforward a request, given what happens after things get published and then they're "in the literature"-- at that point it might be too hard to enforce that condition of review by the tribe.

Robin Boast pointed out that we might benefit from looking into Creative Commons licensing, since what we're talking about is essentially what they call an "Attribution NonCommercial license".

Also, it might make sense to have two use agreements, one from the content partners to AAMHC, the other from the AAMHC to the content partners. After some thought, here is a draft of what I came up with:

[from content partners to AAMHC]
We grant free access to A:shiwi A:wan Museum and Heritage Center and the Zuni Tribe to use the material within this database, provided the [institution name] and photographer are acknowledged in all uses, and that the copyrights of individual artists are respected when appropriate.

[from AAMHC to content partners]
We grant free access to [content partner] to use the material within this database, provided the authors are acknowledged in all uses (and that the AAMHC is able to review any work that is published based on the research provided in this database).

These are just preliminary ideas, and will quite possibly change and develop in the coming months.

Recap of our recent kickoff meeting

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:

1. cultural advisors decide which objects can be shared at Zuni, and they set permissions for access to objects
2. Zuni users come in to AAMHC & interact with catalog, adding text, audio, video, etc.
3. individual set levels of access to their comments
• ie. Zuni community only | museum staff only | staff and public (just ideas)
4. advisors get to review information
5. Zuni's info goes out to museum via WebHooks script
   

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!