[FOLIO-933] CODEX Instance contract definition v1 Created: 13/Nov/17  Updated: 12/Nov/18  Resolved: 04/Jan/18

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Jakub Skoczen
Resolution: Done Votes: 0
Labels: alpha, sprint26, sprint27, sprint28
Remaining Estimate: Not Specified
Time Spent: 7 hours, 30 minutes
Original estimate: Not Specified

Attachments: PNG File Mapping of Codex instance from local Inventory instance.png    
Issue links:
Relates
relates to UISE-27 Figure out which Codex fields supply ... Closed
relates to FOLIO-937 Design and implement "CODEX Instance"... Closed
relates to UISE-1 Understand usecases for the Codex Sea... Closed
relates to MODCXINV-3 expose CODEX instance endpoint Closed
Sprint:

 Description   

Agree on and prepare common API definition for implementation in local inventory and eHoldings (or a new module targeting ERM API).

The definition should be a simplified (flattened) subset of local Instance metadata schema: https://github.com/folio-org/mod-inventory-storage/blob/master/ramls/instance.json

and aligned with Codex Instance definition:

https://github.com/folio-org/raml/blob/master/schemas/codex/instance.json

Filters/search/sort suggested for Codex Search app: https://docs.google.com/spreadsheets/d/1RRLjsTl-SMGEh-5RkVwguffKW4dvkO-IwTdca6kFXeE/edit#gid=952741439



 Comments   
Comment by Jakub Skoczen [ 13/Nov/17 ]

Guys, I am curious if there are any specific limitations in ERM API that would make implementation of certain searching/filtering and sorting capabilities impossible?

Comment by VBar [ 13/Nov/17 ]

I would think that the Codex metadata would be based on the Codex metadata definition found here: https://folio-org.atlassian.net/wiki/download/attachments/5854462/codex.instance.json?api=v2

Comment by Jakub Skoczen [ 14/Nov/17 ]

VBar my hope is that we can align the two. This is one of the short term goals.

Comment by Carole Godfrey [ 14/Nov/17 ]

Jakub Skoczen to address your question - Yes - there are limitations with the ERM API in terms of current functionality (which is what will be available for alpha)

Specifically:

Searching:

  • limited to performing a search against 1 of the following 4 fields: titlename, publisher, isxn and subject (note - I don't believe subject is applicable since it is not a codex field)
  • search can be performed against a single field only (ie no secondary or tertiary searching)
  • search is limited to a basic keyword search

Sorting:

  • supports order by titlename or relevance (defaults to relevance)

Filtering

  • supports filtering by a single publication type

Also note, based on the current Codex data model for instance element (https://folio-org.atlassian.net/wiki/display/PLATFORM/Codex+metadata+elements), the following fields do not map to ERM API fields

  • sourceId
  • format
  • alttitle
  • series
  • languages
  • rights

Please note - there are future improvements planned for advanced search functionality but they will not be available for alpha

Comment by Hongwei Ji [ 15/Nov/17 ]

BTW current RM API reference for titles can be accessed from https://developer.ebsco.com/reference/rmref#get-custid-titles

Comment by Jakub Skoczen [ 16/Nov/17 ]

Thanks Carole Godfrey this is a good summary for our call today. Niels Erik Nielsen can you please list the differences between local Instance schema and Codex instance and indicate where it might be problematic to align them?

Comment by Niels Erik Nielsen [ 16/Nov/17 ]

The local Inventory instance record (https://github.com/folio-org/mod-inventory-storage/blob/master/ramls/instance.json) can be mapped to the Codex instance record (https://folio-org.atlassian.net/wiki/download/attachments/5854462/codex.instance.json?api=v2) as shown in this spreadsheet.

Ten fields can be mapped directly from the Inventory instance record to the codex instance record, either by mapping field-to-field or by mapping subfield-to-field.

Four fields are repeatable in the Inventory instance record but singular in the Codex record (altTitle, series, publisher, date). Seems the mapping would have to pick one of them (the first?) or concatenate them all into a simple string.

One Codex field – 'rights' – is missing from the Inventory instance record.

Comment by Niels Erik Nielsen [ 16/Nov/17 ]

All searching or filtering on Codex record attributes would be searching only Inventory instance records Jakub Skoczen.

Comment by Jakub Skoczen [ 16/Nov/17 ]

Thanks, Niels Erik Nielsen this is perfect! We also need to know what filter and sort capability is essential for Codex Search and if ERM can support it.

Comment by Jakub Skoczen [ 16/Nov/17 ]

We have decided to drop "creator" and only keep "contributor", "creator" should be a repeatable field with [name, type]

Comment by Jakub Skoczen [ 17/Nov/17 ]

VBar the link to the code instance schema does not seem to work any longer?

Comment by Hongwei Ji [ 17/Nov/17 ]

Jakub Skoczen We uploaded the data to github. Please update the link to: https://github.com/folio-org/raml/blob/master/schemas/codex/instance.json

Comment by Jakub Skoczen [ 17/Nov/17 ]

Hongwei Ji VBar the ramls repo is used for shared and implemented interfaces. Since for alpha we will implement only the "instance" piece would you mind moving all other schemas/ramls out to a branch or a different folder that clearly indicates that it is future work and not target for alpha?

Comment by VBar [ 17/Nov/17 ]

> We have decided to drop "creator" and only keep "contributor", "creator" should be a repeatable field with [name, type]

FYI the reason that we had kept both creator and contributor at the Codex level was to provide a "primary" and a "secondary" bucket of contributors. The names being aligned to Dublin Core Elements. For the time being the scope of metadata sources (Inventory, eHoldings) would only use the "primary" bucket of contributors anyways. However, when we start to broaden this to other types of resources we will likely need to re-introduce an otherContributors[] bucket to handle secondary contributors. This becomes an issue with things like movie credits which can have hundreds of names, but we realistically only care about the important ones such as main actors, director, producer etc....

Comment by Jakub Skoczen [ 17/Nov/17 ]

VBar Did I misunderstand that dropping the "creator" was the consensus we have reached on the call?

Comment by VBar [ 18/Nov/17 ]

> VBar Did I misunderstand that dropping the "creator" was the consensus we have reached on the call?

No that is correct and that's why creator has already been dropped. I'm just capturing here why creator was still there at the point of the call. As I mentioned then I was already aware of the desire to consolidate but couldn't quite remember during the call the reason why it was still there.

Comment by Mike Taylor [ 08/Dec/17 ]

Hi,VBar. Looks like the old Codex instance document at https://folio-org.atlassian.net/wiki/download/attachments/5854462/codex.instance.json?api=v2 has vanished. Do you have a new URL for it? I have a bunch of questions that I need to get settled for my work on the Codex UI module, and I suspect at least some of the answers are in that document.

Comment by Hongwei Ji [ 08/Dec/17 ]

Mike Taylor https://github.com/folio-org/raml/blob/master/schemas/codex/instance.json

Comment by Mike Taylor [ 08/Dec/17 ]

Thanks, Hongwei Ji, but that file only really amounts to a list of fieldnames – what I need is statements of semantics, which I assume were in VBar's original document? Please see UISE-27 Closed for my specific questions.

Comment by Hongwei Ji [ 08/Dec/17 ]

Mike Taylor Is the wiki page what you are looking for? https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=5854462

Comment by Mike Taylor [ 08/Dec/17 ]

Thank you, that must be the one!

Comment by VBar [ 11/Dec/17 ]

Mike Taylor Yes, that was the parent page to the attachment link you provided. The attachment was removed when the page was updated to refer to the JSON schema files in GitHub instead. The page remains, but its children have grown up and moved away.

Comment by Mike Taylor [ 12/Dec/17 ]

Thanks, that makes sense.

Generated at Thu Feb 08 23:09:23 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.