-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1279 from emory-libraries/create_record_xml_refer…
…ence_document_1278
- Loading branch information
Showing
6 changed files
with
68 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
# A Catalog Record's XML Reference | ||
|
||
## Summary | ||
|
||
The template for displaying a catalog record's XML document uses two different sources: the record's SOLR document, which is created by indexing and parsing the response for that item's OAI record from Alma, and the data retrieved from a call to Alma's Real-Time Availability API. The information from the OAI is processed whenever a manual indexing is performed or picked up after changes to the Alma record have been committed by one of the four daily automatic, incremental indexings. The values taken from the Real-Time API call are processed the moment the record is requested for viewing (XML or HTML.) | ||
|
||
## Breakdown of XML Values' Origins | ||
|
||
- "title": A value stored in the record's SOLR document, which originates from the Alma's OAI field of "245" and is formed by combining that datafield's subfield strings from "a", "b", "f", "g", "k", "n", "p", and "s", and stripping away the end punctuation. | ||
- "author": The first author stored in the record's SOLR document derived from either of the following combinations of datafields/subfields (and stripping away the end punctuation): | ||
- Datafield "100" and subfields "a", "b", "c", "d", "g", "q", and "e", in that order. | ||
- Datafield "110" and subfields "a", "b", "c", "d", "g", "n", and "e", in that order. | ||
- Datafield "111" and subfields "a", "c", "d", "e", "g", "j", "n", "q", and "j", in that order. | ||
- "is\_physical\_holding": Another value pulled from the SOLR document. This value is set to "true" by the following logic: | ||
- An OAI field of "997" with the subfield of "b" is present, OR | ||
- The above field isn't present, and neither are "998" with the subfield "c" containing the string of "available" (down cased) or "856" with a field indicator 2 of "0", "1", or not "2" and subfields "z" or "3" that do not contain the strings "abstract", "description", "sample text", or "table of contents", AND the record's leader field, seventh position, contains either "e", "f", "g", "k", "o", or "r", as well as "008"'s value at the thirtieth position not equaling "o" or "s", OR the record's leader field, seventh position, not containing either "e", "f", "g", "k", "o", or "r" and the twenty-fourth position of "008" not containing "o" or "s". | ||
- "is\_electronic\_holding: Pulled from the SOLR document, this is set to "true" by the logic below: | ||
- The datafield "998" with the subfield "c" containing the string of "available" (down cased) or "856" with a field indicator 2 of "0", "1", or not "2" and subfields "z" or "3" that do not contain the strings "abstract", "description", "sample text", or "table of contents", OR | ||
- The above field isn't present, and neither is "997" with the subfield of "b" AND the record's leader field, seventh position, contains either "e", "f", "g", "k", "o", or "r" and "008"'s value at the thirtieth position equaling "o" or "s" OR the record's leader field, seventh position, not containing either "e", "f", "g", "k", "o", or "r" and the twenty-fourth position of "008" containing "o" or "s". | ||
- "edition": The first value taken from the SOLR document fed by extracting values from OAI datafields "250", subfield "a" or "254", subfield "a". | ||
- "physical\_description": A SOLR document value processed from scraping the values of OAI datafield "300", subfields "a", "b", "c", "e", and "f". | ||
- "publisher": This SOLR document value is pulled by presenting the very first item that exists in the fields below, ordered by priority: | ||
- Datafield "264", subfield "b" | ||
- Datafield "260", subfield "b" | ||
- Datafield "502", subfield "c" | ||
- "publication\_date": This is, once again, a value taken from the SOLR document for the record. The customized logic used to pull this value is quite extensive and could warrant a document this size just to explain the processing used to extract this data. Below are summary points for this value: | ||
- This displays only the starting year of publication, taken from datafield "008", pulling a four-digit value from positions eight through eleven. | ||
- If the value derived from the positions above proves to be out of the range of what is deemed acceptable by Product Owners, the extraction defaults to the logic provided by our extraction tool, which is based off MARC Standards. | ||
- "isbn": SOLR document value generated by pulling the value from the OAI record's "020" datafield, subfield "a". It goes through standardization provided by our extraction tool, which always returns the thirteen-digit code if it's available. | ||
- "issn": A value that lives in the SOLR document that is pulled from the first OAI field listed below that produces a result: | ||
- "022", subfield "a" | ||
- "022", subfield "y" | ||
- "800", subfield "x" | ||
- "810", subfield "x" | ||
- "811", subfield "x" | ||
- "830", subfield "x" | ||
- "supplemental\_links": This is still derived from the SOLR document. In this case, multiple values stored will display separately as elements wrapped in "supplemental\_link". | ||
- These values are pulled from the OAI datafield "856" that only have a field indicator 2 value that is either blank, "0", "1", or "2", and contains a path string in subfield "u". | ||
- That mentioned subfield "u" feeds the XML "link" element. | ||
- The "label" element is derived from the first available subfields of "y", "3", or "z". | ||
- When the field indicator 2 equals either "0" or "1", the value taken from that list of possible subfields above must not be nil or deviate from the list of approved labels (down cased): "table of contents", "table of contents only", "publisher description", "cover image", or "contributor biographical information". | ||
- If the label value in the SOLR document is empty (which can happen when the field indicator 2 equals "2"), the path string is provided in the "label" element instead. | ||
- 'physical\_holdings": This group of elements is processed from the Real-Time API provided by Alma. | ||
- A "physical\_holding" is produced for each "holding" with a positive number of "items" in the resulting API response. | ||
- "call\_number": This is taken from the response's datafield "AVA", subfield "d". | ||
- "items": a grouping element that contains all the holding's Items. | ||
- "item" | ||
- "library": This depends on whether the item's "in\_temp\_location" field is populated with "true". | ||
- If it is, the value will be taken from the item's "temp\_library" field. | ||
- Else, it will populate the "AVA", subfield "b" value. | ||
- "location": This also depends on whether the item's "in\_temp\_location" field is populated with "true". | ||
- If yes, then this will return the value in "temp\_location" of the item. | ||
- Else, "AVA", subfield "j". | ||
- "barcode": filled by the "item\_data"/"barcode" field. | ||
- "volume\_or\_issue": parsed from the "item\_data"/"description" inner text. | ||
- "status": pulled from "item\_data"/"base\_status". |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters