search

identifiers-org / registry

Identifiers.org Registry
Apache License 2.0
2 stars 2 forks source link

de-double MGI IDs #8

Closed cmungall closed 2 months ago

cmungall commented 6 years ago

identifiers.org MGI URLs have :s in them, which means the URI is encoded as

http://identifiers.org/mgi/MGI%3A5624838

which is not optimal

The whole MGI:MGI thing was a mistake inherited from GO a while ago, over the definition of identifier (local vs prefixes).

Can we have the URI prefix for MGI be http://identifiers.org/mgi/? So URLs would be of the form http://identifiers.org/mgi/5624838

jmcmurry commented 6 years ago

Hi Chris, this is already addressed in the new patterns they support. If you have a context map with MGI mapping to http://identifiers.org/MGI: it works fine.

cmungall commented 6 years ago

OK, so this is a bit confusing

both

  1. http://identifiers.org/MGI:80863
  2. http://identifiers.org/mgi/MGI:80863

are supported (is the plan to make the first canonical and deprecate the second?)

1 is preferable as it doesn't double up, but it still includes the ':' in the URI, which is problematic due to the need to escape

On 18 May 2018, at 18:54, Julie McMurry wrote:

Hi Chris, this is already addressed in the new patterns they support. If you have a context map with MGI mapping to http://identifiers.org/MGI: it works fine.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/identifiers-org/registry/issues/8#issuecomment-390370203

jmcmurry commented 6 years ago

In what context must you escape them? All modern browsers support the ':' natively now.

jmcmurry commented 6 years ago

Re: deprecation, there are already URIs in the wild various places; I don't think they plan to (or should) stop resolving them. My understanding is that in time they do plan to update the documentation to the new patterns. Agreed it is confusing mid-stride.

sarala commented 6 years ago

Hi Chris and Julie,

Yes, we are actively promoting (1) prefix:identifier compact identifier form. However, we will continue to support (2) for now.

cmungall commented 6 years ago

I'm not really concerned with browser behavior. If identifiers.org URLs are to be used as identifying URIs within a semantic web stack there's a complex set of specifications, to be waded through.

I haven't looked at these for a while, but colons have always been problematic.

For example, if we start at the CURIE spec https://www.w3.org/TR/curie/ 

curie       :=   [ [ prefix ] ':' ] reference
prefix      :=   NCName
reference   :=   irelative-ref (as defined in IRI)

irelative-ref is defined here:

https://www.ietf.org/rfc/rfc3987.txt

which eventually bottoms out here:

isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims
                        / "@" )
                  ; non-zero-length segment without any colon ":"

":"s used to be very problematic with a lot of toolchains, but it seems now that the specs may not be always adhered to and many stacks will do the 'intended' thing...

...but why risk it? What is the reason for MGI being any different than others?

sarala commented 6 years ago

Hi Chris,

At the moment MGI is considered as being part of the identifier which results in:

  1. http://identifiers.org/MGI:80863
  2. http://identifiers.org/mgi/MGI:80863

Technically, it is much simpler to do

  1. http://identifiers.org/MGI:80863
  2. http://identifiers.org/mgi/80863 (currently not supported) However, it is still not clear to me whether the data provider would approve this.
jmcmurry commented 6 years ago

When last they were asked about this MGI was not ok with http://identifiers.org/mgi/80863. Things may have changed, just thought I'd convey what I know to date.

sarala commented 6 years ago

Thanks Julie. I'm not sure how to address these differences in approaches between data providers and tool builders.

jmcmurry commented 6 years ago

IMHO, I think you're doing all you can.