After discussions with Director Porter and CDL's John Kunze, the museum has decided to offer ARKs (archival resource keys) for all* of its cataloged objects. (NB: "all" objects would exclude TEMP numbers—and numbers without "TEMP" that are nevertheless temp numbers—as well as objects borrowed from other museums. ARKs would be minted for all accessioned and deaccessioned objects.)
The immediate impetus is the upcoming publication of two monographs (which are estimated to be ready for publication by late spring) that reference specific objects and groups of objects in the museum's collections. ARF is also looking to reinvigorate its publication series, and has requested that we offer DOIs or similar that can be cited in publications.
After discussions with John Kunze of CDL, we have decided to use ARKs for all of our objects rather than DOIs, although DOIs based on these ARKs can be minted as needed (the DOIs would resolve to ARKs, and the ARKs would then point to the museum's current record for the object).
The museum has been granted an EZID account for creating ARKs (username "hearstmuseum").
The ARKs would be based on Museum numbers rather than CSIDs, and the museum will therefore need to keep future modifications to existing Museum numbers to an absolute minimum to minimize the amount of duplicate ARKs resolving to the same object.
The two paths to implementation through EZID are:
Mint static ARKs through EZID. This will possibly require making a record of the static ARKs somewhere (creating and populating a new field in CSpace?), conducting regular checks for changed Museum numbers, and creating additional an static ARK for Museum numbers that have changed since the initial ARK was minted.
Using EZIDs passthrough suffix option, where only a single redirect record is created in EZID, and having CDL's N2T resolver redirect the ARK's suffix content to a service maintained by ETL on behalf of the museum. This service would then interpret the suffix information to redirect the user to the appropriate URL.
John Lowe prefers the second option, but it is not without complications. The most obvious complication is that museum numbers contain ARK-incompatible characters such as hyphens and commas. Thus, the ARK resolver service would need to decode an ARK-compatible suffix into a Museum number (and another service—perhaps the Portal?—would need to dynamically encode Museum numbers into ARK-compatible suffixes and present the resulting (dynamic) ARKs on Portal pages for citation).
Additional information on this approach is available in this document.
Furthermore, because authors (including the authors of the first two publications that are expected to publish PAHMA ARKs) will sometimes want to use a single ARK to point to a group of objects rather than to a single object, the museum would like to be able to offer such "group ARKs" to authors upon request. If such group ARKs cannot be supported by the solution adopted for single ARKs, these group ARKs can probably be hand-minted on demand as long as the base URL used for group ARKs differs from that used for single ARKs so that these requests don't get subjected to EZID's suffix pass-through service.
Director Porter has also indicated that it would be nice to someday also offer ARKs for specific sites, collectors, donors, and so on, although we don't currently have publicly displayed records for Places, People, and other non-object records. But on the hope that we one day will offer such records to the public, we'll want to make sure we keep this option open in whatever ARK implementation we decide on.