Power in Partnerships: Sharing with Collections Management Systems

Thank you for joining us for today’s webinar with Rachel Cristine Woody. My name is Bradley and I will be your moderator for this webinar titled Power and Partnerships Sharing with Collections Management Systems.

Before we start, I would like to provide some information about our company and introduce today’s presenter. Lucidea is a software developing company specialized in museum and archival collections management solutions, as well as knowledge management and library automation systems. Our brands include ArchivEra, Argus, Presto, and SydneyDigital.

Now I would like to take a moment to introduce today’s presenter, Rachel Christine Woody. Rachel is the owner of Relicura and provides services to museums, libraries, and archives. She specializes in museum collections management systems, digitization technology, digital project management, and digital usership. During the course of her career, she has successfully launched multiple digital projects that include advanced digitization technology, collaborative portals, and the migration of collection information into collections management systems. She is also a popular guest author for Lucidia’s Think Clearly blog and has provided us with many great webinars that are listed on our website. So please feel free to check those out after today’s session. Take it away, Rachel.

Alright. Thank you so much, Bradley. Thank you to Lucidea for hosting us today. And of course, thank you for joining us on this particular webinar. We’re gonna get into some different partnership models and what creative partnership can look like when thinking about a collections management system and ultimately your discovery portal.

To do that, we’re gonna talk about those three different models for our language today. Those three models are the unified hub, the peer to peer bridge, and the discovery portal. And then we’ll have a nice little wrap up at the end.

So for each of these, for the first one, the concept of the unified hub is the sharing of a singular database.

So we’ll get into a little bit more technical depth in terms of what does that mean exactly, and we’ll have some examples along the way. The second model is the peer to peer bridge concept, and that’s sharing permissions to access separate databases under different museum purviews.

And then the third one being the shared discovery portal where everyone has their own database typically, and that database is either harvested or there’s some other contribution mechanism to this broader discovery portal often under regional consortiums.

So into the detail, what is the unified hub? This is the most integrated partnership approach.

As we discussed, it is the concept of the singular database, though there could be multiple partners. In most cases there’s at least two and usually three different museums that contribute to a single database So essentially that means while there is one database and each of your museums have access, they are not separate databases. And so the data of each of those museums can exist and does exist in that own singular database ecosystem.

How that looks, though, can vary depending on the collections management system. So if it’s a simpler version of CMS, then that means the data is completely commingled.

There’s not necessarily a nuance to the restrictions. There’s not a finite control over securities or permissions that can help partition that. And there is typically no ability to separate out or support different catalog forms.

Usually, it’s one of the what what you get is what you get in terms of the records that you would create and the data and fields that are available.

Now most of that is going to be be the case regardless of whether you were sharing the database, partially because the collections management system itself is a little bit more simple and straightforward. This can be the case for off the shelf models or more budget friendly systems where they’re budget friendly because there’s not that access or support of the more extreme configuration or customization.

There can, however, be more access to functionality, more access or option of customizing ability, as well as more securities around data if you have a more sophisticated collections management system.

If you are able to afford and when you’re partnering together with other museums, hopefully that’s the case, you can pull resources and actually afford a more robust and more sophisticated collections management system that can provide that partitioned access. Your data can be separate based on different user permissions or different segregation of your data. You could, of course, share your data if you wanted to, and there’s safer ways to do that where you can share and have viewable access to your institutional partners’ data.

This is more protecting it to make sure there’s not, like, an accidental adjustment or deletion of your data from a different museum.

With the more sophisticated CMS, you can have similar but different catalog forms, which can be important, especially if you’re sharing that database with other museum partners. Not everybody’s collection is going to be the same. Our workflows are not necessarily going to be the same, and several of those things may necessitate different approaches to how you catalog, what data you capture, even what format of the field you capture, even if it’s the same kind of data. So having access to those different forms can be desirable, especially when sharing a database among different partners.

And then finally, with a more robust CMS, you could also support different institutional specific processes or workflows. So even though you have all have access to the same types of catalog forms or workflow functionality like for exhibits or loans, you can tailor those and the system can support different processes among your different partners.

So while there will certainly be some challenges and we’ll get into those of sharing a singular database, If you’re able to afford one of the more robust collections management systems, you can actually afford then also the more nuanced functionality that can help better support the concept of sharing a database with other institutional partners.

I wanted to share this example. And, of course, we can’t necessarily see behind the curtain with these partners, but showing sort of an example of what this can look like and then getting into benefits and challenges.

So this is DISCO. This is a partnership among natural history museums in Denmark.

There are three of them currently, though I believe their partnership was formed with the intention to support other partners joining in the future.

There are three museums. They’re in one singular database.

Among the three museums, they’re of various sizes in terms of, like, sheer collection volume.

There are some different collection types even though they’re sort of this overarching natural history element.

And because they’re all in the same system, their data is now also connected to some specific to their collection type of resources. So for example, for this one, their natural, history approach, there is a Danish authority and dataset that they like to connect their data to and have that shared resource be connected and part of their one singular database.

Now while they could certainly have that connection on their own in their in their single implementations, they have banded together to help make sure that there’s some of that data standardization, that there’s linking to all of that data Because this is a data intensive sort of collection that’s apt for lots of great in-depth research and mining of their data, there were quite a few reasons as to why they sought out this singular database model of which were some of those reasons.

So what’s the benefits here? Why have a partnership and join into a singular database, especially because doing so may take some work both on the prep end as well as in the maintenance end.

First and foremost, and especially for your museum directors out there, there can be a massive IT cost savings. This is especially true if you need or would like to afford a better and more robust or more sophisticated collections management system, partnering together means the amount that is affordable increases typically, and you will have better buying power. So having a a better system, but still have it be cheaper, if not even cheaper than the system you may currently have affording on your own.

It can also increase your technical capacity. So in a particular partnership among two or three museums, any one museum may only have one IT person if they have an IT person at all. Whereas when you have three of you, there may be and hopefully will be more access to that, IT expertise.

Also, if you are affording a better system, those better systems often come with vendor support and access, of course, to that level of technical expertise specific to your database.

There’s also just inherently knowledge sharing among the staff, so better staff support and, more internal sort of troubleshooting among all the people using the system versus just you alone in a vacuum.

And it helps to standardize data quality. So even if you, are in a robust system and don’t necessarily need to share catalog forms, for example, you do want your data to play together. That’s probably part of the reason, if not the only reason, why you would consider joining different museums into a singular database is so your data can play together. For disco in Denmark, that was a primary motivator, having the benefit of all of that data together to be used and commingled. So in doing so, that sort of necessitates a standardization among most of the data, at least the important points of data that you want to make sure are standardized and searchable and accessible in an equality based way.

So challenges. Main challenge here is the social contract.

You in joining into especially if it is a collections management system on the simpler end, it requires a high level of trust. You are commingling data. On the simpler side, you may not have that partitioned or security based nuance of access to data.

And so just needing to cultivate human relationships where the trust is there and, of course, maybe having some good processes in place to help protect data.

And then a second major piece and part of the social contract is the agreement on cataloging protocols. So knowing that the data is being commingled, wanting to benefit from all of our data being commingled requires that standardization and so supporting standardization with your cataloging protocols in place. So that’s essentially gonna require work both in preparation for joining into one database as well as maintenance mode while you share that one database with your partners.

So that was unified hub. Now we’re gonna get into the second model, which is the peer to peer bridge or p two p. This is a model that allows museum partners to maintain and have separate databases, so they each need to have their own collections management system.

But you’re able to partner in some specific ways, so this particular model, as with the other, requires two or more institutions to join in together, and it will require each of those institutions to already have a database in place.

So the partnership models for the most part, unless you have access to some excellent code writers and product developers, it will require each of the museum partners to have the same CMS product. This helps the next part of being able to strategically access portions of each other’s systems.

It also requires collections management systems that will allow that linking through secure access protocols, which, of course, not all collections management systems have, though CMS that are vendor supported, you will typically find that as more of an option versus having a more budget friendly collections management system. So it’s there’s some unique and very specific things that need to be in place for peer to peer to peer bridge to work.

For an example for a model in action, there is a joint famous and very public joint stewardship of the Robert Mapplethorpe Collection. This is a collection that is co owned by the Getty and LACMA, the Los Angeles County Museum of Art.

They have the joint acquisition, so joint responsibility of stewardship.

And as we know as museum professionals, order to provide stewardship and access to the collection, it needs to be in our collections management system.

Because of the museums and how they are geographically separate, in terms of not being in the same museum and they’re institutionally separate and defined, they have their own collections management systems that are under the same vendor.

And those collections management systems, as many of them are now, are cloud based, which is a requirement here for providing that access or the seamless access, at least.

And with this particular partnership, they have leveraged the collections management system ability to provide some very specific permissions to their fellow partners to provide access and viewership of the shared collection and its data. So in this case, it’s not access to the entirety of their database, but it is access to the specific collection and materials they’re in.

So why choose the peer to peer bridge? For this particular option, it gives you the benefit of having total data autonomy so you can keep your own collections management system. While it needs to be the same sort of product, you your data is on its own and singular.

It reduces the social contract friction. So, like, the unified hub when we were speaking about it, you don’t necessarily need to share cataloging protocols, though maybe for your work purposes or goals that may make sense. And you don’t necessarily need to have the same level of trust because you’re only sharing a specific part of your data and database, and it can be scalable. So in the example that we talked about with the GETTI and LACMA, it is for one particular collection where that particular collaboration access could potentially expand or scale if they wanted it to.

So challenges being, first and foremost, IT infrastructure. You each need your own collections management system. Unless you have access to extreme technical knowledge and developer abilities, you will often be required to have the same collections management system. And then also the security piece, needing to necessitate and have systems that support the very specific pinpointed access and permissions to some very specific areas in your collections management systems. So it’s a little less risk than perhaps that singular database in our first example, but it does take some specific and technical things being in place for the concept of the peer to peer bridge to work.

Alright. Getting into our third example, which is the discovery portal. There’s a couple terms to start out with before we begin the further technical discussion. First of which, discovery portal. They are called many things. For our webinar, we’re gonna refer to it as a discovery portal, but it’s essentially the public facing website, if you will, front end that then allows that searching and discovery into your collections. So for many of us that have a CMS, it has that public facing website side where you can search your collections and provide access.

That is considered a discovery portal. It can also be a larger meeting where many, institutions contribute to a consortium, and that consortium provides a discovery portal connected to each of your individual smaller discovery portals.

For our purposes, because this is power and partnerships, we’re talking about that bigger consortium model.

And so while similar concept in terms of discovery point of your collections, this is the concept of mass aggregation among multiple partners into a discovery portal.

In order to do that, our next term is harvesting. And depending on the consortium and the particular tool that is supporting the portal, it can happen in a few different ways.

For most of them, at least currently, the harvesting concept is what’s used, and that is essentially going to your individual little discovery portals with just your data and having that tool essentially scrape your data and references to usually your thumbnail images and then taking that back to the larger consortium portal to integrate into their larger dataset to be searched.

That can also, if harvesting is not possible or depending on the consortium, there can be a smaller option of contributing via spreadsheet or, similar method that is less common, though we will talk about it in our next webinar. For institutions that are so small, you may not have your own CMS or or discovery portal because you don’t have a CMS.

The third term is a specific technical term that helps support the harvesting, and that is the open archives initiative protocol for metadata harvesting, which often is referred to as OAI PMH or sometimes even just OAI, but it is essentially the the process of which and supported by a tool that is doing that harvesting and scraping among all of those different little singular portals into this large consortium portal.

For an example, and there are many good ones out there, but one of them is Callosphere. And this is essentially a consortium of California art history and culture.

So across the state, they have contributors that are museums, archives, libraries, special collections, and all of them are harvested to be included in this one large discovery portal.

The benefits and draw, of course, especially in this case, is that it’s California state history or art and culture as it were.

And so anything that falls into the California collection is naturally a thematic fit for this particular consortium and, nicely lends itself to the cross searching and use of collections no matter what the institution type. So, for many of these, they’ll provide different points of access, but users who typically come here, it is less about where the collection lives and more about wanting to search across different, artists, different topics, maybe even different geographic regions of California that would be nearly impossible or take a tremendous amount of time if they had to do it in each of our own little discovery portals versus being able to come to essentially this one stop shop of California history and culture.

So there are many other versions out here. Calisphere is a great, example, especially to look at a regional level of the discovery portal at work.

So partnership edge, what’s the benefit here, Especially when compared to the first two unified hub peer to peer bridge, there’s minimum work to contribute. There may be some data standardization in order to better fit into that larger discovery portal, but you don’t necessarily need to go through, acquiring the same CMS as everybody else or needing to adopt the same cataloging standards because you’re sharing the same database.

There’s a lot more flexibility and lower barrier to entry if pursuing just the discovery portal partnership.

There is zero system disruption, so you don’t need a new system.

You don’t need to use the same system. There’s typically zero change that needs to happen unless you wanted to with the particular database that you have in place.

This gives ultimate system flexibility. So if you’re part of a consortium and then you decide you wanna change your system to a different CMS, that is entirely possible. They may just need to adjust exactly how they are harvesting. Otherwise, there’s not much of a disruption or things that you need to think about outside that own migration of your own content to a different product.

There is amplified collections discovery. So like we saw in the KalaSphere example, everybody is going to go there first. It’s going to be higher on search engine optimization for Google results.

It’s going to be attractive to researchers for the one stop shop nature. And so the potential for discovery and use of your content is higher in the larger consortium portal than it would be if it was just in your singular discovery portal.

And there’s typically low cost, low risk, especially if you are not the institution supporting the broader consortium model. You are only a member or contributor.

The risk and cost is only as low as your participation.

Many of the consortiums, at least the ones that I’m familiar with, there actually is no cost.

There may be, participation in membership coordinating or best practices discussions, but, typically, there is not a fee associated with participation. And, also, there’s just limited risks. So not needing to adopt different IT infrastructure, knowing that your data is being contributed but not actually accessible or editable by anybody else, the risks that are involved in perhaps the first two options are just not present here.

Challenges. So discovery portal, amazing as it is, has some challenges still. First of is data lag. So depending on how the consortium is harvesting or receiving the data And depending on how often their discovery portal itself is updated can contribute to a data lake. There are consortiums out there where the harvesting is happening every second and where the database is updating every second.

And then there are also consortiums where either due to technology or staff restrictions, maybe it’s updated once a month. So if that’s the case, what that can mean is changes you make in your database and that reflect in your discovery portal immediately.

They may not be reflected in the consortium discovery portal until a month later, for example.

And then the second one being dirty data. So when we’re in our own system, we always tend to have dirty data issues in general. It’s not a new concept to us.

But what can happen is that can amplify when we’re looking at the broader consortium discovery portal because everybody’s different data practices and potentially dirty data can enter into that discovery portal, which will hinder searching. It won’t stop it, but if we’re not speaking the same language, using fields the same, it will ultimately impact collection discovery and access. So, again, the dirty data piece is not new to us. It’s in our systems anyway in just a singular fashion, but those problems can be amplified or more frustrating when you’re participating and contributing to that larger consortium portal.

So for wrapping this up, we talked about three partnership models where using a creative partnership approach and thinking about how we use our collections management systems, what that can look like. And we talked about the unified hub, which is the concept of joining together in partnership but under a single database and what that can look like in a simple or more sophisticated version.

We talked about the peer to peer bridge, which is a specific use of the same CMS in a majority of cases and allowing pinpointed access into specific areas of each other’s collections.

And then we talked about the discovery portal, which is amplifying from our singular discovery portal concept and contributing toward a larger consortium of collections, typically themed by topic or by region and having the broader ability of discovery and access.

Among each of these, we talked about the examples, benefits, challenges.

And I encourage you, if any of these sound of interest, there are examples of peers who have gone before us and have entered into these different types of partnerships. And there’s some great, scholarship out there and lessons learned that we can mine through as we consider each of these approaches.

Before I leave you, I wanted to let you know that my newest book is now out, and Lucidea is offering a free e copy. And the book is Weaving a Digital Storytelling with Online Collections. So very much in theme with our content today in terms of making collections more discoverable and certainly with that discovery portal piece thinking about storytelling and what can happen next. So that is of interest. Please pick up your copy, and thanks to Lucidea Press.

And with that, I’ll hand it back over to you, Bradley.

Thank you, Rachel, for the wonderful presentation. And to our audience, if you would like to learn more about our museum collections management system called Argus, please feel free to visit our website or reach out to us at sales@lucidia.com, and we’d be happy to have a chat with you.

If you have any more questions on any of our software or our company, our contact details are listed on the screen, and please stay tuned for more webinars and content related to this series.

On behalf of the Lucidea team, I thank you all for attending today, and until next time. Thank you.