Scrapers should store Repository field

[dstillman]

Scrapers should be updated to use the new repository field, which exists on all item types with the callNumber/archiveLocation fields. Generally this will be the name of the library.

(Yes, this sorta violates the parent-item-as-abstract-representation-of-source-rather-than-specific-instance principle, but then, so does call number, and we shouldn't have one without the other.)

[simon]

closed in r946

[dstillman]

Do we have any options for getting the actual library name, or would that generally require hard-coding each and every library catalog?

If the latter, would it make sense to use, say, the domain instead of the catalog technology? I'm just wondering how useful it would be to your standard user who's trying to remember what library the call number was from to see "Library Catalog (DRA)"...

We had also discussed a Repository URL field, which might make sense, but it'd also clutter up the metadata pane even more with what will generally be the homepage of the library catalog. Is it possible to initiate new sessions on these library catalogs with searches for a particular call number (to get around the dynamic URL problem)?

[simon]

As far as I can tell, no major cataloging software allows us to get the name. I've hard-coded the Library of Congress (since it's the most widely used catalog out there), but it doesn't seem to make much sense to code everything else.

You're right. The domain is probably a better idea than the catalog technology.

Whether a Repository URL is possible depends on the cataloging software used, specifically, whether it creates a new session when a user enters the catalog or when a user performs a search. Thus, this is probably possible with Voyager and InnoPAC, and probably impossible with Aleph and SIRSI.