Bidirectional OO-LD <-> k-type converter

[SimonStier]

Convert between OO-LD schemas and k-type specifications.

A k-type is the template defining structure, semantics and relations of Knowledge Items (k-items). The specs live in https://github.com/semantic-dataspace/knowledge-types as self-contained YAML, and are referenced from https://github.com/semantic-dataspace/semantic-schemas via x-ktype.

cc @yoavnash @Kirankumaraswamy @durmaz07

Mapping

k-type spec to OO-LD schema:

• ontology_classes[].iri to the semantic type, i.e. the @context type entry and the type const
• custom_properties.sections[].inputs[] to schema properties; relation_mapping.iri and relation_mapping.type (data_property or object_property) to the @context term definition
• widget to the corresponding UI annotation
• id, version and $id to $id and the OO-LD version keywords
• kv_properties to free-form key-value handling, where semantic mapping is enabled
• synonyms and tags to the matching OO-LD annotation keywords, where they exist

Open questions

• The k-type notation is a separate format with its own format_version, its own UI model (sections / inputs / widget) and relation_mapping in place of a JSON-LD @context. Which parts should round-trip and which are DSMS-specific and out of scope?
• Convergence is still being negotiated in x-kitem vs OO-LD x-oold-range keyword semantic-dataspace/semantic-schemas#4 (x-kitem vs OO-LD x-oold-range). If that lands, a k-type reference could resolve to a schema and part of this converter becomes unnecessary. Worth settling the direction before implementing
• x-ktype currently names opaque k-type IDs rather than resolvable schemas, so the converter needs a resolution strategy against the knowledge-types registry
• Which direction is authoritative, and whether a full round trip is a goal at all