v3 schema-revision: person.schema.json

[lzehl]

The person.schema.json will be used to identify researchers that were involved in producing the research products or their versions.

According to the current documentation, this schema will have the following properties:

• @type [expects: constant ("https://openminds.ebrains.eu/core/person"), count: 1]
• @id [expects: free text, count: 1] - ebrainsUserName: [expects: string (free text), count: 0 - 1] (this property should be handled confidential)
  [will be handled in digigtalIdentifier]
• email: [expects: string (format: email), count: 1] (this property should be handled potentially confidential)
• familyName: [expects: string (free text), count: 0 - 1]
• givenName [expects: string (free text), count: 1]
• digitalIdentifier: [expects: digitalIdentifier.schema.json, count: 0 - 1]

[lzehl]

@apdavison is this what you had in mind for persons? @olinux can you handle this within the KG?

[apdavison]

If openMINDS is supposed to be an open standard that others can adopt, then ebrainsUserName is too project specific. Either we rename it userName or userID, or we allow digitalIdentifier to contain multiple values (ORCID, ResearcherID, EBRAINS username, etc.)

[lzehl]

For me the latter suggestion sounds good. I'll adopt it.

[skoehnen]

• @type [expects: constant ("https://openminds.ebrains.eu/core/contribution"), count: 1]

@lzehl Shouldn't this be https://openminds.ebrains.eu/core/contribution? (I didn't ask in funding so I better ask now 😉)

[lzehl]

@skoehnen see update above.
Note: @type should always state at the end the corresponding schema name its a property of.

[lzehl]

@olinux if we have to handle "email" confidential, should we handle this as a separate element/schema?

[skoehnen]

Note: @type should always state at the end the corresponding schema name its a property of.

Yes, I thought that too, but I wanted to make sure that I don't overlook anything 🙂

[olinux]

@olinux if we have to handle "email" confidential, should we handle this as a separate element/schema?

Yes, I think we should not have email in this structure if we want to handle the permissions differently. You could have a "contact" object which also could include things like phone number, postal address, etc.

But didn't we even think about not having e-mail in openminds at all so the identification would be done e.g. by ORCID?

[olinux]

also: I think we should allow more than one identifier -> I could e.g. have a ORCID, a github account, ... we should have the chance to register them all

[jcolomb]

jats4r get "type" and "id" for each identifier. datacite has also optionally a url for each identifier type. (https://schema.datacite.org/meta/kernel-4.0/doc/DataCite-MetadataKernel_v4.0.pdf page 11)

[lzehl]

@olinux so digitalIdentifier should be an array. I agree here. As for the email: considering the new curation workflow the publication of a dataset is suppose to be verified by all authors/contributors. Therefore we must have an email for all of them. Within the identifiers (e.g. ORCID) to problem arise: 1) not everyone has a digitalIdentifier (question here should/can we enforce this?) 2) the email is not necessarily accessible via the digitalIdentifier (up to the user what he/she makes publicly accessible)

The advantage of e.g. ORCID is: If something like an ORCID is given we only know better what personal information the user is willing to share, because it's his/her responsibility and not ours.

@jcolomb : yes this is taken care of within the digitalIdentifier schema #103 (and the identifierScheme schema, which is only documented so far in the comments of #103 )