Brief Description

Describes an entity for a concept, with structure among concepts.

For a full description, visit the Service Description and Assumptions page.

Assumptions

Concepts can have a default generic use of concepts or terms (providing a flat namespace).
However, Concept is designed to allow multiple instances to provide more specific namespaces (e.g., material, technique, culture).
The initial version will allow for a single term per Concept record for version 2.3 of CollectionSpace. Refactoring of authorities to support preferred/non-preferred term will allow variants of terms to be supported.

References

/wiki/spaces/COL/pages/666274310
Concept Service Description and Assumptions
Concept Service Entity Diagrams

REST-based API

The Concept Service offers a REST-based Application Programming Interface (API) to CRUD (create, read, update, and delete) operations on individual ConceptAuthority instances, and on the associated Concept instances. These follow the Common model for CollectionSpace REST services.

Note that the Concept instances are not directly "addressable"; they can only be accessed via the parent ConceptAuthority.

ConceptAuthority CRUD+L services
ConceptAuthority REST payload schemas
Concept CRUD+L services
Concept REST payload schemas

ConceptAuthority CRUD+L services

Create a ConceptAuthority

Creates a new ConceptAuthority record. Assigns a unique, service-specified CollectionSpace ID (CSID) to that ConceptAuthority record. Follows standard Create model. See the documentation of the ConceptAuthority schema, below. Example:

Read a ConceptAuthority

Reads an existing ConceptAuthority record, specified by its CollectionSpace ID (CSID). Follows standard Read model. See the documentation of the ConceptAuthority schema, below. Example:

Update a ConceptAuthority

Updates an existing ConceptAuthority record, specified by its CollectionSpace ID (CSID). Follows standard Update model. See the documentation of the ConceptAuthority schema, below. Example:

Delete a ConceptAuthority

Deletes an existing ConceptAuthority record, specified by its CollectionSpace ID (CSID). Follows standard Delete model. Example:

List ConceptAuthority instances

Lists existing ConceptAuthority records, with summary information for each. Follows standard List model, with pagination support. See the documentation of the ConceptAuthority-List schema, below. List supports the following common parameters for List results, pagination controls and query filters:

pgSz for page size
pgNum for page size

Examples:

ConceptAuthority REST payload schemas

The schemas below are abbreviated, and are thus illustrative. For a full list of the fields that may potentially be present in payloads when creating, updating, or reading individual ConceptAuthority records, please see the most recent ConceptAuthority schema.

ConceptAuthority instance schema

Create and Update should use the following schema. The value of vocabType must be "ConceptAuthority".

Read will return the above, plus additional fields (uri and csid) for access:

ConceptAuthority-List schema

List (and variants) will return the following schema:

Concept CRUD+L services

Concept instances are only accessible via the owning ConceptAuthority. The sub-resource is accessed with "items" (for consistency across all vocabulary-like services). In the examples below, the {concept-auth-id} parameter represents the CSID value of an existing ConceptAuthority instance.

Create a Concept in a ConceptAuthority

Creates a new Concept record. Assigns a unique, service-specified CollectionSpace ID (CSID) to that Concept record. Follows standard Create model. Must See the documentation of the Concept schema, below. Example:

You may also POST a part called

and any new relations there will be created. For example, this POST will add a relationship. Note that you must know beforehand the CSIDs of related terms. These are the CSIDs of two other Concept records, which must exist before this call. The special variable ${itemCSID} will be expanded to the CSID of the newly created Concept. (For Java use, please use the constant in CommonAPI.AuthorityItemCSID_REPLACE )

NOTE: if you wish to delete related items,
simply send relations-common-list as an empty element.
This is shown in a comment here:
http://wiki.collectionspace.org/display/collectionspace/Person+Service+REST+APIs?focusedCommentId=72220749&#comment-72220749

Read a Concept in a ConceptAuthority

Reads an existing Concept record, specified by its CollectionSpace ID (CSID). Follows standard Read model. See the documentation of the Concept schema, below. Example:

There are additional query parameters to get the relations for this item.
Query Parameters are defined and explained here, with examples: Authority REST API for Hierarchies\

Update a Concept in a ConceptAuthority

Updates an existing Concept record, specified by its CollectionSpace ID (CSID). Follows standard Update model. See the documentation of the Concept schema, below. Example:

You may also PUT a part called

and any new relations there will be created. Relations to the updated item which are missing from the relations list in the PUT will be deleted from persistence. No target records are deleted, just the relations records that point to target records. e.g. POST to authority with Concept "Drawing", with relations-common-list that has an entry for ${itemCSID} hasBroader "Art" creates a relations record that references both Art and Drawing. When a PUT is made that does not have the relation for Art, then Drawing has no relations, so the relations record for Drawing==>hasBroader==>Art is deleted, but both "Drawing" and "Art" Concept records remain.

Delete a Concept in a ConceptAuthority

Deletes an existing Concept record, specified by its CollectionSpace ID (CSID). Follows standard Delete model. Example:

List Concept instances in a ConceptAuthority

Lists existing Concept records, with summary information for each. Follows standard List model. See the documentation of the Concept-List schema, below. List supports the following common parameters for List results, pagination controls and query filters:

pgSz for page size
pgNum for page size
pt for partial-term matching, to support term completion.

Examples:

Concept REST payload schemas

The schemas below are abbreviated, and are thus illustrative. For a full list of the fields that may potentially be present in payloads when creating, updating, or reading individual Concept records, please see the most recent Concept schema (i.e. for an individual Concept term within a ConceptAuthority or vocabulary).

Concept instance schema

Create and Update should use the following schema.

On create, the value of inAuthority must match the identifier of the parent ConceptAuthority, and will not be modified once the instance is created.

You can view the full set of validation constraints on the data you submit when creating or updating Concept instance records, in the most recent CollectionSpace code, via this Java source code file.

Here's an example payload for creating a new instance:

Read will return the above, plus additional fields (uri and csid) for access:

Concept-List schema

List (and variants) will return a schema similar to the following example:

Browser not supported