[Enhancement]: Handling data sources that might not want specific attribution

[jmergy]

Summary

in a demo was asked about this this week. Basically, data is tagged and Exchange shows the source info from PDC Framework data sources, funder, opportunity so that might not be wanted by the data source

Problem / Opportunity

Might eventually be a more significant ask later but I think we can handle it with the tools we have now.

Proposed solution

Solution, if it arises from a PDC contributor, is to look to setting up the funder, source, and opportunity values in PDC to not be specific or name specific entities. If this comes up, it's a workaround for now. No tech/dev needed to handle this now, but logging if this gets more serious later.

Acceptance criteria

No response

Priority

Low

[bickelj]

@jmergy To make sure I understand, are you saying that too much data are shown from, for example, GET /proposals/{id}? Like this example (dummy/demo data):

{
  "id": 756,
  "versions": [
    {
      "id": 939,
      "source": {
        "id": 6,
        "label": "Imaginary Funder",
        "funder": {
          "name": "Imaginary Funder",
          "createdAt": "2024-12-04T20:27:22.861224+00:00",
          "shortCode": "imaginary_funder",
          "isCollaborative": false,
          "keycloakOrganizationId": null
        },
        "createdAt": "2024-12-04T20:28:04.443882+00:00",
        "funderShortCode": "imaginary_funder"
      },
      "version": 1,
      "sourceId": 6,
      "createdAt": "2024-12-04T20:34:48.558845+00:00",
      "createdBy": "[redacted]",

I imagine we may not want the following here:

1. The source object with all its attributes (sourceId could be sufficient).
2. The createdBy value.

Is that the issue?

[jmergy]

@jmergy To make sure I understand, are you saying that too much data are shown from, for example, GET /proposals/{id}? Like this example (dummy/demo data):

{
"id": 756,
"versions": [
{
"id": 939,
"source": {
"id": 6,
"label": "Imaginary Funder",
"funder": {
"name": "Imaginary Funder",
"createdAt": "2024-12-04T20:27:22.861224+00:00",
"shortCode": "imaginary_funder",
"isCollaborative": false,
"keycloakOrganizationId": null
},
"createdAt": "2024-12-04T20:28:04.443882+00:00",
"funderShortCode": "imaginary_funder"
},
"version": 1,
"sourceId": 6,
"createdAt": "2024-12-04T20:34:48.558845+00:00",
"createdBy": "[redacted]",
I imagine we may not want the following here:

1. The source object with all its attributes (sourceId could be sufficient).
2. The createdBy value.

Is that the issue?

Thanks @bickelj - I think we keep all we have for now. I just wanted to note it. It doesn't feel like an enhancement we would want to pursue yet. If we did have a pdc contributer that signed the DUA, and got provisioned, etc. but for some reason wanted to inhibit discovery of the standard source/provenance like the above, we would have to look at that from a policy standpoint. If we felt it was something okay to do, then we probably would just do a generic entry for the source and funder that would essentially mask things in naming.

Again, not sure it will come up, but if it does, I would go the above route for now. If this arises and gets more traction at some point, which I don't think it will, then we can see possibly how to enhance Framework to better address the user story or use case. I don't want to go there now.

[slifty]

It strikes me that using the systemSource would be appropriate for this use case (e.g. the most granular provenance of the data is the PDC itself)