Rules for metadata.json nodes declaration

[NicolasCARPi]

So now that we have a few examples to work with and possibly some import code in our apps, we can see some issues arising.

First, let's define the logic for importing something:

1. read the metada.json file obviously
2. loop over all the nodes to find the node with @id => ./. Currently I don't think we care that much about the node describing the metadata crate
3. This "root node" MUST have an haveParts which describes Datasets
4. The import code would then loop over the hasParts of this root node to find all the Datasets from the crate (and possible files that are not part of any dataset).

If a dataset has some other files, they should be in the hasParts of that dataset, BUT not mentioned in the hasParts of the root node!

So A would become B in the Kadi4Mat example:

And the idea would be for the code to recursively import the stuff present in the hasParts of any Dataset it finds.

It means that a node gets referenced only once.

My preference goes to referencing the part with only the @id and then there is a root node with that @id. But having the full node in the hasParts is also entirely valid so we should take into account both cases.

Please add your comments below :)

[SteffenBrinckmann]

I would try re-specify the rules:

• one master node contains the ro-crate-metadata.json, which contains only the sdPublisher information. It does not contain dataset-information
• one master node contains the './' node which contains all the data via 'hasPart'.
• the other graph nodes are included and have their sub-data via 'hasPart'
• important, "hasPart" includes only the neighboring node (or next child in a hierarchical tree) and not the full the connection (no grandchildren are in a hasPart)
• links in "hasPart" can contain only the "@id" of the neighboring node OR contain the full node (incl. @id, data, ...)
• all information should only be contained once in json-file

@mikee1976 What do you think? The current Kadi4Mat examples have grandchildren in their node-hasPart?

[nicobrandt]

@jmanideep actually created the examples, but we agree that hasPart should only include its immediate children for the sake of consistency and easy parsing. Our current examples were created manually, so nothing is set in stone yet anyways. We only just started with a first implementation of the actual export functionality in Kadi4Mat.

About the entry containing the ro-crate-metadata.json, it also needs to have an about property according to RO-Crate, as well as some other recommended properties, not just sdPublisher (unless you just meant including only sdPublisher besides these).

[SteffenBrinckmann]

I just mentioned "sdPublisher" as one of the entries. It is the entry which most people like to write stuff into ;-)

We should be careful of using children as they make sense in the hierarchical structures. But graphs are not necessarily children of children; in graphs you can have a grandchild to be an grandparent. Therefore in graphs "nodes" and "neighbors" is more appropriate. But I get your point. :-)

[SteffenBrinckmann]

I was working on the first version of a validator and noticed something:
hasPart includes a list of ids only. According to all examples hasPart must-not include the content of the final node. ro-crate examples

I also liked to put final content into hasParts but that should not happen.

If this case occurs, the validator see will through an exception and fail.