Перейти к основному содержимому

Таксономия

Зачем нужно​

Таксономия нужна для того, чтобы задачи можно было:

  • находить;
  • переиспользовать;
  • анализировать;
  • связывать с roadmap и диагностикой;
  • использовать в персонализации.

Основные оси классификации​

1. Предмет​

Задача принадлежит first-class subject.

Примеры:

  • математика;
  • физика;
  • информатика в будущем.

Предмет задаёт subject-specific taxonomy, answer schemas, checking validators, source attribution и фильтры каталога.

2. Направление​

Задача относится к одному или нескольким направлениям из эталонной модели.

Примеры:

  • олимпиадная математика;
  • школьная математика;
  • шахматы;
  • ТРИЗ.

3. Уровень​

Задача имеет уровень сложности или целевой уровень использования.

Это может быть:

  • школьный диапазон;
  • уровень программы;
  • внутренний уровень банка задач.

4. Тематическая принадлежность​

Задача может быть связана:

  • с одной или несколькими темами дорожной карты;
  • с поднавыком;
  • с разделом программы;
  • с учебным модулем.

В MVP допустима мягкая модель: прямая тема roadmap не обязательна, достаточно topic tags и downstream-связей через usage.

Для public tasks нужен ровно один primary topic. Secondary topics разрешены, но публичный UI может показывать их collapsed. Primary topic нужен для breadcrumbs, SEO, task cards и related tasks.

5. Тип задачи​

Примеры:

  • открытая задача;
  • multiple choice;
  • короткий ответ;
  • развёрнутое решение;
  • практическое упражнение;
  • интерактивная задача.

6. Источник​

Примеры:

  • олимпиада Систематики;
  • внешний турнир;
  • кружок;
  • курс;
  • авторская подборка;
  • диагностика.

Источник должен поддерживать hierarchy/path. Для первого PR source может оставаться taxonomy_node(type='source'), но документация должна описывать source path and publication policy.

Пример source path:

  • Олимпиады и турниры;
  • Турнир имени Ломоносова;
  • 2001;
  • Математика.

По умолчанию у задачи один primary source. Secondary citations можно добавить позднее, если есть реальные случаи повторной публикации одной задачи.

7. Сложность​

Сложность должна храниться как отдельный слой, а не выводиться только из уровня программы.

На первом этапе допустимы:

  • относительная шкала сложности;
  • teacher-curated сложность;
  • subject-specific difficulty.

Позже может быть добавлена калибровка по данным реальных решений.

8. Навык / компетенция​

Потенциальный будущий слой.

Например:

  • логические рассуждения;
  • работа с инвариантами;
  • перебор;
  • комбинаторное мышление.

На раннем этапе этот слой можно держать как необязательные skill tags.

Минимальный набор тегов для MVP​

Для MVP достаточно поддержать:

  • предмет;
  • направление;
  • уровень;
  • тематику;
  • тип задачи;
  • сложность;
  • источник.

Принцип устойчивости таксономии​

Таксономия не должна зависеть от одного конкретного продукта или одного сценария использования.

Правильно:

  • задача имеет тему и уровень, а потом используется в курсе и олимпиаде.

Неправильно:

  • задача “принадлежит курсу” и только поэтому считается математической задачей уровня 3–4.

Технические правила​

  • taxonomy nodes не должны образовывать cycles;
  • slugs/path должны быть stable для public pages;
  • primary topic exactly one for public task;
  • source hierarchy не должен раскрывать restricted/embargoed source в public catalog;
  • перемещение темы не меняет canonical URL задачи /tasks/<taskId>.

Готовность​

  • у каждой задачи есть предмет, тема, уровень и тип;
  • public task имеет primary topic;
  • источники поддерживают hierarchy/path и publication policy;
  • таксономия не зависит от конкретного курса или олимпиады;
  • сложность и skill-теги можно уточнять без потери связи с задачей;
  • соседние домены используют теги, но не создают собственную классификацию.