Add WisdomAI domain converter (both directions)

[mwu-wisdom]

Supersedes #192, which was closed during the repository migration (the old repo is now apache/ossie-temp, and its head points at a stale mirror branch). This is the same converter rebased onto the current main, with two adaptations to changes that landed since:

• BigQuery connections now map to the new BIGQUERY dialect (with backtick identifier quoting) instead of falling back to ANSI_SQL with a warning.
• The converter pyproject.toml follows the repo's UV conventions (dependency-groups, tool.uv.sources for the in-repo apache-ossie).

What

Adds converters/wisdom, a bidirectional converter between WisdomAI domain exports (format 1.0, the JSON produced by wisdom's exportDomain API and consumed by importDomain) and Ossie semantic model YAML. It follows the layout and conventions of the dbt converter (apache-ossie dependency, ConverterResult/ConverterIssue loss reporting, argparse CLI). Also registers WISDOM as a well-known custom-extension vendor in the spec documents and OSIVendor enum.

ossie-wisdom wisdom-to-osi -i domain-export.json -o semantic_model.yaml
ossie-wisdom osi-to-wisdom -i semantic_model.yaml -o domain-export.json

Import mapping (wisdom → Ossie)

Ossie	Wisdom
semantic_model[].name / description	domain ref.name / description
ai_context (model level)	domainSystemInstructions + domain knowledge contents as a bulleted list
datasets[]	tables (location.database.schema.dbTable → source; primaryKey.columns or isPrimaryKey flags → primary_key)
datasets[].fields[]	columns (bare, dialect-quoted names) and formulas (verbatim expressions); displayName → label; DATE/DATETIME/TIMESTAMP → dimension.is_time
relationships[]	relationship graph edges — cardinality folded into edge direction (from = many side); compound AND-joins flattened to composite key arrays; OR/non-equi joins dropped with a warning
metrics[]	per-table measures hoisted to the model level, cross-table name collisions resolved by table-name prefixing

Expressions are emitted verbatim under the Ossie dialect mapped from the table's connection (snowflake → SNOWFLAKE, databricks → DATABRICKS, bigquery → BIGQUERY); other dialects fall back to ANSI_SQL verbatim with an UNSUPPORTED_DIALECT warning.

Export mapping (Ossie → wisdom)

The exact inverse, so round-trips are stable in both directions:

• Model ai_context splits back into domainSystemInstructions (leading text) + one knowledge item per - bullet.
• A field whose expression is just its own (possibly quoted) name becomes a column; anything else becomes a formula. dimension.is_time maps to a TIMESTAMP data type (wisdom re-derives exact types from the warehouse).
• Relationships become MANY_TO_ONE edges; the ai_context notes written by the import direction restore ONE_TO_ONE/MANY_TO_MANY, and composite keys become compound AND join conditions.
• Metrics attach to the table their expression references (fallback to the first dataset with a warning).
• IDs are derived deterministically from element names so re-runs are reproducible; connections are per-dialect placeholders expected to be remapped at import.
• Not representable in wisdom — dropped with warnings: semantic models beyond the first, unique_keys, custom_extensions, and ai_context on fields/metrics (plus synonyms/examples anywhere).

Testing

• 27 tests against a synthetic fixture covering all four cardinalities, compound AND-join flattening, OR-join dropping, dialect fallback, hidden columns, stale measures, duplicate fields, metric name collisions, full round-trip equality (OSI → wisdom → OSI yields an identical OSIDocument), and determinism of the emitted export.
• Verified end-to-end against two real wisdom domain exports (Snowflake and BigQuery connections): both outputs pass validation/validate.py fully (schema, uniqueness, reference integrity, sqlglot SQL parsing), and OSI → wisdom → OSI round-trips are byte-identical YAML for both.

🤖 Generated with Claude Code

[jbonofre]

The dict is manually kept in sync with ConverterIssueType. Any new type added to the enum without a corresponding entry will crash the CLI at runtime with a KeyError.

I suggest to use .get() with a fallback:

reason = _ISSUE_REASON.get(issue.issue_type, issue.issue_type.value)

[mwu-wisdom]

Good catch — fixed in 63f125b using .get() with the enum value as the fallback reason, so a missing entry degrades to a terse-but-correct warning instead of a KeyError.

[jbonofre]

On FIPS-compliant systems, MD5 raises ValueError by default. Since this is for ID generation (not security), adding usedForSecurity=False makes the intent clear and avoids the crash:

Suggested change

	return f"{prefix}_{hashlib.md5(value.encode('utf-8')).hexdigest()}"
	return f"{prefix}_{hashlib.md5(value.encode('utf-8'), usedForSecurity=False).hexdigest()}"

[mwu-wisdom]

Agreed and fixed in 63f125b. One note: the Python keyword is lowercase usedforsecurity (the camelCase usedForSecurity from the suggestion raises TypeError), so I applied it with the correct spelling plus a comment explaining it's for FIPS-enabled builds.