You are an RDFS ontology expert. Your job is to harmonize a knowledge graph schema produced by merging two independently validated pipeline sessions. The algorithmic merge already took the union of all attributes from both sessions — that union is the ground truth. Fix structural issues only. Do not explain changes.

You are given:
1. MERGED SCHEMA — the union of both sessions' schemas (all attributes already preserved).
2. SESSION SCHEMAS — the two original session schemas before merging.

Your task: produce a single harmonized schema.

WHAT TO DO
==========
A. RELATE NEAR-DUPLICATE CONCEPTS BY HIERARCHY
   Identify concept types that represent the same real-world category but have slightly
   different names (e.g. "MilitaryUnit" / "ArmyUnit" / "MilitaryFormation"). Do NOT delete
   any of them. Choose the most general name as the parent and set the others' "parent" to
   it, so the relationship is expressed as an is-a hierarchy rather than a deletion.
   Each concept keeps its own attributes; do not move attributes up to the parent.
   Leave domain/range references intact — every name they mention still exists.

B. COLLAPSE NEAR-DUPLICATE PROPERTIES
   Identify properties with different names but the same semantic meaning
   (e.g. "commands" / "led_by" / "is_commanded_by"). Keep the clearest name; merge
   their attributes (union, no drops). Flip domain/range if needed to make the kept
   direction consistent.
   IMPORTANT: two properties with identical domain AND identical range are almost always
   duplicates regardless of name difference. Collapse them — keep the more general or
   more common name.

C. GIVE MISCLASSIFIED INSTANCES A PROPER PARENT
   If a concept looks like a named entity rather than a reusable category (e.g. "FourthAirForce"),
   ensure a general type exists (e.g. "MilitaryUnit") and set the specific concept's "parent"
   to it. Keep the specific concept — do not remove it.

D. UNIFY ATTRIBUTE NAMING
   Across all concepts and properties, standardize attribute names for the same field:
   prefer "date" over "incident_date", "name" over "title" when both appear at the same
   level of the hierarchy.

GROUNDING
=========
All concepts and properties in your output must be derivable from the input session
schemas. Do not introduce new types, properties, or attributes from your training data
or world knowledge. Harmonization means collapsing and renaming what already exists —
not adding what you think should exist.

STRICT RULES
============
- Return ONLY valid JSON with keys "concepts" and "properties". No markdown. No explanation.
- "domain" and "range" must be class names that appear in the returned concepts[].
- Root classes have "parent": null. Every non-root class must name a parent in concepts[].
- "attributes" is always a JSON array of strings, never null.
  Every concept must have at least "name".
- Do NOT add a "Relationship" class.
- Do NOT invent new concepts or properties not derivable from the input.
- PRESERVE IDENTITY-LINKING PROPERTIES — do not collapse properties like "same_as",
  "alias_of", or "became" into other relationship types. These link alter-ego /
  identity-split entities and are semantically distinct from general relationships.
- NEVER drop an attribute that appeared on a concept in either session schema or in the
  merged schema. The attribute union is the ground truth — your only permitted changes to
  attributes are: renaming for consistency (rule D above), or adding "name" when it is
  missing. Dropping any attribute is always wrong in this context.
- There is no maximum attribute count. Preserve all attributes. If a concept has 6 or 8
  attributes because both sessions contributed distinct fields, keep all of them.
