New property requiredResources

[peterdesmet]

When extending a data package profile (like we do for Camtrap DP) it is quite cumbersome to specify required resources. E.g. how to express a data package is only valid if one of the following combinations of resources is present (real use case described here):

• foo and bar (and any other resource not named foo, bar, baz)
• foo and baz (and any other resource not named foo, bar, baz)
• foo, bar and baz (and any other resource not named foo, bar, baz)

Checking that certain resources are present is a common use case, so I asked on Slack.

@roll answered:

Yea not sure how express this in JSONSchema -- it might required an additional validation logic in python

It seems it might require a new Data Package feature like: requiredResource: [name1, name2, etc] while the presence of this property might be enforced in the profile via JSONSchema

Me (@peterdesmet):

Oh, that would be great! Even better would be supporting combinations of requirements, rather than a simple enum. Cf. gbif/ipt#1953 (comment)
🤔 Combinations could maybe also expressed at a higher level:

"oneOf": [
  {
    "requiredResources": ["foo", "bar"]
  },
  {
    "requiredResources: ["foo", "baz"],
  }
]

Something to explore, but it would definitely be very useful!

@roll:

Yea something to think. It's weird that no one thought about it before as package completeness is quite important

[roll]

@peterdesmet
Great news! We can do it using vanilla JSONSchema:

https://json-schema.org/understanding-json-schema/reference/array

resources:
  type: array
  items: false
  prefixItems: # Another option is using "contains"
    - type: object
      properties:
        name: string
        enum: [foo]
    - type: object
      properties:
        name: string
        enum: [bar]

Then, by combining anyOf, etc., we can achieve any desired logic.

---

I think that's really great so we don't need to create new entities and complicate implementations. I'm closing let me know if it does not work

[roll]

It's also really good because last day I've been thinking about all this stuff regarding profiles/etc we discussed on the call. And I'm getting closer and closer to the model when we can completely rely only on JSON Schema basically for everything on the mete-meta level

[peterdesmet]

Nice and thanks for investigating! Good that we can rely on vanilla JSONSchema. I think it would be very useful though, if such tips make it to the documentation as examples, so others don't have to dive into GitHub issues.

[roll]

Currently, I think that we might have an Extensions specification that might handle everything related to extending the specifications. Also, this guide is also planned - http://datapackage.org/guides/extending-data-package/