add identifierNAME to NXobject

[lukaspie]

Implements vote in #1451 (comment).
Depends on #1485 -> done

Any implementation should consider comments in #1416

[rayosborn]

I thought that, in the end, we decided against using "identiferNAME", instead of an identifier attribute, just called "identifier". Obviously, @sanbrock has the official record.

[prjemian]

If it is an attribute, then it would be added to the nxdl.xsd schema.

[rayosborn]

Isn't it possible also to add attributes to the NXobject class at least for groups?

[prjemian]

It gets messy there. Can be very precise in the schema.

…

On Fri, Oct 4, 2024, 9:49 AM Ray Osborn ***@***.***> wrote: Isn't it possible also to add attributes to the NXobject class at least for groups? — Reply to this email directly, view it on GitHub <#1486 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMUMETIDXGDZ57Y7ZJV3TZZ2TH5AVCNFSM6AAAAABPCXF2O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJTHA4DQMBRHE> . You are receiving this because you commented.Message ID: ***@***.***>

[lukaspie]

I added some of the feedback provided by @paulmillar in #1416 with respect to the type of identifier. He made a strong point that service is not the right word, but rather something like type.

Note that here I am still adding identifierNAME as a field rather than an attribute. My argument for this is that if we were to use an attribute and still keep the service and is_persistent (as was agreed if I recall correctly), we would need to add three attributes like this: identifierNAME, identifier_serviceNAME, identifier_is_persistentNAME, which would be rather messy. Since identifier will be added to the reserved prefixes anyway, why not make it a field with the other two concepts as attributes? Maybe @sanbrock can also chime in with his opinion.

I thought that, in the end, we decided against using "identiferNAME", instead of an identifier attribute, just called "identifier". Obviously, @sanbrock has the official record.

My understanding was that it shall be possible to have more than one identifier (e.g., from different services) for one object. I think this is also what @sanbrock noted. Even if identifier will become an attribute, I would suggest to use <attribute name="identifierNAME" type="NX_CHAR" nameType="partial">.

[prjemian]

We have been reducing use of type to a few limited situations because its meaning varies with context. XML Schema, XML, NXDL, numeric, data, units, ... (I'm certain I've missed a few.) All of these want to use this noun. Quickly, it became bewildering. At the end of the day, the XML Schema and the NXDL data type win. Here's an example:

definitions/nxdl.xsd

Line 47 in 67d8519

<xs:element name="definition" type="nx:definitionType">

Please pick a noun which is not type.

[rayosborn]

At the NIAC, I recall that people (including, I believe, @phyy-nx) thought the "is_persistent" tag unnecessary. We need @sanbrock to confirm, but I also believe that the attributes would just be "identifier" and "service." There is no need to add partial names here, which I agree become very messy. I have no idea whether we specifically voted on any of these issues.

[sanbrock]

We have not voted on it but agreed that a workgrouo shall conclud with a reasonable solution in a form of a PR which can then be voted on.

[sanbrock]

Indeed, we qgreef to use type instead of service.

[sanbrock]

There was no real conclusion on is_persistant. Indeed, its necessity was debated, although I argued that it is acually good to know if an Idebtifier is a PID or not.
Ww may state that the type holds this information. E.g. doi or orcid are good examples of PIDs.

[rayosborn]

@sanbrock, do you believe we came to any conclusion about the need for partial names? Attribute names such as "identifierDOI" are pretty ugly IMHO. If there is going to be a working group, perhaps this PR should be, at least temporarily, withdrawn.

[sanbrock]

Note that we did agree that our solution shall allow attaching multiple identifiers (e.g. orcid, linkdin to a USER).

• identifierNAME with nameType=partial would do that job.
• identifier as a reserved prefix would also do that (but this solution is rather a convention /only appears in the documentation and/or in the xsd descriptuon of the NeXus Definiion Language/ rather than an asserted statement written in NXDL in a definition. While the former requires hard coded implementation in all NEXUS tools in any programming languages used, the later would be inferred automatically by any NEXUS tools which has implemented the interpretation of NeXus definitions written in NXDL. Because of this, I would prefer @identifierNAME with @identifier_typeNAME declared in NXobject over the actual simpler solution of listing identifier among the reserved prefixes.
• identifierNAME as a deckared Field in NXobject would also do the same, but it would allow adding @type to it. This seems to be the most elegant solution. Knowing that only a few udentifiers will be provided in practice for a given group, I do not think it has disadvantages compared to using attributes.

[sanbrock]

@sanbrock, do you believe we came to any conclusion about the need for partial names? Attribute names such as "identifierDOI" are pretty ugly IMHO. If there is going to be a working group, perhaps this PR should be, at least temporarily, withdrawn.

This is actually a draft PR. And we are the workgroup. Note that we wanted to invite @paulmillar too to this duscussion.

[sanbrock]

Note that another alternative is
@identifierTYPE - this allows the use of identifier_orcid, identifier_url, identifier_iri, etc. in the data file, and would make the @identifier_typeNAME (or identifier/@type) as an extra attribute unnecessary.

[sanbrock]

NIAC suggestions on the revwrite of NXidentifirler were recorded in #1451

[sanbrock]

These have been also voted for in Session J. See https://www.nexusformat.org/content/NIAC2024_minutes/

[lukaspie]

CI/CD failing because multi-line doc handling is not implemented (see #1491)

[phyy-nx]

While a separate page can be added on the use of Identifiers, during the discussion in the Telco it was also appreciated that the extensive documentation string is indeed collapsed in the HTML webpage.

Totally forgot. In that case I agree this can go to a vote in our next telco on Monday, once @paulmillar's new comments are addressed. We'll follow the normal procedure of kicking off a two week voting period, unless we happen to get quorum!

[phyy-nx]

@lukaspie please remove type_other and Other from type (see comment on #1407). Once done, as discussed on the Telco, we will start an online vote for this PR. Thanks!

[lukaspie]

@lukaspie please remove type_other and Other from type (see comment on #1407). Once done, as discussed on the Telco, we will start an online vote for this PR. Thanks!

done!

[phyy-nx]

Hi all, as discussed in the Telco, now that the above points have been addressed (thanks @lukaspie), we can now move this PR to an online vote.  NIAC committee members please vote on this PR using emojis. 👍 for yes, 👎 for no, anything else (for example 👀) to abstain.  We need 14 votes to hit quorum so please review and vote!

[PeterC-DLS]

LGTM

[phyy-nx]

Vote has passed with 16 votes. Thanks all!

@lukaspie feel free to merge

[lukaspie]

Vote has passed with 16 votes. Thanks all!

@lukaspie feel free to merge

Great, thanks!