Brief Description

Assumptions

References

Vocabulary and Authority Overview
Concept Service Description and Assumptions
Concept Service Entity Diagrams
ConceptAuthority Schema, ConceptAuthority Schema and Mockup - UCB Version

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

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

Concept instance schema

Create and Update should use the following schema.

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: