Feedback requested: codes versus mnemonics to identify databases
M. Scott Marshall
new federated PURL software with an eye toward initial deployment, one
issue is still hasn't been settled: how to include the database source
in the identifier.
Mnemonics example:
http://sharedname.org/ncbi_gene/85365
Numerical code example
http://sharedname.org/1294/85365
Where 1294 is the code for ncbi gene.
Of course, numerical codes aren't the only way to go (as Mark Musen
pointed out): you could also use alphanumerics that would give the URI
a slightly different flavor and possibly make them slightly easier to
parse by eye (random hand-generated example):
Alphanumeric code example:
http://sharedname.org/A23/85365
Jonathan Rees wrote:
> The only risk of mnemonics then is rebranding, as happened with this particular idspace. > Had we set up the idspace when it was still called 'locuslink', we would (by our
> persistence policy) still be using URIs that say 'locuslink' or 'll' even now when the
> database calls itself 'gene'.
Applying the scenario that Jonathan describes to the same ncbi gene
results in the following:
Obsoleted mnemonic example:
http://sharedname.org/locuslink/85365
It is easy to anticipate that the initial community preference will be
for the mnemonics. It's just easier (when the mnemonics are still
meaningful..). However, I think that people could get over the lesser
appeal of codes if they understood that the purpose is to prevent
potential situations in which obsolete 'name sugar' occupies the
middle of URI's that have been designed in every other way to be
'brand neutral'. If you care about such things as knowing the codes by
sight, you get to know the numbers by using them anyway, just as with
the genes. Otherwise, the seemingly inevitable 'semantic noise'
resulting from locuslink-like identifiers will distract people.
We would like to hear back from you. Are there any other factors to
consider? Feedback please.
Cheers,
Scott