Unraveling complex biology with biological knowledge graphs. Content licensed under CC BY 4.0.

Charles Tapley Hoyt

I’ve just returned from the 17

 th

Annual International Biocuration Conference at the Indian Biological Data Centre (IBDC) in Faridabad, India.

Discussions and Follow-ups from Biocuration 2024

Using Pydantic for encoding data models and FastAPI for implementing APIs on top of them has become a staple for many Python programmers.

Semantic Pydantic

I finally got back into reading! Over winter break 2022, I started the Stormlight Archive then followed up in 2023 by reading the entirety of Brandon Sanderson’s

 Cosmere

, as well as a some other fantasy, science fiction, and literary fiction. Here’s the list.

Books I Read in 2023

The Unified Medical Language System (UMLS) is a widely used biomedical and clinical vocabulary maintained by the United States National Library of Medicine. However, it is notoriously difficult to access and work with due to licensing restrictions and its complex download system. In the same vein as my previous posts about DrugBank and ChEMBL, this post describes open source software I’ve developed for downloading and working with this data.

Unlocking UMLS

Today’s short post is about three SPARQL queries I wrote to get bibliometric information about journals and publishers out of Wikidata. Each of the following queries can be readily copy-pasted into the Wikidata Query Service and run in the browser.

Querying Journals and Publishers in Wikidata

I was recently nominated for the International Society for Biocuration’s Excellence in Biocuration Early Career Award (results will be announced on June 14

 th

!). This made me curious about how to model nominations and awards on Wikidata. In this post, I’ll describe how to curate awards, nominations, recipients, and how to make SPARQL queries to get them.

Modeling and Querying Awards in Wikidata

Archival Resource Keys (ARKs) are flavor of persistent identifiers like DOIs, URNs, and Handles that have the benefit of being free, flexible with what metadata gets attached, and natively able to resolve to web pages. Name-to-Thing (N2T) implements a resolver for a variety of ARKs, so this blog post is about how that resolver can be re-implemented with the curies Python package. In a lot of ways, ARKs look and act like CURIEs.

Re-implementing the N2T ARK Resolver

I’ve been working on improving reproducibility in the field of cheminformatics for some time now. For example, I’ve written posts about making data from DrugBank and ChEMBL more actionable. Over the last year, I’ve been preparing a concept with the editors of the Journal of Cheminformatics on how to include an assessment of reproducibility to reviews of manuscripts submitted to the journal.

Reproducibility Pilot in the Journal of Cheminformatics

Several controlled vocabularies and ontologies that aren’t themselves OBO Foundry ontologies use unsanctioned OBO PURLs. This post is about how to use the Bioregistry to identify which resources are doing this and to give some insight into how we arrived in this situation. Background on the OBO Foundry   The OBO Foundry is a set of independent, interoperable biomedical ontologies that aspire to using shared development principles.

Resources masquerading as OBO Foundry ontologies

This blog is normally about

 very serious science

, but I’m taking a break from that for the evening to advertize my band’s upcoming show on April 8

 th

in the SPH Music Masters Finale (aka, the German Battle of the Bands). We need your support!

The Representatives of Monkey Jack - German Battle of the Bands Finale

The Open Researcher and Contributor Identifier (ORCID) database is an invaluable resource that supports the unambiguous identification of researchers. However, its first party data dump is too complex, verbose, and unstandardized for many use cases. This post describes open source software I wrote that automates downloading, processing, and exporting ORCID into a more usable form. I put the results on Zenodo under the CC0 license.

Easier ORCID

Biopragmatics

Using [Pydantic](https://docs.pydantic.dev) for encoding data models and
[FastAPI](https://fastapi.tiangolo.com) for implementing APIs on top of
them has become a staple for many Python programmers. When this
intersects with the semantic web, linked open data, and the natural
sciences, we are still lacking a bridge to annotate our data models and
APIs to make them more FAIR (findable, accessible, interoperable, and
reusable). In this post, we build an extension to Pydantic and FastAPI
to annotate data models' fields and API endpoints' query, path, and
other parameters using the [Bioregistry](https://bioregistry.io), a
comprehensive catalog of metadata about semantic spaces from the
semantic web and the natural sciences.

As a demonstration, we will build a data model and API that serves
information about scholars.

## First Steps with Pydantic

We'll use [Open Researcher and Contributor (ORCID)](https://orcid.org/)
identifiers as primary keys, include the researcher's name, and start
with a single cross-reference, e.g., to the author's
[DBLP](https://dblp.org/) identifier. We'll encode this data model using
[Pydantic](https://docs.pydantic.dev/latest/) in the Python programming
language as follows:

:::: {.language-python .highlighter-rouge}
::: {.highlight}
``` highlight
from pydantic import BaseModel, Field


class ScholarV1(BaseModel):
    """A model representing a researcher, who might have several IDs on different services."""

    orcid: str = Field(...)
    name: str = Field(...)
    dblp: str | None = Field(None)


print(ScholarV1.schema_json(indent=2))
```
:::
::::

JSON Schema - Version 1

\`\`\`json { \"title\": \"ScholarV1\", \"description\": \"A model
representing a researcher, who might have several IDs on different
services.\", \"type\": \"object\", \"properties\": { \"orcid\": {
\"title\": \"Orcid\", \"type\": \"string\" }, \"name\": { \"title\":
\"Name\", \"type\": \"string\" }, \"dblp\": { \"title\": \"Dblp\",
\"type\": \"string\" } }, \"required\": \[ \"orcid\", \"name\" \] }
\`\`\`

There are several places for improvement here:

1.  Correct capitalization of the titles (`ORCID`{.language-plaintext
    .highlighter-rouge} instead of `Orcid`{.language-plaintext
    .highlighter-rouge} and `DBLP`{.language-plaintext
    .highlighter-rouge} instead of `Dblp`{.language-plaintext
    .highlighter-rouge})
2.  Add useful descriptions of what each field is
3.  Have regular expression patterns to validate input
4.  Give an example

All of these are possible to annotate into Pydantic's
`Field`{.language-plaintext .highlighter-rouge} object, but it requires
lots of effort and takes lots of space. Even worse, this might have to
be partially duplicated if multiple models share the same fields. In the
example below, I annotated ORCID but will skip the others for brevity.

:::: {.language-python .highlighter-rouge}
::: {.highlight}
``` highlight
from pydantic import BaseModel, Field


class ScholarV2(BaseModel):
    """A model representing a researcher, who might have several IDs on different services."""

    orcid: str = Field(
        ...,
        title="ORCID",
        description="A stable, public identifier for a researcher from https://orcid.com",
        pattern="^\d{4}-\d{4}-\d{4}-\d{3}(\d|X)$",
        example="0000-0003-4423-4370",
    )
    name: str = Field(...)
    dblp: str | None = Field(None)


print(ScholarV2.schema_json(indent=2))
```
:::
::::

JSON Schema - Version 2

\`\`\`json { \"title\": \"ScholarV2\", \"description\": \"A model
representing a researcher, who might have several IDs on different
services.\", \"type\": \"object\", \"properties\": { \"orcid\": {
\"title\": \"ORCID\", \"description\": \"A stable, public identifier for
a researcher from https://orcid.com\", \"pattern\":
\"\^\\d{4}-\\d{4}-\\d{4}-\\d{3}(\\d\|X)\$\", \"example\":
\"0000-0003-4423-4370\", \"type\": \"string\" }, \"name\": { \"title\":
\"Name\", \"type\": \"string\" }, \"dblp\": { \"title\": \"Dblp\",
\"type\": \"string\" } }, \"required\": \[ \"orcid\", \"name\" \] }
\`\`\`

However, this was a lot of work. It would be nice if there were some
database of all the semantic spaces in the semantic web and natural
sciences that contained the name, description, regular expression
pattern, and examples. Then, we could draw from this database to
automatically populate our fields.

## Adding Some Bioregistry Magic

The good news is that such a database exists - it's called the
[Bioregistry](https://bioregistry.io). Each semantic space (e.g., ORCID,
DBLP) gets a *prefix* which is usually an acronym for the name of the
resource that serves as the primary key for the semantic space. These
prefixes are also useful in making references to entities in the
semantic space more FAIR (findable, accessible, interoperable, reusable)
using the [compact URI (CURIE)
syntax](https://cthoyt.com/2021/09/14/curies.html), though this isn't
the goal of this demo.

I've mocked some Python code that bridges Pydantic and the Bioregistry
in this repository (https://github.com/cthoyt/semantic-pydantic). I'm
calling it **Semantic Pydantic** because it lets us annotate our data
models with external metadata (and because it rhymes).

Here's the same model as before, but now using a
`SemanticField`{.language-plaintext .highlighter-rouge} that extends
Pydantic's `Field`{.language-plaintext .highlighter-rouge}. It has a
special keyword `prefix`{.language-plaintext .highlighter-rouge} that
lets you give a Bioregistry prefix, then it is smart enough to fill out
all the fields on its own. I also took the liberty of adding several
more semantic spaces that identify scholars like [Web of Science
(`wos`{.language-plaintext
.highlighter-rouge})](https://bioregistry.io/wos.researcher),
[Scopus](https://bioregistry.io/scopus), and even
[GitHub](https://bioregistry.io/github).

:::: {.language-python .highlighter-rouge}
::: {.highlight}
``` highlight
from pydantic import BaseModel, Field

from semantic_pydantic import SemanticField


class ScholarV3(BaseModel):
    """A model representing a researcher, who might have several IDs on different services."""

    orcid: str = SemanticField(..., prefix="orcid")
    name: str = Field(..., example="Charles Tapley Hoyt")

    wos: str | None = SemanticField(default=None, prefix="wos.researcher")
    dblp: str | None = SemanticField(default=None, prefix="dblp.author")
    github: str | None = SemanticField(default=None, prefix="github")
    scopus: str | None = SemanticField(default=None, prefix="scopus")
    semion: str | None = SemanticField(default=None, prefix="semion")
    publons: str | None = SemanticField(default=None, prefix="publons.researcher")
    authorea: str | None = SemanticField(default=None, prefix="authorea.author")


print(ScholarV3.schema_json(indent=2))
```
:::
::::

Finally, we can see a very detailed JSON schema, which includes
everything from before plus additional context from the Bioregistry,
including the prefix itself as well as mappings from the Bioregistry
prefix to external registries like
[BARTOC](https://bioregistry.io/metaregistry/bartoc),
[FAIRsharing](https://bioregistry.io/metaregistry/fairsharing), and
others. Together, these make the data model more FAIR and support
interoperability, since now it is possible to directly match the fields
annotated with Bioregistry prefixes in this model to fields annotated
with the same prefix in other models, even external to the project.

JSON Schema - Version 3

\`\`\`json { \"title\": \"ScholarV3\", \"description\": \"A model
representing a researcher, who might have several IDs on different
services.\", \"type\": \"object\", \"properties\": { \"orcid\": {
\"title\": \"Open Researcher and Contributor\", \"description\": \"

This field corresponds to a local unique identifier from *Open
Researcher and Contributor*.\n

#### Provenance

The semantics of this field are derived from
the\n[`orcid`](\%22https://bioregistry.io/orcid\%22) entry in\nthe
[Bioregistry](\%22https://bioregistry.io\%22): a registry of semantic
web and linked \nopen data compact URI (CURIE) prefixes and URI
prefixes.\n

#### Description of Semantic Space

ORCID (Open Researcher and Contributor ID) is an open, non-profit,
community-based effort to create and maintain a registry of unique
identifiers for individual researchers. ORCID records hold non-sensitive
information such as name, email, organization name, and research
activities.\", \"pattern\": \"\^\\d{4}-\\d{4}-\\d{4}-\\d{3}(\\d\|X)\$\",
\"example\": \"0000-0003-4423-4370\", \"json_schema_extra\": {
\"bioregistry\": { \"prefix\": \"orcid\", \"mappings\": { \"bartoc\":
\"2021\", \"biocontext\": \"ORCID\", \"biolink\": \"ORCID\",
\"fairsharing\": \"FAIRsharing.nx58jg\", \"go\": \"orcid\", \"miriam\":
\"orcid\", \"n2t\": \"orcid\", \"wikidata\": \"P496\" } } }, \"type\":
\"string\" }, \"name\": { \"title\": \"Name\", \"example\": \"Charles
Tapley Hoyt\", \"type\": \"string\" }, \... } } \`\`\` Note that the
extra semantic fields have been truncated for brevity. Each of them also
has lots of detailed information.

## Web Application

Let's take the next step to a web application using FastAPI. The goal of
this web application will be to look up the information for a scholar in
Wikidata based on their ORCID. You don't really have to understand how
the query works other than that it takes in an ORCID string and gives
back an instance of the Scholar model we've been working on above.

The app uses annotations for the query parameters, path parameters, and
other inputs to routes using extensions of Pydantic
`Fields`{.language-plaintext .highlighter-rouge}. So similar to before,
we can extend their custom fields to be semantic in **Semantic
Pydantic**.

:::: {.language-python .highlighter-rouge}
::: {.highlight}
``` highlight
from fastapi import FastAPI
from semantic_pydantic import SemanticPath

app = FastAPI(title="Semantic Pydantic Demo")
Scholar = ...  # defined before


@app.get("/api/orcid/{orcid}", response_model=Scholar)
def get_scholar_from_orcid(orcid: str = SemanticPath(prefix="orcid")):
    """Get xrefs for a researcher in Wikidata, given ORCID identifier."""
    ...  # full implementation in https://github.com/cthoyt/semantic-pydantic
    return Scholar(...)
```
:::
::::

The real power is how this translates to the API, and more importantly,
the automatically generated API documentation. First, the
`SemanticPath`{.language-plaintext .highlighter-rouge} object which we
used in place of a normal `fastapi.Path`{.language-plaintext
.highlighter-rouge} also knows it is for ORCID identifiers. Second, the
response model points to the Scholar class from before which already
knows about its semantics. Below, we see this in a screenshot of the
OpenAPI (formerly known as Swagger) user interface automatically
generated by FastAPI.

![A screenshot of the Swagger UI, enriched by the semantic annotations
described above.](/img/semantic-pydantic-api.png)

There are two big things to note here:

1.  All the detailed information about ORCID makes it into the
    parameter, also giving an example for users to get started
2.  All the detailed information from the response model (Scholar) gets
    shown as a real example.

Now, we have an API that is also annotated with detailed semantics. If
you take a look at the OpenAPI JSON file, it has similar references to
Bioregistry prefixes for the routes themselves, and directly reuses the
JSON schema for the response model.

## Next Steps

So far, this is a proof-of-concept that lives in an *ad hoc* repository.
It's not clear yet if this code is just a neat demo, whether it should
live inside the Bioregistry Python package, I haven't decided yet if
this should go inside the [Bioregistry Python
package](https://github.com/biopragmatics/bioregistry/), or if it should
be in a stand-alone package that might be extensible even further. There
are a few other things to think about in the meantime:

### Infrastructure for FAIR Models and APIs

The first version of this idea just throws the Bioregistry data into the
JSON schema. It would be interesting to develop this infrastructure
further, such as keeping a catalog of all APIs that consume or produce
data models containing semantic fields. A few places this would be
great:

1.  The [Cheminformatics
    Microservice](https://github.com/Steinbeck-Lab/cheminformatics-microservice/issues)
    contains tons of references to [InChi Keys
    (`inchikey`{.language-plaintext
    .highlighter-rouge})](https://bioregistry.io/registry/inchikey)
2.  The Bioregistry could dog-food its own API
3.  The [INDRA Discovery API](https://discovery.indra.bio/apidocs) could
    be refactored to use semantic inputs and outputs

There are also so many more examples, please let me know some services
you think would benefit in the comments on my blog post. Looking
forward, it's also a question on how to automatically discover such
semantic APIs (e.g., by cleverly searching GitHub) or if it would have
to be a manually curated catalog.

### Resolving URLs

A key feature of the Bioregistry is that it provides a way to take a
local unique identifier for an entity in a given semantic space and make
a URL that points to a web page describing the entity. For example, if
you have an ORCID identifier, you can make a URL for the ORCID page
following the format `https://orcid.org/`{.language-plaintext
.highlighter-rouge}. It would be very cool to extend Semantic Pydantic
to add some properties that auto-generate URLs, like in the following:

:::: {.language-python .highlighter-rouge}
::: {.highlight}
``` highlight
from pydantic import BaseModel, Field

from semantic_pydantic import SemanticField


class Scholar(BaseModel):
    orcid: str = SemanticField(..., prefix="orcid")
    name: str = Field(...)


charlie = Scholar(orcid="0000-0003-4423-4370", name="Charles Tapley Hoyt")
assert charlie.orcid_url == 'https://orcid.org/0000-0003-4423-4370'
```
:::
::::

### Run the Demo

The demo can be run by cloning the repository, installing its
requirements, and running the self-contained
`app.py`{.language-plaintext .highlighter-rouge}.

:::: {.language-shell .highlighter-rouge}
::: {.highlight}
``` highlight
git clone https://github.com/cthoyt/semantic-pydantic
cd semantic-pydantic
python -m pip install -r requirements.txt
python app.py
```
:::
::::

------------------------------------------------------------------------

This is my first science post of 2024! I'm very happy that the
Bioregistry is currently supported by the Chan Zuckerberg Initiative
(CZI) under award 2023-329850.


Several controlled vocabularies and ontologies that aren't themselves
[OBO Foundry](https://obofoundry.org/) ontologies use unsanctioned OBO
PURLs. This post is about how to use [the
Bioregistry](https://bioregistry.io/) to identify which resources are
doing this and to give some insight into how we arrived in this
situation.

## Background on the OBO Foundry

The [OBO Foundry](https://obofoundry.org/) is a set of independent,
interoperable biomedical ontologies that aspire to using [shared
development
principles](https://obofoundry.org/principles/fp-000-summary.html). One
such principle is to use a principled approach for creating persistent
uniform resource locators (PURLs) for local unique identifiers in each
ontology. These PURLs follow the form
`http://purl.obolibrary.org/obo/_`{.language-plaintext
.highlighter-rouge}. For example, a prefix might be
`GO`{.language-plaintext .highlighter-rouge} (for the Gene Ontology) and
local unique identifier might be `0032571`{.language-plaintext
.highlighter-rouge} (for *response to vitamin K* in GO) resulting in the
PURL <http://purl.obolibrary.org/obo/GO_0032571>.

While most semantic web resources allow the use of any IRIs
(internationalized resource identifiers), the OBO Foundry enforces that
its PURLs resolve to something useful for readers (e.g., to the
[Ontology Lookup Service](https://www.ebi.ac.uk/ols)). The resolver
behind <http://purl.obolibrary.org> is implemented and maintained in a
[GitHub repository](https://github.com/OBOFoundry/purl.obolibrary.org/)
with corresponding `.htaccess`{.language-plaintext .highlighter-rouge}
files for each OBO Foundry ontology. Correct and useful configuration
for each ontology are a requirement for acceptance to the OBO Foundry.

At the core of the OBO Foundry are several high quality, well-known,
generally useful ontologies such as the [Gene
Ontology](https://bioregistry.io/go) and the [Cell
Ontology](https://bioregistry.io/go). Inclusion in the OBO Foundry has
therefore become a *de facto* stamp of approval for ontologies that
(until now) 254 ontologies have (for better or worse) successfully
sought out.

## The Masquerade

Unfortunately, some ontologies and controlled vocabularies have adopted
OBO PURLs even though they are not OBO Foundry ontologies. This is a
problem for a few reasons:

1. The PURLs are not registered in
 <https://github.com/OBOFoundry/purl.obolibrary.org/> and therefore
 do not resolve
2. The quality of the ontology has not been vetted, meaning that
 low-quality ontologies using OBO PURLs could damage community trust
 in the OBO Foundry
3. These PURLs might conflict with other URIs prefix synonyms,
 increasing complexity for data integration
4. Most importantly: it's confusing.

One of the jobs of [the Bioregistry](https://bioregistry.io/) is to
catalog the URI format strings for identifier resources useful for the
life and natural sciences. This allows us to assess how big the problem
of non-OBO Foundry ontologies are using OBO PURLs, and why. Without
further ado, here's the list of offending resources that appear in the
Bioregistry:

| prefix | name | evidence | uri_prefix |
|-----------------------------------------------------------|-------------------------------------------------|---------------|-------------------------------------------------------------------------------------|
| [aeon](https://bioregistry.io/aeon) | Academic Event Ontology | curated | `http://purl.obolibrary.org/obo/AEON_`{.language-plaintext .highlighter-rouge} |
| [cemo](https://bioregistry.io/cemo) | COVID-19 epidemiology and monitoring ontology | extra | `http://purl.obolibrary.org/obo/cemo.owl#`{.language-plaintext .highlighter-rouge} |
| [covoc](https://bioregistry.io/covoc) | CoVoc Coronavirus Vocabulary | curated | `http://purl.obolibrary.org/obo/COVOC_`{.language-plaintext .highlighter-rouge} |
| [decipher](https://bioregistry.io/decipher) | DECIPHER CNV Syndromes | biocontext | `http://purl.obolibrary.org/obo/DECIPHER_`{.language-plaintext .highlighter-rouge} |
| [dermo](https://bioregistry.io/dermo) | Human Dermatological Disease Ontology | curated | `http://purl.obolibrary.org/obo/DERMO_`{.language-plaintext .highlighter-rouge} |
| [efo](https://bioregistry.io/efo) | Experimental Factor Ontology | biocontext | `http://purl.obolibrary.org/obo/EFO_`{.language-plaintext .highlighter-rouge} |
| [gorel](https://bioregistry.io/gorel) | GO Relations | biolink | `http://purl.obolibrary.org/obo/GOREL_`{.language-plaintext .highlighter-rouge} |
| [hpath](https://bioregistry.io/hpath) | Histopathology Ontology | curated | `http://purl.obolibrary.org/obo/MC_`{.language-plaintext .highlighter-rouge} |
| [idocovid19](https://bioregistry.io/idocovid19) | COVID-19 Infectious Disease Ontology | curated | `http://purl.obolibrary.org/obo/COVIDO_`{.language-plaintext .highlighter-rouge} |
| [lbo](https://bioregistry.io/lbo) | Livestock Breed Ontology | curated | `http://purl.obolibrary.org/obo/LBO_`{.language-plaintext .highlighter-rouge} |
| [lpt](https://bioregistry.io/lpt) | Livestock Product Trait Ontology | curated | `http://purl.obolibrary.org/obo/LPT_`{.language-plaintext .highlighter-rouge} |
| [mesh](https://bioregistry.io/mesh) | Medical Subject Headings | biocontext | `http://purl.obolibrary.org/obo/MESH_`{.language-plaintext .highlighter-rouge} |
| [msio](https://bioregistry.io/msio) | Metabolomics Standards Initiative Ontology | curated | `http://purl.obolibrary.org/obo/MSIO_`{.language-plaintext .highlighter-rouge} |
| [omia](https://bioregistry.io/omia) | Online Mendelian Inheritance in Animals | biocontext | `http://purl.obolibrary.org/obo/OMIA_`{.language-plaintext .highlighter-rouge} |
| [omim](https://bioregistry.io/omim) | Online Mendelian Inheritance in Man | biocontext | `http://purl.obolibrary.org/obo/OMIM_`{.language-plaintext .highlighter-rouge} |
| [pride](https://bioregistry.io/pride) | PRIDE Controlled Vocabulary | curated | `http://purl.obolibrary.org/obo/PRIDE_`{.language-plaintext .highlighter-rouge} |
| [reo](https://bioregistry.io/reo) | Reagent Ontology | curated | `http://purl.obolibrary.org/obo/REO_`{.language-plaintext .highlighter-rouge} |
| [roleo](https://bioregistry.io/roleo) | Role Ontology | curated | `http://purl.obolibrary.org/obo/RoleO_`{.language-plaintext .highlighter-rouge} |
| [soybase](https://bioregistry.io/soybase) | SoyBase | prefixcommons | `http://purl.obolibrary.org/obo/`{.language-plaintext .highlighter-rouge} |
| [uniprot.isoform](https://bioregistry.io/uniprot.isoform) | UniProt Isoform | extra | `http://purl.obolibrary.org/obo/UniProtKB_`{.language-plaintext .highlighter-rouge} |
| [vido](https://bioregistry.io/vido) | Virus Infectious Disease Ontology | curated | `http://purl.obolibrary.org/obo/VIDO_`{.language-plaintext .highlighter-rouge} |
| [vsmo](https://bioregistry.io/vsmo) | Ontology for vector surveillance and management | curated | `http://purl.obolibrary.org/obo/VSMO_`{.language-plaintext .highlighter-rouge} |
| [xl](https://bioregistry.io/xl) | Cross-linker reagents ontology | curated | `http://purl.obolibrary.org/obo/XL_`{.language-plaintext .highlighter-rouge} |

In the *evidence* column, there are a few possible entries:

1. **curated** - this is the URI prefix manually curated in the
 Bioregistry. This happens when the primary ontology artifact uses
 OBO PURLs.
2. **extra** - this is when there's a manually curated extra URI prefix
 in the Bioregistry (in addition to the primary one) that uses an OBO
 PURL. This usually is done to enable the Bioregistry's IRI parser to
 handle cases that appear in third-party data that incorrectly
 constructs IRIs.
3. **biocontext**, **biolink**, and **prefixcommons** - this is when
 other registries have assigned OBO PURLs as their URI expansions

It's worth noting that there are probably *lots* more resources doing
this, e.g., that are listed in
[BioPortal](https://bioportal.bioontology.org/), but have not been
included in the Bioregistry because of their lack of notability,
utility, or reuse.

Here\'s the code that generated the table (before minor modifications)

\`\`\`python import bioregistry from tabulate import tabulate
OBOLIBRARY_SUBSTRING = \"purl.obolibrary.org/obo\" rows = \[\] for
prefix, resource in bioregistry.read_registry().items(): if
resource.get_obofoundry_prefix() or prefix == \"obo\": continue name =
resource.get_name() contact = resource.get_contact() l =
f\"\[{prefix}\](https://bioregistry.io/{prefix})\" if
resource.uri_format and OBOLIBRARY_SUBSTRING in resource.uri_format:
rows.append((l, name, \"curated\", \"\", resource.uri_format)) continue
elif (uri_format := resource.get_uri_format()) and OBOLIBRARY_SUBSTRING
in uri_format: rows.append((l, name, \"default\", \"\", uri_format))
continue for metaprefix in resource.get_mappings(): uri_format =
(getattr(resource, metaprefix, None) or {}).get(\"uri_format\") if
uri_format and OBOLIBRARY_SUBSTRING in uri_format: rows.append((l, name,
\"mapped\", metaprefix, uri_format)) for p in
resource.get_extra_providers(): if OBOLIBRARY_SUBSTRING in p.uri_format:
rows.append((l, name, \"extra\", p.code, p.uri_format))
print(tabulate(rows, headers=\[\"prefix\", \"name\", \"type\", \"code\",
\"uri_format\"\], tablefmt=\"github\")) \`\`\`

## Rationalizations

Based on the table above, there are several situations in which an OBO
PURL appears:

1. Ontologies that are curated in the OBO flat file format then
 converted to the OWL format using
 [ROBOT](https://robot.obolibrary.org/) are automatically given OBO
 PURLs. For example, this occurs for the Livestock Breeding Ontology.
2. Similarly, ontologies that are uploaded to BioPortal likely undergo
 a similar procedure that results in BioPortal PURLs that themselves
 include OBO PURLs. For example, this occurs for FamPlex and the
 Vital Sign Ontology.
3. Ontologies are/were intended to be submitted to the OBO Foundry. For
 example, this includes:
 - The Academic Event Ontology (AEON) is still a work in progress and
 will be submitted to the OBO Foundry
 - The Reagent Ontology (REO) was abandoned and never submitted to
 the OBO Foundry
4. Ontologies that closely used by the OBO Foundry ecosystem, and are
 somtimes mistaken for being in it (e.g., EFO)
5. Not all ontologies, controlled vocabularies, or other semantic
 spaces have associated PURLs. Several registries (e.g., Prefix
 Commons, BioContext, BioLink Model) have "made up" OBO PURLs for
 non-OBO Foundry resources because of their use case-specific
 preferences.
6. In the case of XL, I think that this was an OBO Foundry ontology at
 some point but got renamed. It's very difficult to understand the
 history of the [HUPO Proteomics Standards
 Initiative](http://www.psidev.info/groups/controlled-vocabularies)
 from the outside
7. Some of these examples that appear with evidence "extra" are there
 because third-party resources incorrectly reference entities using
 unsanctioned OBO PURLs
8. In the case of CEMO, it appears the URI prefix is an artifact of
 incorrect configuration curation tooling (likely Protege).

It's hard to know for sure for the situation that lead to the
developers/maintainers of primary resources using unsanctioned OBO PURLs
or the developers/maintainers of third party resources using
unsanctioned OBO PURLs. Regardless, it's still valuable for the
community to know about these problems and potentially use comprehensive
resources like the Bioregistry as a guide towards improving
interoperability and interpretability.