Python ontology parser rejects a reverse verbalization of a relationship

[FactEngineCommunity]

In standard Fact-Based Modelling, a relationship can be described naturally from either participant’s perspective (as below):

While the 'verbalizes' documentation is for a list, the loader for the verbalizes field can accept a list of verbalizations in only one role-order.
I.e. The reverse-fact-type-reading, "{Company} employs {Person}" is rejected, while "{Person} works for {Company}" is accepted.

version: 0.2.0.dev0
name: ReverseReading
ontology:
  - concept: Person
    type: EntityType
    relationships:
      - name: works for
        roles:
          - concept: Company
        verbalizes:
          - '{Person} works for {Company}'
          - '{Company} employs {Person}'
  - concept: Company
    type: EntityType
...

Loading this file with OssieParser().parse(path) raises:
ValueError: Role 0: 'Person:Person' does not match verbalization role 'Company:None'

The first reading loads if the second is removed. In _parse_verbalization(), each placeholder is compared with relationship.role(idx), so every verbalization must follow the declared role order. The call starts in OssieParser.parse() and passes through the spec converter.

Expected behaviour: Both readings should be accepted as verbalizations of the same relationship, with its declared roles unchanged. If fixed role order is intentional, could that restriction be documented? This was observed against Ossie checkout cc919e9.

[tripleaceme]

I'd like to work on this.

Confirmed the cause: _parse_verbalization() in converters/ontology/src/ossie_ontology/model.py checks each {Concept} token against relationship.role(idx) by position, so only readings in declared role order are accepted.

Proposed fix: match each token to a role by concept name (and role name when given) instead of by position, and reject a reading that uses the same role twice or leaves one out. For ring relationships like {Person} manages {Person}, where the concept name alone is ambiguous, the reading would need explicit role names; otherwise it falls back to positional order as today. The relationship's declared roles stay unchanged. Tests go in tests/test_verbalization_parsing.py, including the example above.

One question for maintainers before I start: RelationshipVerbalization.roles would then be in reading order, not declared order. Does anything downstream rely on those two orders being the same? If fixed order is intended, I can document the restriction instead.