rdm: define {crea,contribu}tors schema #11
Conversation
| "type": "array", | ||
| "description": "List of IDs related with the person or org. (e.g., ORCID, RORid)", | ||
| "uniqueItems": true, | ||
| "items": { "$ref": "#/definitions/identifier" } |
There was a problem hiding this comment.
I don't know if this syntax is possible to be honest. Maybe "one_of" is necessary...
There was a problem hiding this comment.
It looks right, but I haven't tried it before. I'll add up a validation test of the schema to my to-do list.
fenekku
force-pushed
the
creators_contributors_metadata
branch
from
f00071b to
960792b
Compare
|
First round of changes made. |
| "type": "string", | ||
| "description": "Kind of identifier.", | ||
| "enum": [ | ||
| "ads", |
There was a problem hiding this comment.
ads is the same as bibcode (bicode is the official name).
There was a problem hiding this comment.
So should we remove ads?
There was a problem hiding this comment.
ads is from zenodo, while bibcode is from DataCite. If Zendo is alright migrating to bibcode, ads should go.
| "description": "Contact email for the purpose of this specific record.", | ||
| "format": "email" | ||
| }, | ||
| "full_name": { |
There was a problem hiding this comment.
We also need support for family_name and given_names. This is highly important for scholarly works and being able to generate correct citation strings.
There was a problem hiding this comment.
What about that discussion we had on names: https://www.w3.org/International/questions/qa-personal-names ? How do we tow that line?
| "istc", | ||
| "lissn", | ||
| "lsid", | ||
| "orcid", |
There was a problem hiding this comment.
This list of identifiers I think needs to be specific to the related field. ORCID makes sense for people, but a DOI does not make sense for people. Discussion for IRL
| "type": "string" | ||
| } | ||
| }, | ||
| "email": { |
There was a problem hiding this comment.
I don't think email should go on the person, but as a possible separate field. It opens up a pandoras box of data protection issues if you store the email associated with the user. I'd rather see e.g. a contact_email field. Also, email addresses have a tendency to go stale after some years especially in research where people move between institutions a lot.
| "description": "Affiliation(s) (if person) for the purpose of the specific record.", | ||
| "uniqueItems": true, | ||
| "items": { | ||
| "type": "string" |
There was a problem hiding this comment.
Are organizational identifiers (ROR, GRID, etc.) out of scope? I think since we're adding ids anyways (for ORCIDs, etc.), making this a complex object for the affiliation with name and ids might make sense
There was a problem hiding this comment.
We will support organizational identifiers. There is a question of whether these get put into the big ids block below, or separate blocks that split out different types of identifiers (organization vs people vs things). I think it's better to separate out identifiers by type, but it gets complicated as you start to nest things. Here is an example of supporting multiple affiliations and multiple identifiers per affiliation:
"affiliationIdentifiers": {
"type": "array",
"items": {
"type": "object",
"properties": {
"affiliationIdentifier": {"type": "string"},
"affiliationIdentifierScheme": {"type": "string"},
"schemeURI": {"type": "string", "format": "uri"}
},
"required": ["affiliationIdentifier", "affiliationIdentifierScheme"]
},
"uniqueItems": true
},
"affiliations": {
"type": "array",
"items": {
"type": "object",
"properties": {
"affiliation": {"type": "string"},
"affiliationIdentifiers": {"$ref":"#/definitions/affiliationIdentifiers"}
},
"required": ["affiliation"]
},
"uniqueItems": true
}|
|
||
| ## Alternatives | ||
|
|
||
| The main alternative to the definition above is to split the `stakeholders` |
There was a problem hiding this comment.
I'm pro-splitting, stakeholders sounds too generic in this context
|
|
||
| OR | ||
|
|
||
| ```json |
There was a problem hiding this comment.
I prefer this one, see also above my comment on additionalProperties
|
|
||
| ? | ||
|
|
||
| Where should `owners` fit in this design (if at all)? The meaning of `owners` |
There was a problem hiding this comment.
owners IMHO, is a "system" field (i.e. might contain a database user ID, and might be used for access control), in contrast to creators which is a bibliographic field.
|
Other updates made. This should be a good fodder for discussion in January. |
fenekku
force-pushed
the
creators_contributors_metadata
branch
from
960792b to
69db810
Compare
RFC for
"contributors"or"creators"metadata schema.Here is where the discussion that had formerly been split across
should really go. This is more concrete and will be easiest to get specific feedback.
@tmorrell I have tried to take into account your previous comments. I have also taken the liberty of putting you as an author on the RFC given your insight. Take a look, so we can improve this even more!