Ontology nodes in PropertyValueList or NumericalProperty/StringProperty

[stevevanhooser]

Hi @lzehl et al -

We'd like to represent name / value pairs where the name is rooted in an ontology instead of just a free-text / uncontrolled name.

As an example, suppose, for a visual stimulus, we wanted to store that the stimulus properties were

[Table format: Ontology, local name, value, units]

[email protected] tFrequency 1.0 Hz
[email protected] sFrequency 1.0 cycles/degree_visual_angle

This would allow many parameters to be rooted in ontologies.

In a meeting this morning, we supposed it could be implemented in openMINDS if NumericalProperty and StringProperty each had an ontologyIdentifier field.

Best
Steve

[apdavison]

This sounds like a good idea to me.

[UlrikeS91]

I also like the idea.

We have used two properties previously that relate to ontologies - ontologyIdentifier and preferredOntologyIdentifier. The latter is used for controlledTerms, while the first one is used on other (complex) schemas which can have an ontology ID assigned (e.g., brain atlas versions or strains).
I don't think either would be suitable for the property schemas since the ontology ID would only relate to the name and not the value of the schema.

I see 2 options that could solve this.

Option 1

Add a new property where users can add the corresponding ontology terms. The category keyword includes all schemas from the controlledTerms model (i.e., all terminologies and the TermSuggestion schema). It gives users the option to choose a suitable term from the exiting terminologies or suggest a new one (with optional fields to e.g., define the term and state the ontology ID). Property name and instructions should be discussed. This is just to present the idea.

{
  "_type": "https://openminds.ebrains.eu/core/StringProperty",
  "required": [
    "name",
    "value"
  ],
  "properties": {
    "name": {
      "type": "string",
      "_instruction": "Enter a descriptive name for this property."
    },
    "relatedOntologyTerm": {
      "type": "array",      
      "minItems": 1, 
      "uniqueItems": true,
      "_instruction": "Add all ontology terms that best correspond to the name of this property either by adding controlled terms or by suggesting new terms.",
      "_linkedCategories": [
        "keyword"
      ]
    },
    "value": {
      "type": "string",
      "_instruction": "Enter the text value that is described by this string property."
    }
  }
}

Option 2

Instead of allowing free-text for the name, we could restrict the options to the category keyword (i.e., choosing from existing terminology or suggesting a new one). This would create the explicit relation between ontology ID and the name of the property which is only implicit in option 1 (via the instructions for relatedOntologyTerm).

{
  "_type": "https://openminds.ebrains.eu/core/StringProperty",
  "required": [
    "name",
    "value"
  ],
  "properties": {
    "name": {
      "_instruction": "Add the name of this property either by adding the corresponding controlled term or by suggesting a new term.",
      "_linkedCategories": [
        "keyword"
      ]     
    },
    "value": {
      "type": "string",
      "_instruction": "Enter the text value that is described by this string property."
    }
  }
}

@openMetadataInitiative/openminds-admins & @openMetadataInitiative/openminds-developers What do you think?

[stevevanhooser]

From the perspective of a project that is trying to adopt as much of openMINDS as we can but that is not completely compatible yet, I think both of these options work easily.

It's my impression that keywords are flat objects that don't have potential links back onto the rest of the openMINDS schema in a complicated way. If that's true, then both options are easy. If keywords could have fields that depend on the whole hierarchy, then I might prefer option 1 because it is a flat object with no links.

Best
Steve

[UlrikeS91]

It's my impression that keywords are flat objects that don't have potential links back onto the rest of the openMINDS schema in a complicated way. If that's true, then both options are easy. If keywords could have fields that depend on the whole hierarchy, then I might prefer option 1 because it is a flat object with no links.

Yes, they are flat objects. You can look at the documentation for the controlledTerms schemas for the full list of properties. They either allow free text fields or IRIs to external resources (e.g., ontology ID) but they do not have further links to any other schemas within openMINDS. The TermSuggestion schema has one further link but only to give users the chance to state which existing terminology a new term belongs to (addExistingTerminology linking to controlledTerms/Terminology).

Let's see what the others think (especially @lzehl), and then I can make the changes to the schemas.

[apdavison]

I don't think Option 2 works, it takes away too much flexibility/adds too much overhead. For many use cases I don't think it will make sense to use a controlled term as the key.

Option 1 is quite nice, but the property should probably be something like "controlledVocabularyTerm" rather than "relatedOntologyTerm", if its value is anything in the "keyword" category.

There's also Option 0, which is essentially Steve's suggestion, and which I prefer:

{
  "_type": "https://openminds.ebrains.eu/core/StringProperty",
  "required": [
    "name",
    "value"
  ],
  "properties": {
    "name": {
      "type": "string",
      "_instruction": "Enter a descriptive name for this property."
    },
    "ontologyIdentifier": {
      "type": "string",
      "_formats": [
        "iri"
      ],
      "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property name."
    },
    "value": {
      "type": "string",
      "_instruction": "Enter the text value that is described by this string property."
    }
  }
}

If we want an ontology term for the value, then we should add a new schema alongside StringProperty and NumericalProperty, called something like OntologyProperty or ControlledTermProperty.

[lzehl]

Dear all, sorry for being quite so far. I agree with @apdavison that option 2 is not flexible enough to follow the logic we had that StringProperty and NumericalProperty are fully user defined (without any instance request necessary).

One could imagine the full flexibility in the following options:
Option 3:

{
  "_type": "https://openminds.ebrains.eu/core/StringProperty",
  "required": [
    "name",
    "value"
  ],
  "properties": {
    "name": {
      "type": "string",
      "_instruction": "Enter a descriptive name for this property."
    },
    "nameOntologyIdentifier": {
      "type": "string",
      "_formats": [
        "iri"
      ],
      "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property name."
    },
    "value": {
      "type": "string",
      "_instruction": "Enter the text value that is described by this string property."
    },
    "valueOntologyIdentifier": {
      "type": "string",
      "_formats": [
        "iri"
      ],
      "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property value."
    },
  }
}

Which then also applies to NumericalProperty:

{
  "_type": "https://openminds.ebrains.eu/core/NumericalProperty",
  "required": [
    "name",
    "value"
  ],
  "properties": {
    "name": {
      "type": "string",
      "_instruction": "Enter a descriptive name for this numerical property."
    },
    "nameOntologyIdentifier": {
      "type": "string",
      "_formats": [
        "iri"
      ],
      "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property name."
    },
    "value": {
      "type": "array",
      "minItems": 1,
      "_instruction": "Enter all quantitative values that are described by this numerical property.",
      "_embeddedTypes": [
        "https://openminds.ebrains.eu/core/QuantitativeValue",
        "https://openminds.ebrains.eu/core/QuantitativeValueRange"
      ]
    }
  }
}

@stevevanhooser generally this is a very good suggestion. We just need to decide on how we integrate it 😄

[stevevanhooser]

Works for me. NDI Cloud might insist on ontology terms but we can apply that beyond what is strictly required for a valid openMinds document. Thanks!via mobileOn Oct 21, 2024, at 11:37 AM, Lyuba Zehl ***@***.***> wrote: Dear all, sorry for being quite so far. I agree with @apdavison [github.com] that option 2 is not flexible enough to follow the logic we had that StringProperty and NumericalProperty are fully user defined. One could imagine the full flexibility in the following options: Option 3: { "_type": "https://openminds.ebrains.eu/core/StringProperty [openminds.ebrains.eu]", "required": [ "name", "value" ], "properties": { "name": { "type": "string", "_instruction": "Enter a descriptive name for this property." }, "nameOntologyIdentifier": { "type": "string", "_formats": [ "iri" ], "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property name." }, "value": { "type": "string", "_instruction": "Enter the text value that is described by this string property." }, "valueOntologyIdentifier": { "type": "string", "_formats": [ "iri" ], "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property value." }, } } Which then also applies to NumericalProperty: { "_type": "https://openminds.ebrains.eu/core/NumericalProperty [openminds.ebrains.eu]", "required": [ "name", "value" ], "properties": { "name": { "type": "string", "_instruction": "Enter a descriptive name for this numerical property." }, "nameOntologyIdentifier": { "type": "string", "_formats": [ "iri" ], "_instruction": "Enter the internationalized resource identifier (IRI) pointing to an ontological term for the property name." }, "value": { "type": "array", "minItems": 1, "_instruction": "Enter all quantitative values that are described by this numerical property.", "_embeddedTypes": [ "https://openminds.ebrains.eu/core/QuantitativeValue [openminds.ebrains.eu]", "https://openminds.ebrains.eu/core/QuantitativeValueRange [openminds.ebrains.eu]" ] } } } @stevevanhooser [github.com] generally this is a very good suggestion. We just need to decide on how we integrate it 😄 —Reply to this email directly, view it on GitHub [github.com], or unsubscribe [github.com].You are receiving this because you were mentioned.Message ID: ***@***.***>

[lzehl]

@apdavison @UlrikeS91 we need to pick this discussion up again. we lost a bit track of it.