-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add contributor.roles
property
#18
Conversation
I'm not familiar enough with JSON schemas, but is there a way to express the fallback in the JSON schema, so that implementors automatically fall back to |
JSON Schema only specifies which fields are allowed, not how to process them. The schema could make sure not both of |
Co-authored-by: Peter Desmet <peter.desmet.work@gmail.com>
Deploying datapackage with Cloudflare Pages
|
Given yesterday's call and given ourselves a bit more freedom for v2. I suggest to add |
Given that the value of |
Such roles can be defined by specifications that build on top of Data Package. Currently however, Data Package dictates that |
I agree, intuitively I would think contributors to a data package could have multiple roles. I'm aware of the Relators in MARC (MAchine Readable Cataloging) : https://www.loc.gov/marc/relators/relaterm.html, which form the basis for the system used in R Packages: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf In R packages, it's extremely common for contributors to have multiple roles, see: https://r-pkgs.org/description.html#sec-description-authors-at-r For example:
With this in mind, an array makes sense to me. |
Interestingly, that DataCite doesn't support multiple roles - https://github.com/inveniosoftware/datacite/blob/master/datacite/schemas/datacite-v4.3.json#L51-L76 BTW, we can also keep |
I prefer |
I like |
Yeah, my apologies—this isn't something I use much myself nor have strong feelings about. Glad to defer to the wisdom of the group (i.e., I'll support whatever group consensus emerges). |
I support
|
@roll Nor does Zenodo, because they use the same DataCite model. https://developers.zenodo.org/#representation (see @peterdesmet As you said, the main value of
|
Can we use |
That feels unnecessarily complicated and too restrictive. There is no universally-accepted role taxonomy, but rather different taxonomies in different domains. |
I agree that Here's an attempt:
Note: I dropped @ezwelty I notice in the DataCite documentation that a contributor has a |
@peterdesmet DataCite's contributor (with required contributorType) is optional and separate from creator, which is required (and has no type). See https://support.datacite.org/docs/datacite-metadata-schema-v44-mandatory-properties#2-creator. So to your list of roles I would add I'd support recommending using an existing taxonomy, and happy to either preserve the Data Package v1 role taxonomy (if better defined) or dropping it. |
Right! I agree with adding
Yeah, it would likely be I have also removed |
Thanks @peterdesmet, I've upated after your definition |
Co-authored-by: Peter Desmet <peter.desmet@inbo.be>
@khughitt |
ACCEPTED by WG (6/9) |
Rationale
Please take a look at frictionlessdata/specs#804. Also, this pull request tests the way we can deprecate things:
contributor.role
is removed)Later we can update all other deprecations to this style e.g.
resource.url
etc