Release Notes for the Axiell Collections Software

Processing records that have inherited Where records can be arranged in a hierarchy, a field can be configured to be inherited so that a record lower in the hierarchy inherits a value entered in a record immediately higher in the hierarchy (its parent). This can be efficient as a value only needs to be entered and saved in the parent record to be inherited by all of its children; importantly, while the value displays in a child record it is not stored in that record (in the child record the field is actually empty until the field is edited and the inherited value is overwritten). fields and / or context A read-only field that displays the full hierarchy of a Linked field, such as a location (Normal location and Current location). Typically placed below the Linked field. fields when running Export to Excel and Output formats can be quite slow due to the demand placed on system resources.

Changes have been introduced that can provide a substantial performance boost:

• Previously when running Export to Excel, inheritance / context checks were automatically run on all records being exported if certain fields (such as object_number, object_name, creator) were exported even though those fields themselves are not inherited or context fields. Now Collections only processes inherited / context fields if they are explicitly included in the list of fields to be exported.
• For Output formats using ADAPL Both a general-purpose programming language and a program built in the ADAPL language. An ADAPL program can be executed as a standalone program or used during various database functions, e.g. to validate data input, or to carry out an additional check during record deletion. , a new options function is available that can switch off / on the processing of inherited and/or context fields at any point in the adapl.

  Details about the options function are available in the Designer 7.16 Release notes.

Previously, when Axiell Intelligence extracted keywords from Wikidata, the original entity term or name found in your record data was used as the keyword or person name in Collections, with a link to the Wikidata entity in the Thesaurus or Persons and institutions record created for the term or name. This is not always ideal. For example, if the keyword Obama in your record data was matched to Michelle Obama by considering the context in which the name Obama was found, the keyword Obama was used and saved to your records, not Michelle Obama. As a result, it was not possible to locate relevant records by searching for Michelle Obama.

That changes with Collections 2.1 and now the actual Wikidata entity title is registered as the term or name in your Collections records.

Now when you perform a new entity extraction and a matching Wikidata entity is found, Collections checks whether there is a link to that entity in an existing Thesaurus or Persons and institutions record; if a link is found, the name or term registered in that record is used. If the Wikidata link is not found, a record is created in the Thesaurus or Persons and institutions for the new term or name.

Fields with an html field type, such as Text (label.text (AB)), can now be added as a column to Result set View and inline grids such as the Find data for the field box, and the content of the field will display with html mark-up:

In both cases, fields are added as columns by selecting the Settings option (the links above are to details about how to add fields as columns).

With the Collections 2.0 release a Settings option was introduced allowing users to customize which columns display on the View table tab in the Find data for the field box and in what order. A side-effect of this improvement was that back-end field names were shown as column headers for all fields displayed. The View table tab is a link screen designed in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. with a default set of fields (details here); fields can be provided with a user-friendly label in the properties of a link screen, and from Collections 2.1 this user-friendly label is used in the Find data for the field box for the default set of fields; fields added by users (PID_other_URI in the example below) will continue to display the back-end label:

Axiell Intelligence is an optional feature designed to enrich your Collections data by leveraging AI to identify entities (people, places, dates, and so on) in your unstructured content and write-back structured keyword metadata linked to authority records and Wikidata.

The core concepts of Axiell Intelligence are Entity Extraction (also known as Named Entity Recognition) and Entity Linking. The first identifies entities within unstructured text in nominated fields, and classifies them into predefined categories such as individuals (people’s names), organizations (names of companies, institutions, or groups), locations, dates, times, and more. Structured metadata in the form of keywords (names, terms, etc.) is then written back to the source records, linked to authority Authority data sources are used for vocabulary control and they manage the many names and terms referenced by records in almost every other data source. The purpose of a controlled vocabulary is to ensure consistent use of names and terms throughout your records and this is achieved by specifying that a name or term is preferred; then when a non-preferred version of a name or term is selected in a Linked field drop list, it is automatically replaced with the preferred name or term. records in Persons and institutions and the Thesaurus (created on-the-fly if necessary) and to Wikidata.

Axiell Intelligence's AI is able to process data faster and more efficiently than we can, while enabling human oversight to ensure an ideal combination of machine and human intelligence. The end result is enriched data with interlinked records, providing improved context for staff, researchers, and the public.

For the moment, Axiell Intelligence is only available for English language content.

You will find full details about Axiell Intelligence here.

A Settings button has been added to the Find data for the field box, enabling users to customize which columns display and in what order (similar to Result set View):

In the Settings dialogue it is possible, amongst other things, to add / remove fields (columns) and to reorder them:

Details about working with the Settings dialogue can be found here.

As can be seen above, it is possible to include thumbnails in the Find data for the field box by including the image or media reference field in the Find data for the field box. When only one thumbnail displays, this is the first or preferred image linked to a record. More thumbnails can be shown by specifying the maximum number of thumbnails to display in the event that more than one image is linked to a record.

The Record History Reports function is an optional feature that allows suitably authorized users (those with the $ADMIN role) to list records changed within a period, with the old and new values displayed per field. Full details about the function can be found here.

A number of improvements have been made for the Collections 2.0 release:

• All labels for column names and buttons now display in the current interface language.
• A Field name column has been added to hold the system name of fields in the current interface language:

  

  Tip: All column labels and data are exported with the Export to CSV option.

• The Record History Reports window lists records changed within a specific period; each row identifies a change to a record and the first column includes one of three icons to indicate whether a value was added (), deleted () or modified ().

  The first column is now labelled Type (previously it had no label); placing the cursor over the column label pops up a tooltip that describes the icons:

  

• Previously, when a value in a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). was changed, only the old record number and the new record number in the link reference fields were shown in the Record History Reports window. Now the link reference values are replaced with the value of the linked term (a person's name for instance). The Tag and Field name columns now show the tag and name for the Linked field (instead of its link reference field).

  Note: As a consequence of this change, sorting is no longer possible on the New data and Old data columns. If it is necessary to sort on the data columns, it is possible to export the list to a CSV and use Excel for sorting.

The title bar in the Import dialogue now includes the name of the target data source, making it clear which data source you importing data into. Previously it only stated Import:

Details about importing data can be found here.

When importing data into Collections you will find two additional options, AdlibXML (grouped) and AdlibXML (unstructured), in the Import box:

A Style Sheet drop list will display when either of the Adlib XML formats is selected, but it will only be populated if Application Administrators have set up a custom import job. A custom import job is used to convert a non-Adlib XML exchange file (one that is MarcXML or LIDO, for instance) to AdlibXML in order that it can then be imported into Collections. If the Style Sheet drop list is empty, simply ignore it (your exchange file already contains structured or grouped AdlibXML); if, for example, the import data file contains MarcXML and an appropriate style sheet has been made available, you would select it from the Style sheet drop list:

Tip: An XSLT style sheet is provided for import of object data from EODEM Exhibition Object Data Exchange Model exchange files are designed to simplify and streamline the process of sharing information about exhibition and loan objects between different museum collections management systems. exchange files. The registration of third-party objects for loans and exhibitions is greatly simplified when participating parties support the generation and import of data via the EODEM.

Continue to set up the import as usual by specifying the file containing the import data and confirming that the other options in the Import box are correct (details about how to import data can be found here). Note that it is not possible to specify a subset of fields to import when importing Adlib XML (step 6 in How to import data).

Tip: Application Administrators will find details about setting up custom import jobs to produce unstructured or grouped AdlibXML for import into Axiell Collections in the Axiell Designer Help.

When exporting data it is now possible to use custom XSLT formats to transform Collections' native (unstructured or grouped) record XML to another format (e.g. HTML).

When set up for a data source by an Application Administrator an Xslt option is added to the Format drop list in the Export box; when selected, a Style Sheet drop list will display to the right, from which the required export format style sheet is selected:

Tip: An XSLT style sheet is provided for export of object data to EODEM Exhibition Object Data Exchange Model exchange files are designed to simplify and streamline the process of sharing information about exhibition and loan objects between different museum collections management systems. exchange files. The registration of third-party objects for loans and exhibitions is greatly simplified when participating parties support the generation and import of data via the EODEM.

Axiell Collections' predecessor, Adlib for Windows, supported custom export formats, and any custom XSLT export formats that were migrated from Adlib to Collections will now be available in Collections following installing of Collections version 2.0.

Tip: Application Administrators will find details about configuring this functionality in the Axiell Designer Help.

With a Filter, users can define a subset of records in a data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. and limit all their searches to this record set while the filter is active. A curator of ceramics, for example, might only be interested in Object catalogue records where:

• Management status = internal

  -AND-

• Object category = ceramics

By specifying a filter with these conditions, any search by the curator in the Object catalogue will be restricted to the subset of records defined by these conditions, as long as the filter is active (full details here).

A filter icon displays in the Title bar when a Filter is active:

The query that defines the Filter is shown as a tooltip for the filter icon, and it is displayed on the Standard and Advanced tabs of the Search box. Here we see a Filter query on the Advanced search tab in Collections version 1.19:

As we see, field tags are used and, perhaps less obviously, the neutral value INTERNAL is used for the enumerative field Read-only drop lists; their values are added and translated by Application Administrators in the Collections administration tool, Axiell Designer: users can select a value in an enumerative field, but cannot add or translate a value., e.g. Management status (ms) rather than the display value internal. With enumerative fields, the neutral value (a language independent value stored in the database) can be more cryptic than the display value (the value that displays in the User Interface).

Now, the more user-friendly system field name is used instead of a field tag, and the display value rather than neutral value is used for enumerative fields. For example:

Here we see the Standard tab of the Search box:

And here, the Advanced tab of the Search box:

Note: If there is no field name defined in the current interface language, the field tag will be shown.

As we see above, system field name can include an underscore (they can also include dots). Application Administrators are able to specify a more user-friendly label (without underscores, for example) for the field name as a method text in the field definition in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc.. When displaying the Filter query, a method text in the current interface language has priority over the system field name.

For example, a Filter query might be defined for the Level (record_type) field as:

Application Administrators could add a more user-friendly method text to the definition of the record_type field so that Level is displayed instead of record_type:

When Full text indexing has been implemented in a database, an equals search in a non-unique Text (term) indexed field The entire value in the field is indexed as a single value, including spaces and punctuation. When searching a text (term) field, your search value must exactly match the entire contents of the field. will not only match the value you are looking for but also values that differ in their use of punctuation. For example, a search for:

AB-12345

will return AB-12345, ab12345 and aB123.45.

Note: An equals search is case-insensitive.

The new exact operator, which is available in an Advanced search, only returns records with an exact match in terms of case and punctuation. For example:

alternative_number exact "AB-12345"

will only match AB-12345.

An equals search in a unique Text (term) indexed field such as object_number is already punctuation-sensitive; an exact search ensures the match is also case-sensitive.

Note: The exact operator can also be used in READ Facs_name WHERE searches in adapl.

More details about indexing can be found here.

The introduction of the Period field type1 Axiell Collections version 1.15. made it possible to save and to search for date periods as a natural language value, such as 12th century, Spring 2023, and so on.

Tip: Details about the Period field type (including a definition of the basic elements used to describe a period, and valid formats) can be found here.

When adding a value to a Period type field, and when specifying a search value, we use the natural language version of a period; while such fields display the natural language version of a period, the indexed (searchable) value is stored in the database as an ISO start and end date range (i.e. a numerical value). For example:

Period entered by a user	Indexed value
12th century	1100.0101 - 1199.1231
Spring 2022	2022.0301 - 2022.0531
late 2018	2018.0901 - 2018.1231
Early 19th Century - 2022	1800.0101 - 2022.1231
1950s	1950.0101 - 1959.1231

Performing an equals search on a Period type field such as:

Production period = "spring 2023"

will find records in which the field contains dates falling within the spring of 2023; performing a wider search on the specified period was not possible as it is only possible to search for a single period, not period ranges.

This changes in Collections 2.0 with the introduction of the overlaps operator. More descriptive labels have also been provided for the various Relational operators:

Operator	Details
overlaps	Perform a wider search on the specified period by returning any records in which a date intersects with (overlaps) the search date. For example: Production period overlaps 2000 will return records with periods such as 2000-2002, circa 2010 and 21st century. Understanding overlaps It is important to understand that overlaps is not a wider search in the sense that it defines a range either side of the search date and returns records that fall within that date range. A search for: Production period overlaps 2000 will not return records earlier than the year 2000 for instance. It is more accurate to describe an overlaps search in terms of intersection, returning records with periods that intersect with (i.e. cross over or overlap) the search period. In the example above, the date range of 2000 is understood to be from 2000-01-01 to 2000-12-31. When we run the search: Production period overlaps 2000 any period that intersects this range is considered to overlap, and a record with an overlapping period in the search field will be returned: Record with period of: Record is returned? Explanation 1999 No The date range of 1999 is 1999-01-01 to 1999-12-31, which does not overlap the date range of 2000. March 2000 Yes The date range of March 2000 is 2000-03-01 to 2000-03-31, which overlaps the date range of 2000 for 31 days. June 1999 to June 2000 Yes The date range of June 1999 to June 2000 is 1999-06-01 to 2000-06-30, which overlaps the date range of 2000 for 6 months. 21st century Yes The date range of 21st century is 2000-01-01 to 2099-12-31, which overlaps the date range of 2000 for a year. 20th century No The date range of 20th century is 1900-01-01 to 1999-12-31 which does not overlap the date range of 2000. circa 2010 Yes circa is understood by Collections to mean the year and 10 years either side, thus the range of this period is 2000-01-01 to 2020-12-31, which overlaps the date range of 2000 for a year. Note: This operator is also available for Advanced searches (and WebAPI requests), and it is the default operator for Period type access points An access point is a user-friendly way to search a field or combination of fields or to execute a search statement (known as a fixed query). Access points are found on the Standard tab of the Search box and most often comprise a label (naming the field / fields to be searched) and a search field in which you enter or select a value to search for. Only indexed fields can be set up as access points (an index is a database table designed to speed up the search of frequently queried fields; it only contains values from a field and the id number of the records in which that value appears). Non-indexed fields can be searched on the Advanced search tab. in a Standard search.
within	Used for = in Standard and Advanced searches (and WebAPI requests). A search of: Production period within "circa 2000" will return records with periods such as 2000-2002, circa 2000, 1990, 1990-2000. Tip: circa = the year and 10 years either side.
after	Return records where the value in the search field is later than the search period. Used for > in a Standard search. For Advanced searches (and WebAPI requests) use >.
after including	Return records where the value in the search field is later than or the same as the search period. Used for >= in a Standard search. For Advanced searches (and WebAPI requests) use >=.
before	Return records where the value in the search field is earlier than the search period. Used for < in a Standard search. For Advanced searches (and WebAPI requests) use <.
before including	Return records where the value in the search field is earlier or the same as the search period. Used for <= in a Standard search. For Advanced searches (and WebAPI requests) use <=.
is not empty	Return records where the search field contains a value. Used for =* in a Standard search. For Advanced searches (and WebAPI requests) use =*.
is empty	Return records where the search field is empty. Used for ='' in a Standard search. For Advanced searches (and WebAPI requests) use =''.

Notes

• Search values with spaces or hyphens must be enclosed in quotes in an Advanced search; in WebAPI requests use the URL encoded version of a quote (%27 for single quote), e.g.:

  wwwopac.ashx?database=collect&search=period%20within%20%272000-2002%27

• It is possible to use dates in the current interface language / region format.

Application Administrators will find details about implementing the Period data type in the Axiell Designer Help.

A change to how occurrences If a field in the current record can have more than one value, we add an occurrence of the field for each value (e.g. a book can have multiple authors so we add an occurrence of the author.name (au) field for each author). An occurrence can be a member of a group of fields, and adding an occurrence of the field adds all members of the group at once. are sorted in Collections 2.0 sees a significant improvement in performance.

A date field occurrence, for example, may be set to sort Descending; when a new occurrence of the field is entered and the record is saved, the occurrences are sorted and the most recent date is first. Previously, every sorted occurrence in a record was sorted automatically when the record was saved, even if there had been no change to the content of the field.

Now, sorting only occurs when a record is saved if the field contents have changed, resulting in a significant performance boost, especially where there are numerous sorted occurrences with many values.

Previously, a Download or Upload button displayed to the right of email fields when editing records:

Email fields have an Application data type, which by default display the buttons (details in the Axiell Designer Help). The button no longer displays. In Display mode, email addresses are underlined and can be clicked to open your default email application to compose an email to the destination address:

Application Administrators are now able to specify a start and end point for an audio or video file; when Play is pressed in Media viewer the specified fragment of the media is played by default (although the entire file is available and can be played by manually dragging the slider in the media player):

There are various ways this feature can be implemented and Application Administrators will find details about configuring this functionality in the Axiell Designer Help. One approach is to link the Multimedia documentation record for an audio or video file to a Catalogue record and specify a start and end point for the linked media in the Catalogue record; in this way, sections of a media file could be specified and described in their own Catalogue record.

Tip: The start and end time must be specified in seconds (120 seconds for a start point of 2 minutes for example).

It is possible to view your Collections data in predefined reports, and to print these reports. Reporting and printing use the same templates (Microsoft Word templates, Excel templates or XSLT style sheets for example) to lay out and style your data; the main difference between reporting and printing is that reporting displays your record data on-screen, and printing is obviously intended to output your data to a printer.

Printing record data in Collections prior to version 1.18 involves selecting a template from the Output formats box, opening the associated third-party application (MS Word, MS Excel or web browser), and then printing the formatted data from the open application.

From Collections version 1.18 an option was added to print the result of an Output format directly to a printer, rather than first opening the third party application. When available, a Print button is added to the Output formats box:

Users select an output format from the list and then select Print to display a Select printer dialogue from which a printer is chosen:

Application Administrators will find details about configuring this option in the Axiell Designer Help.

Note: Note that this option is currently only available for local implementations of Collections and not the hosted implementation of Collections.

Collections version 2.0 extends this option by allowing Application Administrators to associate one or more printers with a particular output format, ensuring that users can only select an appropriate printer for the chosen output format (a label printer for printing labels, for instance). As before, a user selects a template from the Output formats box and clicks Print to display the Select printer dialogue, which now only lists one or more printers appropriate for this output format.

Tip: Application Administrators will find details about configuring this functionality in the Axiell Designer Help.

The background images used for the Collections Login page are stored in the ..\Content\Backgrounds\Login folder of a Collections installation.

It is now possible to use your own images for the Collections Login page.

Application Administrators (with access to the Collections installation directory) need to create a Custom folder:

..\Content\Backgrounds\Custom

in which to hold the custom background images (either .jpg or .png).

When Collections loads, the Custom folder is checked first and any images stored there will display; if the Custom folder does not exist or it contains no images, the images in the Login folder are used.

Note: Do not replace the images in the ..\Content\Backgrounds\Login folder as the images in this folder may be overwritten when Collections is updated.

When you select a term from an external thesaurus in a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., Collections now checks all unique indexes in the local thesaurus for a match with data from the external term record. If a match is found, the link will be made to the existing local thesaurus record; in other words, the external record will not be derived and a duplicate record will not be added to your local thesaurus.

Note: There is no notification when this happens.

As a result, Application Administrators should check which fields in the local thesaurus have a unique index if their system is also using an external thesaurus. If, for example, the Term field is uniquely indexed, it will not be possible to derive the same term from an external thesaurus even if the metadata is different; on the other hand, if a URI field (referencing a Linked Open Data term) has a unique index, it would be possible to derive the same term as long as the duplicate(s) in your local thesaurus do not have the same URI.

The Result set View toolbar includes a drop list of options for marking of records, including mark all / unmark all, drop marked records, etc. (details here). Marking / unmarking of all currently listed records can now also be achieved by clicking a checkbox in the column header row in Result set View: