Concept Service REST APIs
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
Vocabulary and Authority Overview
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: