"One should also point out to the authorities
maintaining these IDs that
they should spend some effort on producing a workable
solution for this. It
seems they should be the first to provide a resolver service (or maybe it
would be an "ID search engine" if it is so complicated).
With the qualifiers in place, Wikidata can also be used to achieve this, of
course, but it seems we are just manually reverse engineering something
that should be done at the site of whoever is controlling the ID
Well said, Markus. A most hearty agreement here on my side and one
colleagues and I have been trying to raise awareness of for a long time now
). One of the challenges is that databases are
already being asked to do more with less. They can see the utility of such
a service to others, but when I've asked DBs before (not naming names),
traction has been limp (I've yet to ask Chembl). Sometimes it works out
though. For instance, KEGG used to have 12 different type-specific URLs,
Thankfully, they've collapsed those to a single URL pattern.
The databases that find it the toughest are not those who simply don't
embed typing, but rather those that don't embed typing AND ALSO have local
identifiers that would otherwise collide. For instance, a prominent bio
database is in this boat (not naming names) and would like to make things
better but it is hard and messy due to the collisions.
FYI 345 of the 560+ records in the identifiers.org
corpus are type-specific
at the level of identifiers.org's namespace; these roll up to ~300
The question though is what WikiData is trying to accomplish. Say you
encounter the chembl ID CHEMBL308052
<http://linkedchemistry.info/chembl/chemblid/CHEMBL308052> do you need to
retrieve the type of the entity for reasons other than determining what URL
How are you representing entity labels / IDs to users?