[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: |
|
||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||
| 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:
Sorting:
Filtering
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
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
|
| 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. |