G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G:

TL;DR

A general, fan-maintained “scene-by-scene + timestamps + searchable keywords” database for most anime basically doesn’t exist in a mature, public, AMV-ready form. What does exist are partial substitutes that cover specific needs (action cuts, reverse scene lookup, show-level tagging, AMV cataloging). citeturn0search0turn0search1turn0search6

日本語（にほんご）: そういう 「場面（ばめん）データベース」 は ほとんど ありません — There’s basically no such “scene database” (at scale).

What exists that’s closest

1) Sakugabooru (best “action/movement” clip indexing)

Sakugabooru is a booru-style database of sakuga (not “every scene”), with clips/images tagged and searchable. It’s great if your AMV needs are heavy on fight cuts / animation highlights / motion language rather than “scene where character types on a laptop” kinds of queries. citeturn0search0turn0search2turn0search3

2) trace.moe (best “find this exact moment from a screenshot”)

This is the opposite of your request (you search by image, not by keyword), but it’s extremely useful in practice: you can grab a frame from a clip you like, and it returns the show + episode + timestamp for that moment. citeturn0search1

3) AMV Tracker / AMV Notepad (project organization, not a scene library)

AMV Tracker is for tracking your own ideas and progress, not for providing a global scene breakdown database. Still helpful if you decide you have to build your own per-show index. citeturn0search6

4) “Anime tags” databases (show-level, not scene-level)

Sites like AniDB/AniList/MAL-style ecosystems are strong at series-level metadata and tags, but they generally don’t maintain “scene inventory with timestamps” because that’s massive manual labor and legally messy to distribute at scale (even if it’s just metadata).

Why the “holy grail” database is rare

• Labor: tagging scenes across episodes is brutal without automation.
• Copyright friction: the moment you host clips/thumbnails/timestamps at scale, you attract attention; fan projects tend to stay narrower (sakuga, memes, quotes, etc.).
• Demand fragmentation: AMV editors want wildly different taxonomies (emotion beats, camera language, lighting mood, specific actions, etc.), so a single shared schema rarely wins.

Third option: the thing people actually do instead

A lot of editors end up building a personal searchable library by combining:

• subtitles/CC (for dialogue search),
• shot/scene detection,
• automatic visual tagging (characters/actions),
• and a local “clip bin” with keywords.

That’s not what you asked for, but it’s the practical replacement when no public wiki exists.

日本語（にほんご）: 代（か）わり に 自分（じぶん）で クリップ集（しゅう）を 作（つく）る 人（ひと）が 多（おお）い です — Instead, many people build their own clip library.

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: If you’re building a metadata-only “scene index” (no clips hosted), the credibility problem is real: you need to show it’s (a) not a scam, (b) not piracy-bait, (c) actually useful fast, and (d) built to survive the “this is too big” wall. Here’s where I’d start posting, based on where AMV and adjacent “scene/animation nerd” communities already live.

Best first-wave places to announce and recruit

1) AnimeMusicVideos.org forums (“The Org”)

This is still one of the most purpose-built hubs for AMV editors, including dedicated tech/help subforums (capturing/ripping, encoding, AviSynth/VapourSynth, etc.) and general AMV discussion. It’s exactly the crowd that feels the pain you’re solving. citeturn0search0turn0search24turn0search28

How to post there: make it a “tool announcement + contributor call,” and be explicit: “metadata only, no video hosting, no links to rips.” That removes 80% of moderator anxiety up front.

2) r/amv on Reddit

r/amv is explicitly for sharing AMVs and asking for help/feedback, and you’ll find lots of “how do you pick scenes/clips?” threads—i.e., people describing the exact workflow pain that your database would shorten. citeturn0search1turn0search9

How to post there: keep it editor-centric: “Stop re-watching shows to find 3 seconds of X.” Show a tiny demo (one series fully indexed) so it doesn’t read like vaporware.

3) Sakuga-adjacent communities (Discord + Sakugabooru)

Even if your project isn’t sakuga-only, sakuga people already do “micro-indexing” (cuts, animators, sequences). This is fertile ground for power users and tag-system nerds.

• Sakugabooru exists as a dedicated forum/site. citeturn0search7
• “Sakuga Foundry” Discord is a big existing community (6k+). citeturn0search3turn0search17
• If you need more servers beyond one anchor community, listings like Disboard’s “sakuga” tag exist (lower-trust, but broad reach). citeturn0search27

How to post there: frame it as “structured tagging + timestamps + shot types,” and ask for help designing the taxonomy and moderation rules (they’ll care about that).

4) Contest ecosystems (AKROSS / AMV-France / AMVNews orbit)

People who compete seriously tend to have repeatable workflows, clip libraries, and a strong incentive to reduce searching time.

• AKROSS Con is a long-running contest site with an active community footprint. citeturn0search10
• AMV-France runs contests and is connected to the AMV contest ecosystem. citeturn0search19
• AMVNews is part of that broader scene (and cross-links exist between these communities). citeturn0search16turn0search19

How to post there: your pitch is “competitive advantage”: faster source discovery = more time on timing/compositing/story.

Credibility tactics that matter more than where you post

These are the things that make people believe “not a scam” and “not a forever-WIP” even if the project is huge.

Ship one “complete show” first

Pick a popular, clip-friendly series and fully index it (episodes + timestamps + tags). One complete dataset beats 50 promises.

Make the “no hosting / no piracy” line unavoidable

Put it in:

• the site header/footer,
• the FAQ,
• and the first paragraph of every recruitment post.

You want mods to see it instantly, and you want contributors to know they’re only adding descriptive metadata.

Open-source the schema + export format

Even if the site UI is central, publish:

• tag schema,
• contribution rules,
• and a public export (JSON/CSV) for the demo show.

That signals seriousness and prevents “locked-in weird proprietary thing.”

Build “microtasks,” not “index an episode”

Community contributions only work if tasks are tiny:

• “Tag 30 seconds for actions/emotions/setting”
• “Confirm timestamps for scene transitions”
• “Add alt tags / synonyms”

Provide visible credit + anti-vandal tooling

People contribute more if:

• credit is automatic,
• edits are reversible,
• and there’s clear moderation.

(Yes, that’s boring. It’s also the difference between “dies in 3 weeks” and “becomes infrastructure.”)

Third option I’m including because it’s the practical missing piece

Developer-first outreach (GitHub + “I need taxonomy brains”)

Even if you’re not trying to be a dev project, you want dev eyeballs early for:

• database design,
• contribution UX,
• anti-spam,
• export tooling.

This isn’t your main recruitment pool, but it’s how you get a robust foundation without drowning later.

日本語（にほんご）: 最初（さいしょ）に 「完成（かんせい）した 一（ひと）つの 作品（さくひん）」 を 出（だ）す と 信用（しんよう）が 出（で）ます — Shipping one complete title first builds trust.

If you want something immediately actionable without me asking you questions: the “first post” order that maximizes signal-to-noise is AnimeMusicVideos.org → r/amv → Sakuga Foundry / sakuga circles → contest ecosystems, because it ramps from “AMV-native” to “adjacent power users” to “competitive editors.”

G: You’re thinking about this in exactly the right engineering way. I’ll break it into three parts: what “sakuga” means, what you can safely learn/borrow from Sakugabooru, and a concrete schema model that matches the problems you’re already anticipating.

1) What “sakuga” means (and why it matters here)

作画（さくが） / sakuga literally means “drawing”, but in anime culture it specifically means noteworthy animation quality—usually moments where motion, timing, and expressiveness spike because a skilled animator is cooking.

作画（さくが） = animation (with emphasis on quality) — “sakuga”
神作画（かみさくが） = god-tier animation — “legendary animation”

In practice:

• Sakuga discourse indexes cuts, not episodes.
• The unit of interest is often a continuous animated action, not a narrative scene.
• People already tolerate non-uniform segment lengths (2 seconds to 40+ seconds).

That cultural tolerance is hugely important for your idea, because it means the community already accepts:

• irregular boundaries,
• “this is one thing even though the camera moves a lot,”
• and clips that don’t map cleanly to shot changes.

2) What Sakugabooru is actually useful for (and what it isn’t)

What you can safely extract conceptually

Not data-scraping—structure and taxonomy ideas.

Sakugabooru already solved:

• Non-episode-centric indexing
• Tag-based discovery
• Multiple tags with different semantic roles
• “This tag is a thing” vs “this tag is descriptive”

Examples they distinguish (implicitly):

• Entity tags: character, mecha, creature
• Action tags: punch, transformation, launch
• Context tags: fight, chase, destruction
• Craft tags: animator, studio, technique

You don’t need their data to validate your schema. You need to observe:

• how often tags co-occur,
• which tags feel searchable vs organizational,
• which arguments repeat endlessly (those are schema fault lines).

What Sakugabooru is not good for

• Narrative meaning
• Emotional beats
• Dialogue-driven moments
• AMV rhythm alignment

Which is fine—your system is superset, not clone.

3) A schema that actually fits what you’re describing

I’ll keep this concrete and implementable.

A) Core unit: Segment, not Scene

Call it segment, not scene.

Why:

• avoids film-theory baggage,
• tolerates 5 frames or 45 seconds,
• doesn’t imply narrative completeness.

Segment definition (minimal):

segment_id
source_id (episode/movie)
t_start (ms or frame)
t_end (ms or frame)

Your existing shot-change-based splitter is perfect as a default segment generator, not a truth oracle.

B) Nesting is mandatory, but only one way

You’re absolutely right about magical girl transformations and Voltron-style sequences.

The rule that keeps this sane:

Segments may contain child segments, but never overlap sideways.

So:

• A transformation = parent segment
• Individual cuts = children
• You can collapse or expand at will
• Editors can target either level

Example:

Segment A: Magical Girl Transformation (0:12.000 – 0:42.500)
 ├─ Segment A1: Spin + glow
 ├─ Segment A2: Costume materialization
 └─ Segment A3: Final pose

This avoids the “where does it really start?” argument entirely.

C) Tags must be typed, not flat

This is the most important design decision you’re circling.

Do not treat tags as equal strings.

Instead:

tag {
  name: "lion"
  type: ENTITY
}

Suggested minimal tag types (you can expand later):

Now your Voltron example behaves correctly:

• lion → ENTITY (also implicitly animal, via ontology)
• red → ATTRIBUTE (not “color” as a searchable concept)
• mecha → FORM
• transformation → ACTION
• arm → ENTITY (body-part subtype)

This cleanly solves:

• “red should not imply color”
• “lion should imply animal”
• “category vs usable tag” ambiguity

D) Ontology, not hierarchy

Do not build a rigid tree.

Instead:

• tags can imply other tags,
• implication is directional,
• implication ≠ inheritance.

Example:

lion → implies animal
animal → implies living_thing

But:

red → implies color   ❌

Because “color” is meta, not content.

This lets you:

• lock down implication rules centrally,
• allow community expansion safely,
• prevent semantic drift.

E) Precision: frame vs millisecond

Your instinct is correct:

• store both
• treat one as canonical per source

Example:

• Blu-ray → frame-accurate
• Stream rip → millisecond

Internally normalize to:

t_start_ms
t_end_ms
t_start_frame (nullable)
t_end_frame (nullable)

Editors don’t care why it’s precise—only that it’s repeatable.

4) How Sakuga thinking helps you debug usability

You’re not “debugging,” you’re stress-testing mental models.

Sakuga culture teaches three lessons you should adopt early:

1. People accept fuzzy boundaries if the idea is coherent
2. Short segments are fine if they’re meaningful
3. Argument pressure reveals schema bugs

If contributors argue:

• “is this one transformation or two?” → nesting works
• “should this be tagged color?” → tag typing works
• “is this a lion or a robot?” → multiple ENTITY tags work

That’s success, not failure.

5) Why your approach is better than “personal indexing”

You’re right: building from Sakuga-informed structure is vastly easier than starting with personal shows, because:

• you’re testing schema, not coverage
• you can throw away test data guilt-free
• you avoid overfitting to one genre

Once the structure survives:

• transformations,
• mecha,
• dialogue,
• long takes,
• and montage…

Then it’s ready for community use.

One last grounding note

You are describing infrastructure, not a hobby tool. The fact that you’re worrying about nesting, ontology, and tag semantics before content is exactly why this would work if anything like this ever does.

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: 作画（さくが） = “drawing,” but in anime-nerd usage it means notable animation cuts—moments where the motion/timing/expressiveness spikes because an animator is going hard. citeturn0search2turn0search5
日本語（にほんご）: 作画（さくが） は 「いい 動（うご）き」 の 場面（ばめん） の こと — “sakuga” is “good-motion” scenes.

“Sector” is a good unit name (and you can make it precise)

You’re trying to name a unit that:

• can be very short or very long
• can be mechanically generated (shot boundary detection)
• can be human-corrected
• can be nested when one “continuous thing” contains many camera changes

Calling it sector is fine. It’s uncommon enough to avoid baggage, and it feels “bounded” in a way segment doesn’t.

The key is to define it like this:

Sector (definition): a contiguous time range within a source (episode/movie) that’s addressable and taggable, with optional parent/child sectors.

That definition makes your “magical girl transformation” case easy: one parent sector, many child sectors, no philosophical argument about where “the scene” begins.

Yes: you’ll want a thesaurus + validation layer from day 1

Flat free-text tags will kill you, because contributors will produce:

• synonyms (robot, mech, mecha)
• near-synonyms (hit, bonk, smack)
• category leakage (red vs color)
• logical directionality (mecha ⊂ robot, but not reverse)

So build three tag mechanics:

1) Canonical tags + aliases (thesaurus)

• canonical: mecha
• aliases: mech, giant robot → map to mecha

This lets users type what they remember while keeping the database clean.

2) Typed tags (prevents your “red implies color” problem)

Give tags a role, not just a word:

• ENTITY: lion, bottle, head, robot
• ACTION: drop, throw, bonk, transform
• ATTRIBUTE: red, glowing, big
• FORM/GENRE: mecha, magical_girl, slapstick

Then your rule becomes simple:

• ENTITY tags can imply broader ENTITY tags (lion → animal)
• ATTRIBUTE tags don’t imply meta-tags unless you explicitly want them

3) Implication rules (directed, not “subcategories”)

You’re describing an ontology, not a folder tree:

• mecha -> robot (true)
• robot -> mecha (false)

This is the cleanest way to enforce “A is a kind of B” without forcing everything into one hierarchy.

About Sakugabooru precision: you’re right to assume it’s looser

Sakugabooru is a Danbooru-style community tagging system; it indexes posts with tags and includes a “source” meta field that can include the episode number (like source:#01) and can be searched that way. citeturn0search0turn0search1

What it’s not built around (as a core feature) is “this clip is exactly at frame X of the episode.” It’s clip/post-centric, not timeline-index-centric. That makes it great for schema inspiration and tag culture, but not a drop-in for your “sector timeline with millisecond accuracy” goal.

If you want accuracy tooling inspiration, trace.moe is closer to your precision vibe: it’s explicitly designed to return anime + episode + time for a screenshot match (with preview for verification). citeturn0search10turn0search6turn0search28

Your “B-side/comedy” point is the real value proposition

Sakuga indexing already helps people find the flashy stuff.

Your database’s killer feature is:

• mundane actions: drop bottle, trip, spit-take, shrug, glance, slow pan
• micro-gags: bonk, blink, deadpan stare, pratfall
• low-key rhythm: walking loops, conversations, awkward pauses

That’s where an AMV editor wastes hours.

So in your tag schema, reserve early “budget” for action verbs and slapstick primitives:

• bonk / hit / throw / drop / slip / stumble / spit / point / grab / dodge / flinch …because those are broadly reusable across shows.

“Third option I’m explicitly considering”

You could skip “frame-perfect everywhere” as a requirement and treat it as an optional precision layer:

• baseline: sector start/end in milliseconds (good enough)
• upgrade path: frame-accurate for sources with known FPS + verified encodes

That avoids making perfection the bottleneck while still allowing “surgical” projects later.

G: Got it. I’ll drop the cheerleading and stay technical.

I’m going to break this into three clean answers, matching what you actually asked for:

1. Name suggestions for the unit (no S-words, not cute)
2. Existing, non-proprietary paradigms for thesaurus / synonym-aware search (including porn, because yes, that’s a real reference class)
3. How those paradigms map onto your very specific constraints (human-defined meaning, AI only as a checker, nested ontology, explainable results)

No pep talk. No “this is brilliant.” Just usable material.

1) Naming the unit (no S-words, not “snippet”)

You’re right that sector is semantically too broad. You want something that implies:

• bounded in time
• extractable
• internally coherent
• not necessarily narrative
• composable / nestable

Here are candidates that have precedent without being loaded:

Neutral / technical

• interval – precise, time-bounded, boring in a good way
• window – implies a view into time; used in signal processing
• range – minimal semantics, very flexible
• slice – common in data contexts; not cute, but slightly informal
• cut – industry-native (editing), but implies intent rather than detection
• span – temporal, neutral, works with nesting
• block – bounded, chunk-like, infrastructure-ish

If I had to shortlist based on how little philosophical baggage they carry:

• interval
• span
• window

Those three survive long-term without you hating yourself.

日本語（にほんご）: 区間（くかん） = time interval / span — this maps very cleanly to what you’re doing.

2) Thesaurus & synonym paradigms that already exist (and are not a single site)

What you’re describing is not a dictionary and not free-text tagging. It’s closer to concept expansion with controlled ambiguity. There are established paradigms for this.

A) WordNet-style lexical graphs (general language)

This is the academic baseline:

• words are nodes
• relationships include synonymy, hypernymy (“is a kind of”), hyponymy, etc.
• critically: sense-separated, not just word-separated

This directly addresses your bearing example:

• bearing (posture)
• bearing (carrying)
• bearing (mechanical)

Each is a different sense node, not the same tag.

You would not use WordNet raw, but you would steal the idea:

• canonical concept IDs
• aliases point to concepts
• concepts have typed relationships

B) Faceted search (e-commerce & porn both use this)

This is where porn actually is relevant.

Porn databases solved:

• extreme synonym chaos
• overlapping fetishes
• people searching emotionally, not technically
• “I don’t know the word but I know the vibe”

Their solution was facets, not flat tags:

• action
• body part
• object
• position
• visual effect
• intensity

Search behavior:

• “jumping” boosts results tagged with jump, leap, hop
• but ranking explains why (“matched via action: leap”)

That transparency is the key insight you were circling.

C) Ontology + weighted expansion (search engines)

Modern search engines do:

• exact match
• synonym match (lower weight)
• related-concept match (even lower)
• contextual suppression (don’t expand if it makes things worse)

This is not AI guessing meaning; it’s rule-driven expansion.

3) How this fits your constraints (this is the important part)

You have several hard requirements. I’ll map directly.

Requirement: Human-defined meaning, AI only as checker

Correct instinct. The pattern here is:

• Humans create canonical concepts
• Humans define relationships
• AI is only allowed to:
  • suggest possible duplicates
  • warn about missing sibling concepts
  • flag unusual one-off structures

AI never decides meaning. It audits structure.

Requirement: Nested categories without collapsing usefulness

You already noticed the trap:
“ATTRIBUTE” as a flat type is garbage.

So instead, think axis → domain → concept, not “tag → subtag”.

Example:

• AXIS: visual
  • DOMAIN: color
    • red
  • DOMAIN: effect
    • glowing
  • DOMAIN: scale
    • large

Now:

• glowing is searchable
• color is not (unless explicitly enabled)
• red doesn’t imply “color” unless you want it to

Same for objects:

• AXIS: object
  • DOMAIN: container
    • bottle
      • glass bottle
      • plastic bottle

You’re already doing this mentally. The key is not naming everything “subcategory”, but separating why something is grouped.

Requirement: Explainable search results

This is non-negotiable for trust.

When someone searches “jumping” and gets a hit tagged “leaping”, the UI should say:

matched via action synonym: leap → jump

This is exactly how porn and e-commerce keep users from feeling gaslit.

Requirement: Hyper-precision without forcing it

Your instinct here is also right.

Design rule:

• precision is allowed, never required

So:

• every interval/span has start/end
• frame accuracy is optional metadata
• millisecond accuracy is default
• nesting handles fuzzy continuity

This avoids perfection paralysis.

Requirement: Format / version metadata (4:3 vs 16:9, etc.)

This is a separate axis, not a tag.

Think:

• source technical profile
  • aspect ratio
  • native resolution
  • frame rate
  • scan type

This never pollutes content tagging, but does affect editor decisions.

One corrective pushback (since you asked for less ass-kissing)

You are overthinking naming and under-finalizing axes.

Names can change later. Axes are structural debt.

If you lock down:

• temporal unit definition
• axis/domain/concept separation
• directed ontology rules
• explainable search expansion

Then whether you call it interval, span, or window becomes cosmetic.

Final anchor thought

You are not building “tags for anime scenes.”
You are building a controlled vocabulary for time-indexed audiovisual actions.

That’s why:

• sakuga helps conceptually but not structurally
• porn search is a valid analog
• AI must stay in the auditor role
• nesting is unavoidable

If you want, next step we can:

• lock the minimum viable axis set
• or design the search expansion scoring model
• or stress-test your bottle / weapon taxonomy for collapse points

No questions at the end.

G: You’re right on the substance: the category dimension has to be expandable, not just the keyword list. The usual “type + subtypes (2–3 deep)” design collapses under exactly the examples you gave (container→bottle→glass, object→weapon→blade→axe… plus visual→effect→glow, etc.). So the structure wants to be a graph, not a tree.

Category/keyword flexibility without a rigid depth limit

Think in three layers, each of which can grow indefinitely:

1) Concept nodes

A concept is the “thing you mean,” not the string you typed.

• CONCEPT: bottle
• CONCEPT: glass_bottle
• CONCEPT: leap (action)
• CONCEPT: jump (action)

2) Relationship edges

Everything becomes “edges,” and edges have types. Depth is irrelevant because paths can be arbitrarily long.

Useful edge types:

• IS_A: mecha IS_A robot
• PART_OF: arm PART_OF robot
• MATERIAL_OF / HAS_MATERIAL: glass_bottle HAS_MATERIAL glass
• HAS_PROPERTY: glow HAS_PROPERTY visual_effect
• ALIAS_OF (or LEXEME_MAPS_TO): “leaping” → leap

This alone solves “two layers isn’t enough,” because you’re no longer counting layers.

3) Facets as views, not hierarchy

Your “axes/domains” become query lenses over the same graph:

• facet “object”
• facet “action”
• facet “visual effect”
• facet “scale”
• facet “format/tech metadata” (separate system)

A concept can belong to multiple facets without duplicating it.

This is how you get:

• lion appears under ENTITY/creature and animal
• red appears under ATTRIBUTE/color but doesn’t force “color” as a searchable keyword unless you flip it on

Your “two linked dictionaries” idea: good, but make it explicit

What you’re describing is basically two synchronized lexicons over the same concept graph:

A) Human canon dictionary (authoritative)

• curated concept IDs
• curated relationships
• curated aliases
• stable, explainable

B) AI-assisted proposal dictionary (non-authoritative)

• proposes aliases (“jumping” ~ “leaping”)
• proposes relationship edges (“axe IS_A bladed weapon”)
• proposes duplicate detection (“glass bottle” vs “bottle (glass)”)
• proposes missing siblings (“plastic bottle” exists, maybe “glass bottle” should too)

Critical rule: the AI dictionary never changes canon; it only creates reviewable diffs.

That’s the “easy to include from day 1” point you’re making, and I agree. If you don’t build for parallel lexicons early, retrofitting it later becomes painful (every lookup path has to be rewritten).

How the two dictionaries interact during search

When a user searches jumping:

1. Canon match

• exact concepts tagged in sectors (intervals/windows/whatever you choose)

2. AI expansion match (optional toggle)

• expands to aliases and related concepts with lower score
• returns results annotated as:
  • “matched via alias: jumping → jump”
  • “matched via synonym edge: jump ~ leap”

That “why did this show up” explanation is what prevents the system from feeling arbitrary.

One naming note, since you still care about it

If you want a term that aligns with this graph model, interval remains the cleanest, because it’s purely coordinate-based and doesn’t pretend to be narrative. It also pairs naturally with nesting: “parent interval / child interval.”

日本語（にほんご）: 区間（くかん） は いちばん 近（ちか）い ことば です — “kukan” (interval/span) is the closest word.

Third option I’m explicitly considering

If “AI-assisted dictionary” feels socially radioactive, you can label it “suggested mappings” and treat it like spellcheck:

• off by default
• visible diffs
• user-controlled accept/reject
• per-user personalization later (private alias layer)

That preserves your architecture without triggering the “AI is deciding meaning” backlash.

G: You’re not contradicting yourself. You’re describing a flat lexicon of tokens plus a structured concept graph plus a simple UI-driven composition model so users don’t have to invent “bottle-as-weapon” as a separate keyword. That’s the right direction.

Term

kukan works fine as your unit name. It’s semantically tight (interval), has no English baggage, and you can define it however you want. I’ll use kukan (romanized) as requested.

日本語（にほんご）: 区間（くかん） = kukan = time interval.

1) Don’t make “bottle-as-weapon” a new keyword. Make it a pattern.

What you want is composition, not multiplication of keywords.

Model the annotation on a kukan as a set of claims that bind concepts to roles and states.

Core idea: concepts stay single; usage is expressed by role/state edges

• Concept: bottle (one canonical concept)
• Separate concept: weapon (role category / intent class)
• Separate concept: held (state)
• Separate concept: swing / strike (action)

Then a kukan can assert:

• bottle present
• bottle held_by character_X
• bottle used_as weapon
• bottle performs_action strike
• optional: bottle material glass (or “made_of glass”)

That gives you:

• “bottle sitting on table” = bottle present, maybe “contains wine”, not held
• “drinking” = bottle held + action “drink”
• “glassed over head” = bottle held + used_as weapon + action strike + target head

No AI required. Just structured assertions.

2) Keep the lexicon flat, but map words → concepts; concepts → relationships

You can still store “bottle” in a flat list for lookup, but internally it’s:

Lexeme table (flat)

• "bottle" → concept_id C_BOTTLE
• "carafe" → concept_id C_CARAFE
• "glass" → two concept_ids:
  • C_GLASS_MATERIAL
  • C_DRINKING_GLASS_OBJECT

That’s how you prevent the “glass (material) vs glass (cup)” collision: separate concept IDs, same surface word, disambiguated by facet or prompt.

3) Make the “category dimension” a graph of facets/domains, not a depth-limited tree

You were worried about unlimited layers. The fix is:

• Concepts are nodes
• “object/container/bottle/carafe” are not rigid “layers”; they’re paths via IS_A edges
• “bottle has material glass” is a different edge type (HAS_MATERIAL)

So the structure can grow arbitrarily without needing “3-layer support”.

4) Searching without hoops: default queries + optional refinement

Users won’t want to build Boolean expressions. So you give them one word, then expand.

Example: user searches “bottle”

Default returns:

• kukans with bottle present (any role/state)

UI then offers toggles (derived from common edges):

• held
• being drunk
• used as weapon
• breaks/shatters
• contains liquid
• material: glass / plastic

These toggles are just filters over the same structured claims.

This is the key to “almost right” searches:

• they type “bottle”
• then click “used as weapon”
• done

5) How to represent “held”, “weapon”, etc. cleanly

There are two sane approaches:

A) Treat them as concepts too (simplest)

• held is a concept in a “state” facet
• weapon is a concept in a “role” facet

Then each claim is an edge:

• (bottle) --HAS_STATE--> (held)
• (bottle) --USED_AS--> (weapon)

B) Treat them as typed fields (more rigid, faster validation)

• state: held | not_held | unknown
• role: weapon | container | prop | unknown

You can start with A (flexible), then later harden frequent ones into fields if performance/UX demands it.

Given your “expandable category dimension” requirement, A fits better early.

6) “Explain the term” drill-down (your carafe example)

This is a UI view over the concept graph:

• show concept: bottle
• show parents via IS_A:
  • container → object
• show siblings under container:
  • bottle, carafe, jar, flask…

So the user can climb one step and discover “carafe” even if they didn’t know the word.

That’s not AI. That’s just graph navigation.

7) What this implies for your minimum viable schema

If you only lock down a few primitives early, you can stay flexible:

• kukan: (source_id, t_start, t_end)
• concept: (concept_id, facet, canonical_label, description)
• lexeme: (string, concept_id, weight, note)
• edge: (from_concept, edge_type, to_concept)
• claim (per kukan): (kukan_id, subject_concept, predicate, object_concept_or_value, optional_actor/target)

That “claim” layer is what lets “bottle” stay single while expressing “held/drunk/weapon”.

Third option I’m explicitly considering

If you want even less structure up front, you can start with only:

• present claims
• action claims
• state claims

…and postpone materials, subtypes, etc. until you feel the pain. Because the graph model won’t break when you add them later.

That’s the whole point of doing it as claims + edges: you don’t have to pre-commit to a depth.

G: You’re zeroing in on the real constraint: co-occurrence isn’t meaning. If “bottle” and “attack” both appear in a kukan, that doesn’t mean the bottle is involved in the attack. So you need typed associations between concepts inside the kukan, not just a bag of tags.

Also: the word you wanted me to hold onto is kukon (your “composition” concept), and the time unit is kukan. I’ll use them consistently.

1) Fix the “false hit” problem with role binding, not more keywords

Your example:

• Person A drinking from a bottle
• Person B punches A with brass knuckles

A naive search: bottle AND attack returns this kukan, incorrectly.

Solution: a kukan stores events (or “actions”) where participants are explicitly bound to roles.

Minimal structure that kills the false positive

Inside a kukan, you don’t store “attack” as a free-floating tag. You store something like:

• Event E1: drink
  • agent: Person A
  • instrument: bottle
• Event E2: punch
  • agent: Person B
  • target: Person A
  • instrument: brass_knuckles

Now a search for “bottle used as weapon” becomes:

• event where instrument = bottle AND event_type in {strike, hit, attack…}

That will not match the kukan above because bottle is instrument of drink, not punch.

This is the core: kukon = composition = a set of structured events + entities + relations, not just tags.

2) Terminology upgrade: avoid anthropomorphic “held by”

You’re right to avoid “held by.” It smuggles human assumptions.

Use a neutral relation family like:

• linked_to (generic)
• carried_by
• gripped_by
• wielded_by
• controlled_by
• attached_to
• possessed_by (optional, for anime being anime)

You can keep it compact by having a single canonical predicate:

• bound_to(actor, mode) where mode ∈ {carry, grip, wield, control, attach}

But for UI sanity, discrete verbs are easier.

3) Two-phase entry workflow without redoing work

You want: rough pass first, refine later, without reattaching everything.

That argues for an “incomplete but stable” internal object model:

Phase 1: fast sketch (bag + hints)

Contributor dumps:

• bottle
• brass knuckles
• sucker punch

System creates:

• entities: bottle, brass_knuckles
• event stub: punch (unbound or partially bound)

Phase 2: refinement (bind roles)

Contributor later edits:

• punch.instrument = brass_knuckles
• drink.instrument = bottle
• bottle relation: carried_by Person A (optional if implied by drink)

Key point: events exist even when underspecified. You’re editing bindings, not rebuilding.

4) Redundancy collapse without scolding the user

You described: user might enter “bottle used as weapon” and “bottle held,” and you don’t want nagging.

Do this with soft inference + silent normalization:

• If an event has instrument = bottle and the event is in an attack class, infer bottle is wielded_by agent unless contradicted.
• If the user explicitly adds “held,” store it as confirmed, not duplicate.
• Internally, keep one canonical fact with a confidence/source flag:
  • inferred vs explicit

So UI never says “you screwed up.” It just converges.

Edge case you raised: projectile bottle (thrown).

• attack event: throw
  • instrument: bottle
  • agent: thrower
• relation: not “held” (or “gripped” only at start) So “used as weapon” does not imply “held” globally; it implies “handled_in_some_way,” which can be:
• wielded
• thrown
• dropped So infer the weakest safe relation unless specified.

5) Concept IDs: don’t bake human-readable meaning into the ID

Your instinct (“ID begins with keyword + modifiers”) helps debugging, but it’s a trap long-term because names change.

Do this instead:

• internal: C_8f3a2… (stable)
• display key: glass [material] vs glass [drinking_vessel]
• include a short human-readable slug for debugging only:
  • glass__material
  • glass__vessel

So you get uniformity when skimming, without making IDs semantic debt.

6) “Simple database” vs complexity

This is still a “simple database” in the sense that it’s just:

• tables (or documents) storing entities, events, and edges

It’s not “simple” in schema, but it’s not exotic:

• you can do it in Postgres with a handful of tables
• or as JSON documents with indexes

The interface complexity is what will dominate your life, not storage.

7) Preferred terminology vs open synonyms

You’re leaning toward a preferred anchor term. That’s correct, and there’s a strong counterargument only if you do it wrong.

Best practice

• One canonical concept
• Many aliases (synonyms, misspellings, slang)
• UI accepts any alias, stores canonical

Counterargument to canon: “language wars / regional preference.” Fix: canon is internal; UI can show user-preferred labels.

So you can have:

• canonical label (for consistency)
• display label (per user or per locale)

No need for multiple “preferred terms” fighting. The concept stays singular.

8) UI pattern that stays lightweight on old hardware

Your fear is valid: “clever” reactive UIs can become lag factories.

A low-power approach:

• one kukan per page (or simple form)
• booru-style autocomplete = server-side, debounced
• no heavy live reflow; avoid complex nested widgets that rebuild on every keystroke
• “add event” opens a plain subform or new page, not a dynamic mega-panel

The “who/what/where/how” scaffold you mentioned

That’s a good entry skeleton:

• WHO (entities/characters)
• WHAT (events/actions)
• WHERE (setting/shot context)
• HOW (relations/modifiers)

Then within WHAT, the autocomplete behaves like code completion:

• choose event verb
• fill roles (agent/target/instrument) via autocomplete

That’s your “coding environment” analogy, and it maps cleanly.

9) Names for the internal structures (so you stop forgetting)

• kukan = time interval unit
• kukon = composition model inside a kukan (entities + events + relations)
• entity = thing node (bottle, person, brass knuckles)
• event = verb node (drink, punch, throw)
• binding = role assignment (instrument=bottle)

If you only keep one new technical word in your head besides kukan/kukon, keep binding. It’s the mechanism that prevents false hits.

日本語（にほんご）: 結（むす）び つけ = binding / linking roles — this is the idea, even if you don’t use the word.

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: Understood: only “kukan.” I won’t use the other spelling again. I’ll stick to composition/compose for the internal structure.

Japanese term for “link” in this context

You want a word that covers “link/connection/attachment” without sounding like a web URL.

Two good options:

• 接続（せつぞく） = connection / linking (general, technical, neutral)
• 連結（れんけつ） = coupling / chaining / linking (good for chain-link / mechanical “linked together”)

If you want one to standardize on so you don’t equivocate with English “link,” I’d pick renketsu for “chain/attachment” semantics, and setsuzoku for broader “connected” semantics.

日本語（にほんご）: 連結（れんけつ） = chain-link / coupling / linked-together
日本語（にほんご）: 接続（せつぞく） = connection / connecting (neutral)

Composition without privileging “events”

You’re describing a structured association graph where “holding,” “standing,” “at table,” etc. are all just nodes + relations, and nothing is inherently “special.” That’s workable.

A clean way to do it (without making “events” a privileged top-level thing) is:

Everything is a node

• Ken (character node)
• bottle (object node)
• lighter (object node)
• table (object node)
• landscape (setting node)
• hold / flick / stand (action nodes, not a separate class)
• “unexpected” (modifier node)
• “attack” (concept node)

Relations are typed edges

Use a small set of typed predicates (your “renketsu/setsuzoku” layer), e.g.:

• connected( Ken , bottle , mode=grip )
• connected( Ken , table , mode=at )
• connected( bottle , landscape , mode=foreground_of )
• connected( Ken , flick , mode=performs )
• connected( flick , lighter , mode=acts_on )

Nothing here requires “event primacy.” It’s just edges.

How this prevents “Ken flicking a bottle”

Because the structure isn’t “bag of words”; it’s role-bound edges.

• “Ken flicks lighter” = (Ken) --performs--> (flick) and (flick) --acts_on--> (lighter)
• There is no (flick) --acts_on--> (bottle), so a query for that won’t match.

How searches like “Ken holding bottle” expand safely

You want “Ken holding bottle,” “Ken holding,” “Ken bottle,” etc. to converge when appropriate.

Do that by defining a small set of query rewrite rules that turn free text into graph patterns:

• “Ken holding bottle” → find a path: Ken --connected(mode∈{hold,grip,carry,wield})--> bottle
• “Ken bottle” → find any connection between Ken and bottle (weaker match)
• “holding bottle” → find any node connected-to bottle via hold/grip/carry regardless of who

This gives you ranked results without false positives:

• exact pattern match ranks highest
• weaker “any connection” matches rank lower

Redundancy minimization without making users redo work

You don’t need to eliminate redundancy; you need to collapse it internally.

If a user enters both:

• “bottle used as weapon”
• “Ken holding bottle”

You can store both as edges, but normalize to:

• one canonical connected(Ken,bottle,mode=grip) edge
• one canonical connected(bottle,weapon,mode=used_as) edge
• with provenance flags: {explicit:true} / {inferred:true}

UI stays quiet; the database stays clean.

“Internal verbs” vs “search verbs”

Your “running” example is real: “run” needs qualifiers (toward/away/chase/jog/flee).

This is best handled by treating:

• base action node: run
• relation/modifier nodes: toward(target), away_from(threat), pursuit, escape, jogging

So the user can search:

• run (broad)
• run + escape (narrow)
• run + toward(person) (role-bound) without forcing you to invent a separate privileged event system.

A practical naming tweak to reduce mental load

Use English internally for predicate names, but show Japanese label tooltips so you can talk about it without ambiguity:

• predicate family: connect_* (English)
• displayed label: “連結 / 接続” depending on the mode

That avoids your “link/link” equivocation problem in conversation and keeps code readable.

I’ll use kukan and composition going forward, and I’ll treat actions as ordinary nodes unless/until you decide a child-class (“event”) is worth adding.

G: Got it. I’ll lock the vocabulary exactly as you specified:

• kukan = time interval unit
• RENKET (singular) / RENKETS (plural) = connection/attachment edges inside a kukan
• composition = the whole internal structure (nodes + RENKETS)
  No other invented Japanese words, no alternate spellings.

RENKET(S): Japanese grounding (clean and unambiguous)

Your choice maps cleanly to 連結（れんけつ）.

• 連結 (renketsu) = coupling, chaining, linking-together of parts
• Mechanical / structural, not metaphorical
• Does not imply hierarchy or direction by default
• Works equally well for objects, actions, states, abstractions

That makes RENKET a good English-facing technical noun:

“A RENKET expresses how two nodes participate together in a kukan’s composition.”

This avoids the ambiguity of “link,” “relation,” or “association” in conversation.

New node class you identified: Situation

You’re right to call this out separately, and you’re also right not to rush to formalize it yet.

What you’re pointing at is a class of nodes that describe global or emergent context of a kukan, not reducible to a single RENKET:

Examples you gave (good ones):

• surprise
• awkward
• ridiculous
• disbelief
• lazy

These are not:

• entities (bottle, Ken)
• actions (punch, drink)
• simple properties (red, glass)

They’re situational descriptors—contextual overlays.

Key design implication (important):

A situation node RENKETS to the kukan itself, not to a specific object or action.

That avoids forcing false structure like “surprise is caused by bottle.”

So at the conceptual level:

• nodes include situation
• RENKETS can target either:
  • node ↔︎ node
  • node ↔︎ kukan

You don’t need to decide more than that yet.

Internal verbs vs search verbs (reframed cleanly)

You’re not talking about verbs in the linguistic sense.
You’re talking about objective motion/state-change descriptors versus user-intent descriptors.

A cleaner framing:

1. Compositional motion nodes (internal, objective)

These describe what changes in the frame over time, like stage directions or animation notes.

Examples:

• approach
• retreat
• turn
• raise
• lower
• collide
• separate
• accelerate
• stop

These are composition-affecting, not interpretive.

They RENKET things together without implying motive or narrative.

2. Search-intent concepts (external, interpretive)

These are what users mean when searching:

• attack
• chase
• escape
• run (as song energy)
• panic
• pursuit

Search verbs can map onto patterns of compositional motion, not single nodes.

Example:

• “run away” (search)
  ↳ maps to compositional pattern: move + away_from + threat

This preserves your rule:

• the database is dumb about meaning
• intelligence lives in how searches are expanded, not how data is stored

You’re right to park this for later; the important thing is not baking interpretation into storage.

No hierarchy, no primacy, no spine

Your instinct here is solid and worth stating plainly:

• No node is inherently central
• No RENKET implies “subject” unless explicitly typed
• Ken, bottle, lighter, situation, motion — all peers

The “central thing” exists only as a storage convenience, not a semantic one.

That’s compatible with:

• searches centered on Ken
• searches centered on bottle
• searches centered on drinking
• searches centered on “surprise”

Same data, different traversal.

Why this still fits a “simple database”

What you’ve described is still structurally simple:

• Nodes table
• RENKETS table (typed edges)
• Kukan table
• Optional: labels / aliases / search-expansion rules

The interface and query logic are where complexity lives, not the data model.

That’s the right place for it.

Final consolidation (so you can walk away and come back later)

• kukan = bounded time interval
• composition = everything inside a kukan
• nodes = entities, motions, situations, properties, abstractions
• RENKET(S) = typed connections between nodes or between node ↔︎ kukan
• no hierarchy, no special action class yet
• interpretation happens at search-time, not storage-time

This is a stable conceptual base. You’re not boxing yourself in, and you’re not prematurely solving the hard parts.

G: Got it. Lowercase, no U, and no invented variants. I’ll use renkets (singular) / renketses only if grammatically necessary, otherwise just renkets as a mass noun. No caps.

You’re also right about the internal verb / motion vocabulary: it has to be actor-agnostic, intent-free, and purely geometric/compositional. Anything that implies motive (“retreat,” “pursue,” “attack”) is already too interpretive.

What you’re actually describing is a motion primitive layer—language that describes how spatial relationships change, not why.

Internal motion primitives (objective, non-subjective)

These are the kinds of terms that survive across:

• duels
• retreats
• advances
• gags
• accidents
• crowd motion
• abstract animation

Core spatial-change primitives

• separating – distance between nodes increases
• converging – distance between nodes decreases
• crossing – paths intersect
• passing – nodes cross without stopping
• overlapping – spatial intersection persists
• aligning – orientation becomes similar
• misaligning – orientation diverges

Your duel example fits cleanly here:

• two characters converging
• passing
• then separating No “retreat,” no “attack,” no subjectivity.

Position / reference primitives

These describe relative placement without implying agency:

• approaching is borderline subjective; better:
  • distance decreasing
• offsetting – lateral displacement
• foregrounding / backgrounding
• occluding / revealing
• encircling (pure geometry, no intent)
• stacking (vertical ordering)

State-change primitives (still objective)

• appearing / disappearing
• entering frame / exiting frame
• accelerating / decelerating
• stopping / starting
• fragmenting (breaks, shatters)
• coalescing (pieces form one)

These describe what changes, not who causes it.

How this fits your model (without privileging actions)

• These primitives are just nodes.
• They participate in renkets exactly like objects, situations, or properties.
• No node is “the verb.”
• No node requires an agent.

Example (no hierarchy implied):

• Ken —renkets→ bottle
• bottle —renkets→ table
• Ken —renkets→ separating
• bottle —renkets→ foreground
• kukan —renkets→ surprise

Search-time interpretation decides whether “separating” + “Ken” + “enemy” means retreat, duel aftermath, breakup, or slapstick.

Search vs storage (the clean separation you want)

• Storage: only motion primitives like separating, crossing, fragmenting
• Search expansion: maps user words like “retreat,” “run away,” “escape” → patterns of primitives
• No primitive ever encodes motive

This keeps the database “dumb” in exactly the way you want.

Japanese grounding (for your mental map only)

日本語（にほんご）:

• 分離（ぶんり） = separation
• 接近（せっきん） = getting closer (but still a bit interpretive)
• 交差（こうさ） = crossing

You don’t need to use these, but they line up with the geometry-first framing you’re after.

Final lock-in (so you don’t have to reread this later)

• renkets = neutral connection/attachment edge
• internal motion language = geometric, intent-free primitives
• no privileged verbs, no actors required
• interpretation happens only at search time

This framing is consistent, minimal, and won’t collapse when you come back to it a year later.

G: Understood and locked in.

• renket = singular
• renkets = plural

Lowercase, no variants, no substitutions.

I’ll treat renkets strictly as neutral connection primitives, and motion primitives as geometric/state-change descriptors only—no agency, no intent, no subject weighting. I won’t drift back into subjective verbs or actor-centric language.

Nothing else to add here.