search

OBOFoundry / OBOFoundry.github.io

Metadata and website for the Open Bio Ontologies Foundry Ontology Registry
http://obofoundry.org
Other
164 stars 201 forks source link

Annotate ontologies with responsible organization(s) #1720

Open cthoyt opened 2 years ago

cthoyt commented 2 years ago

In addition to having a single point of contact for each ontology as prescribed by FP-11 (Locus of Authority), it would be useful to annotate the primary organization(s) responsible for each ontology using either a Research Organization Registry (ROR) identifier or Wikidata identifier.

Benefits:

  1. It's often difficult to figure out what group(s) is/are responsible for an ontology, even given the name, email, and potentially GitHub handle of the contact person.
  2. Group ontologies maintained by the same groups, even if the contact is different is not currently possible, but would be directly enabled by using ROR/Wikidata identifiers. For example, the Rat Strain Ontology is one of several maintained by the RGD group at Medical College of Wisconsin (https://ror.org/00qqv6244) but having different responsible people.
  3. Allow summarization and reporting of OBO Foundry efforts based on geography/localization

How could this be accomplished?

bpeters42 commented 2 years ago

I am not so sure we want to enhance the link between ontologies and a specific group. In my personal experience, ontologies developed by one group (often for a specific associated database/project) are the ones least likely to be interoperate with the broader community. As these ontologies have as their main use-case to serve their own project, and they often have their database data model tightly integrated with their ontologies, they are understandably reluctant to change things in order to be more compatible with other ontologies. The success of GO comes from it integrating across different model organism databases.

I am completely okay with the technical solution presented here, and I am also okay with implementing it as described. But I would want to make sure that this doesn't 'reward' the single group ontologies, and makes ontologies that are driven by multi-organization collaborations look bad. Minimally, this clearly must be an optional annotation.

On Mon, Jan 3, 2022 at 10:53 AM Charles Tapley Hoyt < @.***> wrote:

In addition to having a single point of contact for each ontology as prescribed by FP-11 (Locus of Authority) https://obofoundry.org/principles/fp-011-locus-of-authority.html, it would be useful to annotate the primary organization(s) responsible for each ontology using either a Research Organization Registry (ROR) identifier https://ror.org/ or Wikidata identifier https://www.wikidata.org.

Benefits:

  1. It's often difficult to figure out what group is responsible for an ontology, even given the name, email, and potentially GitHub handle of the contact person.
  2. Group ontologies maintained by the same groups, even if the contact is different is not currently possible, but would be directly enabled by using ROR/Wikidata identifiers. For example, the Rat Strain Ontology https://obofoundry.org/ontology/rs.html is one of several maintained by the RGD group at Medical College of Wisconsin ( https://ror.org/00qqv6244) but having different responsible people.
  3. Allow summarization and reporting of OBO Foundry efforts based on geography/localization

How could this be accomplished?

  • If ORCiD identifiers are incorporated as proposed in #1719 https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1719, then ROR's for organizations could be looked up from that service
  • Again, manual curation would probably be necessary, but between email and GitHub handles, it might be easier to ask people for this information in bulk

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1720, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2IQFKESBBU6SBTCTWETUUHWDRANCNFSM5LFZLKHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Bjoern Peters Professor La Jolla Institute for Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

cmungall commented 2 years ago

Single or multi valued?

How do we represent more nuanced relationships, eg supported by

Should we be moving towards a role oriented data model like CREDIT where each agent is annotated with role, temporal period etc?

On Mon, Jan 3, 2022, 10:53 AM Charles Tapley Hoyt @.***> wrote:

In addition to having a single point of contact for each ontology as prescribed by FP-11 (Locus of Authority) https://obofoundry.org/principles/fp-011-locus-of-authority.html, it would be useful to annotate the primary organization(s) responsible for each ontology using either a Research Organization Registry (ROR) identifier https://ror.org/ or Wikidata identifier https://www.wikidata.org.

Benefits:

  1. It's often difficult to figure out what group is responsible for an ontology, even given the name, email, and potentially GitHub handle of the contact person.
  2. Group ontologies maintained by the same groups, even if the contact is different is not currently possible, but would be directly enabled by using ROR/Wikidata identifiers. For example, the Rat Strain Ontology https://obofoundry.org/ontology/rs.html is one of several maintained by the RGD group at Medical College of Wisconsin ( https://ror.org/00qqv6244) but having different responsible people.
  3. Allow summarization and reporting of OBO Foundry efforts based on geography/localization

How could this be accomplished?

  • If ORCiD identifiers are incorporated as proposed in #1719 https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1719, then ROR's for organizations could be looked up from that service
  • Again, manual curation would probably be necessary, but between email and GitHub handles, it might be easier to ask people for this information in bulk

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOM2SOVVBD5UGB4R45DUUHWDLANCNFSM5LFZLKHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

jonquet commented 2 years ago

In MOD 1.4 we have suggested : dct:publisher and dct:rightsHolder One can also use foaf:fundedBy and omv:endorsedBy And of course mod:ontologyInUse which was mentioned in another tracker to report the use of an ontology by a project.

Those are the properties "sugegsted" by MOD1.4 ... see the relations (for each property in mod-v1.4_profile.rdfs) to maybe find other possible metadata standard property to use.

MOD1.4 (https://github.com/sifrproject/MOD-Ontology) is currently being updated to MOD2 that will be compliant with DCAT2. Done with FAIRsFAIR.

matentzn commented 2 years ago

As I mention in #1719 it would probably be a good idea if we first formulated the scope of the metadata collected by OBO and its purpose. I am however decidedly against documenting attribution in OBO Foundry metadata - that should be done in the ontology metadata by the ontology producers. But afaik, I don't see you (@cthoyt) suggesting that.

1) Re geo-location analysis.. I tried such a thing once (https://rpubs.com/matentzn/ro2018), but its really hard to get a complete picture due to the shifting employments, many different groups involved etc. I am not against this, but would worry about marginal gain.

It's often difficult to figure out what group(s) is/are responsible for an ontology

Yeah I do agree with that.. Could this be solved by simply adding an "affiliation" field to the primary contact? Curating all organisations responsible in creation of an ontology is really expensive (in retrospect and moving forward). Some ontologies like Uberon or OBI have dozens of "responsible" orgs.. But getting one may be feasible, as long as it is clear this is not for attribution, just contact.

I love your suggestion of automatically retrieving current affiliations from Wikidata. I am sure these will be often out of date, but it is exactly this kind of stuff this will encourage curation moving forward.. Even if it is probably doomed to be incomplete, it will still be useful and a good step towards better open data. Who would be responsible for the curation of the ORCID-ROR links?

cthoyt commented 2 years ago

Thanks everyone for the feedback so far. There's definitely a fine line in between what information should be curated in the ontologies themselves and what information should be centralized in the OBO Foundry. Ideally, we could programatically pull data in from ontologies (similarly to the OBO Dashboard) in a continuous integration environment to supplement what's available through manual curation. However, I think we're all aware that the tooling is very hard to work with and the quality of the metadata in the ontologies that's managed by the authors themselves is not always actionable (and every time we start talking about metadata, the discussion becomes totally meta). I think #1719 will be a much easier sell, and perhaps we can start there to demonstrate what might be possible here before making any decisions

wrt ORCID-ROR links, this is mostly up to people to curate their own ORCID identifiers (except for the fact that ORCID links to Wikidata which also links to RORs). Being a community of curators, I would hope people see the value in keeping their own profiles up-to-date 🙃

cmungall commented 2 years ago

Ideally, we could programatically pull data in from ontologies (similarly to the OBO Dashboard) in a continuous integration environment to supplement what's available through manual curation

That was the idea with:

https://github.com/OBOFoundry/OBOFoundry.github.io/blob/b2dbb692c98aba6e56551a11071fe28fbb758a27/util/processor.py#L197-L223

this is old code though and may be faster to rewrite than fix