hbz / mabxml-elasticsearch

Raw hbz union catalog data exposed via a web API
http://lobid.org/hbz01
3 stars 1 forks source link

Incorrect holding information #47

Closed acka47 closed 6 years ago

acka47 commented 6 years ago

Reported via email by lobid-resources API user at TU Dortmund library:

für die Ressource ( http://lobid.org/resources/HT013025438 ) sind wir in den Lobid-Daten als besitzende Bibliothek genannt, was aber nicht (mehr) der Fall ist. In der Verbunddatenbank gibt es von uns keinen Lokalsatz. Es gibt auch keinen lokalen Besitzer von uns, da der Titel "nicht bestandsfähig" ist.

I assume this is a problem with the hbz01 export as the information is in the XML:

<datafield tag="088" ind1=" " ind2=" ">
  <subfield code="a">290</subfield>
</datafield>

Looking at the Aleph OPAC, there is no holding for 290 (UB Dortmund), see http://193.30.112.134/F/?func=find-c&ccl_term=IDN%3DHT013025438.

dr0i commented 6 years ago

Hard to track down as the modification date shows that all resources are in sync: XML, HT013025438.json and http://193.30.112.134/F/?func=find-c&ccl_term=IDN%3DHT013025438 all declare to be modified at 20170815. Also investigated our sigil-isil-concordance for a mapping error but couldn't found any. One must conclude that the failure is a result of the "expanding" (aka "sql-joining of tables") of a hbz resource done within the aleph-software which is not in our reach for analyzing. Assigning @ChristophEwertowski to ask the Verbundgruppe if this is what happened.

ChristophEwertowski commented 6 years ago

Asked the collegues. MAB field 088 is created from the Lokaldaten and the "LOW" field. The LOW field is meant for library management systems which are non-Aleph-systems but wasn't deleted in this case. If the modification date changes in the same save step Aleph removes the right LOW field. This wasn't the case here since the Titeldaten didn't change. For some months the libraries are allowed and recommended to remove the corresponding field if they remove one holding statement. I already wrote the API user back and he referred it to the catalogers. Closing this issue.