User story #1 - Single source of truth

[morchickit]

As 360Giving I want the registry to be the single source of truth so we can validate against it.

[robredpath]

@morchickit what does validation look like in this context?

[morchickit]

Meaning other applications can check against it.

[robredpath]

Can you give me an example of what that might look like? I'm struggling to see how this is different from just being machine-readable

[morchickit]

How is machine readable connects to it?

This is a concept - we want one place where people know who publish to 360Giving that they can validate it against their data. All the files that are published, so if one of the files they have is not in the registry list, it means it's not a 360Giving file.

On Fri, Jun 1, 2018 at 4:15 PM, Rob Redpath notifications@github.com wrote:

Can you give me an example of what that might look like? I'm struggling to see how this is different from just being machine-readable

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ThreeSixtyGiving/registry/issues/1#issuecomment-393912193, or mute the thread https://github.com/notifications/unsubscribe-auth/ADHzuxGn6pDRiwq_08HmjOCF98jXomRhks5t4VqLgaJpZM4TvpLn .

[timgdavies]

if one of the files they have is not in the registry list, it means it's not a 360Giving file.

This is quite an important strategic discussion here - and one that needs careful consideration.

Right now, there is the '360 Giving Data Standard' and then '360 Giving' as an initiative.

It is possible (and I would argue desirable) that people can use the '360 Giving Data Standard' without their data being in a central registry.

For example, if I go through the annual reports of a set of charities as part of a research project, and list their grants into a 360 Giving template, I might want to publish that, and describe it as '360 Giving Data Standard' data, for other researchers for use. But I might not register it with 360 Giving, because I'm not the original publisher of this information.

Equally, I can envisage a future in which the '360 Giving Data Standard' format is used to exchange data between a grants application system, and a system for doing due diligence on grants, before grants are made and published.

I can also envisage cases where grant-makers in Canada adopt the '360 Giving Data Standard' to publish their data, and maintain their own register of published data.

If you say that "It's not a 360 Giving file if it's not in our registry" then that excludes these cases, narrows the utility of the standard, and creates a 'single point of failure' for access to data, which is risky for the long-term sustainability of an initiative.

However, it is also entirely understandable that '360 Giving' the initiative wants to have a 'Single Source of Truth' to answer questions like:

• Who is participating in 360 Giving (the initiative)?
• How many people are publishing valid data?
• Where can we get their data?
• Have we got the latest data from everyone? Or is there some data we need to update?

It is worth noting that this is a common challenge for many standards initiatives - and a lot of this is a question of designing both communications, and institutions (e.g. can we be confident we can maintain registry for foreseeable future, and scale to meet demand*).

One response is to try and separate the language of the standard, from the initiative. For example:

• Grants Data Standard - you are providing a Grants Data Standard file if it validates against the schema)
• 360 Giving file - you are providing a 360 Giving File if you have registered it in the 360 Giving registry

or

• 360 Giving Data file - you are providing a 360 Giving Data file if it validates against the schema
• Greater Grants Data list - you are part of the 'Greater Grants Data' movement if you have given us details of your files for our list. Only files on the list are part of 'Greater Grants Data'

(Note, these are examples only, would need more word-smithing in full).

It might also help here to think of this issue as about Central registry of all published data - rather than Single Source of Truth, as I think the concept of an SSOT is better reserved for us talking about schemas, than talking about the publication of open data, where ultimately with data on the web, we should start from the assumption that AAA (Anyone can say Anything about Anything), and set our ambition at the level of curating a particular, coherent, view onto that, rather than an SSOT.

[* For example, in the case of OCDS, we looked at the experiences of GTFS, the transit spec applied in 100s of cities around the world, and noted that there is not single central registry of data feeds, and that instead various community and market players maintain lists. We felt the potential universe of publishers of contracting data was so large (cities, countries, individual companies etc.) that we could not hope to keep a single central list up to date. By contrast, in IATI there is a reasonably clearly defined community of publishers, and a strong demand for a 'single dataaset' across them all, and the institutional resources and contractual relationships to have the potential to maintain the registry. I think 360 Giving is somewhere between these two cases: not too large a universe of possible publishers, but weaker incentives to get people to maintain the information in registry. ]