Ten years ago, an anthropologist named Kim Christen from Washington State University was visiting the Warumungu Aboriginal community in Australia, when it became apparent to her that their challenging task of cultural preservation could be significantly aided through a custom-built online tool. She applied for, and received funding for the web development of such a tool, and Mukurtu 1.0 was born. Some years later, the California-based Center for Digital Archaeology had joined the effort, and Mukurtu, having been well-used already and showing great promise, was slated for a complete rebuild with a fuller feature set. Kanopi Studios landed the contract, and I became the chief developer for the launch of Mukurtu 2.0.
“Mukurtu (MOOK-oo-too) is a grassroots project aiming to empower communities to manage, share, preserve, and exchange their digital heritage in culturally relevant and ethically-minded ways… Mukurtu is a Warumungu word meaning ‘dilly bag’– a safe keeping place for sacred materials.”
– Washington State University
Mukurtu was my inaugural Kanopian experience, and I was delighted to be hoisted into a position of developing socially-relevant technology. I believe there is a special potency where ancient culture meets modern technology.
Architecture
By the time of my arrival, Kanopi had already architected the fundamentals of the Mukurtu 2.0 platform, based on Drupal 7. Mukurtu is installed via a custom profile. A site may be installed and hosted by Reclaim Hosting, or a community may freely download Mukurtu from Github and install and host it themselves. In a Mukurtu site, there are Communities which are groups within the larger community. Within Communities, there are Cultural Protocols, which are also member-based groups. Communities are managed by Community Managers, and Cultural Protocols are managed by Protocol Stewards. There are other roles within each as well. This is all provisioned by Organic Groups.
The primary piece of content is a node type called a Digital Heritage Item (DH item). All such content belongs to a Cultural Protocol (CP), and thus also to a Community. We use a custom widget to select the Community and CP dynamically. DH items can belong to more than one CP, so there is an option of sharing the item with people that are members of any of its CPs or sharing it only with people that are members of all of its CPs.
A Digital Heritage Item is a relatively complex node type with five tabs of fields, but the most significant piece within it, other than the title and description, is the Media Assets. This is the actual piece of preserved culture, whether it be an image, a document, a video (uploaded or hosted on a video sharing service like Youtube), or an audio file (uploaded or hosted on Soundcloud). For this, we wanted the ability to use a single multi-value field for all media types. The Media module could not do this, so we went with an alternative — the Scald module. The original purpose of the Scald module was to make entities out of media, such that they were fieldable. That was no longer needed once File Entity was released, but Scald remained the only way to upload any media type in a single field. Among the fields on a media item are optional fields for Community and Cultural Protocol, so the permissions on a media item may exist in addition to the permissions on its parent Digital Heritage item.
So we have a complex permissions system that reflects communities with individually customizable needs, where privacy is a significant concern. The goal is to disperse, yet preserve, cultures that are rightfully sensitive to cultural appropriation. Given the complex permission needs, it was no surprise that custom permissions work was needed. In addition to stock OG permissions handling, I had to make combined use of all three of hook_node_access, the node grants system, and hook_search_api_query_alter. This is one of the pride points of my work on this project because it works well, and efficiently — the code for this is neatly summarized here.
Browse and Search
Browsing and searching are built on Search API, with a generous use of facets. The idea is to be able to easily plug in Solr when sites reach that capacity, but so far, things are running smoothly for all clients using Search API’s DB server. Search and browse results can be viewed in both list and grid views. Some heavy customization on Scald thumbnails is done here.
Mapping
Digital Heritage items can be assigned geographical points and browsed by map. Coming soon are the addition of lines and polygons geo-types, map clustering, a custom base map, a combined list/map view which respond to each other, a customized map legend, and rich popups when hovering on map items. I chose Leaflet over Openlayers, as the mapping library, for its efficiency, mobile-friendliness, and out-of-the-box great aesthetic. The drawback with that choice is that the Leaflet Drupal module is less mature than the Openlayers Drupal module. I’m very much looking forward to those mapping “coming soons,” some of which will have me contributing back to the Leaflet module.
Mobile App & Scald Services
The Center for Digital Archaeology built a mobile app to be able to view and create Digital Heritage items and their media from the field. On the server side, I used Drupal Services to build the resource. For the Scald (media) items, I built a custom Services resource. After sharing this on the Scald issue queue, the maintainer suggested I make a Drupal sandbox project out of it, which he would link to from the module page, so I did. At zero users, I can’t say it is heavily used, but it was nonetheless satisfying to share code with the community in a more official way.
Batch Import / Export
Already implemented, is the batch import and export of content (Digital Heritage items, media, Communities, Cultural Protocols) through CSV. A grant application is in for the import and export of DH items through XML using the Dublin Core standard, with additional support for the METS and MODS extensions of Dublin Core.
Extended Functionality
Collections are groups of Digital Heritage items. “Dictionary” is a taxonomy of words in a given language, with words enhanced within their own set of fields. “Categories” is a taxonomy to group DH items together independently of their Cultural Protocol. DH items can be related to each other. Community Records are records within a DH item (sharing the same Media Assets), with customized field values for different Cultural Protocols, so a given Digital Heritage item can be shared between communities, but also contain information private to each community. Book Pages allows one to organize DH items as navigable multi-page items. There are also many finer pieces of functionality beyond the scope of this article.
In The Funding Pipes
Still to come, is integrating Open Atrium’s discussion and calendar tools into the build, a rich and customized email notification system, and “file fixity” with scheduled MD5 and SHA checksum comparisons to assure indigenous communities that their cultural resources remain untampered with throughout time.
The Perfect Drupal Project
Mukurtu is a powerful yet tailored system which fully warrants the label “platform”. It is, in many ways, the perfect use case for Drupal. It is open source, the code is clean, and it serves a righteous purpose. It is a long-running project with steady improvements informed by the needs of an ever-growing, yet specific user base. Mukurtu is what I started with at Kanopi, and two years later it remains a significant project on my Kanopian horizon. I am grateful to be able to work on it in any capacity, let alone such a committed one, and I have our CEO, Anne Stefanyk, to thank for having the vision to invest in this genuinely beneficial Nonprofit project.
