Update docs on finding the root dataset

[simleo]

Updates the root data entity section as follows:

• Adds a paragraph to the metadata file descriptor spec to allow absolute URIs (e.g., https://example.org/crate/ro-crate-metadata.json) when the root data entity is also an absolute URI.
• Changes the recommended algorithm for finding the root data entity to leverage the constraint that the metadata MUST contain an ro-crate-metadata.json (or absolute URI whose last path segment is ro-crate-metadata.json) entry. This makes the algorithm simpler and more efficient in the "standard" case of a single entry with an @id of ro-crate-metadata.json (see https://github.com/ResearchObject/ro-crate-py/pull/119).

Note that, in order to make this PR independent from #189, I've avoided using the term "detached crate". If we merge that PR first, however, we should change this one to explicitly mention detached crates.

[simleo]

Re: the nested crate example, it would be nice to recommend adding a conformsTo to the relevant entry in order to indicate that it's an RO-Crate:

    {
      "@id": "http://example.org/crate/nested/",
      "@type": "Dataset",
      "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2-DRAFT"}
    }

I haven't included that in this PR since in the current spec the conformsTo applies to the metadata file descriptor. However, we're planning to move it to the crate, so we can make this change after we've done that.

[stain]

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.

[simleo]

@stain #183 was closed yesterday but this PR is still open.

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.

Commits 588e536, fe6e479 and e15f6ae did just that. Is there anything else that's preventing this PR from being merged?

[ptsefton]

@stian where is this up to?

[stain]

Merging without review as call 2023-03-23 agreed to merge all outstanding PR (that are not WIP) so we can do an overall review and push out 1.2.