Hi @Billy
Absolutely no worries about late replies!
I’ve spoken to Marion at 360Giving and we’d both love to chat with you synchronously. I’ve filled out your contact form for myself and on her behalf, so feel free to wing us an email to arrange a time. Marion also has a link to book time with her directly if you prefer that way, although I’m not sure if it accounts for time zones.
Either way, Marion and I would love to chat with you about your work 
Specification
As we shift to grant awards, we’d love to borrow or adapt as much of the work that 360 Giving has already done to standardize award reporting. At a minimum we’d like to maintain a mapping between the CommonGrants model and the 360 Giving model.
The ultimate goal is to support the kind of federated linking that you’re describing, and I think this could be particularly powerful once we integrate grant opportunity data with the post-award reporting on federal grants that are currently hosted by USA spending.
This all sounds super exciting. On the topic of mapping, having a mapping between the two models is definitely worthwhile.
We also know that 360Giving is currently skewed towards UK contexts at the moment but we’re at the start of planning our first MAJOR update. As part of that I’ll be investigating ways to make it more of an international standard, and it’ll be very useful to have your insight from the US context to help us understand concepts in grantmaking at a broader level. This could lead to stronger alignment between the standards, or better opportunities for inter-standard linking between datasets.
Developer tools
Would love to learn more about what this tool looks like and how it’s implemented!
The 360Giving Data Quality Tool is available at the following link:
Under the hood, it is an instance of some software we develop at Open Data Services called “CoVE”, which stands for “Convert, Validate, and Explore”. I’d link to it here, but new users are limited to two links in posts!
CoVE uses some other tooling we built at Open Data Services called flatten-tool which supports round-tripping between JSON data and spreadsheet/flat formats given a schema. 360Giving publishers mostly publish in spreadsheet formats, since the data is often compiled by “non-technical” administrative workers. This also means we get a boost in adoption, since grantmakers don’t need to invest in developing APIs; they can just host a spreadsheet file on their website and our tooling will pick it up and convert it.
CoVE specifically solves the problem of letting people upload data and get useful feedback about it. It validates it using the JSON Schemas but massages the messages you get from the validation library into something more useful for people.
The Data Quality Tool has also developed further than being an instance of CoVE. It performs additional testing on data beyond validation, to look at issues of data quality. In the case of 360Giving this will be things such as including particular fields for specific use cases, or looking at the format of certain fields like organization identifiers to see whether they’re using org-ids. These tests pick up where the validation leaves off. Schema validation gets us valid data, but the additional testing gets us data which is more interoperable and useful.
We’re currently working on improving the output of that command to make it a bit more useful, but I’d welcome any other thoughts you have on ways of making this API-level validation more useful for potential adopters.
API validation is something I’m only just starting to grapple with myself. With my Open Data Services hat on for a second, rather than just my 360Giving hat, if you get in touch I’ll link you up with the folks at Open Referral who are also grappling with API Validation at the moment. They’re also based in the US, so I think there might be scope for collaboration and insight-sharing between you two.
Documentation
Follow-up question: Are there any other sites (in addition to 360 giving) that you feel demonstrate this separation of concerns well?
Yes! At Open Data Services we help a number of data initiatives develop and maintain data standards so we have a few examples. Again, I can’t link directly to them but I would check out:
- The Open Contracting Data Standard (OCDS) – standad [dot] open-contracting [dot] org
- The Beneficial Ownership Data Standard (BODS) – standard [dot] openownership [dot] org
In particular, the OCDS docs are quite advanced and really representative of good data standard documentation imho. 360Giving were an earlier standard so OCDS benefitted from a lot of the lessons we learned at 360Giving, and we’re about to start revisiting the structure of the docs, likely in accordance with Diátaxis: dividing docs into Reference, Tutorials, How-tos, and Explanation oriented material. I think where we’re headed with 360Giving is paring back the content on the standard docs site to be mostly reference material and putting up other material onto another site.
Adoption
Rather than become a central repository for data, we’re aiming to do three distinct but complementary things with CommonGrants:
This is a great model. 360Giving both is and isn’t a central repository for data. 360Giving’s publication model is decentralised. Publishers host their data on their own site; mostly this looks like a link to a spreadsheet file but there are one or two publishers who give us an API endpoint which produces 360Giving JSON.
We then have a registry of publications. Specifically files, as publishers may want to chop up their grants data into multiple files rather than maintain one big file. The registry has recently become “self-service” where publishers can update the links to their files and add new files etc.
We then have some (open source) tooling called the “datagetter” which fetches data from the registry to a machine, and works in tandem with flatten-tool and our validation libraries to then put valid data into a datastore. The datastore is also open source. 360Giving host the only known instance of the datastore, but in theory people can spin up their own (with an alternative registry if they want!). The datastore powers applications like GrantNav, which in practice act a centralised source of grants data because people love using it but in theory people can again spin up their own instance.
This is a bit different from a purely federated model such as you describe, but we definitely agree with a decentralised approach.
Governance
This is another area in which I’d strongly welcome your feedback. Since we’ve still only published pre-releases of our models and associated developer tools, we expect there to be some breaking changes made in the next few iterations. But I’d love to land on a sensible versioning strategy for our tools, data model, and proposed API early to provide prospective adopters with more stability and confidence in the standard.
Since 360Giving don’t actually have an API specification (for reasons outlined above), that might be out of scope for my jurisdiction for this thread but I am interested in this as well. I can put you in touch with some folks at Open Referral, who have a similar model as yourselves. They used to version these separately but as of HSDS 3.0 now version them together as part of the same specification. It might be useful to have a chat with them as to what motivated that move and the tradeoffs it brings.