Page History

...

For example, for an ingest operation, it represents a set of Add operations for each datastream created on ingest; for a modifyDatastream operation it represents an Update for the datastream if the API-M method parameters include updated content.

Messages are only dispatched for based on modifications to the latest versions of datastreams; it is assumed that consumers are only interested in the current , and not historic, versions of contentstate. So for example if the latest version of a datastream is purged, this is represented as a modification, with the new content being the now-latest version (the version preceding the one being purged).

Data model

A ContentObjectModification is used to encapsulate a set of ContentItemModifications

...

• The User making the change
• The date/time of the change
• The URI identifier of the Fedora digital object (the REST API endpoint of getObjectProfile)
• The URI identifier of the parent Fedora digital object (not implemented - see Issues)
• The type(s) of the Fedora digital object (not implemented - see Issues)
• A textual description of the modification (used for information/debugging only)
• A set of ContentItemModifications

Each ContentItemModification represents:

• The URI identifier of the datastream (the REST API endpoint of getDatastreamDissemination)
• A URL for the modified content location (the datastream version) - present for Add and Update operations, not present for Delete operations and state changes
• The internet media type (MIME type) of the content - present for Add and Update operations, not present for Delete operations and state changes
• The type of modification (Add, Update, Delete) - not present for state-only changes

• Wiki Markup
  The state change of the datastream, specifying the previous and new states \[1\]

  • For Add operations the previous state is not specified

...

ContentObjectModification implements Iterable<ContentItemModification>

AtomPub serialisation

Content changes using the above POJOs are serialised to AtomPub as follows:

An AtomPub Feed for the ContentObjectModification with:

• a Category for the server version
• a Category for the message format
• an Author for the user
• a Title for the textual description
• an Updated item for the date/time of modification
• a Link with a relationship REL_VIA for the object URI
• a Link with a relationship REL_RELATED for the parent object URI
• Category elements for the object type(s)

An AtomPub Entry for each ContentItemModification:

• an Author for the user (same as Feed)
• a Title (same as Feed)
• an Updated entry (same as Feed)
• a Content item with the URL of the content location and the MIME type (for Add and Update)
• a Link with a relationship REL_VIA for the item's URI
• a Summary item with a textual description (mandatory, but not used for anything)
• Category items for the before and after states (for state changes)
• a Category item for the type of modification (not present for state-only changes)

Example messages

Code overview