[DISCUSS] Ontology: Naming of custom_properties in the ontology spec (PR #146)

[Jochen Christ via dev <de...@ossie.apache.org>]

Hi all,

PR https://github.com/apache/ossie/pull/146 adds a flexible object to the ontology spec for metadata that the spec does not model.

The main use case is importing from other formats without losing information, for example OWL/RDF (rdfs:label, owl:equivalentClass, vs:term_status) or SAP CSN annotations, so that a round-trip stays lossless. It is available on the ontology root, concepts, relationships, and roles. Keys are free-form, values can be any JSON, and the spec does not interpret them.

Example from the PR:

  ontology:
    - concept: Person
      type: EntityType
      description: A person.
      iri: foaf:Person
      custom_properties:
        rdfs:label: Person
        owl:equivalentClass: http://schema.org/Person
        vs:term_status: stable

Before we merge, I'd like to settle the name of the field.

The core spec already has custom_extensions, a list of {vendor_name, data} entries where data is a string. The new field is a structured map instead, because OWL/RDF is not a single vendor, and JSON inside a string is hard to read, edit, and validate. With custom_extensions and custom_properties side by side, users may confuse the two: the names are close, but the shapes differ.

Candidates:

1. custom_properties (current name in the PR)
   Descriptive, but close to custom_extensions with a different shape.

2. annotations
   Familiar term for tool-specific metadata (e.g. Kubernetes annotations) and clearly distinct from custom_extensions. In OWL, annotation properties have a specific meaning, and the field may also carry axioms such as owl:equivalentClass.

Which candidate would you prefer?

A related question: should the core spec follow? I'm happy to open a follow-up PR that introduces the same structured field in the core spec and deprecates custom_extensions, so that we have one extension mechanism across the spec.


Thanks,
Jochen