Skip to end of metadata
Go to start of metadata
On This Page

CollectionSpace will have tenant-specific bindings for various components. A binding may include information listed below and more...

  1. Tenant identification (tenant ID, name, display name, etc.)
  2. Repository domain ID assigned to the tenant
  3. Services used by the tenant
  4. Service bindings including
    1. CollectionSpace entity schemas
    2. Repository workspace where objects are stored for the tenant
    3. Document types, etc.
  5. Roles and policies for access control
  6. Vocabularies used
  7. Application configuration in XML
  8. UI specific artifacts such as stylesheets, icons, images, etc.

Such a binding would be created/generated at the time of provisioning a tenant. Following describes some of the major components of a tenant binding. The schema for tenant binding is here.


tenant config

TenantBindingConfig contains one or more tenant binding of type TenantBindingType.


A TenantBindingType consists of the following.

  1. Each tenant binding consists of one or more service binding. A service binding represents a CollectionSpace service used by the tenant.
  2. A system generated unique tenant ID. This identifier is generated when a tenant is provisioned in the system.
  3. A name for the tenant. Usually this would be a domain name without TLD suffix. It should also include subdomain if applicable, e.g. phama.berkeley.
  4. A displayName is English-like name of the tenant. For example, "Museum of Moving Images" or "Phoebe Hearst Museum of Anthropology".
  5. Version indicates the version of the tenant binding.
  6. Each tenant is assigned a separate space in repository. This space is called repositoryDomain.

Following is the XML data type for the tenant binding.

tenant binding


A ServiceBindingType describes a tenant specific binding for a CollectionSpace service.

Following is the schema for ServiceBindingType.

service binding

It includes the following.

  1. The meta-data for object being exchanged with the service consumer. The object could be a CollectionSpace entity object such as CollectionObject, Loan, Intake, etc. Such an object could consist of one or more parts based on how the common schema is extended.
  2. Document handler to process the service requests
  3. One or more validation handlers (validatorHandler) to validate the content received from the service consumer
  4. The reposiotryClient indicates the name of the repository client used by the service to store the object data.
  5. The name indicates the name and version indicates the version of the CollectionSpace service.


ServiceObjectType describes tenant specific meta data for each CollectionSpace entity served by a distinct service. This part of the binding is created by the tenant administrator. It contains the following elements.

  1. One or more tenant defined properties.
  2. One or more parts the object is made up of. For example, a collection object could consist of parts such as system data, common collection object data, museum domain specific collection object data and tenant specific collection object data.
  3. A serviceHandler is an application defined handler used to process the object data. This handler should implement the ServiceHandler interface (TBD) and follow the packaging instructions (TBD) to deploy it at runtime.
  4. Each service object is uniquely identified using ID, name and version.
  5. A tenant administrator could update the timestamp to indicate when this service binding was updated. A tenant provisioning service/tool (TBD) could update this field as well.

Following snippet shows the schema for the ServiceObjectType.

service object type

An ObjectPartType represents the metadata for a part of a CollectionSpace entity. Following describes the elements of an object part metadata.

  1. Pre-defined properties (name value pairs) by the tenant.
  2. Content meta data of the part as described by ObjectPartContentType. Various types of content is possible. Examples are XML content, printed-quotable content, based 64-encoded content, etc. The binding only contains the meta data for the content that is marshalled or unmarshalled at runtime by the service.
  3. The control group indicates to the service where the content resides. This is similar to Fedora control group. Following are the control groups supported by CollectionSpace.
    1. External indicates to CollectionSpace that the content resides in a 3rd party data store, e.g. MediaVault or CalPhoto.
    2. Managed content is actively managed by CollectionSpace. A collection object stored in CollectionSpace repository is marked as managed content.
    3. Inline content is the content that is provided by the tenant at the time of provisioning of the service. This is a static content that is inserted by the service.
  4. If a part content is required to have version, it should be marked as such using the versionable attribute. By default a part is not versionable.
  5. A change in the part content could be auditable. While the global audit option would be available at the tenant level (TBD), at individual part level an audit could be turned on or off by using the auditable attribute.
  6. The label is an application defined lable to uniquely identify the part in service operations (CREATE, READ, UPDATE and INDEX). This label is used to identify and retrieve part content from a multi part MIME message exchanged with the consumer.
  7. A tenant administrator could update the timestamp to indicate when this part metadata binding was updated. A tenant provisioning service/tool (TBD) could update this field as well.
  8. The order attribute indicates in what order this part should be processed by the CollectionSpace service.
object part type"controls=true


The ObjectPartContentType describes the meta data for the object's content. Following consists of the part content meta data.

  1. An optional content digest. The digest could be created using any of the supported digest algorithms as shown in XML schema below in ContentDigestType.
  2. The type of the content. It could be XML content, base64 encoded binary content or a reference to the content found outside of the CollectionSpace. The XML data type called XmlContentType shown below includes schemaLocation and namespace URI to be used while validating the XML content.
  3. A tenant administrator could implement the PartHandler interface (TBD) and configure it as partHandler. This handler would then be used by the CollectionSpace service to handle the processing of the part content at runtime. The packaging instructions (TBD) should be followed by the tenant administrator in order to successfully deploy the handler at runtime.
  4. The contentType indicates the MIME media type for the part content.
object part content type


The following example of a tenant binding is for tenant named Phoebe A. Hearst Museum of Anthropology (pahma.berkeley). This binding uses a repository client named nuxeo-java. The repository client is defined elsewhere in service layer configuration. This binding has only one service binding named CollectionObjects. This binding name has 1-1 relationship with the name of the service CollectionObjects. The service binding for CollectionObjects service for tenant "", consists of the following 4 parts.

  1. A system part named collectionobjects_system used by the service layer to propagate error codes and messages in responses. The schema for this part is defined under namespace
  2. A common part named collectionobjects_common using schema from namespace
  3. A domain specific extension named collectionobjects_anthropology using schema from namespace
  4. A tenant specific extension named collectionobjects_anthropology_pahma using schema from namespace
example tenant binding for CollectionObject service