How it Works: Noids - mlibrary/hydra-prototype GitHub Wiki

Background links

• ActiveFedora::Noid
• Noid
• University of California Noid Paper
• When noids enter the Hydra sphere

Modules

CurationConcerns::Noid

Adds behavior to the curation_concerns model concerns to favor a Noid-minted identifier instead of Fedora's default UUID. Effectively, this suggests only resources-we-really-care-about get Noids, as opposed to "system" objects (members containers, bitstreams).

ActiveFedora::Noid

Defines a default noid template (.reeddeeddk). It also has hooks to "treeify" all Fedora identifiers to automatically ensure that all objects don't hang off the root of the repository (e.g. m039k4882 ➔ m0/39/k4/88/m039k4882, and m039k4882/members ➔ m0/39/k4/88/m039k4882/members).

ActiveFedora::Noid::SynchronizedMinter is the default minter, which uses mutexes to manage a statefile (by default, /tmp/minter-state, but can be overridden in the application's config/application.rb).

Noid

What actually generates the noid from a given template. From the PDF:

A Template is a coded string of the form Prefix.Mask that is given to the noid dbcreate command to govern how identifiers will be minted. The Prefix, which may be empty, specifies an initial constant string. For example, upon database creation, in the Template

tb7r.zdd

the Prefix says that every minted identifier will begin with the literal string tb7r. Each identifier will end in at least two digits (dd), and because of the z they will be sequentially generated without limit. Beyond the first 100 mint operations, more digits will be added as needed. The minted noids will be, in order,

tb7r00, tb7r01, ..., tb7r100, tb7r101, ..., tb7r1000, ...

Questions

How do we mint in a distributed environment? Given that a custom minter can be plugged into the noid machinery.

Is it worth exploring service-oriented prefixes? e.g. mdr.x346f0157 and asset.rx913p88g and dp.x346f3449 and mpub.x346f032w? (No preference.)