Updated schema to include top-level 'prefixes' property and 'Ontology Component.uri' property

[scotthenninger]

Motivation

The Ossie Ontology Specification currently treats each model as a self-contained, stand-alone entity. Because all concept names are local to a model, there is no way to establish relationships or correspondences between models. This proposal adds an optional mechanism for assigning globally unique identifiers to concepts by adopting the Uniform Resource Identifier (URI) convention from the XML/RDF ecosystem.

To keep URIs concise and readable, this proposal also adopts the RDF/XML notion of namespace prefixes, allowing URIs to be written as compact QNames - e.g., foaf:Agent representing the URI [http://xmlns.com/foaf/0.1/Agent](http://xmlns.com/foaf/0.1/Agent).

Both additions are optional: models that do not need cross-model identity are unaffected and remain valid.

Proposed Changes

This involves two changes to the current Ossie ontology Specification:

1. At the ontology level, create a prefixes property.
   Defines a mapping from a prefix to the namespace URI it abbreviates, enabling QName expansion throughout the model.
   Example: foaf: http://xmlns.com/foaf/0.1/

2. At the Concept level, create a uri property.
   Assigns a global identifier to a concept (OntologyComponent), expressed either as a full URI or as a QName resolved against the declared prefixes.
   Examples: uri: foaf:Agent, uri: http://xmlns.com/foaf/0.1/Agent

Here's an example using the proposed changes:

name: OrganizationOntology
ontology:
- prefixes:
   foaf: http://xmlns.com/foaf/0.1/
- concept: Agent
   type: EntityType
   description: "A generic agent (person, organization, etc.)"
   uri: foaf:Agent
   relationships:
    - name: AgentHasHomepage
      description: "Associates an Agent with its home page"
      multiplicity: OneToOne
      roles:
         - concept: AgentHomepage
      verbalizes: [ "'{Agent} has {AgentHomepage}' ]

- concept: AgentHomepage
   type: ValueType
   description: "The home page of the agent"
   uri: http://xmlns.com/foaf/0.1/homepage

Schema impact

Both properties are optional, so existing valid models remain valid (backward compatible). The changes affect two objects:

[jochenchrist]

I like the prefixes / namespaces on ontology level. This clearly helps for mapping RDF/OWL.
uri for a non HTTP string feels a bit off.

What about a more generic id property?

name: OrganizationOntology
ontology:
- prefixes:
   foaf: http://xmlns.com/foaf/0.1/
- concept: Agent
   id: foaf:Agent
   type: EntityType
   description: "A generic agent (person, organization, etc.)"
   relationships:
    - name: AgentHasHomepage
      description: "Associates an Agent with its home page"
      multiplicity: OneToOne
      roles:
         - concept: AgentHomepage
      verbalizes: [ "Agent has a home page" ]

- concept: AgentHomepage
   id: http://xmlns.com/foaf/0.1/homepage
   type: ValueType
   description: "The home page of the agent"

[jochenchrist]

I think we should also add the uri / iri / id to relationships.

[scotthenninger]

I added URI to Relationships.

To be clear foaf:Agent or any QName is a URI, not a string. That's what the prefix does, turn it into a fully qualified URI.

I think we're specifically looking for a URI here, which leads to a globally unique identifier, and not an informal identifier, so I think uri is what we're looking for, not the more general id, which could be interpreted as being any string, which wouldn't address the desire to have an interconnected graph of models.

[FactEngineCommunity]

Just be careful with the 'verbalizes' field.

This is incorrect: "verbalizes: [ "Agent has a home page" ]"

For your example, we should have:

    verbalizes: ['{Agent} has {AgentHomepage}']

i.e. the "verbalizes" field is not freeform, or notes. It specifies object types separated by predicates.
In your example it specifies the triple:

Element	RolePlayed	Value/Expression
Subject	EntityType	Agent
Predicate	Predicate	has
Object	ValueType	AgentHomepage

NB verbalizes is not only for Binary Fact Types/Triples, to my understanding, but in this case it is a binary relationship.

====
NB See the flights.yaml example for samples of the verbalizes field.

===
On the core issue for this PR I support the notion given that it forms a core part of the spec (i.e. Is a documented part of the spec and not some undocumented freeform-text optional).
I support the notion of adding uri / iri / id to relationships.

[scotthenninger]

Thanks I updated the verbalizes field in my example.

[jochenchrist]

I added URI to Relationships.

To be clear foaf:Agent or any QName is a URI, not a string. That's what the prefix does, turn it into a fully qualified URI.

I think we're specifically looking for a URI here, which leads to a globally unique identifier, and not an informal identifier, so I think uri is what we're looking for, not the more general id, which could be interpreted as being any string, which wouldn't address the desire to have an interconnected graph of models.

qname would also be an option then.

Edited: qname is too specific.

I think uri / iri is fine. I have a light preference towards iri (https://www.rfc-editor.org/info/rfc3987/).

[kurtStirewalt]

@scotthenninger, I have a question that sems from the motivation for the PR. You write:

The Ossie Ontology Specification currently treats each model as a self-contained, stand-alone entity. Because all concept names are local to a model, there is no way to establish relationships or correspondences between models.

It makes sense for an Ossie model to declare relationships that refer to constructs from another Ossie model if:

1. Ossie ontologies themselves have a global identifier, and
2. Ossie models that depend on one another declare only ontologies (no BI semantic models and no ontology mappings)

(1) is easy by adding a prefix for the ontology itself. Regarding (2), I'm wondering if we get into trouble if one Ossie model with an ontology mapping depends on another that also has an ontology mapping? Wouldn't we have some obligation to make sure the BI semantic models and the ontology mappings are consistent with one another? Or would you propose to outlaw this case -- meaning that if an Ossie model with an ontology contains a BI semantic-model and an ontology mapping that it could not be referenced using another Ossie model?

I think uri / iri is fine. I have a light preference towards iri

I also have a light preference for iri.