The concern is that the variability of the way to describe URLs is too large (http, https etc). @cmungall believes we should prefer a clear prefix based scheme for source type, rather than URLs. I can see the appeal to that, but I am a bit on the fence here - sometimes it seems just easier to identify a resource by its resource URL.

@cmungall main concern is, that if you merge mapping sets, you may not be able to accurately group on subject and object source due to the above risk of variance. For example, you may refer to SNOMED as a source like this: https://www.snomed.org/, or this http://www.snomed.org/ or this https://www.snomed.org (don't get hung up on the fact that some ontologies have PURLs, many dont).

Request for comment:

• Option 1: use Prefixes rather than URLs to denote sources. Example: object_source: UBERON. The context will provide an entry for UBERON to ensure its unambiguously clear what that refers to, i.e. http://purl.obolibrary.org/obo/uberon.owl. Note versions etc have nothing to do with anything here: they are captured by a different field.
• Option 2: Use URLs, preferring PURLs to denote sources (current solution): object_source: http://purl.obolibrary.org/obo/uberon.owl.

I don't mind Option 1 personally, but I would like some clarity on how UBERON is linked to http://purl.obolibrary.org/obo/uberon.owl. Just answering with "bioregistry" is not sufficient - I would insist on this information being encoded somewhere in the metadata, for example the prefix map.