Create function `add_metadata()` or `add_property()`
Add function to add common properties to descriptor file, e.g.:
package <- add_metadata(id = "https://doi.org/10.5281/zenodo.5070086")
- [ ] Would the function check if the parameter names are valid? If so, what about optional ones? Maybe
add_property()is better - [ ] How would the function react if a property is already there? Overwrite with warning?
- [ ] Can we use the
add_property()function for adding properties to fields or schemas? If so, can the user give a vector of equal length to the number of properties?
Note that because of a recent change, one can use append() to add properties:
my_package <- append(my_package, c(name = "my_package"), after = 0)
- It allows to add a property at a specific place
- It does not warn if a property is already there, but just adds a second one
- It does not warn for custom properties (allowed) that are not part of the frictionless spec
@damianooldoni do you think that append() is sufficient?
Just dropping by here to say I was looking for this. In my case, I would like to add extra metadata at resource level such as these https://specs.frictionlessdata.io/data-resource/#optional-properties. The append approach will work, but it would be nice to document this and / or to expand this with warnings if a property is already there or not part of the frictionless spec. Great package!
Aha, the append approach is already documented: https://docs.ropensci.org/frictionless/articles/frictionless.html#create-and-edit-a-data-package 👍
Yeah, the documentation provides a simple use case for appending to a package (level 0). Appending to a resource (level 1, your use case) can be done the same way. It is also possible to append to the fields (level 2) of a schema, by starting with an initial create_schema() and expanding it. I have done so here for the movepub package.
So there are use cases at multiple levels. We could support those with additional functions, but append() already gives quite a lot of flexibility, so I'm not sure it is worth it. Contributions welcome though. 😄
Maybe consider adding an ellipsis argument to add_resource() to allow passing extra metadata as key-value pairs?
@param ... Additional key-value pairs.
and in the function body pass the ellipsis when the list() is created after some checks (which can error or warn) (see https://ellipsis.r-lib.org/):
some_checks_for_ellipsis()
resource <- list(
name = resource_name,
data = df,
profile = "tabular-data-resource", # Necessary for read_resource()
# other properties are set by write_resource()
schema = schema,
...
)
Oh, I like that approach. Would solve the level 1 use case.
I will give it a try and send a PR
I have created a separate issue #140 to describe that enhancement.