Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove heuristic for nested ro-crate metadata files #365

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 0 additions & 48 deletions docs/_specification/1.2-DRAFT/root-data-entity.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,54 +110,6 @@ metadata_entity = entity_map["ro-crate-metadata.json"]
root_entity = entity_map[metadata_entity["about"]["@id"]]
```

More generally, the metadata id can be a URI whose last path segment is
`ro-crate-metadata.json`, so the above lookup can fail in non-conforming crates,
e.g. a JSON-LD file that has imported an RO-Crate using Linked Data mechanisms.

In this case we can look for the root entity by executing a
heuristic algorithm similar to the one shown above,
with the only difference that step 2 must be replaced by:

2. .. if the `@id`'s last path segment is `ro-crate-metadata.json`

It is possible to build an RO-Crate having more than one entity whose `@id`
has `ro-crate-metadata.json` as its last path segment. For instance, the crate
could reference a collection of sample _RO-Crate metadata file_s available from
different web sites, or from the same web site but at different locations. In
order to facilitate consumption, data entities representing such files SHOULD
NOT have an `about` property pointing to a [Dataset] in the crate, so they can
be told apart from the actual Metadata Descriptor. A scenario that can
potentially lead to confusion is when a dataset in the crate is itself an
RO-Crate (_nested_ RO-Crate): again, the crate could be a collection of
RO-Crate examples. In this case, the top-level crate SHOULD NOT list any files
or directories belonging to the nested crates, but only the nested crates
themselves as [Dataset] entries. For instance:

```json
{
"@context": "https://w3id.org/ro/crate/1.2-DRAFT/context",
"@graph": [
{
"@id": "http://example.org/crate/ro-crate-metadata.json",
"@type": "CreativeWork",
"about": {"@id": "http://example.org/crate/"},
"conformsTo": {"@id": "https://w3id.org/ro/crate/1.2-DRAFT"}
},
{
"@id": "http://example.org/crate/",
"@type": "Dataset",
"hasPart": [
{"@id": "http://example.org/crate/nested/"}
]
},
{
"@id": "http://example.org/crate/nested/",
"@type": "Dataset"
}
]
}
```

See also the appendix on
[finding RO-Crate Root in RDF triple stores](appendix/relative-uris#finding-ro-crate-root-in-rdf-triple-stores).

Expand Down