Add author, organization and grant types.#1
Add author, organization and grant types.#1RoseReatherford wants to merge 7 commits intooxa-dev:mainfrom
Conversation
| members?: (Person | Organization)[]; | ||
|
|
||
| /** Sub-organizations (inverse of parentOrganizations). */ | ||
| subOrganization?: Organization[]; |
There was a problem hiding this comment.
I don't think we need subOrganizations here; if they were involved, then they should be the actual organization in the attribution. If not, then they shouldn't appear at all. I don't think this adds information that's necessary for a document to be completely described.
There was a problem hiding this comment.
This also includes departments for an institute which may have different identifiers and billing contracts. I was going off of how Stencila uses this portion.
| order?: number; // In JSON-schema this should have a minimum of 0. | ||
| } | ||
|
|
||
| export enum AuthorCRediT { |
There was a problem hiding this comment.
We want to avoid typescript enums; they have negative downstream consequences for building packages. See eg https://www.totaltypescript.com/why-i-dont-like-typescript-enums
There was a problem hiding this comment.
Hmm... Good point. How should we handle this? They are supported in JSON-schema.
There was a problem hiding this comment.
Do we even want to support AuthCredit or should we just leave it as PropertyValue like other identifiers?
There was a problem hiding this comment.
PropertyValue makes you have to see what kind of identifier it is in case it changes what things people want to use for contributions. Makes it a longer lasting schema.
| /** | ||
| * The name of a Person object. | ||
| */ | ||
| export type PersonName = Record<string, unknown> & { |
There was a problem hiding this comment.
We want to be extremely careful about names: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
There was a problem hiding this comment.
I love that article! I was talking to Nokome about how I'm, myself, an edgecase with multiple legal names. So! I'm going off of schema.org and Stencila here as a compromise. I think this is the best and most common way of gathering this information.
There was a problem hiding this comment.
Made family name optional in latest push.
There was a problem hiding this comment.
I'm, in this case, not letting "good" get in the way of "good enough". :)
There was a problem hiding this comment.
In schema.org they're all optional and a single string: https://schema.org/Person
There was a problem hiding this comment.
Yes, Stencila has multiple/array here which is where I based off of. I originally had it as a single value, but Nokome pointed out Stencila has needed to use multiple values for names so that seems fine to me.
There was a problem hiding this comment.
@nokome, tagging you here for comment: can you give a bit more context on how multiple names are used, in contrast to how CSL-JSON does it?
There was a problem hiding this comment.
Here's the schema for this: https://github.com/stencila/stencila/blob/f4daaea38f09136a5b3108825b845e7ddd1d202c/json/Person.schema.json#L17
| /** ===================== | ||
| * MonetaryAmount | ||
| * ===================== */ | ||
| export type MonetaryAmount = Record<string, unknown> & { |
There was a problem hiding this comment.
I think this is too fine-grained.
There was a problem hiding this comment.
I think it helps add some structure. We do need to enforce something. Schema.org has these mechanics and I think it's a good way of doing it. There are multiple options.
There was a problem hiding this comment.
We do need to enforce something.
Why?
There was a problem hiding this comment.
Having too much flexibility brings us back to JATS.
There was a problem hiding this comment.
This is about exchanging documents. We truly don't have to define a standard for exchanging monetary units.
|
I think that it would be useful to see what existing systems use for name schemas.
|
2 participants
This allows for the base objects of author, organization and grant types using TypeScript.