Community platforms search: how catalogs make terms findable

A catalog nobody can search is a document. The community platforms search experience depends on vocabulary: the words a reader types are not the words the catalog records, and unless someone builds the bridge between them, every search is a coin toss.

The vocabulary problem is worse for community platforms than for most categories, because the field itself never settled on names. One reader's forum is another's board, a third's server, a fourth's group, a fifth's guild. A catalog that indexes only its own terms will fail all but one of them.

What to take away

Two vocabularies, kept apart

The controlled vocabulary is the set of values a field may hold. For the classification axes it is short and fixed: the four values for where a platform runs, the four for conversation shape, and so on, as set out in the notes on classifying community platforms. For descriptive fields it is a list you maintain: what "export" is allowed to mean, what "moderation level" is allowed to mean. Every entry uses these terms and no others. This is what makes filtering possible.

A service may fit more than one operating-model value—for example, federated software can also be self-hosted. Record entry at the community or space level when access differs within a platform.

None of this needs a homemade format. The W3C's Simple Knowledge Organization System (SKOS) is a common data model for thesauri, classification schemes, subject heading systems and taxonomies, and a vocabulary expressed in it becomes machine-readable data that other tools and catalogs can reuse.

The synonym list is everything a reader might type instead. It grows forever and it is never applied to the entries themselves, only to the query. A reader who types "message board" is shown entries whose shape is "threaded and persistent"; the entry still says "threaded and persistent". A reader who types "self-host" or "own server" or "install" is shown entries whose runs-on value is "self-hosted". Other useful mappings include "chat room" to "real-time" and "invite-only" to "closed-entry"; each query term maps to a recorded value, not a new value on an entry.

This split is old library practice, not a new idea. The guidelines in ANSI/NISO Z39.19 cover the construction, testing and maintenance of controlled vocabularies, including synonym rings, and ISO 25964 does the same for thesauri. A catalog does not need to adopt either in full, but both describe the same rule: entries carry the preferred term, and the variants a reader might type point to it.

Keeping the two apart is what stops the catalog's fields from drifting as fashions change. The synonym list absorbs the drift.

Facets first, text second

Most searches on a platform catalog are requirements in disguise. "Forum I can host myself with no accounts required" is three facet values: threaded, self-hosted, open entry. Free text finds it badly and a facet filter finds it exactly, which is the precision and recall trade made in the reader's favor.

For example, a directory might index Discourse as self-hostable software for threaded, persistent discussion; Reddit as a hosted service with threaded discussions; Mastodon as a federated service with a feed; and Discord as a service centered on real-time chat. Treat these as examples of how to apply the vocabulary, not as a substitute for checking a particular community's settings or access.

So the search interface leads with the axes. Each axis is a set of checkboxes; checking one narrows the list; the count beside each remaining value shows what is left. Free text sits beneath, for names and for whatever the facets do not cover.

The facet counts do a second job. A reader who checks "federated" and "real-time" and sees a count of zero has learned something the catalog knows and no single entry states: that combination is empty in the set. That is a finding, and it is only visible through search.

What free text should index

Names, including former names, help readers find what a thing was called when they last heard of it. Quoted passages from terms and help articles let a reader find an entry by a phrase remembered from a policy.

Notes on blanks and contradictions from building an entry from four sources matter. "Export missing timestamps" is what a reader searches after it bites them.

Not indexed: the editorial narrative, if there is one, because it will match everything, and the checked dates, because a date search wants a date filter, not a text match.

Negative results are results

When a search returns nothing, the page should state what was searched, which facets were active, and how many entries matched before the last filter was added. A blank page teaches nothing.

A page saying "no self-hosted, federated, closed-entry platforms are recorded; three self-hosted federated ones exist with open entry" answers a question the reader didn't know how to ask.

Log the empty searches. They are the shortest route to the next section.

The search log as an editorial tool

Every query a reader types is a small piece of evidence about the catalog's gaps, and the log of them is worth reviewing at every recheck.

The log contains what readers typed, and nothing else. Do not keep who typed it or when beyond the coarsest grain needed to count repeats. The catalog's purpose does not require it, and a search log with identities in it is a liability with no corresponding use.

At each recheck, the five patterns above collapse into three routine actions:

Search inside the platforms themselves

A separate field, and one readers ask about: how well does each platform let a community search its own history. It varies from full-text search across everything ever posted to nothing beyond scrolling.

Record it as an observed field with a test like those for things you can settle yourself on a messaging service: post a distinctive phrase, wait, then search from a member account and a logged-out one.

Make it a facet. For threaded and message-distributed platforms, this property often decides whether the archive is usable.

When a platform's search is poor, a community can lose practical access to its past posts; the community platforms overview covers that memory problem. The catalog's job is to record which platforms offer searchable history and under what access conditions.

Common questions

How large does the synonym list get?

Larger than the catalog. That is fine; it is cheap, and every entry in it is a search that used to fail.

Should the synonym list be published?

Yes. A reader who can see that "board" maps to "threaded and persistent" learns the catalog's vocabulary in one glance and searches better afterwards.

What if readers search for a platform by a feature the catalog deliberately does not record?

Say so in the negative result: the catalog does not record that property, and here is why. Readers accept a stated boundary far more readily than a silent one.

Is faceted search worth building for a small catalog?

For under a few dozen entries, a single page with the classification table and a browser's find-in-page does most of the job, and the facets can be headings. Build the real thing when the table no longer fits on a screen.