@ericfennis: should we really add categories as a concept, how do you think it should be represented in the data layer?
Possible alternatives I see:

1) Categories could just be "special" tags - special in the way, that we'd designate some tags as categories and store their data in a separate categories.json file:

[
  {
    "tag": "arrows",
    "name": "Arrows",
    "description": "Lorem ipsum dolor sit amet",
    "icon": "arrow-left-right",
  },
  ...
]

or

{
  "arrows": {
    "name": "Arrows",
    "description": "Lorem ipsum dolor sit amet",
    "icon": "arrow-left-right",
    "weight": 0,
  },
  ...
}

Pros:

• pretty easy to set up and maintain (at least from a technical point of view).
• the task of assigning categories to existing icons would be less labour intensive (although tag associations would still need to be overhauled because of missing or incorrectly assigned tags).

Cons:

• categories will probably include false matches because of generic search terms as well as homographic tags, e.g.:
  • text might be added to icons featuring or related to text, e.g. file-text, newspaper, or regex, but the current text tag as a category would just meant to include icons used in text formatting (alignment, headings, text style etc).
  • map might be added to an icon that represents mapping a network drive or mapping values, but map as a category should only feature icons that would be used on maps (points of interest, locations, pins, navigation etc).
  • This issue could be alleviated by using really specific category-as-tag names (e.g. text-formatting in this case), but language is unpredictable, so any attempt for a workaround wouldn't be completely foolproof, especially on the long run.
• certain search terms will also include "false" matches, making certain icons much harder to find and search for, e.g.:
  • if we add the map category to all icons featuring points of interests e.g. education, building, syringe, croissant etc, searching for "map" will have all of these pop up, even when you were really just looking for map itself.

2) We could add categories as a separate entity, unrelated to tags:

Pros: categories and tags have a somewhat different use case and purpose (basically free text search vs faceted filtering), since this solution makes the models completely detached, it would get rid of all cons listed in 1).

Cons: is harder to set up and maintain, a completely new set of icon categories will need to be assigned to all our icons.

In this setup we could either:

2.1) Add a file storing icon-category relationships (in the exact same format as tags.json) as well as a separate file storing category information e.g.:

{
  "arrows": {
    "name": "Arrows",
    "description": "Lorem ipsum dolor sit amet",
    "icon": "arrow-left-right",
    "weight": 0
  },
  ...
}

or:

[
  {
    "name": "arrows",
    "title": "Arrows",
    "description": "Lorem ipsum dolor sit amet",
    "icon": "arrow-left-right",
    "weight": 0
  },
  ...
}

Pros: pretty similar concept to what we already have with tags.

Cons: pretty fussy to maintain and even more fussy when you need to add new icons.

2.2) Add a categories.json file storing categories as well as all icons in that category, such as:

[
  {
    "name": "Arrows",
    "description": "Lorem ipsum dolor sit amet",
    "icon": "arrow-left-right",
    "icons": ["arrow-left", "arrow-right", ...]
  },
  ...
]

Pros:

• pretty straightforward structure, the number of icons per category is easily accessible
• no "false" categories can be added to icons (names that do not have a category data structure).
• generally speaking, it's fairly easy to maintain, but...

Cons:

• ...there's a significant risk of new icons not being assigned to the categories needed.
• Filtering by category (especially multiple categories) would be funky to implement and would probably need transforming the data to an icon-category mapping.

2.3) Have the same categories.json file as in 2.1, but migrate from the current tags.json format to one that also stores category relationships e.g.:

{
  "accessibility": {
    "categories": [...],
    "tags": [...]
  },
  ...
}

Pros:

• pretty easy to maintain and add new icons.
• also opens up the opportunity to easily add further metadata to icons, some random ideas:
  • description (e.g. alternate text description of visual components of icon)
  • version/date added/updated (not sure if this information can be gathered automatically from github)
  • additional licenses (e.g. for certain brand icons or the accessible icon)
  • source reference (e.g. https://accessibleicon.org/)
  • manual contribution entries
  • a list of available styles (in case we ever add filled/duotone styles)
  • suggested maximum/minimum weight/size should these differ from the overall project guidelines

Cons: the current data structure would need to be migrated and handled accordingly, although this could simply be handled by converting the new format to the existing tags.json structure as part of the build flow.

Personally, while I originally suggested option 1 in #94, upon researching the impact, I am now leaning heavily towards option 2.3.