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.

[samleeflang]

The above discussion requires a lot of data model changes. At the moment we don't make use of the Agent object for organisations. We foresaw the use case, so we made room, but this approach didn't align with the TDWG/DwC way to fit the organization. That is why we have specific fields for the organisation at the top level: ods:organisationName, ods:organisationID, ods:organisationCode. We could evaluate this, but I prefer to do that when we do a bigger openDS upgrade which we have plannend for next year.

If we take the current approach, we would need to make these additional changes:

Update of openDS Digital Specimen FDO Type

Add three new fields to the openDS model (which will create a new version 0.5.0)

• ods:intermediaryID
• ods:intermediaryCode
• ods:intermediaryName
  We will model the harmonisation rules after the organisation where for the ods:intermediaryID we will only accept an RoR or a WikiData identifier. Based on this identifier, we collect the name. This ensures that all datasets from the same intermediary will receive the same identifier and the same name.

Update of FDO Profile for the Digital Specimen

To ensure the intermediary will be available for the citation, we will need to add the field to the FDO Type (so it is available in the DOI Record). For this we need two additional fields:

• intermediaryHost
• intermediaryHostName
  We will again use the RoR or WikiData identifier in the intermediaryHost. For the intermediaryHostName we will use the name available in RoR or WikiData. This will create a new 1.1.0 version of the FDO Type data model.

Update DataCite record

For this we will need to map the new FDO Type properties to a DataCite property. We will need to discuss with DataCite which property would be best suited for this use case.

Update documentation

We will need to update the schema.dissco.tech and terms.dissco.tech documentation pages so they are in line with the updated version of the data models.

Translator logic

We will need to update the translator logic so that an additional entity relationship will be created for the intermediary. This ensures the relationship to the intermediary will be correctly displayed on the Specimen overview page in DiSSCover.

As there is no place currently in the DwC-A for the intermediary, we propose to set this field as a default value. This does mean that there can only be one intermediary for an entire dataset. The intermediary will then need to be provided together with the DwC-A endpoint from which DiSSCo will harvest the data.
As with all changes, we will first deploy the change on our development environment. After the feature is implemented, it will move to acceptance. On acceptance we will test with the user and see if the behavior is correct. After the user has validated the change, we will deploy it on our production environment.