Use Case 42 - Hide or Unhide an Object from DiscoveryΒΆ

View document revision history.
Alter discovery of an object through search, but do not alter ability to retrieve the object given its identifier.

A content owner or manager would like to prevent further discovery of an object though ensure that references to the object (using its identifier) remain valid. Or, if the object is already hidden from search, return it to a discoverable state.

This is operation is called “Archive” in the DataONE service APIs.


  • Client, a content manager or owner (must have write permission)
  • Coordinating Node
  • Member Node


  • Client has authenticated to the desired level.
  • Object has been synchronized by the Coordinating Nodes
  • The object may be replicated to other Member Nodes


  • A user with write permission calls CNCore.archive()
  • A user with write permission calls CNCore.unarchive()

Post Conditions

  • The archive property of Types.SystemMetadata is altered
  • System metadata for all replicas of the object is updated
  • The search index operated by Coordinating Nodes is updated accordingly

Figure 1. Use case 42 diagram showing actors and components involved in this action.


Figure 2. Sequence diagram for Use Case 42 illustrating the high level sequence of operations associated with altering discoverability of an object.


  1. For the GET operation, should isAuth() be performed only by CNs? Relying on the MN system metadata requires trusted implementation of the MN system and consistency of system metadata across all MNs (which will be the case, though with uncertain latency). Requiring all isAuth() operations to be performed by CNs will increase trust in the operation (assuming the operation is not spoofed by a MN) though will increase load on CNs. This should be specified in the Authorization use case.
  2. Data sent to watchers might include: timestamp, object identifier, user id, IP of client.