Global identifiers for HED terms

[VisLab]

There has been some movement to submit HED and the HED score library in particular to INCF for consideration as a standard.

One of the requirements from INCF is that global identifiers be used. For many of the existing standards INCF standards, the IDs are at a high level -- e.g. at the dataset level or the software package level.

HED by its nature is more fine-grained. However, I think it makes sense to have IDs at the term level for HED and I would like to begin discussion about what those IDS should be.

Since terms must be unique within a schema, this simplifies things. Here are some possibilities:

HED:sensory-event HEDv8.1.0:sensory-event

and for libraries:

HEDSCORE:Intermittent-photic-stimulation HEDSCOREv0.1.0:Intermittent-photic-stimulation

I prefer not to have the version number. We are committed to not remove terms once they are in, but to use a deprecated attribute if we don't want people to use them. Terms can be moved within the schema however and attributes modified.

Only HED schema and HED library schema that are in the official repositories as released versions would be considered to have an official global ID.

Comments? @smakeig @dungscout96 @sappelhoff @arnodelorme @dorahermes @tpatpa @happy5214 @IanCa @monique2208

[tpatpa]

@VisLab, where can I read more about global identifiers? I want to learn more about existing IDs and requirements/rules for defining an ID. Also, will the global identifiers be used as prefixes when annotating?

[VisLab]

The INCF criteria can be found at https://incf.org/incf-standards-review-criteria-v20.

The main item of concern is FAIR#1. This would not affect tagging or analysis at all.

The main concern is having a standardized/persistent way of identifying terms in the schema.

One way is to assign ID numbers to each term in the underlying schema. These ID numbers could then be used as keys in underlying databases. However, upon thinking about it, that seems to be unnecessary and more trouble than it is worth, since HED 3G forces the terms themselves to be unique and persistent within the schema.

We just need to agree that we will deprecate terms rather than remove them from future schema. (We allow terms to be moved within the schema without triggering a major version release.)

[sappelhoff]

However, upon thinking about it, that seems to be unnecessary and more trouble than it is worth, since HED 3G forces the terms themselves to be unique and persistent within the schema.

indeed -- in 3G each term is an ID. I think deprecation rather than removing is a good idea. In many software packages however, deprecation might mean that in a future version of the software, previously deprecated items are no longer accessible at all. How would that be for HED?

Is the registration specifically for HED 3G, or HED in general? What happens with the INCF registration if HED 4G is released (if ever)?

[VisLab]

Deprecation: I think we need to leave the terms in the schema so they will be persistent.

The HED Working Group has talked some about a kind of migration policy as people come up with better ways of expressing concepts. Ideally, there would be a tool that could be run to replace deprecated terms with the new terms. Initially, we had such a tool for the transition from HED-2G to HED-3G, but once HED-3G become so different in philosophy, we decided it was easier just to re-tag directly.

HED3G versus HED4G: I hate to think of it. I don't know.

[VisLab]

The HED namespace and global IDS will be introduced in HED schema version 8.3.0 and specified in PR #576.

[VisLab]

HED 8.3.0 will have hedId's --- the mechanisms and the embedding into a HED ontology are discussed in the new HED specification chapter on HED ontologies.