documentation: xrefs for defs

[nicolevasilevsky]

Need documentation about how to write and reference definitions. I drafted some text below

Text definitions should follow the recommendations outlined here:

All text definitions in Uberon should have a database_cross_reference (dbxref). They dbxref could be a PubMed ID, a DOI to a book, a Wikipedia link or an ORCID for the person who requested and/or added the term. Examples of the preferred formats are listed below:

• PMID:154915
• https://doi.org/10.1016/B978-0-12-409503-8.00002-0
• ISBN:978-1-62808-994-3
• http://en.wikipedia.org/wiki/B-1_cell
• http://orcid.org/0000-0001-5208-3432

[nicolevasilevsky]

From @dosumis on Slack:

I think this needs better standardisation. It seems we're gradually normalizing using full URLs in dbxrefs. I understand why given how broken our curie system is, but I'd rather fix that as moving to URLs makes it hard to use IDs to build out linked data. One obvious example is DOIs. You can use a doi to pull Biblio data from multiple sources (e.g. EuroPMC). That's harder if some are provided as URLs. Orcids are another good example.

Re fixing curies: Standard for Curies always used to be go xrefs yaml file. This is still used as a reference by OLS. Can we make a plan to move this out from under GO? Can we use it in our toolchains (e.g. with ODK) for dbxref checking or would some other format or a better structured YAML file be needed? Could we have a standard system allowing individual repos to choose which dbxrefs they allow and import doc from the YAML?

Might need a meeting to discuss.

[meghalithic]

What about full MLA citations?

[nicolevasilevsky]

I'm not sure that I've ever seen a full MLA citation referenced in an ontology, I think the preference would be to use the DOI or PMID, if applicable.

[dosumis]

IDs are always preferable as they can be used in API calls. It should be possible for downstream applications to reconstruct or retrieve MLA citations from the results of API calls. I think NCBI allows this directly.

We don't do a good enough job of pointing users to the options for this though. Might be worth adding some docs (although risk they'll go out of date)

[github-actions[bot]]

This issue has not seen any activity in the past 6 months; it will be closed automatically in one year from now if no action is taken.

[paolaroncaglia]

@nicolevasilevsky and @dosumis tagging you as you've contributed to this ticket. Can this be closed - has the documentation been updated already - or are there action items left? Commenting to prevent closure in the latter case. Thanks.

[nicolevasilevsky]

I don't think this is done, I think the documentation still needs to be updated.

[github-actions[bot]]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

[anitacaron]

@bvarner-ebi, could you write some documentation here, please? 😄

[ghost]

@anitacaron, can Uberon adapt the same standards as CL (https://github.com/obophenotype/cell-ontology/pull/2058) ?

[matentzn]

As a general guideline all ontologies supported by the tech team should adapt mostly the same standards