ro-crate
ro-crate copied to clipboard
ResearchObject
Make overriding ("inheritance") of properties more explicit
After some discussions with @stain at an IBISBA meeting:
The only explicit mentioning that I could find about overriding properties is the attribution:
In ROLite, if a file does not list a
creator, and is within the Research Object's folders, it's creator can reasonably be assumed to be thecreatorof the containing research object. However, where appropriate, the Research Object manifest allows overriding with more precise attribution per resource.
- It is unclear if this also applies to e.g.
licenseas well or only attribution - Does an
@idreferring to a folder propagate the properties to all the files that are contained in the referred to folder (unless a more specific thing (sorry, lacking the word) is available)?
If we agree we allow some implicit properties like creator and license to apply to a research object folder "root folder" (?) or on a directory, then yes, we should agree:
- Which provenance/license properties re-apply recursively?
- Do these properties re-apply also to sub-sub-folders?
- What is the order of overriding? (intuitively the most specific path should win)
- What kind of tooling should do this inference to "complete" the RO?
- Does such properties also apply to "external" resources outside the "root"?
- Do we need to define the research object "root folder"? (e.g. fix the location of
manifest.jsonld)
A bit of added complexity here. The Root RO-Crate Dataset should use creator etc as properties pointing to well described contextual entities with a URI (as per DataCrate but for individual files creator is going to be better expressed using provenance via CreateEvent. But yes we should make some statements about what is inherited. But I think machine reasoning about RO-Crate of un-trusted provenance would be risky.
dc350427c4d612f47d41d105d283a8196705e987 expands a bit on license recursiveness, but not for folders.