How to associate labels to ids in repeated slots

[dr-shorthair]

Some properties of Mappings have unrestricted cardinality, and some IDs and matching labels (e.g. author_id+author_label, reviewer_id+reviewer_label).

Is there a convention to associate these correctly?

[matentzn]

@dr-shorthair Thank you for reaching out!

There is currently no way to associate author_id and author_label - and this is by design. From the early days of SSSOM, we decided that the core design feature of SSSOM is simplicity, which meant, in essence, avoiding a nested data model. There are no nested elements in sssom at all - formally, all elements are associated directly with the mapping. What you would want (and many others like you) is to be able to have, in the datamodel at least, an author element with two slots, id and label. Unfortunately, this is not supported, and won't be in the standard model. There have been debates on a separate more structured model, but so far no one has shown enough interest to spearhead the design of such a model (which could be quite complex).

I personally think of it like this:

We should always use author_id if possible. Only if not possible, use author_label. Managing metadata about people involved in the mapping process should be managed elsewhere (else, why not add "author_expertise" or "author_affiliation" to the metadatamodel?).

In any case, nothing here is clear cut, and I can see a lot of push back against what I am saying :P

[dr-shorthair]

Thanks. In my original question, I almost commented that *_label should be treated as non-normative, with *_id being the default, but wasn't quite sure how to phrase that.

[gouttegd]

Re-opening because @matentzn ’s answer, about how author_id and author_label (and other similar slots such as creator_id, etc.) are not linked and should not be thought of as being linked, should really be part of the spec. The question in the ticket is a valid one (I have been asking that myself), and the spec should provide an answer to it.

Right now the spec about author_label simply says: “In the spirit of provenance, consider using author_id instead.” That is not enough.