-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add prefix http://purl.uniprot.org/core/ #1113
Comments
Looks like UniProt also acts as a registry definining prefixes for lots of other DBs, e.g.:
(taken from one of the RDF files in the latest release) Not sure how to best approach this @cthoyt ? I guess we should add these as alternate prefixes for all the other DBs but a full list would be helpful (@JervenBolleman?) |
Full list of databases obtained from sparql endpoint, though I am not sure exactly how these map to the URI prefixes seen above:
|
For more information about xrefs in UniProt see https://web.expasy.org/docs/userman.html#DR_line and https://ftp.uniprot.org/pub/databases/uniprot/current_release/knowledgebase/complete/docs/dbxref.txt which are the equivalent of the RDF file https://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/databases.rdf.xz One can ask for information about where these links go a sparql query at our public database endpoint PREFIX up: <http://purl.uniprot.org/core/>
SELECT
*
WHERE {
GRAPH <http://sparql.uniprot.org/database> {
?database a up:Database .
OPTIONAL {
?database up:urlTemplate ?urlTemplate .
}
OPTIONAL {
?database up:abbreviation ?abbreviation .
}
OPTIONAL {
?database rdfs:seeAlso ?furtherInformation
}
}
} However, what the RDF representation is currently not exposed. If there is a desire for this please contact uniprot via the contact form. We also do not guarantee that these links to other databases will be maintained if the xref is removed from use in UniProt. There will also be a few prefixes not in the list above, that come from the UniParc representation in RDF. |
Hello, @jamesamcl and @JervenBolleman, thanks for submitting this. The Bioregistry already integrates the UniProt registry, see here: https://bioregistry.io/metaregistry/uniprot. Among other metadata, this page links to https://bioregistry.io/api/metaregistry/uniprot/mappings.json which is the set of mappings from bioregistry prefixes to the IDs UniProt assigns to these external databases. In addition, if you go to e.g., https://bioregistry.io/registry/ensembl.fungi, you will see that UniProt is shown and linked out to in this table: Given the above, I'm trying to understand if there are specific changes / extensions we would want to make in the Bioregistry. |
Hi @bgyori, UniProt does not use DB-0148 as a "prefix" in anyway we would have used EnsemblFungi (we don't as there was an agreement in the RDF with ENSEMBL to use an rdf.ebi.ac.uk). As a general note pease do not use any single PI's as contact point for UniProt. Just use the UniProt contact form. |
I think that's just a slight terminology issue, the column in the table uses "prefix" to refer to how an external registry catalogs an identifiers resource. Some external registries use what you would actually call a prefix, others not so much, still this is just a column name. In terms of contacts, at least son far, the approach in Bioregistry advocated by @cthoyt has been to use specific people as contacts when possible. I will look into it and get back to you. |
What you can do is add one more prefix to the uniprot subconcepts. |
@JervenBolleman Apologies for tagging you directly if this was inappropriate; I was under the impression you were responsible for the RDF serialization of UniProt and our culture has generally been to involve the relevant database contacts in these discussions wherever possible (as IMO it is not particularly in the spirit of FAIR to discuss interoperability issues in a private support ticket tracker). @bgyori Thanks for the info, I didn't think to look for UniProt on the metaregistry collections. I am hoping to use BioRegistry to map IRIs to one consistent set of CURIEs, but I found that UniProt's IRI prefixes weren't included in the standard BioRegistry prefix map which is what prompted this issue. |
@jamesamcl tagging me is fine, but might lead to very slow or missed responses. To be honest I am the public face of the UniProt RDF serialization, my colleagues at SIB are the real stars on this topic, but are less keen on presenting :( The UniProt protocol is to prefer to have contacts happen in the first instance via our contact form. So someone can be assigned to help, this might be as little as please have a look at github issue X or biostars question Y. The helpdesk/contact form is staffed by multiple people. PIs and individual staff get so much mail they might respond much later, or sometimes not at all, or are just not available during certain periods. To be honest we at UniProt, think that UniProt is a team effort. Which is why for the main NAR UniProt paper we no longer put in individual authors but the consortium as an author. If you feel the need to put in names, then you should really fill in the whole list -> from https://www.uniprot.org/help/key_staff plus the PIs. |
This PR adds a URI pattern for `uniprot.core` (which already exists as a prefix in Bioregistry but so far had no URI defined). Related to #1113
Prefix
up
Name
UniProt core
Homepage
https://sparql.uniprot.org/
Source Code Repository
No response
Description
This IRI prefix
http://purl.uniprot.org/core/
is used by the UniProt RDF representation as seen on https://sparql.uniprot.org/CC @JervenBolleman
License
No response
Publications
No response
Example Local Unique Identifier
up:mnemonic
Regular Expression Pattern for Local Unique Identifier
No response
URI Format String
No response
Wikidata Property
No response
Contributor Name
no attribution required
Contributor GitHub
Contributor ORCiD
Contributor Email
No response
Contact Name
No response
Contact ORCiD
No response
Contact GitHub
No response
Contact Email
No response
Additional Comments
No response
The text was updated successfully, but these errors were encountered: