[Epic] Support RO-Crate 1.2 specification

[elichad]

Placeholder issue until we identify the exact changes that need to be made.

See the changelog (which could still be updated until 1.2 is released).

[stain]

@elichad to Populate with sub-tasks

[elichad]

Detailed changes are listed in the upgrade guide and quick reference.

Some changes should only be applied to 1.2 crates, not 1.1 crates (e.g. detached crates can only exist in 1.2). So we might need a version selector, or we will have to drop support for 1.1. @simleo what do you think?

A list of tasks to get started with:

• version selector for 1.1/1.2
• selector for attached/detached crates (1.2 only, 1.1 crates are always attached)
• update context version (1.2 only)
• implement support for making detached crates
• update rules for determining which entities are data entities (1.2 is clearer than 1.1 on this)
• support referencing other RO-Crates (not sure if changes are needed, maybe a helper function?)
• enforcement of relative IDs having a corresponding file in the root, and vice versa (not sure if changes are needed)
• all entities should be directly or indirectly reachable from the Root Data Entity via cross-references (how to check?)
• implement other changes from the guides linked above (here I skipped a bunch of stuff relating to usage of specific terms)

Happy to split those out into issues if you like.

[simleo]

Thanks for your detailed comment, @elichad! Here are my initial thoughts.

• We should not drop support for 1.1, it's been around for quite a long time now (almost five years). When we updated the library to support 1.1 (Update to RO-Crate 1.1 #28), we kept the ability to read 1.0 crates (by using LegacyMetadata instead of Metadata for crates with ro-crate-metadata.jsonld), but not to create them. This time we should change the library so that it's able to both read and create crates of all supported versions -- now the library is widely adopted and users should be able to update gradually. So yes, we need some kind of version selector and likely a version property for the ROCrate class.

• At this point I'm not sure about a selector for attached/detached. I think ROCrate should have a property for this (e.g. is_detached), but maybe its value should be a consequence of how the RO-Crate is initialized, rather than selectable. Or the other way around. This needs to be tried in practice.

• The context should change automatically depending on the version of the RO-Crate.

• Support for making detached crates should definitely be added, not sure how for now. Related to the attached/detached selector issue (maybe we should merge them).

• The "determining which entities are data entities" thing will require major changes, especially in the way an existing RO-Crate is read: now entities are considered data entities if and only if they are referenced directly or indirectly (through Dataset instances, see Fix indirect data entities #216) from the RDE's hasPart.

• I'm also not sure if changes are needed for the "referencing other RO-Crates" bit. This issue seems to have lower priority than the others.

• The thing about relative IDs having corresponding existing files might need some changes. Relevant issues are Bug? Fails to load a crate file without its data entities (directories) #73 and Fix behavior wrt "missing" data entities #135.

• "all entities should be directly or indirectly reachable from the Root Data Entity via cross-references": currently this is automatically true for data entities (see above), but not for contextual entities. I'm not sure we should even check, since this is not a validator, especially if it turns out to be computationally expensive. Possibly another low priority issue.

Happy to split those out into issues if you like

Yes, please! We need to break down the work into smaller units.

On a side note, I will be on annual leave for three (possibly even four) weeks starting next Monday.

[elichad]

On the selector for attached / detached, maybe this should be implemented as an argument of ROCrate.write() - since it primarily affects the file structure (or lack thereof).

• if attached - follow existing behaviour
• if detached - write just the JSON-LD file, and raise an error if there are any non-web data entities.

In that case, a RO-Crate that has been read in could be written out in a different format. I think that's actually a benefit, though we could also set a flag like ROCrate.is_detached when reading a crate to modify the default behaviour (i.e. if you read a detached crate and then write it back out, it should stay detached unless you specify otherwise).