oborel / obo-relations

RO is an ontology of relations for use with biological ontologies
http://oborel.github.io/
Other
92 stars 47 forks source link

Demonstrate annotating affiliation to contribution #708

Open cthoyt opened 1 year ago

cthoyt commented 1 year ago

In this PR, I demonstrate the following:

  1. Declaring an individual corresponding to my current top-level affiliation, Harvard University (https://ror.org/03vek6s52) via its Research Organization Registry (ROR) persistent identifier
  2. Add an annotation on to the Annotation Assertion that I am the dcterms:creator of RO:0018030 (chemical relationship) that says I did this under my affiliation with Harvard University. This uses the http://www.w3.org/ns/org#memberOf predicate, as suggested in https://github.com/information-artifact-ontology/ontology-metadata/issues/127#issuecomment-1498014390.

What's not in scope of this PR:

Screenshot 2023-05-15 at 17 25 41

Why

Given we have begun standardizing contributions using canonical ORCID URIs and connecting the ORCID Instance Ontology to make those annotations rich in metadata, the next step is to get more granular and include institutional affiliations as well.

In the past, some contributions have been annotated to entire organizations (e.g., GO Constortium), to meetings/workshops, etc. Working towards a well-defined model can allow more precise information that focuses on who exactly is doing the typing/editing, then still maintain the provenance on how they did it. Potentially multiple organizations can be annotated to a given dc:creator Annotation Assertion in OWL, corresponding to the affiliations of the contributor at the time of contribution, referencing the workshop/scenario in which they made the contribution, etc. One person might have made contributions over time within the context of their work in different organizations (e.g., after moving institutions), and therefore may appear with different annotations in different records.

In addition to URIs from ROR, which itself is very picky about only including top-level organizations in its controlled vocabulary, Wikidata can be used for more granluar things like specific departments, workshops, etc.

Benefits

  1. Better reporting for organizations. If you're an organization that has many different people working on many different ontologies, you might want to be able to say how many terms you created/contributed to. The solution proposed in this PR is also slightly better than the two step mapping from organization -> person -> contribution since the same person might be part of different organizations over time and making contributions in different capacities/with different affiliations.
  2. Better reporting for the community. After beginning to adopt this kind of annotation, it can be shown across the entire OBO Foundry community (and other ontologies that adopt OBO standards) what organizations are making contributions

TO DO, before merging this PR

Follow-up, after this PR

  1. Write documentation/tutorials on how to make these annotations
  2. Present this annotation concept to the greater OBO community
  3. Pull in the ROR Instance Ontology (RORIO) to auto-propogate the appropriate named individual declarations, similarly to how ORCIDIO is imported.
matentzn commented 1 year ago

As you know, I fully endorse the sentiment to document organisations. I think RORIO is the way to go, and for those orgs that don't have ROR, we provide a standard wikidata module.

Your proposal as far as I can see has one big downside which is that a lot, if not most, attribution happens on level 2 in the axiom assertions stack:

 <owl:Axiom>
        <owl:annotatedSource rdf:resource="http://purl.obolibrary.org/obo/HP_0000002"/>
        <owl:annotatedProperty rdf:resource="http://purl.obolibrary.org/obo/IAO_0000115"/>
        <owl:annotatedTarget>Deviation from the norm of height with respect to that which is expected according to age and gender norms.</owl:annotatedTarget>
        <oboInOwl:hasDbXref rdf:resource="https://orcid.org/0000-0002-0736-9199"/>
    </owl:Axiom>

Adding another axiom annotation on that level will not fly, as it involves triple nesting, for which we have zero tool support.

Perhaps this is best solved with an SOP?

cthoyt commented 1 year ago

Just to be clear, you mean that the non-protege tooling doesn't support doing things with the annotations on Annotation Assertions (which, by the screenshot, you can see at least protege itself supports), and the alternative is to just use a simple dc:contributor (or equivalent relation) in the axiom itself?

The downside to this is it would rely on assuming the connection between the contributor and the organizations, but I guess this could be acceptable in order to simplify things.

matentzn commented 1 year ago

I am not talking about annotations on annotation assertions, I am talking about axiom annotations on axiom annotations on annotation assertions (maybe this is what you mean, just to be clear). Your screen shot is only an axiom annotation on an annotation assertion. What I am talking about is having the same statement (dc:contributor X) on a synonym assertion, like:

a oio:hasExactSynonym { dc:contributor X }.

yes your downside is precisely the counterargument!

cthoyt commented 1 year ago

ohh I see. So this current example would work but the synonym wouldn't since it's one level deeper

cthoyt commented 1 year ago

In 8da4406, I demonstrate what it looks like to add this kind of axiom onto a synonym - there's no simple way to make some transitivity between Chris Mungall and LBNL in this example, unfortunately :/

(please disregard the predicate used to annotate Chris in this example - it should get updated to dcterms:contributor but that's a job for another PR)

Screenshot 2023-04-03 at 13 16 31
matentzn commented 1 year ago

Looks nice. BTW, to make this particular suggestion fly, you need to know that obo format cannot handle this very well. This is not important for RO, and @balhoff has implemented a fix in OWLAPI afaik, but just want to be complete here :)

cthoyt commented 1 year ago

I actually would rather maintain the most granular annotations. What I would suggest is:

  1. Only add contributor information for the person on synonyms (and explicitly not the affiliation-level information)
  2. Make sure that all people who are listed as a contributor on a synonym is also listed as a contributor on the term itself w/ dc:contributor
  3. Include the high-granular information on the top-level. If the same person makes multiple contributions over time with different affiliation, I dont think there's any harm in the top-level term's dc:contributor annotation assertion having the union of all of the affiliations for that person over time
matentzn commented 1 year ago

I think I totally agree with this suggestion. I want to wrote a postprocessing query for ODK that basically just turns owl axiom annotation assertion contributors in top level contributors - its super easy, and we could all agree that for most purposes and analyses, we only actually care about the top level.

cthoyt commented 1 year ago

Great, glad you agree. in 42dd4f5, I updated the synonym annotation I made in https://github.com/oborel/obo-relations/commit/8da44064378895c0e7a2ff7c868d6983ea698038 to reflect this. Now, all we need to do is decide what relationship is the best (or if we should mint one in IAO)

E.g., https://www.wikidata.org/wiki/Property:P1416 (affiliation) is a good predicate. I'm not sure how the best way to ontologize this is, though. Again as an annotation property would be best.

cthoyt commented 1 year ago

@matentzn I re-wrote the header of this PR, I hope it's not controversial anymore now that I made the scope explicitly smaller and we can consider this for merge.

github-actions[bot] commented 1 year ago

This PR has not seen any activity in 90 days and has been marked as stale. If it is no longer needed, please close the PR. Otherwise, please update the PR with a status update.

jhpoelen commented 6 months ago

@cthoyt Hi! We are reviewing this pull request in today's RO meeting. https://docs.google.com/document/d/19dhzj5QoliQZQgDJRczI878rLtexzMDo1g0K9_LRUWk/edit . Are you still interested to have your pull request reviewed? If not, please close this pull request. If so, please comment.

cthoyt commented 6 months ago

@jhpoelen Yes, I would still like this to be considered. The short version is we still would need to decide what's the right property to start adding these annotations

github-actions[bot] commented 3 months ago

This PR has not seen any activity in 90 days and has been marked as stale. If it is no longer needed, please close the PR. Otherwise, please update the PR with a status update.