bep

Update Namespace and Identifier Handling

Abstract

The purpose of this BEP is to improve references in BEL terms (<namespace>:<name>) by adopting the OBO syntax of references (<namespace>:<identifier>!<name>).

For example, p(HGNC:MAPT), could be optionally written using the OBO syntax of p(HGNC:6893!MAPT), which includes both the identifier (6893) and the label (MAPT) of the human Tau protein.

This BEP also more specifically defines what characters are allowed in namespaces.

Preamble

BEP-Id: BEP-0008

Status: Published

Version: 1

BEL-Version: 2.0.0+

Authors: Charles Tapley Hoyt

Created-Date: 2019-07-25

Type: Standards Track

Rationale and Goals

Grounding entities referenced in BEL documents is non-trivial because it is more common to use BEL namespaces that list the labels for named entities rather than their identifiers. While this improves readability of BEL documents, it makes it difficult to ground entities because the labels change so often, and there is no standard way of maintaining these resources. The inclusion of OBO-style identifiers would allow users to write BEL documents that are both easier to validate while preserving the readability and understandability of the text. Entities referenced with OBO-style identifiers could be looked up for lexical correctness using services like Identifers.org then other (yet defined) standardized BEL resources could be used to optionally check the correctness or up-to-datedness of the label that was used. Alternatively, BEL systems could decide to completely throw away the labels specified by users and look them up themselves. This would alleviate the some of the burden posed by grounding entities and maitenance of BEL namespaces in some cases, while leaving the legacy system in place while we consider how to upgrade old documents. Tools like the Ontology Lookup Service and Glida will continue support users in finding both the identifier and name for each entity, and this will likely not increase the effort needed for curation.

Use Cases

1. Specifying an abundance, gene, RNA, miRNA, protein, or named complex:

• Old: p(HGNC:MAPT)
• New: p(HGNC:6893!MAPT)
• New (spaced): p(HGNC:6893 ! MAPT)

1. Specifying a physical location:

• Old: p(HGNC:MAPT, loc(GO:cytosol))
• New: p(HGNC:MAPT, loc(GO:GO:0060402!cytosol))
• New (spaced): p(HGNC:MAPT, loc(GO:GO:0060402 ! cytosol))

Note that GO identifiers have a redundant GO: prefix. This is okay.

1. Specifying a protein modification

• Old: p(HGNC:MAPT, pmod(GO:"protein phosphorylation"))
• New: p(HGNC:MAPT, pmod(GO:GO:0006468!"protein phosphorylation"))
• New (spaced): p(HGNC:MAPT, pmod(GO:GO:0006468 ! "protein phosphorylation"))

1. Specifying the locations of a translocation

• Old: p(FPLX:RAS, pmod(F)) directlyIncreases tloc(p(FPLX:RAS), fromLoc(MESH:"Intracellular Space"), toLoc(MESH:"Cell Membrane"))
• New: p(FPLX:RAS, pmod(F)) directlyIncreases tloc(p(FPLX:RAS), fromLoc(MESH:D042541!"Intracellular Space"), toLoc(MESH:D002462!"Cell Membrane"))
• New (spaced): p(FPLX:RAS, pmod(F)) directlyIncreases tloc(p(FPLX:RAS), fromLoc(MESH:D042541 ! "Intracellular Space"), toLoc(MESH:D002462 ! "Cell Membrane"))

There are other places where named identifiers can show up, like inside other types of modifications and inside fusion. The handling of these references would be consistent across all instances.

Discussion

• @cthoyt: I believe users should be allowed to mix and match which namespaces they want to use new/old syntax. Should we enforce that all references to the same database must use the same style?
• @cthoyt: Should the DEFINE statement at the top of the BEL document be updated to allow users to specify which type of references they want to use for each namespace?
• William: what about the redundancy of identifiers in namespaces that also have the namespace and name, such as GO (example: GO:GO:1234)? Since only the identifier will be validated, then any namespace reference with the appropriate identifier can be used for case in which the implementation would prefer to omit the prefix.

Specification

Anywhere that an identifier was possible using the <namespace>:<name> syntax, it should be possible to use the <namespace>:<identifier>!<name> syntax. Names containing characters that were neither alphanumeric nor an underscore were quoted. In general, identifiers are more well-formed and will not require the option to be quoted, while the name will still be able to be quoted. Like in OBO, there is the optional ability to leave whitespace between the <identifier> and ! as well as between the ! and <name>.

Entity IDs are composed of namespaces (prefixes), database/terminology identifiers and optional labels, e.g. <namespace>:<accession>!<label[Optional]>

• REGEX (unquoted): [\w\.\-]+:[^\s\,\)\!]+\s*!?\s*[\,\)]
• REGEX (quoted): [\w\.\-]+:".+.*?"\s*!?\s*".*?" (any double quotes in the quoted strings for the accession or label must be escaped)

Namespace specification

Namespaces may contain upper or lower case alphanumeric characters, ‘.’ periods, dash and underscores, e.g. regex: [\w\.\-]+ This is a superset of what was allowed in BEL 1-2.1 (uppercase alphanumerics only).

This has been updated to be compatible with identifiers.org (https://registry.identifiers.org/prefixregistrationrequest which has the following instruction on namespaces: Character string meant to precede the colon in resolved identifiers. No spaces or punctuation, only lowercase alphanumerical characters, underscores and dots. Example: ensembl.plant or ec-code or chebi NOTE: contrary to instruction - there are several identifiers.org prefixes using dashes)

Accession IDs

Recommended are unique identifiers from the source database/terminology service. The Accession ID must be surrounded by double-quotes if it contains spaces, a comma, an exclamation mark or a closing parenthesis, regex: [\s\,\)\!]

Optional Label

The label must be surrounded by double-quotes if it contains a comma or a closing parenthesis, regex: [\,\)]

Backwards Compatibility

The addition of this BEP does not break backwards compatibility, but it does bring up the concern that using a combination of BEL-style and OBO-style references might make handling BEL documents more tricky and less consistent.

Reference Implementation

This site is open source. Improve this page.