Category vs body_part in the Exercises Dataset: What Is the Difference?

The category field is a free-form UI label that mirrors the body_part enum, which provides a validated, canonical value for backend logic and analytics.

The hasaneyldrm/exercises-dataset repository contains over 1,324 exercise records, and every entry includes both a category and a body_part field. Understanding the difference between category and body_part ensures you query the data correctly, build reliable filters, and validate new submissions against the official JSON Schema.

How the Schema Defines category and body_part

The relationship between these two fields is codified in data/exercises.schema.json. The schema explicitly documents each field's purpose, type, and constraints.

category: Free-Form UI String

In data/exercises.schema.json at lines 64-67, the category property is defined as a plain string with the description "Body part category. Mirrors body_part." Because it lacks an enum restriction, it can hold any non-empty string, though in practice it is populated with the same value as body_part. Frontend components typically consume this field for human-readable labels and drop-down filters.

body_part: Normalized Enum Value

In the same schema at lines 70-73, body_part is defined as a string drawn from a fixed enum: back, cardio, chest, lower arms, and others. This guarantees that every exercise targets a known, consistently spelled body region. Backend services and analytics pipelines should rely on this field for strict validation and grouping.

Why the Dataset Stores Both Fields

The duplication is intentional. According to the source schema and dataset design, maintaining both columns serves four distinct purposes.

1. Redundancy by Design

The schema notes that category mirrors body_part to make the dataset easier to consume for two separate use-cases. UI clients read category for display purposes, while validation logic consumes the canonical body_part enum. This separation prevents spelling variations from breaking downstream tools.

2. Schema Validation

Because body_part is constrained to an enumerated list, automated checks can reject records that contain typos or unsupported regions. The category field carries no such restriction, so it cannot serve as a trusted validation anchor on its own. When adding new exercises, you must select an exact enum value for body_part to pass validation.

3. Legacy and Backward Compatibility

Earlier versions of the dataset and some external tools referenced only the category field. Preserving both columns ensures that older integrations continue to function without requiring migrations. Newer applications can adopt the stricter body_part enum while legacy consumers still read category.

4. Typical Query Workflows

Front-end filters should group by category (e.g., “Show all Chest exercises”), while database queries and data science notebooks should predicate on body_part. Using the enum for storage and the free-form string for presentation keeps rendering code decoupled from validation logic.

Code Examples: Querying and Validating the Dataset

These runnable snippets demonstrate how to consume, filter, and validate records safely.

List Distinct Categories in JavaScript

The following browser-based script fetches data/exercises.json and extracts every unique category value for a filter menu.

fetch('https://raw.githubusercontent.com/hasaneyldrm/exercises-dataset/main/data/exercises.json')
  .then(r => r.json())
  .then(exercises => {
    const categories = [...new Set(exercises.map(e => e.category))];
    console.log('Available categories:', categories);
  });

Filter Exercises by body_part in TypeScript

This Node.js snippet reads the local dataset and returns only exercises whose validated body_part equals back.

import * as fs from 'fs';

const raw = fs.readFileSync('data/exercises.json', 'utf-8');
const exercises: any[] = JSON.parse(raw);

function getBackExercises() {
  return exercises.filter(e => e.body_part === 'back');
}

console.log('Back exercises count:', getBackExercises().length);

Validate a New Record with Python

Use jsonschema to verify that both fields are present and that body_part matches an allowed enum value defined in data/exercises.schema.json.

import json, jsonschema, pathlib

schema = json.loads(pathlib.Path('data/exercises.schema.json').read_text())

new_exercise = {
    "id": "9999",
    "name": "Sample Press",
    "category": "chest",
    "body_part": "chest",
    "equipment": "dumbbell",
}

jsonschema.validate(instance=new_exercise, schema=schema)
print("Record is valid!")

Key Source Files

Working with this dataset requires referencing the following files in the repository:

• data/exercises.schema.json — Defines the category and body_part properties, including the mirroring note and the body_part enum at lines 64-73.
• data/exercises.json — The full dataset containing 1,324 exercise objects.
• README.md — Provides a high-level overview of the dataset and its fields.

Summary

• category is a free-form string intended for UI labels and filtering.
• body_part is a schema-validated enum that guarantees consistent, canonical values.
• The JSON Schema in data/exercises.schema.json explicitly states that category mirrors body_part.
• Use category for display logic and body_part for validation, storage, and analytics.
• Legacy tools may rely on category, while new integrations should prefer the body_part enum.

Frequently Asked Questions

Is category always identical to body_part?

In practice, yes. The dataset populates category with the same value as body_part, and the schema describes category as a mirror of body_part. However, because category is not constrained by an enum, it could theoretically differ if edited manually.

Which field should I use for a workout app filter?

Use category for client-side display and filtering, because it is meant for human-readable grouping. For server-side queries or database indexing, use body_part to benefit from the guaranteed enum values and avoid inconsistencies.

What happens if category and body_part have different values?

The JSON Schema does not enforce equality between the two fields; it only enforces that body_part matches the defined enum. A mismatch would pass validation, but it could break UI expectations since the dataset is designed with the assumption that they mirror each other.

How do I validate a new exercise before adding it to the dataset?

Load data/exercises.schema.json and run the candidate object through a JSON Schema validator such as Python’s jsonschema library. Ensure body_part is set to one of the allowed enum strings and that category matches it for consistency.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}