Search | Communifire Documentation

Communifire's search engine returns results based on relevance. Communifire's search engine searches among the following:

• People
• Spaces
• Content
• Chat Messages

Quick Results

When you start typing in the search bar, a dropdown menu appears that suggests results. If you do not see what you are looking for, you can hit enter or click All results.

Search Results Page

When you view all results, you are taken to a results page. By default, results are in descending order of relevance.

On the left are search filters. You can filter and sort results in the following ways:

• Sort
  • Most relevant
  • Most viewed
  • Most recent
  • Most commented
  • Highest rated
  • Date (oldest first)
• Date
  • Start date
  • End date
• Spaces
• Content types
• Authors
• Tags
• Tag groups

Top Level Search vs Space Search

The search bar at the top of your intranet searches the entire intranet - all people, all public spaces and private spaces a user is part of, and all content in all the spaces a user has access to. Each space also has its own Space Search that searches through only the content in that space. 

Search By Tag

Use the following URL to search by tag:

http://your-community.communifire.com/searchresults?keyword="Tag"&searchtags=1&spaces=SpaceID

Replace http://your-community.communifire.com with your community's URL, Tag with the tag to search by, and SpaceID with the ID of the space to get results from.

Search Analytics

You can see an overview of the keywords and tags people search for and the click-through rate in Control Panel > Analytics > Search Analytics .

Search Logic

Communifire search uses Elasticsearch. Elasticsearch indexes all records as "documents". A document is a set of fields. Each field has a name and a textual value. Each document typically contains one or more fields which uniquely identify it.

In Communifire, each piece of content, like an article, a blog, an event, etc., is stored as a unique document in Communifire's search index. While indexing an individual article, Communifire indexes the article as a single document and indexes the various fields like article title, article body, tags, comments, etc., as separate fields within this single document. The content title is given more weight while indexing so that search results having the search keyword in the title are prioritized over results which have the keyword only in the body.

In the case of users, each user is indexed as a single document with fields like user name, email, full name, and profile fields (both custom profile fields as well as default profile fields) indexed as separate fields in this single document.

In Elasticsearch, by default, results are returned in descending order of relevance. By default, Elasticsearch makes use of Lucene’s practical scoring formula, which represents the relevance score of each document with a positive floating-point number known as the score. The higher the score, the higher the relevance of the document. A query clause generates a score for each document, and the calculation of that score depends on the type of query clause.

The score is calculated on the basis:

How often does the term appear in the document? The more often, the more relevant. A document containing five mentions of the same term is more likely to be relevant than a document containing just one mention.

How often does each term appear in the index? The more often, the less relevant. Terms that appear in many documents have a lower weight than more-uncommon terms.

How long is the field? The longer it is, the less likely it is that words in the field will be relevant. A term appearing in a short title field carries more weight than the same term appearing in a long content field.

Source: What Is Relevance? — Elasticsearch

So if Communifire has indexed a short article and a long article, and the keyword is in the title of both the articles, then the short article will rank higher in relevance than the long article.

To understand all this, let's use some examples. Say we have 4 articles (or any content type) added and indexed in Communifire:

Article 1 with title: "Brown fox brown dog"
Article 2 with title: "The quick brown fox jumps over the lazy dog"
Article 3 with title: "The quick brown fox jumps over the quick dog"
Article 4 with title: "The quick brown fox"

Now if the user searches for this text: brown dog, the results would be the following, sorted in decreasing order of relevance:

1. Article 1 will be the most relevant because it contains brown twice and dog once.
2. Article 2 and 3 both contain brown and dog once each, and the title field is the same length in both docs, so they have the same relevance score.
3. The last result would be Article 4, which matches the search term even though the title contains only brown and not dog.

Let's see another example where we have 3 users with the following data indexed in Communifire:

User 1
Name: Maria Hores
Username: hmaria22
Favourite Movie: Avatar, Schindler's List

User 2
Name: Maria Juanez
Username: maria-juanez
Favourite Movie: (not filled)

User 3
Name: Maria Antares
Username: a_maria
Favourite Movie: Titanic, Heat

Now if the user searches for this text: maria, the results would be the following, sorted in decreasing order of relevance:

1. Maria Juanez: maria matches the name and also the username.
2. Maria Antares: Here maria matches the name and also the username, just like the top result, but Maria Antares has the Favorite Movies field filled in whereas Maria Juanez does not. This means that the indexed document for the user Maria Juanez is shorter than Maria Antares's indexed document, so Maria Juanez is more relevant.
3. Maria Hores: This user will be the last in the search results because maria matches only the name.

To learn more about relevance, refer to Elasticsearch's What Is Relevance? page.

Search Operators

Communifire search supports boolean operators, boosting, fuzzy search, phrases, and wildcard search. To enable using special characters in search, go to System Properties , edit LuceneSpecialCharFilter, and remove the special characters from the CSV list.

Boolean operators

By default, search terms are optional. Search will return results that match at least one of the search terms. You can use boolean operators to require terms, make terms optional, and exclude terms.

• AND
• OR
• NOT

Examples:

"New York City" AND London - Returns results including both "New York City" and "London."

Dallas OR London - Returns results with either "Dallas" or "London."

London NOT Paris - Returns results that contain "London" and do not contain "Paris."

Boosting

Use the boost operator ^ to make one search term more relevant than another. The default boost value is 1, but can be any positive floating point number. Boosts between 0 and 1 reduce relevance.

Example:

Suppose we have 3 pieces of content:

Article 1 contains "fox"
Article 2 contains "quick fox"
Article 3 contains "slow fox"

A search for quick^2 fox slow^0.5 will return results in the following order:

Article 2 containing "quick fox"
Article 1 containing "fox"
Article 3 containing "slow fox"

Fuzzy search

Use the fuzzy operator ~ to search for terms that are similar to, but not exactly like the search term. Fuzzy search uses the Damerau-Levenshtein distance to find all terms with a maximum of two changes, where a change is the insertion, deletion, or substitution of a single character, or transposition of two adjacent characters. The default edit distance is 1. The edit distance can be specified by following ~ with a positive integer.

Example:

Suppose we have 3 pieces of content:

Article 1 contains "quick fox"
Article 2 contains "quikc fox"
Article 3 contains "quokc fox"

A search for quick~ will return Articles 1 and 2.

A search for quick~2 will return Articles 1, 2, and 3.

Phrases

Wrap phrases in double quotes to search for the exact phrase.

Example: "Knowledge management"

Wildcard search

Wildcard search returns results where the wildcard can be replaced by a single character or multiple characters.

• ? — Single character wildcard
• * — Multiple character wildcard

Examples:

Suppose we have 5 pieces of content:

Article 1 contains "text"
Article 2 contains "test"
Article 3 contains "tester"
Article 4 contains "tent"
Article 5 contains "testing"

A search for te?t will return articles 1, 2, and 4.

A search for test* will return articles 2, 3, and 5.