be more specific about nested datasets. fix #98

[NicolasCARPi]

No description provided.

[FlorianRhiem]

What is the logic behind A Dataset MUST not contain other Datasets in its hasPart section.?

In the SampleDB export, hasPart is used to link to prior versions of a Dataset, which are also Datasets but not meant for importing as a top-level dataset, as that would lead to multiple versions being imported for one Dataset. Hence these are not in hasPart of the root data entity, but are in hasPart of the importable Dataset.

[NicolasCARPi]

@FlorianRhiem maybe we can modify it to read: "If a Dataset contains other Datasets in hasPart , they must be considered as previous version of the Dataset".

But I believe it would be best to use isBasedOn to avoid confusion. hasPart is the stuff to import, and revisions/history is using isBasedOn. What do you think?

[FlorianRhiem]

I wasn't aware of isBasedOn, that sounds perfectly fitting for prior versions. Using that sounds good to me!

[FlorianRhiem]

I just implemented a version of the export using isBasedOn and the rocrate validator fails for the following check:
Check if the Data Entity is linked, either directly of inderectly, to the Root Data Entityusing thehasPart(as defined inschema.org) property

This seems to refer to this part of the spec: https://www.researchobject.org/ro-crate/specification/1.1/data-entities.html#referencing-files-and-folders-from-the-root-data-entity As there are folders for these datasets (which contain additional files for each previous version), this actually applies here. So it seems the correct way would be to include them both in hasPart and in isBasedOn?

Perhaps it would be enough for us to specify that importable Datasets should be included in the hasPart of the root data entity and not restrict hasPart for other data entities?

[NicolasCARPi]

Perhaps it would be enough for us to specify that importable Datasets should be included in the hasPart of the root data entity and not restrict hasPart for other data entities?

Sounds good to me. Then the logic to import Datasets is really to look at the hasPart of root node, and ignore hasPart of Datasets that are also Datasets, unless there is support for importing them. Using both attributes sounds about right, too, as it gives more information.