The Frictionless Data Community Call was held on 28 August 2026 at 16:00 CEST, bringing together maintainers, contributors and new community members for an update on the ongoing Data Package version 2 migration and a look ahead to upcoming community outputs.
Welcome and Introductions
The call opened with a round of introductions. Letícia Coelho, Special Projects Coordinator at the Open Knowledge Foundation, welcomed everyone and introduced herself in her first Frictionless community call.
Peter Desmet, based in Belgium at the Research Institute for Nature and Forest (INBO), introduced his work publishing biodiversity data and maintaining several R packages that support researchers working with it. He is also involved in standards development within Biodiversity Information Standards, where he maintains Camtrap DP, a camera trap data standard built on Data Package, and is helping the Global Biodiversity Information Facility move toward supporting Data Packages as an input format.
Pierre Camilleri, associate at the French cooperative multi.coop, works on computer science projects for public-sector clients, including France’s open data platform, data.gov.fr. That work is what first brought him to Frictionless Python, which the platform uses for data validation, and he has since become a maintainer of the library.
Keith Hughitt, who works at a small AI and healthcare startup, said his interest in Frictionless goes back several years and is rooted in open knowledge and reproducible research, both at scale and in his own personal projects.
Phil Schumm, at the University of Chicago, described his role as Director of Statistics and Statistical Computing at the Center for Translational Data Science, where his team builds data-sharing platforms largely for NIH-funded efforts. He has been incorporating Frictionless standards into that stack and is keen to see it adopted more broadly across the biomedical community.
Peter Murray Rust, a long-time member of the Open Knowledge community since its early days with Rufus Pollock, joined to learn more about the current state of the project. He is also involved with #semanticClimate, a volunteer initiative extracting content from public literature, and is interested in exploring the idea of “frictionless documents.”
Renata Ávila, thanked the group for the ongoing work.
Technical Updates: Data Package Version 2 Support
The bulk of the call was dedicated to progress updates on the NLnet-funded work to bring Data Package version 2 support to the core Frictionless libraries.
frictionless-r. Peter Desmet reported on the R package, which he started in 2022 to bring Data Packages to the life sciences and biology communities that rely heavily on R. The package focuses on reading tabular data defined as a Data Package and building packages from scratch, and several other R packages already depend on it for that functionality. As part of the NLnet-funded work, the team released frictionless-r 1.3.0, closing 39 issues and giving users who need to stay on Data Package v1 a stable version to rely on.
Work has since moved to the upcoming, breaking 2.0 release, which removes the blocker that prevented the package from reading v2 datasets and adds support for several v2 changes: hidden paths, relaxed resource naming, labelled missing values, optional date-time milliseconds, and (via an open pull request) groupChar for integers. Field matching, one of the larger new features in v2, will not make it into this first release. A central design question was backwards compatibility: the team settled on having every function return packages, resources and schemas in the version they were provided in, so reading and writing a v1 package keeps it as v1, and the same for v2. Only the functions that create new packages, resources or schemas — such as create_package or create_schema — follow the v2 specification by default, which can result in mixed-version packages. A separate upgrade function, close to completion, will let users explicitly convert a package from v1 to v2. The 2.0 development version has resolved 31 of 43 issues and is already installable from GitHub for testing . Remaining steps include finishing tests, publishing a release candidate, and writing a blog post once the release is ready, alongside warning maintainers of dependent R packages about the coming breaking change.
Peter also reflected on how difficult it has proven to update software to match a changing specification, and suggested that the Data Package spec itself should now stay as stable as possible rather than accumulate further changes. He raised an open question for the other maintainers: when a package declares itself as v2 via $schema but its resources don’t declare a version, how should those resources be interpreted? Pierre confirmed that frictionless-py currently avoids the ambiguity altogether by requiring a package to be entirely v1 or entirely v2, forbidding v1 resources inside a v2 package.
Renata suggested that this reflection on versioning and specification stability is valuable enough to be written up as a separate blog post, since it could offer guidance not only for Frictionless but for other standards-development projects more broadly.
frictionless-py. Pierre Camilleri walked the group through progress on the Python package. Implementing $schemasupport turned out to be harder than expected, largely because of the need to build reliable heuristics for distinguishing v1 from v2 descriptors — straightforward when a $schema URL points to the standard Data Package profile, less so for custom profiles. Significant refactoring — including a new Header class to properly compare data labels against schema fields — laid the groundwork for the fields match property, an evolution of the “schema sync” option that previously existed outside the spec and has now been formally adopted into it. Pierre demonstrated the three fields-match modes (partial, superset and subset) live on the call, showing how each changes what counts as valid when a dataset’s columns don’t line up exactly with its schema. This work, along with a new categories field type, is available in a first release candidate, version 5.20.0, expected to ship the following week after fixing a few issues Peter had flagged during testing.
Pierre also spoke about his approach to breaking changes: he has largely avoided them so far, making exceptions only for internal, undocumented and untested behaviour, and floated the idea of bundling small, well-scoped breaking changes into an annual major release rather than introducing them piecemeal. He asked the group how much they rely on frictionless-py’s internal classes versus its core reading and validation features, since that shapes what should be considered a breaking change going forward.
The conversation that followed touched on several open design questions — how to handle schemas with more fields than the data actually contains, how foreign keys should be validated across v1 and v2, and whether $schema-based JSON Schema validation should complement the library’s current Python-based validation. Both maintainers agreed that a lightweight, standalone validator — potentially built on a shared Rust core — remains an attractive long-term goal, echoing a similar proposal submitted for a Frictionless Science project two years ago, though neither expects it to happen soon given how spread out validation logic currently is across frictionless-py.
Phil Schumm added that his team relies heavily on frictionless-py’s transformation utilities, and while he’s comfortable adapting if those are eventually refactored or deprecated, he’d welcome advance notice. He also raised a separate, longer-running effort: bringing Frictionless support to Stata, a language widely used across the social sciences and increasingly in biomedical research. Since no v1 Stata tooling exists yet, he can build directly for v2, and is leaning toward wrapping frictionless-py via Stata’s Python bindings rather than reimplementing validation from scratch, both to move faster and to keep behaviour consistent with the Python (and ideally R) packages. Peter and Pierre both encouraged this approach, agreeing that reimplementing validation logic in a new language is a heavy, long-term maintenance commitment better avoided while frictionless-py’s public API remains stable and reliable to build on.
Any Other Business
Letícia asked participants to contribute to the script for the upcoming Frictionless explainer video.
Renata proposed that the community start compiling a shortlist of the top three most urgent or useful things needed for Frictionless, with rough budget estimates attached, to help plan and justify funding requests — including NLnet’s 2027 budget — for both maintenance and higher-impact features that could grow adoption of Data Package and the wider Frictionless toolset. Given the scope of that conversation, she suggested dedicating the first 15 minutes of the next call to it. She closed by thanking Peter and Pierre for their sustained work on the version 2 migration, and offered OKFN’s support with the upcoming blog post, community outreach for testers, and a mention in next week’s newsletter.
The call closed with thanks all around and an invitation to keep the conversation going on Slack ahead of the next community call.
Funding
This project was funded through NGI0 Entrust, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet program. Learn more at the NLnet project page.
