Developing Persistent Identifier module for Omeka-S

The Omeka team is currently planning the development of a Persistent Identifier (PID) module for Omeka-S, which will allow users the option of assigning PIDs to Omeka items for the purpose of stable ongoing URL linking and reference. The module will be able to both mint/assign new PIDs to items, as well as retrieve and update existing PIDs for imported items. It will also be designed in a flexible way in order to accommodate different PID services such as DOI, ARK, Handles etc.

One central issue to implementation is how Omeka-S item URLs are currently assigned. There is no internal persistent URL/landing page for an item: the URL depends on the Omeka-S Site where the item is published, and an item may have multiple URLs if it is published on more than one Site. Thus there is currently no obvious single URL to point a PID at for a given Omeka-S object.

We have a few ideas for addressing this issue, but would like to hear more from our user community. Which of the following options makes the most sense to you? Do you use or plan to use PIDs in your collections, and how would you like to see them integrated with Omeka-S?

Option 1: On the Site Resources page, include an option to ‘Update Persistent Identifiers’, which will go through all items assigned to the site and either mint/assign a PID, or retrieve a PID from the items identifier field and use the PID API service to update that item’s PID target to the current Item URL.

Pros: item page will retain theme/branding
Cons: updating/assigning PIDs will require user intervention whenever items are added/removed, items on multiple Sites can only have one PID targeted URL

Option 2: Ability to create a separate, site-agnostic landing page for an item, and assign the PID to point to this page.

Pros: a single, stable URL for a PID to point to no matter if the item is published to a Site or multiple Sites
Cons: a ‘generic’ landing page with no Site-specific theme or branding

Option 3: similar to option 1, but PIDs are assigned independently within the context of each Site. In other words, an item on multiple Sites would have multiple PIDs, each pointing to the item on each separate Site.

Pros: retain theme/branding, allow for an item to have several stable PIDs across several sites
Cons: a single intellectual item with multiple PIDs assigned kind of goes against the whole point/spirit of assigning PIDs

Are we missing anything? Feel free to share any other ideas/thoughts/concerns surrounding PIDs and Omeka-S. Thank you!


The API already provides an internal persistent URL for an item at the api/default route. For example, points to the JSON-LD serialization of item #1. I suppose you could add content negotiation to redirect the client to an HTML representation of the item, possibly landing on Option 2 above. I don’t see a compelling reason to specify an item’s site given the nature of Omeka S as having a pool of resources. The site is incidental, and any representation of an item will already have a list of sites to which it belongs.

1 Like

Very helpful Jim, thanks! I think everything depends on what exactly the collection holder and/or end user expects to see after clicking on the PID. The JSON-LD result is great for pure data but would likely not be acceptable for an author citing a resource in a publication, or an online exhibit linking out to an Omeka item–they would want something understandable to their intended audience.

So content negotiation to some sort of human-readable landing page would need to be at the very least an option, but the JSON-LD persistent URL could be a useful building block in that process.

Of course Jim 's proposal is the way to go. This is already standard practice in the Semantic Web for some decennia to handle uri’s. The content negotiation determines the response to the resource uri.

Note that there is already a persistent identifier module for Omeka S that create opaque identifiers for ark.: the module Ark.

I also feel that option 2 is the most sustainable and coherent.

The resulting page could still prominently show the sites where the item has been added, encouraging the viewer to see the item in context.