PIDs for NeXus terminology

[hgoerzig]

Many funders at least in Europe are asking to make research data Findable, Accessible, Interoperable and Reusable (FAIR) [1]. During the last years it has been become consensus in the research data management community like the RDA and the EOSC contributing institutions (FAIRsFAIR) that persistent identifiers (PIDs) are a central element for making data FAIR. PIDs should uniquely identify objects but also link related items together. PIDs used to identity many research related items like datasets, persons, and publications. But PIDS are also created for instruments, software and vocabulary. The latter one might be esp. interesting for the NeXus vocabulary. 
An example for creating PIDs for vcabulary can be found in the IUPAC golden book. They are registering their vocabulary as DOIs:
https://doi.org/10.1351/goldbook.S05848 would resolve to http://goldbook.iupac.org/terms/view/S05848 .
By using PIDs like DOIs for a vocabulary two things are getting possible:

1. the term used can be related in a machine readable way to other items and
2. the DOI is persistent, in case IUPAC decides to change URI to the term, they only have to change the path in the registration of the DOI.
   This combination allows it use the vocabulary e.g. in ontologies, but also permits the use of PIDs in data catalogues as well as in combination with e.g. ontologies create mappings.

Some more example what could be done below. But now suggestions of how to proceed for implementing Pis for the NeXus terminology:

1. the fields and groups or where necessary are getting a new attribute in the nxdl files e.g. in https://github.com/nexusformat/definitions/blob/master/base_classes/NXmonochromator.nxdl.xml
2. this will be transformed in an anchor in the resp. html file
3. Registering the terms at one of the PID providers e.g. datacite (https://datacite.org/), crossref (https://www.crossref.org/), ePIC (https://www.pidconsortium.net/) or institutional handles. Here we would still have to investigate what is most appropriate.
   (I am just experimenting with ePIC)

Here the examples:
NeXus has very clear defined semantics and in some facilities the NeXus terminology is used in the data catalogues with some variations, and in some facilities other terminology is used.

If the NeXus terminology is used you find the path like entry/instrument/monochromator/energy or monochromator_energy registered e.g. in the ICAT.
What they all mean is the expression registered here:
https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy

Let's say https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy is getting an official PID from the NeXus NIAC and the repository catalogues are able to register PIDs (the ICAT has a column PID in the table parameter types in its recent version). In this case there are various options:

1. you could register entry/instrument/monochromator/energy or monochromator_energy under the same official PID
2. both of the expressions could get repository internal PIDs and outside the catalogue they could be mapped to the official PID representing the https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy.

Later on it would be possible to integrate the NeXus vocabulary with other vocabularies. 
Her some examples for the and the IUPAC golden book Semantic Sensor Network Ontology.

Here it is the IUPAC again:
https://manual.nexusformat.org/classes/applications/NXxas.html#nxxas is narrower than https://doi.org/10.1351/goldbook.S05848
or https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy is the sameAs https://doi.org/10.1351/goldbook.E02102

Or the Semantic Sensor Network Ontology:
http://www.w3.org/ns/sosa/Sample
sameAs
https://manual.nexusformat.org/classes/base_classes/NXsample.html#nxsample

http://www.w3.org/ns/sosa/Sensor
broader than
https://manual.nexusformat.org/classes/base_classes/NXsensor.html#nxsensor

[1] https://www.nature.com/articles/sdata201618.

[benajamin]

This is an interesting philosophy that feels easy to get behind. If I understand correctly, you are proposing that we attach a URI to every item we define:

• base classes
• application definitions (experimental technique)
• fields
  And this URI will help to define the meaning of these items.

Do we need to choose a single source for the PIDs (i.e. choose between IUPAC and SSNO)? Or should we add both URIs where they overlap?

[hgoerzig]

We need to choose a PID type and provider. This could be e.g. a persistent handle, ePIC, or DOI. IUPAC and SSNO were just examples to show how IUPAC is giving PIDs to their terminology and SSNO, I could imagine someone wants to integrate/map the terminology with.

[prjemian]

FYI:

Noting from the nexusformat/definitions repository CHANGES.rst file:

:v2020.1:  released *2020-01-31*

    * see Release Notes wiki: https://github.com/nexusformat/definitions/wiki/releasenotes_v2020.1
    * The manual is now published through GitHub Pages: https://manual.nexusformat.org
    * We have a DOI (with zenodo https://zenodo.org/record/3629571) that updates with each release of the definitions repository.  The DOI link is noted on our GitHub home page.

Now: https://zenodo.org/record/3632902

[prjemian]

Add html anchors to each term (field, group, attribute, link) that is defined. This could be added to utils/nxdl2rst.py.

[prjemian]

For example, in NXmonochromator, we would create a link from the energy field to a link for https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy. There is no such anchor now, but this could be demonstrated.

[prjemian]

We might extend this to make a root anchor for any defined term, so that https://manual.nexusformat.org/#energy would identify any use of the term energy. Or even https://nexusformat.org/#energy (but these links do not exist now).

[benajamin]

Proposal is to encourage the development of a technical demonstration for future consideration by the NIAC.

• thumbs up to accept
• thumbs down to reject
• any other emoji to abstain

[hgoerzig]

How can we proceed here? I think it is just an html thing. When the html is generated from the nxdl file there has to be an anchor created.
In order to get here:
https://manual.nexusformat.org/classes/base_classes/NXmonochromator.html#energy
instead of:
<strong>energy</strong>
it has to be:
<strong id="energy">energy</strong>

This would have to be done for all fields and attributes. Are there exceptions e.g. for field and attributes that have semantically the same meaning as the @default attribute that is in almost every base class.

[benajamin]

@hgoerzig please continue implementation discussions in the nexusformat/definitions#855 issue opened by @prjemian (see link just above your comment). This thread is just for the NIAC discussion.

[benajamin]

The proposal was accepted with 13 votes for and 1 abstention.
Implementation is being discussed in nexusformat/definitions#855