-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip all records with only suppressed holdings/items/portfolios. #2077
Conversation
Mimics similar behaviour in DigiBib IntrOX (Limetrans; relevant Jira issues: DOX-1354, DOX-1568, DOX-1622).
a7fdbd9
to
40e7d98
Compare
Do we maybe need more test cases? |
Concerning the suppression I will get feedback. to you what we prefer. I would have preferred two commits because one cannot relate the changes in the tests to the changes in the code so easily. I was confused that the reject mechanism resulted in the deletion of a single holding object. But then I realized that this was due to the new "suppression" mechanism for POR that was also commited. |
Okay, thanks.
Which changes exactly would you have separated? |
copy_field("$i.d", "$i.@sublocation") | ||
replace_all("$i.@sublocation","https://hbz-network.userservices.exlibrisgroup.com/view/uresolver/49HBZ_NETWORK","") | ||
do list(path:"$i.A", "var": "$j") | ||
if none_equal("$i.b", "Not Available") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This conditional introduces something new. A suppression mechanism that was not there before.
Introduce this in a separate commit. In the second commit add the helper elements @suppressed
and @unsuppressed
and the rejection mechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither were the other two. But you would prefer one commit with the holding/item changes (no test coverage) and one with the portfolio changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I understand. Sorry for being dense so early in the morning ;) You mean the suppression of the portfolio, not the suppression of the record; holdings and items were suppressed before, but the portfolio wasn't.
So there are two decisions to be made:
I'll adjust the commits once you've made your decision. |
My first thoughts on this (after not much reflection): It makes sense to skip those records but we should make sure to not exclude records that we actually want in lobid. E.g. in NWBib, there are 52k resources that are not articles and do not have any holding information: |
Just to be clear: The proposed change only applies to records that only have suppressed holdings; records without any holdings aren't skipped (neither are records with both suppressed and unsuppressed holdings). |
How do we ensure that these are not suppressed: And Because the supression marker is only set for ITM, H52 (PhysicalObject) and POR (DigitalDocument) , but not for the other types of holdings (NurTitel and PhysikalischerTitel) |
You mean, e.g., what if a record has a suppressed I guess the safest option would be to limit the change to the "DigiBib hbz Verbundkatalog" collection (question 2 above). This way you don't have to suffer any unforeseen consequences. |
…DigiBib hbz Verbundkatalog" collection. Mimics similar behaviour in DigiBib IntrOX (Limetrans; relevant Jira issues: DOX-1354, DOX-1568, DOX-1622). See #2077 for alternate proposal (skip these records altogether).
See #2078 for alternate proposal. |
I understand. But NWBib titles might be affected by this, anyway, which we should check. However, it looks like we are going in the direction of removing the DigiBib collection statement so that we won't have to dig deeper into this. |
The discussion might not have been totally in vain, but we've decided not to go forward with this change (for the time being). Sorry for the noise, everyone. (The examples which @eschackmann identified didn't match the use case we previously saw in IntrOX and weren't covered by the conditions implemented here.) |
Mimics similar behaviour in DigiBib IntrOX (Limetrans; relevant Jira issues: DOX-1354, DOX-1568, DOX-1622).
If you don't want to exclude these records altogether, we'd have to apply this change to the
inCollection
statement for "DigiBib hbz Verbundkatalog" instead.