Use Case: Allow RO-Crates to have root dataset IDs other than "./"

[ptsefton]

As a profile designer, I want to allow RO-Crates to have IDs that are not ./ so that ** ro-crate-metadata can be served over an API**.

"./" was originally a magic name until Stian came up with the metadata descriptor - the convention is no longer needed and is meanigless if the ro-crate metadata is not in a file on disk but is served via an API.

• See also Use Case: RO-Crate over an API #178

[simleo]

The spec already allows this (since version 1.1): the root data entity SHOULD have an @id of ./. This is not handled by ro-crate-py yet though. Perhaps we want to get rid of this recommendation and write something like "legacy specs (until version 1.0) required the root data entity to have an @id of ./; this is still recommended for RO-Crates stored as file system directories" instead.

[stain]

@simleo however properties of the root data entity includes:

@id: MUST end with / and SHOULD be the string ./

I think we can soften that MUST to another SHOULD - athough then the Root Data Entity is more of risk of not having anything to do with the root directory which could get confusing.

So do we need to clarify the terminology then? This entity then becomes the "RO-Crate" rather than of the RO-Crate Root (which is effectively how it is used). Note that the current root terminology helped to avoid "The RO-Crate is made of the RO-Crate and the RO-Crate Metadata File" loops

[simleo]

Discussed this morning at the meeting. One of the main issues raised was that if the root data entity id is an arbitrary URI, then it's not clear what to do with relative paths of data entities. @dgarijo came up with an idea that many of us found great, myself included: state that relative paths are unsupported in data entities (behavior of implementation is undefined) if the root data entity id is not ./. In other words, the root data entity id may be an arbitrary URI, but then all data entities should have an absolute URI as their id.

[dgarijo]

@simleo thanks for the credit, but I think it was @stain and @ptsefton who proposed it. I just rephrased emphasizing the 2 use cases focus on (i.e., leave out of scope relative paths if the root data entity id is not ./)

[stain]

As suggested in #189 when trying to add this I had trouble with repeated references to RO-Crate Root Directory which becomes tricky if the root dataset no longer is grounded in a directory (with ro-crate-metadata.json may or may not be implied to be in such a directory)

[stain]

Check minutes as we think it was decided @id can be URI?

@simleo Spec already allows URI, (but requires / at end). Touches on detached/attached crate and nesting of crates.

We agreed that implementation can try to be lax and rescue user -- but spec should be more strict. Don't suggest the heuristics. Just note to not expose internals of nested crates as it could confuse root dataset algorithm.