Research Area: Controlled Vocabulary

Tool discoverability is currently hindered by the absence of a standard system for defining tools, their functionality, their audiences, etc. The current approach used by tool directories involves freeform keywords, which are i18n-unfriendly and lead to keyword duplication. (It turns out that software directories in general, including Packagist and npm, work this way, which is not exactly inspiring.)

The challenge is to create a system of standardized vocabulary, maintained by the community, that can be used to describe tools. Where possible, we should re-use existing software/platforms and re-use existing vocabularies, rather than invent new ones. One idea was to use Wikidata identifiers, which may work for most terms but not all. Creating a totally novel system risks duplication of effort.

Another design challenge would be to create a system that would be easy to use in the context of manually updating a JSON toolinfo file, if this is a use case we want to support. What would be the language-neutral "tokens" used?

If we do not use an existing system, we need to figure out where to store this new system, in such a way that the content can be updated if needed.

Different options we can consider:

• Use Wikidata as the backend
  • Advantages: Reasonably well understood; very flexible and accommodating; many terms are already included and translated
  • Disadvantages: Concepts people may want to use to describe their tool may not be considered notable by Wikidata standards. I am researching the extent to which this is going to be a problem.
• Create our own Wikibase to use as the backend
  • Advantages: Maintains compatibility with Wikidata while allowing us to expand beyond its usual limits
  • Disadvantages: Wouldn't be as well known (Q numbers would not be Wikidata Q numbers); requires significant effort to maintain the Wikibase software and an active community to maintain the content; could potentially duplicate the effort of Wikidata
• Create a project on Translatewiki.net
  • Advantages: The platform is designed for i18n which is what we're trying to do here; it has some familiarity within our community; we could tap into an existing volunteer base
  • Disadvantages: Not a usual platform for many Wikimedians; could complicate updating the standard over time
• Have a page on Meta translated with the Translate extension
  • Advantages: A workflow that certain community members would be familiar with; the content would "live" on a wiki with SUL rather than somewhere else
  • Disadvantages: The Translate extension

The problem is resolved when:

• We know what vocabularies are going to be used and for what purposes (e.g. relevant audiences, tool purpose)
• We determine which existing vocabulary/vocabularies to use
• For novel vocabularies, we determine where the data will live and how this data gets updated, including technical and social considerations.
• A decision is made as to whether we can user-friendly language-neutral tokens to describe concepts in this controlled vocabulary for the purposes of toolinfo files or if we will keep information described via controlled vocabulary out of the toolinfo standard.