RFC: Representing an intermediate level between the institutions and DiSSCo ERIC in DiSSCover and in FDO

[wouteraddink]

A new Request for Comments (RFC) to propose a shift from a flat, many-to-one relationship between DiSSCo ERIC and individual institutions toward a hierarchical model: DiSSCo ERIC relates to intermediate nodes (hereafter “intermediates”), which in turn relate to one or more institutions.

The RFC google doc can be found here .

Please submit your comments as github issues by 2026-08-25.

[sharifX]

@Maxime-Griveau @wouteraddink

Why not use the existing openDS Organisation FDO schema?

We already have organisationName, organisationIdentifier, and organisationIdentifierType there. We also have the Agent object, which already supports @type: schema:Organization and ods:hasRoles. Why not add the organisation's role and type as metadata there, instead inside the Digital Specimen record?

Something like this:

"ods:hasRelatedPID": [
  {
    "ods:ID": "https://hdl.handle.net/20.5000.1025/ABC-123-XYZ",
    "ods:relationshipType": "ods:hasIntermediate"
  }
]

or:

"ods:hasRelatedOrganisation": [
  {
    "ods:ID": "https://hdl.handle.net/20.5000.1025/ABC-123-XYZ",
    "ods:organisationRole": "intermediate"
  },
  {
    "ods:ID": "ror/université-de-lille-org-pid>",
    "ods:organisationRole": "holding-institution"
  }
]

or reusing the existing Agent object directly:

{
  "@id": "https://ror.org/0XXXXXXXX",
  "@type": "schema:Organization",
  "schema:identifier": "https://ror.org/0XXXXXXXX",
  "schema:name": "Récolnat",
  "ods:hasRoles": [
    {
      "@type": "schema:Role",
      "schema:roleName": "intermediate",
      "schema:startDate": "2019-01-01T00:00:00.000Z"
    }
  ]
}

I would also recommend to check how are others handling this.

See, for example, the ENVRI service-provider metadata: the same organisation can be schema:provider in a service context and dct:publisher in a dataset context. Here role is determined by which predicate is used, not stored as a separate attribute on the org.

Healthcare standards point the same way. FHIR aligns with W3C PROV: Provenance.agent, Provenance.agent.type, Provenance.agent.role, and even Provenance.agent.onBehalfOf ([build.fhir.org/provenance.html](https://build.fhir.org/provenance.html)). On the organisation side, FHIR's Organization.partOf handles hierarchical relationships separately from role.

CIDOC CRM is also agent and action based: P14 carried_out_by plus P14.1 in the role of attaches role to a specific participation in an activity. There's also a Group class, a subclass of Actor cidoc-crm.org/html/cidoc_crm_v7.1.3.html#E74.

Europeana EDM's edm:intermediateProvider is probably the closest (https://pro.europeana.eu/page/edm-documentation) defined as:

The name or identifier of the intermediate organization that selects, collates, or curates data from a Data Provider that is then aggregated by a Provider from which Europeana harvests. The Intermediate Provider must be distinct from both the Data Provider and the Provider in the data supply chain.

Also worth consulting a few EU-level recommendations and implementations too. This is covering both governance/structure and data/metadata modelling. This is to point out we need to balance human and machine use cases here:

• The EOSC Federation Handbook zenodo.org/records/18454649 defines named terms for legal/governance roles specifically (EOSC Node Host, EOSC Node Coordinator, EOSC Resource Provider).
• Data space frameworks are another important reference point. The DSSC Blueprint's Business and Organisational Building Blocks, and IDSA's Dataspace Protocol, both work through many examples of participants and actors. DSSC's definition of Intermediaries and Operators is directly relevant here.

The main point is the same organisation might be

• national node
• aggregator
• publisher
• service provider
• annotation curator
  And we need to track these roles.

And conceptually "Intermediate" cannot be thought of a stable entity.

We are basically looking at a role in a particular workflow during a particular period. I understand the use case and the underlying issue, but the solution needs to align with the existing FDO models given that DiSSCo is already modelling distinct roles and actions. We need to keep track of the actions that are happening at specimen level, service level, and dataset level.