• Ferret out any cross-registrations that may not be an exact match on prefix, but on other fields.
  • Assess the text-edit distance or other easy to do similarity match across all of the title fields.
  • Based on the above, for each prefix in the list, provide two pieces of data: 1) score indicating how likely the prefix in one row is to be related to a prefix in another row. (eg. corresponding to the same dataset, or to portions of that dataset). (eg. KEGG-disease, vs KEGG-protein). 2) what that corresponding prefix is to investigate
  • Re-arrange the list so that the related ones are clustered together for easier curation (?)

First front end concept is in https://docs.google.com/drawings/d/1O-9VUcUExZBgGf5d-jAVlV0AsaMQdjK6ovooAVONh2k/edit. After evaluating desired functions, consider additional options as appropriate.

Eg. with [example-id] as is done in GO, or # as done elsewhere.
Unfortunately, we can not just always append the id to the end as sometimes more needs to be appended after that (eg. .html etc)

[ ] Wireframe
[ ] Get feedback from repositories

HGNC is an example collection with four co-occuring identifier complexities:

1. Ambiguity about what $id even is.

The identifiers.org record above captures the fact that HGNC records exist in 3rd party databases but identifiers.org doesn't have a strong concept of a prefix; consequently it isn't possible to get to both "physical locations" of the entity using a single (equivalent) $id. In one case $id is prefixed, and in the other, it is not. HGNC, mercifully, honors both forms. However:

1. Other data providers may not be as forgiving as HGNC is
2. More often than not variation in the local ID pattern is precisely what the data provider is relying on in order to redirect to their right type-specific path.

A stronger notion of prefix is the simplest thing that would help data integrators collapse the following as equivalent http identifiers since 2674 is the invariant part of the ID.

Given the identifiers.org data model, there is no way to determine whether http://identifiers.org/hgnc/hgnc:2674 points to the same entity as http://identifiers.org/hgnc/2674. This is why I favor developing a bare-curie based resolver like http://n2t.net/hgnc:2674--or if identifiers.org is interested in doing so--http://identifiers.org/hgnc:2674

This would allow us to determine that all of these are talking about the same entity:

Authoritative sources:

• http://www.genenames.org/cgi-bin/gene_symbol_report?hgnc_id=hgnc:$localid
• http://www.genenames.org/cgi-bin/gene_symbol_report?hgnc_id=$localid

Identifier resolvers:

• http://identifiers.org/hgnc/$localid
• http://identifiers.org/hgnc/hgnc:$localid
• http://identifiers.org/hgnc/HGNC:$localid
• http://n2t.net/HGNC:$localid

Third party content providers

• http://hgnc.bio2rdf.org/describe/?url=http://bio2rdf.org/hgnc:$localid
• https://monarchinitiative.org/resolve/HGNC:$localid

2. Multiple entity types (Genes and Gene families)

3. Multiple identifier types (alphanumeric symbol and numeric ID)

4. Type-specific URL patterns combined with lack of deterministic typing in local ID

Consequently you have to know what you're looking at before you can know where to resolve it. Note lack of deterministic typing in localID is not a problem unless you need type-specific URLs the way HGNC does.

Sorry to bug you @KrisGray, you're listed on the HGNC github; could you comment as to whether there's a single URL that can be used across types of IDs in HGNC? (family, symbol, numeric ID) so that we can address at least number 4 on the list?

cc: @timclark, @jkunze

In order to allow us to collapse entries that are based on out-of-date info

http://www.essepuntato.it/lode/http://purl.org/spar/datacite

Review user scenarios at https://docs.google.com/document/d/1DxU2IN56fUoASxaiEOsn2NDtjRGWw5rK_BxRAKcyvwU/edit, evaluate for applicability to current hackathon. Consider how to address in UI (#9).

https://docs.google.com/spreadsheets/d/1cDGJcRteb9F5-jbw7Q7np0kk4hfWhdBHNYRIg3LXDrs/edit#gid=0