Arctic Health, intended for students, researchers, and anyone with an interest in health aspects of the Arctic, is a central source for information on diverse aspects of the Arctic environment and the health of northern peoples. The Arctic Health website provides access to a database of over 280,000 evaluated publications and resources on these topics. To improve access to this collection, a new search engine has just been launched at https://arctichealth.org

Search results in Arctic Health include published and unpublished articles, reports, data, and links to organizations pertinent to Arctic health, as well as out-of-print publications and information from special collections at the University of Alaska. Resources come from hundreds of local, state, national, and international agencies, as well as from professional societies, tribal groups, and universities.

Arctic Health is managed by the Alaska Medical Library at the University of Alaska Anchorage, by Prof. Kathy Murray and a team of staff. Andornot has worked with this group since 2005 and designed several previous search interfaces using Inmagic WebPublisher PRO and dtSearch.

Prof. Murray approached Andornot last year with several updates in mind, such as to ensure the search results are accessible on mobile devices, not just desktops. Rather than simply adjust the existing site, this precipitated a complete review of the current system, including data entry workflow and the actual content to be included, as well as discussions on a more modern search engine.  

As we do with many projects, Andornot began this challenge by separating out the user groups and functions. Library staff need a system to manage and upload records, with features for adding, editing, converting and validating data. Researchers and health care practitioners, on the other hand, need an easy to use, robust system for searching the vast archive of resources. With such a large number of records, a sophisticated search engine is needed to float the most relevant results to the top of any search.

For the back-end, Andornot developed a web application that uses Inmagic DB/TextWorks for data storage, and Inmagic WebPublisher PRO as a middle layer. We were able to update and re-use an XSLT we'd previously developed that UAA uses to import records in XML format from PubMed. This hybrid approach of using existing commercial software and a custom-developed web application provided the features needed by library staff at a more economical cost than a completely custom written system. 

For the public search interface, we used our Andornot Discovery Interface (AnDI). AnDI is a modern search engine based on the popular Apache Solr system, with features such as:

• Excellent keyword search engine and relevancy-ranked search results.
• Automatic spelling corrections and “did you mean?” search suggestions.
• Full text indexing of linked documents.
• Facets, such as subjects, authors, places, dates, and material types, to allow users to quickly and simply refine their search.
• A selection list allows users to mark items of interest as they search, then view, print or email the list.

AnDI helps users quickly find relevant materials from the large collection at Arctic Health and is a significant improvement over the previous search options.

Both systems in this solution are hosted by Andornot as part of our Managed Hosting Service.

Check out the new iteration of the Arctic Health resource database at https://arctichealth.org, and contact Andornot for help with your project.

Andornot recently helped a municipal archives save hours of manual work when civic records are transferred to them, by automating part of the data transfer process. 

This municipal archives uses Inmagic DB/TextWorks to manage their collections. The many departments in the municipality complete a form when they are transferring records to the archives. The form is a fillable PDF form, but when the archives receives it with the records, they still need to re-key, or copy and paste, data into their DB/TextWorks system.

This fillable PDF form was altered so that a Submit button placed prominently on the form generates an XML file in Adobe's .xfdf format. Andornot developed an XSLT that can be used by DB/TextWorks' data import feature to transform data from this XML file into DB/TextWorks records. The XSLT selects appropriate data from the XML, and adds some default values like the material type, some notes, etc. 

Dozens of records can now be imported in seconds or minutes, ready for the archives to review and edit further.

Further automation is also possible using the Inmagic Importer, which can monitor a folder and import files when they appear. This would allow the archives to drop multiple XML files from the transfer forms into a folder at once and then a few minutes later, access those records in the DB/TextWorks database.

Approaches like this are great for all sorts of institutions. Another common example is libraries sourcing catalogue records from other catalogues, such as by using BookWhere software, and importing those records into their catalogue, through DB/TextWorks or Genie.

Contact Andornot for assistance improving your workflow  and automating repetitive tasks like this example.

Why enter records into your database when you can have someone else do it for you? Or at least, why not borrow records from other sources and import them into your database? It’s quite easy to do, saving time and improving accuracy. One approach to this is:

1. Use a service such as Bookwhere, Biblios.net or PubMed to search for records in numerous online databases, for materials such as books, journals, articles, videos, maps ­- anything that might have been catalogued by someone somewhere may be found (see our blog post on Biblios.net).
2. Save records in MARC XML format (though any XML format can be used).
3. In Genie (part of the Inmagic Library Suite), use the included Bookwhere XSLT to convert selected MARC tags to Genie fields and import records. (XSLT is short for Extensible Stylesheet Language Transformation, and is a language used to transform XML data into other formats).
4. In Inmagic DB/Text, customize an XSLT to map MARC XML or any other XML data source to your data structure and import records.
5. After importing records, you would of course further customize them to suit your database.

If you use Genie, it includes an XSLT (Bookwhere.xsl in the Genie ImporterFiles folder) that maps MARC XML fields into Genie fields. You can customize this XSLT further for your cataloging needs. For example, some MARC tag to Genie field mappings we have added include:

 

MARC Tags	Genie Field
090 or 050	CatCallNumber
520	CatAbstract
856 subfield u	CatURL
856 subfield y	CarURLNotes
246, 247, 730, 740, 770, 772, 776, 780, 785, 787	CatAlternateTitle
Leader position 6 or 7	CatRecordType

Here's an example of the above Leader mapping added to the Genie Bookwhere.xsl transformation:

<xsl:template name="RecordType2" match="marc:leader">

<xsl:choose>

<xsl:when test="substring(marc:leader, 8, 1 )='s'">

'CatRecordType' Periodical

</xsl:when>

<xsl:when test="substring(marc:leader, 7, 1 )='a'">

'CatRecordType' Book

</xsl:when>

<xsl:when test="substring(marc:leader, 7, 1 )='g'">

'CatRecordType' Videorecording

</xsl:when>

</xsl:choose>

</xsl:template>

Virtually any XML file can be imported into a textbase using an XSL. The beauty of XSLT is that data cleanup can be done as part of the process. For example, ALL CAPS can be converted to Title case, fields can be separated or joined, dates can be transformed to other formats, and much more.

A client of ours recently started using the new BookWhere XML MARC record import feature of Inmagic Genie. They noticed that although the new feature allowed them to import MARC records nicely into Genie, it did not import a call number from any of the records. There are several MARC call numbers that could be used, depending on the classification system used by the Genie user. See http://www.loc.gov/marc/bibliographic/ecbdclas.html for specifics on which MARC field you should use. We have used MARC field 050 - Library of Congress Call Number - in this example (leave out leading zero).

Woe. Woe, I say. Woe! To Thee! If thou wouldst assay to run an XSL transform with the .NET XslTransform object. And a knight recreant would I be to keep my tongue caged within its red and toothy prison over it. As 'twere.

Simply put, the .NET XslTransform class is not MSXML based. MSXML is fast. XslTransform is slow. Particularly with transforms of larger XML docs - performance gets worse the larger the XML input is. Supposedly this will all go away with .NET 2.0.

If you pass WebPublisher an XSL document with a query, you're in no trouble, since WebPublisher is using MSXML.

Keywords: tortoise, hare, woe