HTTP REST CORS API ecosystems with JSON serialization

[jonasalmeida]

Creator Name: Jonas Almeida, PhD, NCI/DCEG Senior Investigator and Data Science Director Creator Affiliation: National Cancer Institue (NIH/NCI), Division of Cancer Epidemiology and Genetics (DCEG)

Requirement(s)

• Full programmatic web interoperability with web-stack client-side privacy-preserving orchestration. This requirement is now widely supported by data.gov and also by numerous federal and state data resources relying on socrata infrastructure. It is however still not supported by many others, typically tied to in-house data platforms under the justification of support for specialized semantic annotation. The FAIR argument for requiring consumer-facing syntactic interoperability first is detailed in our recent paper https://pubmed.ncbi.nlm.nih.gov/36804665 ("Moving towards FAIR practices in epidemiological research").*

Summarize the requirement(s) and related aspects that the DCAT-US profile should fulfill, optionally including priorities for each requirement. This can be written in a few sentences or with bullets.

Our epidemiology research work has benefited tremendously from access to (near) real-time data from sources where semantics may change over time but JSON serialized syntactic interoperability remains constant, two examples

Example 1: Tracking causes of mortality during COVID-19 pandemic: https://episphere.github.io/mortalitytracker (https://pubmed.ncbi.nlm.nih.gov/33135727)

Example 2: exploring breath of medical information in millions of public discharge reports served by the New York dept of Health: https://mathbiol.github.io/#load%20sparcs (https://pubmed.ncbi.nlm.nih.gov/30671301/)

Problem Statement

• The two secondary data uses of federal and state data systems above span a period of a decade, exemplifying the benefits of giving precedence to syntactic interoperability even in scenarios where semantic interoperability was not a primary concern. In both cases variable names and definitions changed over time: real-time data wrangling (as part of the data retrieval process) is a practical and effective solution, as exemplified by openHealth in-browser constructs: https://pubmed.ncbi.nlm.nih.gov/26958160. In summary, this requirement proposes a data-first solution from the moment data is available. QAQC issues are better identified, and solved, by the stakeholders consuming the data. It is proposed that reliance on consumer-facing infrastructure like Socrata become the norm - specialized solutions giving primacy to semantic consistency can still be pursued after the near real-time data source is in place.*

[fellahst]

Jonas,

I want to express my gratitude for your valuable inputs regarding this project. After carefully reviewing your requirement request, I find myself faced with a challenge in fully understanding the specific requirements for the DCAT-US profile. It is important to note that the primary purpose of the DCAT-US profile is to promote semantic interoperability in describing assets such as datasets and services and facilitate their discoveries. This profile is independent of the actual implementation of services and APIs, as its main focus is on outlining how to access these assets. In order to better assist you, I kindly request clarification regarding the specific information or requirements you would like to be addressed within the DCAT-US profile. I am eager to learn more about your needs and optimistic that we can effectively address them.