Embedding an RO-Crate in an OCM share?

[glpatcern]

We are considering an extension of the OCM share gesture, to include the possibility to support so-called Research Object Crate (RO-Crate) payloads. This is for a possible integration with Data Repositories, in the context of the EOSC Data Commons project, and the RO-Crate can be seen as a kind of workflow specification.

Here I'll try and sketch how the workflow would look like and the kind of extension we'd need in terms of OCM specifications. The overall scenario is slightly different from the usual EFSS-to-EFSS setting we have in mind when dealing with OCM: the entity offering an RO-Crate as an OCM share may be a generic system that is capable of putting together the payload for dispatch to a target EFSS, which in turn can access the referenced content and "execute" the work.

Therefore, for A "sharing" an RO-Crate to B, we would have:

1. The discovery endpoint at B exposing a new ro-crate resource type such as:

...
   "resourceTypes": [
      {
         "name": "ro-crate",
         "protocols": {
            "http": "embedded",
         }
      }
   ],
...

This would signal that B is capable of accepting a share where the payload is an ro-crate, which itself essentially is a bunch of references. It would also be capable of offering such a share, but that's less relevant here.

2. The service A sending the payload embedded in the /ocm/shares call, e.g.:

{
  "shareWith": "[email protected]",
  "name": "sample ro-crate.json",
  "description": "An example data analysis",
  "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
  "owner": "[email protected]",
  "sender": "[email protected]",
  "senderDisplayName": "John Doe",
  "shareType": "user",
  "resourceType": "ro-crate",
  "expiration": 0,
  "protocol": {
    "name": "multi",
    "rocrate": {

      "@context": "https://w3id.org/ro/crate/1.1/context",
      "@graph": [
         {
...
            "hasPart": [
                {
                    "@id": "https://dockstore.org/api/ga4gh/trs/v2/tools/%23workflow%2Fgithub.com%2Flaitanawe%2Fismb2024%2Fgalaxy_example/versions/main/PLAIN_GALAXY/descriptor//Galaxy-Workflow-reverse_file_galaxy_workflow.ga"
                },
                {
                    "@id": "https://example-files.online-convert.com/document/txt/example.txt"
                }
            ]
        },
...

    },
}

Then, the server B would let the recipient choose to "accept" such a share, which would trigger the download of the referenced resource(s) and potentially the execution of some workload (e.g. a Jupyter notebook, or a Galaxy workflow, etc.).

The key difference here is that B does not access the payload from A, as anyway the ro-crate payload is pure metadata, the real data being made available at third-party locations as specified internally in the payload itself.

Now, in terms of specifications, all the above does NOT need any change to the API. But I'm using the patternProperties part, and I'm proposing here a different flow, therefore I'd appreciate some comments about the whole idea, from "this is total nonsense" to "that's a great way to include a new use-case under the OCM umbrella" and anything in between.

[glpatcern]

Noting that the patternProperties support does not seem to be valid, cf. #181.

[glpatcern]

And in fact, the patternProperties can be replaced with additionalProperties, maintaining the same principle. This is what is done in #181 and #182. With that, the proposal here would need NO change to the OCM standard and would only be a matter of "how compliant it is to use an OCM gesture with some embedding in a rather different context?"

[glpatcern]

Following discussions at the OCM meeting, this proposal makes sense, provided that the sender A - the third-party system - can itself qualify as an OCM endpoint by exposing the following (static) discovery information, noting that in #192 we have relaxed the minimum requirements for this:

{
  "enabled": true,
  "apiVersion": "1.2.0",
  "endPoint": "https://third-party-server.org",
  "resourceTypes": [
    {
      "name": "ro-crate",
      "shareTypes": [
        "user",
      ],
      "protocols": {
        "http": "embedded"
      }
    },
  ]
}

Such discovery payload would enable a receiver OCM Server "B", when checking the sender = [email protected], to validate its origin - even without a signed request in first approximation - by inspecting https://third-party-server.org/.well-known/ocm.