Update SampleDB example for SampleDB 0.29.1

[FlorianRhiem]

I have recreated the SampleDB example with the current release. The example now contains the flexible object metadata as variableMeasured entries.

[NicolasCARPi]

Hello Florian,

The Author property must not be an array. See example: https://www.researchobject.org/ro-crate/specification/1.1/appendix/jsonld.

[NicolasCARPi]

author must not be an array

[NicolasCARPi]

What happens if you have multiple values in "mentions"? Does it become an array? I've come to realize that a value in JSON-LD can very well be a string, an object, or an array of string, or an array of object, which to be honest is really painful to deal with properly in the code because it means you always have to check what kind of data you have...

So here I was expecting mentions to be an array, but if you only have one, it's valid to simply have the object with the @id there directly. My previous comment about the author was also the same, if you have multiple authors, it can become an array.

I guess I'll have to change a bunch of code to accomodate for all these cases.... :/

[FlorianRhiem]

Yes, it's not the most convenient part of the format for sure, when it comes to parsing. After reading the part of the spec about ro-crate-metadata.json being in compressed form with single-item arrays being being unpacked, I had to do the same. Both implemented a function for doing the unpacking, because I build stuff like mentions and tags as arrays internally when exporting, and added some checks to the import part of SampleDB to handle those unpacked arrays. I hadn't known that before and simply used arrays for all things with (possibly) multiple values, such as variableMeasured or author.

[NicolasCARPi]

Interestingly there is this in the RO Crate spec:

To simplify processing and avoid confusion with string values, the RO-Crate JSON-LD Context requires URIs and entity references to be given in the form "author": {"@id": "http://example.com/alice"}, even where Schema.org for some properties otherwise permit shorter forms like "author": "http://example.com/alice".

(source)

So I guess for all attributes where the value is not "text" but an object with properties, we can expect an object OR an array of objects.

After reading the part of the spec about ro-crate-metadata.json being in compressed form with single-item arrays being being unpacked

Talking about this part? (source)

Multiple values and references can be represented using JSON arrays, as exemplified in hasPart above; however as the RO-Crate JSON-LD is in compacted form, any single-element arrays like "author": [{"@id": "#alice"}] SHOULD be unpacked to a single value like "author": {"@id": "#alice"}.

It's important to see that it is a SHOULD. Therefore, I think it's perfectly fine to always use an array, even if there is only one Author for instance, in order to make our code leaner. But we should support reading the array and not array form. But we don't need to support the string form, as we can always expect to find at least an object with an @id in there.