Capabilities

Declares what an implementation supports — the spec version it targets, whether it provides the optional deposit surface, the registered extensions it implements, and the search filters and facets it provides.

apiVersionstringrequired

The version of this specification that the implementation targets.

Example: 0.3.0

extensions objectrequired

The registered extensions this implementation provides, as a map of extension identifier to a details object describing how the extension is provided. Presence of a key means the extension is implemented; the value is an empty object when the extension has no extra details to communicate.

Unregistered experimental extensions use an x- prefixed identifier and are outside the scope of this specification.

segmentsobject

Details the implementation communicates about its segments support. The extension currently has no extra details to communicate; the value is an empty object.

property name*object

deposit objectrequired

Declares whether the implementation provides the optional deposit surface, and on what terms. This block is REQUIRED in /capabilities: every implementation states its position explicitly, so a client never has to infer read-only-ness from a missing key.

supported is the single flag clients check. When it is true the implementation provides the deposit and RO-Crate endpoints, and idMinting and fileUpload MUST also be present. When it is false the implementation is read-only, the deposit and RO-Crate endpoints are not provided, and the remaining fields MUST be omitted.

Deletion behaviour is declared separately, in the top-level tombstonePolicy.

supportedbooleanrequired

Whether the implementation provides the deposit surface. true - deposits are accepted and the deposit and RO-Crate endpoints are available; false - the implementation is read-only.

Example: true

idMintingstring

How RO-Crate IDs are minted at deposit creation. client - the client MUST propose an ID; server - the server always mints one; both - the client MAY propose an ID and the server mints one when absent.

Possible values: [client, server, both]

Example: both

fileUploadstring[]

The file staging modes the implementation supports on PUT /deposit/{id}/file/{fileId}. inline - the file's bytes in the request body; presigned - transport metadata in the request, bytes uploaded directly to a returned target. New modes may be added by revision of this specification; clients MUST ignore values they do not recognise.

Possible values: [inline, presigned], >= 1

Example: ["inline","presigned"]

depositTtlSecondsinteger

How long an open deposit lives before expiring. When absent, expiry is implementation-defined and clients should not rely on any particular TTL.

Possible values: >= 1

Example: 604800

maxFileSizeBytesinteger<int64>

The largest file the implementation accepts in a deposit. When absent, no limit is declared.

Possible values: >= 1

Example: 5368709120

tombstonePolicystringrequired

What deleted resource URIs return. "410" - deleted URIs respond 410 Gone with a Tombstone body; "404" - deleted resources are indistinguishable from those that never existed. One policy covers RO-Crate, entity and file URIs alike; implementations MUST NOT mix them.

REQUIRED of every implementation, whether or not it provides the deposit surface: entities and files are mandatory core, so any catalog may hold a URI that no longer resolves.

Possible values: [410, 404]

Example: 410

search objectrequired

Declares what the implementation's search endpoint supports — the filters that may be used in search requests and the facets returned in search responses.

Every field declared in facets MUST also be declared in filters, so that clients can always turn a facet value the user clicks into a filter on the next request. Filter-only fields (for example date fields, which are filterable but not meaningful as facets) are permitted.

filters objectrequired

The fields that may be used in the search request's filters object, as a map of field name to a declaration of the field's type and display label. Requests using a field not declared here MUST be rejected with a 400 ValidationError.

property name* FilterCapability

Describes a search filter field the implementation supports. The type tells clients which UI element suits the field (e.g. a date picker for date, a toggle for boolean) and which request syntax the field accepts: date and number filters accept a single range object or a non-empty array of range objects (matched as an OR of the ranges) as well as an array of values; string and boolean filters accept an array of values only.

New filter types are added by revision of this specification; clients MUST hide filters with a type value they do not recognise rather than fail.

typestringrequired

The filter's value type. date values are ISO 8601 strings. boolean values are the strings "true" and "false".

Possible values: [string, date, number, boolean]

Example: date

labelstring

An optional human-readable display label for the filter field.

Example: Date created

facets objectrequired

The facet fields the implementation supports in search responses, as a map of facet field name to its declaration. Every field listed here MUST also appear in filters.

property name* FacetCapability

Describes a search facet field the implementation supports.

labelstring

An optional human-readable display label for the facet field.

Example: Language

Capabilities

{
  "apiVersion": "0.3.0",
  "extensions": {
    "segments": {}
  },
  "deposit": {
    "supported": true,
    "idMinting": "both",
    "fileUpload": [
      "inline",
      "presigned"
    ]
  },
  "tombstonePolicy": "410",
  "search": {
    "filters": {
      "inLanguage": {
        "type": "string",
        "label": "Language"
      },
      "mediaType": {
        "type": "string"
      },
      "createdAt": {
        "type": "date",
        "label": "Date created"
      }
    },
    "facets": {
      "inLanguage": {
        "label": "Language"
      },
      "mediaType": {}
    }
  }
}