Andornot Blog

Inmagic DB/TextWorks version 16, released in July 2017, provides you with several great new features for managing data and databases. This blog post is one of a series providing details of how to take advantage of these new features.

This blog post is about the new ability to sort empty fields last in search results.

Suppose you search a bibliographic database and sort the results by publication date, in reverse order, so the most recently published materials appear first. This works very well when every record in the search results has a publication date. However, if a record has no date, as sometimes happens, those "empty" records will appear first in the search results. This tends to be disconcerting to users as it's not often clear why they are first.

This new feature in DB/TextWorks version 16 allows you to sort those records last. This feature can be used in DB/TextWorks and in WebPublisher PRO searches, including in web forms built from our Andornot Starter Kit.

Here's how to apply this sort option to any Report Form in DB/TextWork (a Report Form is typically used to display many records at once, usually in a brief format):

Open your database in DB/TextWorks version 16.

Open a form that has an existing sort order, or one you want to add it to, in the Form Designer with Display > Design Form.

Select Report Options > Compulsory Sort.

Note the new tick box for sorting empty fields last. Select the field you wish to apply this to, add it to the Sort Fields list on the right, and tick the Sort Empties Last option.

If you have a web interface built by Andornot using our Andornot Starter Kit, you can follow the same steps above to apply this to a Web Form. It's most suitable for something like a WebBriefDate form, where results are sorted by Date.

You can also use this new Sort Empties Last feature with reports that have no sort order applied yet, on-the-fly, by searching, then selecting Display > Sort Report and choosing this sort option (step 4 above).

Contact Andornot for help applying this new feature to your databases, or for a free assessment of your databases and suggestions to use them more efficiently or in new ways. We’d be happy to chat with you!

DBTextWorks version 16, released in July 2017, provides you with several great new features. This blog post is one of a series providing details of how to take advantage of these new features.

This blog post is about the changes to the textbase structure editor.

The Edit Textbase Structure > Edit Fields dialogue has two new features:

Sort Field List by – This feature permits you to sort the Field List by Field Name, or by Field Type.

Hide <Deleted> Fields – This option permits you to hide the <Deleted> items so they do not clutter up the display.

These small changes are super helpful for textbase designers. They appear in the Edit Textbase Structure > Edit fields dialogue as shown below.

We usually start our databases with fields in a logical order, either alphabetic or in the case of a library catalogue, following the traditional ISBD / MARC order. But over time, fields may be added, renamed and deleted, making it hard to find one you want to work on. Previously, fields appeared in the order in which they were added in this editor, interspersed with the word Deleted for fields that have been deleted (although the field and its data is gone, an entry such as this remains in the list of fields).

These two new features, along with the larger size of this dialogue from the previous version of DB/TextWorks, makes textbase structure work that much easier. Sorting by name helps you find a known field, while sorting by type helps you work on a group of similar fields at once. Hiding Deleted fields declutters the interface so you can focus on only active fields.

Note that selecting a sort option or hiding deleted fields is a choice you need to make each time you open the field editor. It’s not saved between sessions.

If you decide you want to eliminate the Deleted fields altogether, rather than just hide them, you can recreate your database from scratch and re-import data, forms, etc. It’s not as daunting as it sounds, and Andornot would be happy to help you. This leaves a super clean database in great shape, for you, your current staff, and especially new staff who come on board.

Inmagic has released version 16 of the very popular and long-standing DB/TextWorks database management system, and the companion WebPublisher PRO web search interface. Several new features, as well as issues fixed from previous releases, continue to make this software great value for our clients.

New features include:

Sorting – When specifying sort fields, you now have the option to sort empties last. Before, records where the sort field was empty could only be listed first or omitted. Since this option does not change the perceived number of records in the report, it is also available for the textbase Default Sort Order and for WebPublisher reports.

Form Designer – WebPublisher reports can now easily link from a small image on a web page (a thumbnail) to the full size image. The new option is on the HTML tab of the Picture Box Properties dialog box.

Adding/Editing Records – When editing a Link field, a new type of box permits you to browse the values in a field other than the Link field, making it easier to select the record you want to link to. For example, you can display the list of Borrower Names, and clicking a name will paste that user’s employee ID into the Link field box.

Select All (Ctrl+A) – This keyboard shortcut now behaves as it does in nearly every other product. You can use it to select all the text in a box, all the boxes on a form or screen, all the text in the Command Query window, or all the annotations on an image. In previous releases, Ctrl+A was used for Redo. Redo now uses Ctrl+Y.

Edit Textbase Structure – The Edit Fields dialog box has two new features:

Sort Field List by – This feature permits you to sort the Field List by Field Name, or by Field Type.

Hide <Deleted> Fields – This option permits you to hide the <Deleted> items so they do not clutter up the display.

Note: Both are display-only features to make it easier to find and work with the fields you want to modify. Neither affects the actual field order specified in the structure.

Other issues addressed include:

Print Images – If a textbase has multiple Image fields, and you print only the images from a specific field, blank pages are no longer printed for any images specified in the other fields.

Report window – Addressed an issue with the records sometimes not being visible past the first page when you held down the mouse scroll wheel then dragged the mouse.

Send Report as Mail – Improved the handling of multiple email addresses when using the "Mail to addresses specified in records" feature.

Textbase Information – Addressed an issue where longer short date formats caused the year to be truncated in the "Current date" specified at the top of this display.

Toolbar icons – The icons for Vertical Tile and Horizontal Tile were backwards in previous releases. This issue has been corrected, and the options have been renamed to "Show Windows Side by Side" and "Show Windows Stacked" to make their behavior clearer.

Form Designer – Addressed an issue with the Box Properties dialog box crashing when a box included an extremely large Fixed Text or Added Text string (usually HTML).

WebPublisher Browse Choices – The buttons have been optimized; for example, we've added an "Add & Close" button so that users no longer need to click "Add" then "Close".

If you upgrade from a version prior to 15 directly to 16, be sure to read the instructions about the necessary upgrade to your textbases as well as the software. If you're already using version 15 or 15.5, you’ll have done this already.

Clients with a current Inmagic maintenance subscription will receive emails from advantage@inmagic.com with instructions for downloading this release. As always, contact Andornot with any questions about this new release, to check the status of your maintenance subscription, or for help upgrading.

Version 4.0 of VuFind, the popular open-source discovery interface, was released early July 2017.

This version brings VuFind up to date with important PHP and Solr developments while also adding several new features and offering a straightforward upgrade path from the 2.x series of releases.

Some key additions and changes:

New channels feature. These are similar to the canned queries we include in almost all projects we work on, no matter which system, where pre-created search parameters or groups of records are offered to users through a simple link, as a guide to interesting aspects of the collection. See a demo at https://vufind.org/demo/Channels/Home.

New ability to create and host static content pages. This feature is especially welcome as in previous versions, additional content (e.g. About Us, Contact Us) was most easily placed on the home page, which could make for a bit of a crowded space.

Improved ability to load cover images from local files. We added this ourselves as custom development in a previous VuFind project, so are happy to see it appear in the core VuFind system.

A new theme, called Sandals. As with several previous themes, it's based on the responsive Bootstrap framework, so it works well on mobile devices. This new theme has a somewhat more modern look to it.

Additionally, several bug fixes, new configuration options and minor improvements have been incorporated.

Although VuFind was largely developed by and for academic libraries, we've found applications for it in other organizations, including smaller specialized libraries. Our blog has details of selected projects. In general, we recommend VuFind for organizations with purely bibliographic records and little or no need for customization, a custom graphic design, integration of other features or content, etc. For organizations with those requirements, our Andornot Discovery Interface is a perfect choice.

Contact us to learn more about the VuFind discovery interface and how it might suit your organization.

One of Omeka's many strengths is the built-in data entry screens, based on Dublin Core fields. While there's a small learning curve to understanding DC, once mastered, it provides just the right set of metadata to describe anything you might want to put in an Omeka site, whether an artifact, photograph, document, map, etc.

But what if you already have a database of this sort of information and want to publish most or all of it in an Omeka site? Perhaps you're using the ever-popular Inmagic DB/TextWorks database management system, but don't yet have your records searchable online, or want to use Omeka's Exhibit Builder plug-in to mount an online virtual exhibit featuring a portion of your collection. Re-entering all that metadata into Omeka one record a time would be onerous. This is where the CSV Import plug-in comes in!

As the name implies, this plugin allows you to quickly import many records in a batch from a text file. You simply choose a suitable text file, map fields from your source into Omeka's Dublin Core schema, set a few other values and very quickly your records will be available in Omeka for review, further editing or simply ready for searching. The only main feature missing from this plugin is the ability to import PDFs, documents, photos and other media files that are saved locally on your computer or network. To bulk import these files, they need to be accessible on a web server with a URL to the file in your database. Note that this may not be as challenging to set up as you may think; there are always ways to work around issues like this, so don't hesitate to contact us for help.

Here's a step by step guide to using this plug-in with DB/TextWorks and Omeka. The procedure for exporting data from other databases will vary of course, but the principles remain the same. As always, do contact us for help !

Mapping Fields

Start by reviewing Omeka's Dublin Core fields on the Item entry screen and think about where data from your database should go.

You may want to prepare a simple two column list mapping fields from your data source into the Dublin Core fields, like this:

DB/TextWorks Field Name

Omeka Dublin Core Field Name

Title

Title

Material Type

Format

Author

Creator

Corporate Author

Creator

Publication Date

Date

ISBN

Identifier

etc.

You don't need to populate every Omeka DC field of course, just the ones that make sense for your data. And you can merge multiple fields from your database into one Dublin Core field in Omeka. To learn more about each DC field, read the brief note on the Omeka data entry screen, or visit http://dublincore.org/documents/dces/ for more detailed information.

Note that there is also a plugin called Dublin Core Extended Fields which adds even more fields. If you have a particularly complex database and feel the need to preserve and fully represent all or most fields, this might be for you. In our view, though, keeping things simple is better, and was precisely why DC was developed, to have a brief, common set of fields that could be used to describe almost anything.

Choosing Data to Export

When you get to the step of importing records into Omeka, you have the option of assigning one Item Type to all incoming records, and only one. The Item Type determines which additional metadata elements are available when editing the record. For example, the "Still Image" Item Type adds fields for Original Format and Physical Dimensions. If your source data contains information that is available in these extended fields and you wish to import it, or add it after by editing imported records in Omeka, you may wish to export records in groups by Item Type. E.g. all "still images", then all "Moving Images", etc. You can then import these in batches and specify the correct Item Type for each. The additional fields specific to that Item Type will then be available for import from your source data.

Exporting From DB/TextWorks

If your data contains special characters like accented letters or letters from outside the Latin alphabet, the file must be encoded as UTF-8 for Omeka to import it correctly. DB/TextWorks offers several text encoding options, so before exporting data, choose Tools > Options > Text Encoding and under "Output file encoding", choose the UTF-8 option (applies to v15.0 or later of DB/TextWorks).

To export a selection of records, search for them first, then select File > Export.

Save the file somewhere handy, with a .txt or .csv extension.

In the Export Options dialogue, make the following choices:

Export File Format:Delimited ASCII

Delimiter options:

Record Separator{CR}{LF}

Entry Separator|

Quote Character "

Field Separator,(only commas are supported for import)

Select the "Store Field Names in First Row" option

If any of your fields are of the type Rich Text, be sure to export those as HTML. That HTML can be preserved during the import to Omeka by selecting the HTML option for the field on Step 2 of the import (see below).

Records to Export:choose to export either the records you searched for with "Export Current Record Set" or the entire database with "Export Entire Textbase"

Fields to Export:select only those fields that you included in your field mapping

Optionally you can save these options as a profile for re-use again later.

Complete the export and note how many records were exported (so you can verify that the same number are imported into Omeka).

Importing Data into Omeka

With the export to a comma-separated text file complete, login to your Omeka site and select the CSV Import option in the menu. If that option isn't available, you'll need to install and activate this plugin first.

In Step 1 of the CSV Import, select your exported data file, then set the following options on this page:

If your database field names happen to be identical to those in Omeka and have “DublinCore” in their names (e.g. DublinCore:Title), you can select the Automap Column Names to Elements option. For all others (most of you!), deselect this option.

If importing different types of records in batches, select the Item Type appropriate to each batch.

Choose the following delimiters to match your export from DB/TextWorks:

Column Delimiter , (matches the Field Separator in the DB/TextWorks export)

Optionally, choose to assign all items to a Collection or make all items Public.

If you're importing a large number of records, you probably don't want to Feature all of them, as it's more common to select a small set of Items to feature on the home page of Omeka.

Continue to the next step.

In Step 2, you will select the Omeka DC fields into which your data source fields will be imported, using your field mapping as a guide.

Click the Use HTML checkbox if this data includes HTML markup (e.g. if it's a Rich Text Format field in DB/TextWorks and during export, you included that field and chose to export it as HTML).

For source fields which contain tags, select the Tags option instead of selecting a field to import the data to.

For source fields which contain URLs to files, select the Files option instead of selecting a field to import the data to. This will cause the import to fetch those files and add them to Omeka. Fetching many large files will take quite a while, so if this is your very first import, you might be best to try importing just a small data set with or even without this files option, to work out kinks in your whole procedure.

Reviewing Imported Data

If you imported a small number of records, you can review each one. If you imported a large number, you may wish to spot check a random sample, to make sure all the data ended up where you expected it, that records are public or not, featured or not, in a collection or not, etc.

If there are problems, the Undo Import feature is your new best friend. Find it back in the CSV Import plugin and use it to remove the records just imported.

Need Help?

Need help with any of this? Contact Andornot and we'll be glad to work with you on this.