Activity search behavior using Author API

Introduction

Activities you create are saved in your Activity list. You may need to search for an Activity to review or edit it.

Activities contain many attributes, but only a subset are indexed for searching. Understanding how each searchable field behaves can help you find Activities more efficiently.

This article explains how Activity search works for the following searchable fields:

  • Reference
  • Title
  • Description
  • Status
  • Tags

The search behavior differs for each field because they are intended to store different types of information. For example, References are unique identifiers, whereas Titles and Descriptions are human-readable text.

Search fields

The following table summarizes when to use each searchable field.

Search field Best used for Search behavior
Reference Finding a specific Activity when you know all or part of its reference Token-based and beginning character (right wildcard) search
Title Finding Activities by their human-readable title Token-based and beginning character (right wildcard) search
Description Finding Activities using keywords or phrases contained in the description Token-based right wildcard search (v2026.1.LTS and later)
Status Filtering Activities by publication status Exact status matching
Tags Finding Activities associated with one or more Tags Exact Tag matching with AND/OR options

Reference

References are unique identifiers for Activities. Because references are typically system-generated or customer-defined identifiers rather than natural language, they are not intended to be human-readable. This difference is reflected in how reference searches are performed. By default, Activity references are UUIDs - 36-character strings with an extremely high probability of uniqueness.

Tokens

In order to support finding Activities by reference, we split them up into many sub-strings called "tokens" (Using an ngram analyzer).

The length of these tokens are between 4 and 12 characters, inclusive. If you are interested to know why these token lengths were chosen, see the last section on this page..

That means for any given reference, we'll split it into every possible (sequential) substrings, of lengths 4 characters, 6 characters....etc, up to 12 characters.

For example, a reference of LRN_REF_1 generates the following tokens:

[
'LRN_', 'RN_R', 'N_RE', '_REF', 'REF_', 'EF_1',
'LRN_R', 'RN_RE', 'N_REF', '_REF_', 'REF_1',
'LRN_RE', 'RN_REF', 'N_REF_', '_REF_1',
'LRN_REF', 'RN_REF_', 'N_REF_1',
'LRN_REF_', 'RN_REF_1', 'LRN_REF_1'
]

So a 9-character reference generates 21 tokens.

Our default UUIDs, for example: b040fea1-2627-42a7-ad42-2762169eccf1 generates 261 tokens.

We support references up to 150 characters, and such references will generate 1287 tokens.

Token search

When searching for a reference, the exact search term (i.e. we do not tokenize it) is compared against all of these tokens for each Activity. E.g. if the search string is REF_1, this value is looked for in the generated tokens. If matches one of the tokens, then this is returned along with any other Activity which match.

In this case, the search string can be anywhere in the reference.

Beginning character search (right wildcard search)

At the same time as token search, we also do search for Activities that "begin with" the provided search term. This is also known as a right wildcard search. So for LRN it will search for all references which start with this string.

There are 2 reasons we also do this search alongside token search. These are to support searching by:

  • The entire reference. References typically are >36 characters, i.e. outside our token length range, and so this is needed to find them.
  • Search terms of lengths outside of our token lengths. E.g. with a 3, or say 15 character search string. This must include the beginning part of the reference, as we indicate in the UI.

    Activity search by reference.png
    Activity search by reference

Title

To enable Activity search by title, you must enable the show initialization option in your Author API.

Titles are intended to be human-readable identifiers for Activities. They are non-unique and generally should not contain special characters.

Tokens - titles

Titles are analyzed using a language analyzer rather than an n-gram analyzer.

For example: math level 3 semester 1 is tokenized as:

math, level, 3, semester, 1

Hyphens (-) are treated as spaces and generate the same tokens.

Periods (.) behave differently:

  • a.b remains a single token.
  • 1.a is split.
  • a.1 is split.

Although periods are supported, they are not recommended in titles.

Tokens - search term

When the search is performed, the search term is also split up the same way. E.g. if the search term is math semester, this will be split into math and semester.

Token search

The search now does a logical AND search using these tokens: must match math AND semester. The tokenized Activity titles are then searched, and as the above title example contains both of the search terms, it's returned.

Beginning character search (right wildcard search)

As we do for references, we also do a right wildcard search for the provided (exact) search term.

This is for a similar reason - that tokens may not exist for the provided term. This could be because periods (.) were used and weren't split on for example, or the exact title may be used.

Description

Activities can also be searched using their description. Descriptions are intended to provide additional context about an Activity and are analyzed as human-readable text, similar to Activity titles.

From v2026.1.LTS, the Description field supports right wildcard searching to help locate Activities when only part of a word or phrase is known.

Tokens - descriptions

Like Activity titles, descriptions are analyzed using a language analyzer. The description is split into individual tokens based on English language rules. Hyphens (-) are treated as spaces, while periods (.) follow the same tokenization rules as Activity titles.

Wildcard behavior

When searching descriptions, the search performs a right wildcard search on each token in the query. This allows partial word matches while maintaining search performance.

  • Only right-side wildcards (prefix matching) are supported.
  • Full wildcards are not supported.
  • Wildcards are applied to each token individually, not the entire search string.

For example, searching for: math equat quad is interpreted as: math* equat* quad*

It is not interpreted as: *math equat quad*.

Description search examples

Search query Result
branch Returns Activities whose descriptions contain tokens beginning with branch, such as Sample branching activity with testlets, Sample branching activity, and Branching test - End of level 1.
branch test Returns Activities matching both wildcard tokens, such as Branching test - End of level 1 and Sample branching activity with testlets.
branch test lev Returns Branching test - End of level 1 because all three wildcard tokens match.
branch test lev end Returns Branching test - End of level 1.
branch test lev end of Returns no results because wildcard matching is disabled once the query reaches the token limit.
Sample branching activity with testlets Returns an exact match for the Activity description.

Token limit

For performance reasons, wildcard matching is applied only to shorter search queries.

When a search query contains five or more tokens, wildcard matching is disabled and the search falls back to exact token matching.

For example:

This is a long search query that

contains six tokens and therefore performs an exact token match instead of wildcard matching.

Tokenization rules

Description searches use the same tokenization rules as Activity titles.

Tokens are generally separated by whitespace and punctuation, with the following exception for periods (.):

  • A period is not treated as a separator when it appears between alphabetic characters.
    • Example: a.b is treated as a single token.
  • A period is treated as a separator when either side of the period is not a letter.
    • Example: 1.a
    • Example: a.1

Although periods are supported, they are not recommended in Activity descriptions because they are intended to remain human-readable.

Note: Wildcard searching is available only for the Description field. Reference and Title searches follow their own search behavior, as described in the previous sections.

Tags

When creating Activity, tags can be added to improve searching. See more information about tagging here.

Typing at least 3 characters in a tag parameter field will return tag suggestions in a dropdown. The suggestions will match the typed characters in any word occurring in the tag type or tag name.

When an ItemBank contains a lot of tags and the tag you're searching for contains special characters (like '.' or '-'), the query to find suggested tags might time out. The reason for this might be that our code and the database index treats special characters like empty spaces, so a search term like 'term1.term2' is split into two terms ('term1' and 'term2') which are then used to search against tag types, tags and a combination of both. One way to improve search performance is by using a colon ':' indicating whether you want the search to occur against types or tags only. If you want to search against types only, add the colon at the end of the term 'term1.term2:'. If you want to search against tags only, add the colon at the beginning of the term ':term1.term2'. If you want to run a combined search against tag types and tags, add the colon where the type name ends and the tag name starts: 'type1.type2:tag1:tag2'.

When you select a tag and search, Activities containing the tag (only exact matches!) will be returned. The search behavior is different whether you choose Match all tags or Match at least one tag.

  • If Match all tags is chosen, only Activities that contain all the selected tags will be returned (logical AND).
  • If Match at least one tag is chosen, Activities only have to contain one of the selected tags (logical OR).

Status

Status search filters Activities based on their publication state rather than matching text.

The available statuses are:

  • Published
  • Unpublished
  • Archived

Appendix

Token lengths

These min and max token lengths were chosen based on analysis of references in our database and a balance between maximum search-ability and space.

UUIDs have sections/sub-strings (split by hyphens) of 4 characters so the majority of references don't contain references with 3 character sections. If we had supported 3 character tokens, a UUID would generate 295 tokens - an additional 34 tokens per reference, and thus cost more.

Likewise, with the upper limit, there were very few references with more than 12 character substrings, and so is little benefit to generating tokens longer than that.

Was this article helpful?

Did you arrive here by accident? If so, learn more about Learnosity.