Entries that should probably be marked as namespaceEmbeddedInLui=False

[cthoyt]

The following entries are marked with "namespaceEmbeddedInLui": true, but I do not think they should not be. None of their sample identifiers actually contain the prefix, and the CURIE that follows https://identifiers.org/{curie} also is completely normal, following the same pattern as all of the other entries with "namespaceEmbeddedInLui": false.

Additionally, all of the provider's format strings seem to only take in the identifier (though some do seem to also contain hard-coded copies of the prefix), so is it that I am misunderstanding the usage of "namespaceEmbeddedInLui"?

This is of general importance because given a prefix/identifier pair, it is still often unclear how to construct a valid URL for identifiers.org. Typically, examples marked with "namespaceEmbeddedInLui": true come from the OBO world where the solution is to uppercase the prefix to make a valid URL for identifiers.org, but beyond this, there don't seem to be any general rules for how to handle true entries.

cc: @bgyori @dhimmel @cgreene this might be of interest to you too

prefix	pattern	sample	example url
mge	^mge:\d+$	2	https://identifiers.org/mge:2
mzspec	^mzspec:.+$	PXD002255::ES_XP_Ubi_97H_HCD_349:scan:9617:LAEIYVNSSFYK/2	https://identifiers.org/mzspec:PXD002255::ES_XP_Ubi_97H_HCD_349:scan:9617:LAEIYVNSSFYK/2
swh	^swh:[1-9]:(cnt|dir|rel|rev|snp):[0-9a-f]+(;(origin|visit|anchor|path|lines)=\S+)*$	1:rev:309cf2674ee7a0749978cf8265ab91a60aea0f7d	https://identifiers.org/swh:1:rev:309cf2674ee7a0749978cf8265ab91a60aea0f7d
did	^did:[a-z0-9]+:[A-Za-z0-9.\-:]+$	sov:WRfXPg8dantKVubE3HX8pw	https://identifiers.org/did:sov:WRfXPg8dantKVubE3HX8pw
ocid	ocid:[0-9]{12}	190000021540	https://identifiers.org/ocid:190000021540

This table was generated with the following code:

import requests
from tabulate import tabulate

#: see https://docs.identifiers.org/articles/api.html#getdataset
URL = 'https://registry.api.identifiers.org/resolutionApi/getResolverDataset'


def main():
    res = requests.get(URL).json()
    rows = []
    for entry in res['payload']['namespaces']:
        prefix = entry['prefix']
        pattern = entry['pattern']
        namespace_in_lui = entry['namespaceEmbeddedInLui']
        sample_id = entry['sampleId']
        url = f'https://identifiers.org/{prefix}:{sample_id}'
        if namespace_in_lui and pattern.lstrip('^').startswith(f'{prefix}:'):
            rows.append((prefix, pattern, sample_id, url))

    print(tabulate(rows, headers=['prefix', 'pattern', 'sample', 'example url'], tablefmt='html'))


if __name__ == '__main__':
    main()

[renatocjn]

Likely very late to answer this, but I'm answering in hope this can still helps someone.

I will start by saying that namespaceEmbeddedInLui is indeed pretty confusing, but there isn't much we can do about it. Aside from breaking several published URIs.

By default, identifiers.org URIs are created by concatenating http://identifiers.org/ + [prefix] + : + [local ID]. However, this is a problem for namespaces that use CURIES as local IDs, such as the ontology ones that you mention (go, eco, etc) because this would cause repetion in the CURIES that goes against them being used as compact identifiers. For example:

• https://identifiers.org/eco/ECO:0000006
• https://identifiers.org/go/GO:0006915

So the flag was introduced to allow the prefix to be considered part of the ID during local ID pattern validation at resolution time. But this causes the confusion since the construction of identifiers.org to be different when this flag is set to true. In this case, the URI construction is done by http://identifiers.org/ + [local ID] as the local ID already includes the prefix with a valid separator. Thus allowing:

• https://identifiers.org/ECO:0000006
• https://identifiers.org/GO:0006915

This doesn't work when other separators are used. Like some ontologies that use undescore, such as obi.

Another confusion here is that sample IDs in the registry never include the prefix. This is also confusing since when creating a sample URI using the sample ID and prefix from the registry, one should be aware of the regex pattern to match the expected case of the prefix as the registry stores all prefixes in lowercase to facilitate case insensitive resolution (both https://identifiers.org/uniprot:P0DP23 and https://identifiers.org/UNIPROT:P0DP23 work as the flag is unset).

At this point in time, there isn't much we can do about this flag as removing it or changing its behavior can cause breaking changes.

For the namespaces listed, I wasn't here when they were created, but it seems to me that the namespaceEmbeddedInLui is set on the because they require the prefix in their IDs. See their specification for more details:

• https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
• https://w3c.github.io/did/
• https://github.com/HUPO-PSI/usi/blob/master/Specification/USI_FullSpecification_1.0.0_final.pdf

---

TL;DR

The namespaceEmbeddedInLui flag is confusing. It was intended to remove redundant components in a URI. Not much we can do to make it more intuitive without breaking changes to namespaces. How to form URIs:

namespaceEmbeddedInLui == true ? 
    "http://identifiers.org/" + localID : 
    "http://identifiers.org/" + prefix + ":" localID

If this snippet doesn't work for any namespace, let us know.

The listed namespaces likely have it set because their specification requires that prefix.