Include isArray and arrayShape

[ccl-core]

Addresses: #649

Note that this is a bit different than the original proposal in #649 :

{
          "@type": "cr:Field",
          "@id": "recordset/fieldname",
          "isArray": true,
          "arrayShape": [
            1,
            2,
            1
          ]
       ...
}

This is a bit difficult for us to process using mlcroissant... When we create the graph from the jsonld data, we would loose the order information; moreover, as we create a triple for each element in the arrayShape, and triples need to be unique, we would loose dimensions which have the same size.

As an alternative I propose to use a @list, so we keep the order info more nicely and we don't loose data:

{
          "@type": "cr:Field",
          "@id": "recordset/fieldname",
          "isArray": true,
          "arrayShape": {
            "@list": [
              1,
              2,
              1
            ]
          },
       ...
}

WDYT?

In this PR:

• Introduces isArray and arrayShape
• Includes one example dataset (datasets/1.0/huggingface-baratilab-flow3d/metadata.json) which is a simplified version of https://huggingface.co/datasets/baratilab/Flow3D-V0-Ti-6Al-4V_fast_test (less fields, only one config) which includes the new fields.
• Updates all contexts

Still TODO: Remove repeated from all datasets and use isArray and arrayShape instead.

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

[marcenacp]

nit: references coming after source was more readable.

[marcenacp]

Should we write a test that the verifier fails if isArray is specified with no arrayShape? Or is this legit in the specs?

If there's an implicit behaviour that arrayShape defaults to (-1,), we could probably document this

[marcenacp]

After the discussion with Omar:

• isArray without arrayShape is valid, and in that case arrayShape defaults to (-1,). The documentation should specify this behaviour.
• arrayShape without isArray should make the verifier fail.

[benjelloun]

As we discussed offline, arrayShape can be represented more compactly as a string that contains space separated dimensions, e.g., "1 2 -1 3", where -1 corresponds to a dimension where the length is not specified. Even though this approach is encoding structured information in a string, it's unambiguous and easy to parse, so I think it's acceptable. We already do accept such input in other places, e.g., for bounding boxes.