Corinna Baksik
My feedback
19 results found
-
225 votesCorinna Baksik
supported this idea
·
-
234 votesCorinna Baksik
supported this idea
·
-
36 votes
An error occurred while saving the comment -
241 votes
An error occurred while saving the comment Corinna Baksik
commented
To clarify, we're looking for the export to include the location and call number of the physical resource at the holdings level (e.g. we're not looking for a list of all item records and their "item call number" field). If an item is in a temp loc, that temp loc info would be what is exported.
Corinna Baksik
supported this idea
·
-
222 votesCorinna Baksik
supported this idea
·
-
4 votesCorinna Baksik
shared this idea
·
-
206 votesCorinna Baksik
supported this idea
·
-
7 votesCorinna Baksik
shared this idea
·
-
205 votes
An error occurred while saving the comment Corinna Baksik
commented
For example, when you search for Clemens, Samuel Langhorne, ǂd 1835-1910, you don’t get a reference generated from the NAR 500 fields in the browse index telling you to see also Twain, Mark, ǂd 1835-1910. And in the detailed view of this record, there’s no mention of Mark Twain’s “relationship” with Samuel Langhorne Clemens: http://id.lib.harvard.edu/alma/990099247200203941/catalog
In Serials Cataloging, we make a lot of 510s between earlier/later names of corp. bodies and 530s between earlier/later titles of series. These don’t get displayed. They did in the card catalog.Corinna Baksik
shared this idea
·
-
Display related holdings for monographs only for the 773 $w relation and not for the 8xx $w relation
658 votesHi all,
We are currently reviewing this idea together with Alma.
We will update with any new information we have.
Best regards,
Yael.
Corinna Baksik
supported this idea
·
-
312 votesCorinna Baksik
supported this idea
·
-
57 votesCorinna Baksik
shared this idea
·
-
61 votesCorinna Baksik
shared this idea
·
-
22 votesCorinna Baksik
supported this idea
·
-
17 votesCorinna Baksik
shared this idea
·
-
101 votesCorinna Baksik
supported this idea
·
-
208 votesCorinna Baksik
supported this idea
·
-
77 votesCorinna Baksik
supported this idea
·
-
93 votes
An error occurred while saving the comment Corinna Baksik
commented
I think this is the wrong approach. We do not want individual journal issues in the index at all - they flood the user with noise. For example, the HathiTrust issues are simply lists of issues with no added value to the user: http://screencast.com/t/TNMJqDSaH
You can hide the month/date fields using the following CSS. You may have to make some additional adjustments for alignment.
prm-search-bar .advanced-search-tabs .advanced-drop-downs.marginless-inputs md-select[ng-model*="startDay"],
prm-search-bar .advanced-search-tabs .advanced-drop-downs.marginless-inputs md-select[ng-model*="startMonth"],
prm-search-bar .advanced-search-tabs .advanced-drop-downs.marginless-inputs md-select[ng-model*="endDay"],
prm-search-bar .advanced-search-tabs .advanced-drop-downs.marginless-inputs md-select[ng-model*="endMonth"] {
display:none;
}
prm-search-bar .advanced-search-wrapper .date-range-inputs md-input-container input[ng-model*="startYear"],
prm-search-bar .advanced-search-wrapper .date-range-inputs md-input-container input[ng-model*="endYear"] {
margin-left:-154px;
}