Should we use a ontology-level metadata tag to indicate 'ontology domain'?

[nataled]

(Issue offshoot from #965)

Foundry ontologies are grouped into categories such as agriculture, health, upper, etc (see the Ontology Domains dropdown on the main Foundry page). Currently the assigned category is presented in an ontology's YAML file. The question at hand is whether or not this information should be captured within the ontology itself using a to-be-determined metadata tag. We already have a controlled vocabulary; perhaps these could be added to OMO as instances.

Side note 1: there does not seem to be a suitable tag in OMO at the moment; the closest is http://purl.org/dc/elements/1.1/subject but that seems like it pertains to something more specific than the general categories we're interested in.

Side note 2: We already have a controlled vocabulary; perhaps these could be added to OMO as instances IF we decide that we want to use the new tag.

[matentzn]

I personally think (but not too strongly), that it's best to led OBO do the sorting into domain parts and stick with the OBO yaml approach. I now hesitate to add additional metadata fields; even optional ones, just to keep things simple. But I am also fine with supporting the suggestion of adding it.

[nataled]

@matentzn I presume you mean you'd rather that our group decide which domain fits best, as opposed to the submitter? As a long-time database curator, I too (mildly) lean toward this.

[hoganwr]

Interesting discussion. First, as I understand it, this issue is driven by the idea (dare I say, philosophy?) that we should include the ontology's metadata in the ontology itself as well as in the OBO yaml. Or to the extent possible, or that makes sense. So yes, that does given the ontology developer control over the metadata that goes in the ontology, where the OFOC (or other OBO entity) controls much metadata in the yaml, including the "domain". One thought is we could require and enforce via Dashboard check that the domain in the ontology must match what is in the yaml. Or just not put it in the ontology itself. I do not feel strongly that we need to stuff all ontology metadata into the ontology itself.

…

On Wed, Oct 15, 2025 at 8:21 AM Darren A. Natale ***@***.***> wrote: *nataled* left a comment (OBOFoundry/OBOFoundry.github.io#2779) <#2779 (comment)> @matentzn <https://github.com/matentzn> I presume you mean you'd rather that our group decide which domain fits best, as opposed to the submitter? As a long-time database curator, I too (mildly) lean toward this. — Reply to this email directly, view it on GitHub <#2779 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJR55QLBL73YTHPU5XC6FT3XZC6PAVCNFSM6AAAAACJIFOBNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMBWGQZDIOBTGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[matentzn]

Agree with all what @hoganwr said.

As an aside: In 2022 I implemented a weird idea that allows people to simply import OBO registry metadata into their ontologies: information-artifact-ontology/ontology-metadata#106

No one was ever truly interested - this would make sure that OBO metadata is always up to date with what people add into their ontologies as well, and lets OBO Foundry metadata YAML be the source of truth for everything. Maybe we can revisit that.

[hoganwr]

Love it!

…

On Mon, Oct 20, 2025 at 5:53 AM Nico Matentzoglu ***@***.***> wrote: *matentzn* left a comment (OBOFoundry/OBOFoundry.github.io#2779) <#2779 (comment)> Agree with all what @hoganwr <https://github.com/hoganwr> said. As an aside: In 2022 I implemented a weird idea that allows people to simply import OBO registry metadata into their ontologies: information-artifact-ontology/ontology-metadata#106 <information-artifact-ontology/ontology-metadata#106> No one was ever truly interested - this would make sure that OBO metadata is always up to date with what people add into their ontologies as well, and lets OBO Foundry metadata YAML be the source of truth for everything. Maybe we can revisit that. — Reply to this email directly, view it on GitHub <#2779 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJR55SYRGRT6M6YCPHGPNL3YS5JJAVCNFSM6AAAAACJIFOBNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRRGU3TANRSGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>