Interacting with other repositories

[mikethicke]

One of our goals with the Commons is to be interoperable with other academic platforms and services. How should the Commons repository interact with other open repositories?

A built-in option with Invenio is the "metadata-only" deposit. This allows users to create deposits on our platform with an external DOI. Then other users will find that deposit when searching our site and ultimately be able to access the content on its home repository. The advantages of this for our users is that it makes their content more discoverable. The advantage for us is that it makes people more likely to use our platform when looking for content.

While I think this is a reasonable feature, I don't think it's one we should rely on for interoperability and I'm not even sure it's a good feature to have at all.

Reasons why I think "metadata only" deposits are bad:

1. They are static. If the metadata of the original deposit changes, or in the extreme if the underlying deposit is retracted, our deposit won't be updated.
2. They create ambiguity. If someone wants to have a discussion about a deposit, should it be in reference to the deposit on our repository or the source repository? If we're trying to build social interactions around deposits, this could cause undesired fragmentation in discussions.
3. They duplicate data. If used at scale, say through auto-importing content from another repository, they could cause our database to grow unsustainably. This is essentially the problem we're having with Mastodon, where data from external instances is stored in our local database, causing it to grow far faster than our local instance.
4. They are ad hoc. If we rely on users to make metadata only deposits, we just get what our users create.

What I think is a better solution:

Search.

It would be better if we were able to integrate our search, either the general Commons search or the repository's search, to connect to partner networks and repositories.

1. Search is dynamic. When the underlying deposit changes, so do the search results.
2. There is no ambiguity. There is a single location and a single DOI for a deposit.
3. There is no duplication. We aren't storing anything in our DB.
4. They are not ad hoc. When we partner with another organization, we get access to all the content they provide, and vice-versa.

PS: There is a good article on repository aggregators here, though it is somewhat old.

[bjr70]

Could OAH-PMH be helpful here? https://www.openarchives.org/pmh/

[monotasker]

I see your point in a lot of this, Mike. Especially the danger of large-scale duplicated data and database size. I agree with you about search integrating other repositories.

I still wonder whether that's enough reason to get rid of metadata only deposits, because I'm not sure that simply duplication of other repositories is the only use-case for them. One valid use-case I can see for metadata-only deposits is where an open-access version of a journal article is made available on the web-site of the print publisher. I think it's useful for a user and us if they can create a record (using the original DOI if there is one) that points to the open-access files published elsewhere.

I think you can get other similar use cases where, say, an open-source project hosts its code on github. The user doesn't want to move all the code into the repository, but they do want it to be discoverable and available for discussion on the commons.

One basic question is "What is a repository deposit for?" Is it only to provide accessible storage for material? Or is it also to make material accessible and easily available for community discussion? I think it's both, particularly in the context of a social network like the Commons. I like the purity of "one document, one deposit" on the web in theory, but in practice I think duplication and pointers are important if our priority is the communication.

So I'm wondering whether we can find ways to limit the scale and nature of metadata record creation, rather than banning them?

[bjr70]

We definitely shouldn't get rid of metadata-only deposits. There have been several occasions where assets were larger than the size limit for deposits and users in the current database had to create a PDF one-sheet to upload and then point to the content hosted elsewhere. We want to avoid that, even with increased deposit size limits.

One basic question is "What is a repository deposit for?" Is it only to provide accessible storage for material? Or is it also to make material accessible and easily available for community discussion? I think it's both, particularly in the context of a social network like the Commons. I like the purity of "one document, one deposit" on the web in theory, but in practice I think duplication and pointers are important if our priority is the communication.

I agree. Repositories are about sharing and discoverability, not just accessible storage.

[zwhnz]

"Repositories are about sharing and discoverability, not just accessible storage." +1000. This is a big selling point for us! Repository as an interactive, social space.

[mikethicke]

Yeah, ultimately I don't think we should turn off metadata-only deposits. But I'd be wary of using them for any kind of automated harvesting, such as that facilitated by OAI-PMH. FWIW there are already open access repository aggregators--do we want to compete with those?

One problem with search is the lack of standardization, but that is something we could work on with partner repositories---either by developing standards or by designing our search so that it is easy to adapt to others' search APIs.

[bjr70]

Completely agree, Mike. We don't want to create records or duplicate what the aggregators are doing. Search would be fantastic, though. Is this discussion public? I wonder if creating a conversation if this isn't an appropriate one and asking some of our colleagues - especially librarians - on Mastodon to weigh in would be helpful or highlight some opportunities for collaboration?

[zwhnz]

Agree re: not competing with aggregators. Whatever we do should be scoped to specific use cases, the main ones we've identified being "what if an institution already has a repository?" and "how do we cooperate with the other Commons in a way that benefits our users?". And the USRN project is leading the conversations about standardisation and integration, so I want to keep us in line with that work. We can reach out once we've got a clearer sense of our goals internally.

[zwhnz]

To read: https://sparcopen.org/wp-content/uploads/2022/10/Desirable-Characteristics-of-Digital-Publication-Repositories-APPROVED-20230331.pdf

[marynamovchan]

Repository as an interactive, social space