Child pages
  • Ingest
Skip to end of metadata
Go to start of metadata






1.00 (2016-10-25)




Merritt Ingest Service


Not available

More information:

Curation home page

The Ingest micro-service provides a means to add new digital content into the curation environment for active management by the Program. Using terms defined by the Open Archival Information System (OAIS) reference model, the Ingest service accepts Submission Information Packages (SIPs) and converts them into Archival Information Packages (AIPs). This process may involve the use of other micro-services: the Transformation service to transcode objects into normative forms defined by internal standards; the Characterization service to produce relevant descriptive information for management in the Inventory service; and the Storage service to manage object files.

The Ingest micro-service defines the following conceptual entities:

  • Batch. A set of jobs.
  • Job. The processing of a single digital object.
  • Profile. An indication of the type of digital object being ingested.
  • Handler. A specific ingest sub-task.
  • Notification. The final status resulting from an ingest.

A Ruby library for submitting objects to the Merritt ingest system has been developed; please see the bitbucket page for more information.


Programmatic submission to the Ingest service can be made using the API.  As described in the Ingest specification document, the request arguments are:




(optional) The name of the file


The file itself, i.e. its contents


Valid values:

  • file
  • container
  • object-manifest
  • batch-manifest
  • container-batch-manifest
  • single-file-batch-manifest


The submission profile, which we will provide to the submitter


(optional) ARK identifier, if known


(optional) local identifier, if known


(optional) valid values:

  • adler-32
  • crc-32
  • md2
  • md5
  • sha-1
  • sha-256
  • sha-384
  • sha-512


(optional) digest value, hex-encoded string


(optional) creator


(optional) title


(optional) date


(optional) descriptive note


(optional) valid values:

  • anvl
  • csv
  • json
  • turtle
  • xhtml
  • xml

All of the enumerated values (file type, digest type, response form) are case-insensitive.

Sample cURL

curl --silent -u user:password \
-F "file=@ucsf_etd_200609.checkm" \
-F "type=container-batch-manifest" \
-F "submitter=username" \
-F "responseForm=xml" \
-F "profile=merritt_demo_content" \
-F "localIdentifier=local-ID-test" \
https: //

Using the secure https connection with curl may require additional certificates. Please contact UC3 with any questions.

METS feeder

The steps to submitting content using METS:

1) First, create a METS document that points to all of the component parts of a digital object, using one of the profiles described in the CDL Guidelines for Digital Objects. The METS documents and all of the digital object components should be on a web-accessible server. If you need to open up a firewall, we can give you the addresses of the machines that need to access the files.

2) Create a "manifest," which is a just simple list of all of the URLs for METS documents. (This list must be on a web-accessible server also.) The METS manifest is a text file with line breaks between each METS document, looking like this:

http: //URL/subdir/metsfile1.xml
http: //URL/subdir/metsfile2.xml

3) Then send the URL of the manifest to the feeder. The URL should have this format:


with these elements:

  1. feederURL (for Merritt stage, this is; for production,
  2. userID (login)
  3. authCode (password)
  4. accessGroupID (collection name--we can let you know the collection name) (nb–without the _content suffix)
  5. fillin (Optional. if "false", this will suppress fixity check of object components by feeder, speeding up the submission. The implicit default is &fillin=true)
  6. manifestURL (with URL encoding replacing ":" (%3a) "/" (%2f) etc)

To fill in some of the variables, it would look like this (no line breaks):

curl "http: //"

4) We will retrieve the list and ingest the METS documents.

Polling status


Provide status of a Merritt Ingest submission during and after processing.  Status responses include:

  • PENDING: Queued for Ingest service
  • CONSUMED: Currently in process
  • COMPLETED: Successfully processed
  • FAILED: Unsuccessfully processed

Polling REST API


Single object

  • Other requests are passed directly through to couchDB. See:
  • Job, Primary and Local IDs (JID, PID, LID) must be JSON URL encoded and double quoted.  For example, %22localid001%22 for localid001.

Supports HTTP Basic. Credentials provided by Merritt team.

  • No labels