Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Applying Authority API

Description

  • UI should not call the currently used GET /search/linked-data/authorities for searching for authorities.

  • Instead, UI should utilize the existing GET /search/authorities and GET /browse/authorities APIs to search for authorities (same APIs used in inventory).

  • Each search result from these APIs will include an "id" property for the candidate.

  • When a user selects a candidate from search result, the UI should call the GET /records/{id}/formatted?idType=AUTHORITY API to display detailed information about the selected authority. The response from this API will include a parsedRecord -> id property, which represents the srsId.

  • After the user selects an authority and clicks "link," followed by "Save" in the work (or instance) form, the UI should send a POST /resource request to the mod-linked-data module (as it is doing today).

    • For new authorities that is assigned to a work in the current session, send the “srsId” of the selected authority in the API request payload. API payload will be enhanced to support “srsId” property as part of .

    • When an existing work is opened for editing, UI makes call to GET /resource/{id} API for pulling the data. No change is made in the response of this API. When user save the work without making any change to the associated authorities (say, not updating the “creator of work”), send the original “id” (that was received in GET /resource/{id} response) in the PUT API request payload.

Example:

User opened an existing work, which has one creator, 2 contributors and 3 subject headings for editing. Let us assume user replaced one contributor with a new one and added a new subject heading** and clicked Save. The request payload to PUT /resource/{id} API should be as given below.

 

 

** we do not support adding subject headings today. We will support it in near future.

Environment

None

Potential Workaround

None

Attachments

3

Checklist

hide

Activity

Show:

Tetiana KovalchukOctober 14, 2024 at 9:36 AM
Edited

Doug LoynesOctober 10, 2024 at 4:38 PM

- Let’s keep the scope tight. We can live with option 1, for now. And then maybe introduce improvements to the UI later (if/as we have capacity, that is).

Siarhei KarolOctober 10, 2024 at 5:43 AM

Edit form is generated and rendered dynamically based on the profile.
Hiding “Subclass” subcomponent requires adding additional logic to the schema generation mechanism (as well as the record-to-schema mapping logic).

So I can propose two options:
1. Show “Subclass” subcomponent with the empty value until the user saves a record in the database (as it works now).
2. Add “Subclass” hiding logic in the scope of a new ticket.

Punnoose Kutty Jacob PullolickalOctober 6, 2024 at 12:42 AM
Edited

Hi
I talked with on Friday & this is what we think

1. Let us ignore the requirement "Non-LC authorities (e.g. FAST) should not be listed, as these values will be assignable to a linked data resource." for now. Doug will update the ticket.

2. Regarding subclass: For newly assigned authorities in the “current session” (using the lookup plugin), we will not show the “subclass” value (as we will not know the “subclass” till the work is saved). Let us hide the “subclass” field in this case. When an existing work is opened for viewing / editing, then GET /resource/{id} API will give you the “subclass” value. We will show the subclass in this case.

Siarhei KarolOctober 4, 2024 at 11:41 AM

  1. Authority Source facet contains a list of options. In was mentioned:
    "Non-LC authorities (e.g. FAST) should not be listed, as these values will be assignable to a linked data resource."
    Which field from the API call can be used for the filtering the list of these options? As per discussion, we cannot use a regular "id" because it can be changed.
    Example of the API response:

     

  2. There is a linked “Subclass” field the work form:


    Looks like the API response with the search results doesn't contain any fields which can be used to map the Authority record to the Subclass field. What else can be used for this?


could you please clarify this?

Done

Details

Assignee

Reporter

Labels

Priority

Story Points

Sprint

Development Team

Citation

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created September 27, 2024 at 2:18 PM
Updated October 14, 2024 at 12:11 PM
Resolved October 14, 2024 at 12:11 PM
TestRail: Cases
TestRail: Runs