Subjectivity, Veracity and Truth
SwiftRiver is constructed from the viewpoint that there are no absolute truths and that what is considered to be factual by most is still highly subjective or biased depending upon context.
Thus, we build tools which allow users to curate their own depiction of a perspective. In the same way that there are more than one newspaper, more than one political party in most countries, more than one religion, even more than one ‘official’ source for occurrences like earthquakes or climate change. We build tools that enable people to convey their confidence in datasets. This in no way implies that data is unbiased.
Swift apps add many layers of context to data as meta-data for making processing data faster, which in turn give our own systems more ammowith which to attempt to understand and auto-mate it’s processing.
What does veracity mean?
Veracity is simply the term we use to represent the baseline of trust that our users have conveyed about content, sources and events. This baseline allows us to do things like recommend related content that is likely be relevant to their view; or in the case of an organization, the collective view.
A number of factors go into creating this profile: how content is organized, how it’s interacted with, how people have behaved in the past, how certain communities feel about it’s members and vice-versa, calculations for real-world phenomena like time and location of an event and so on.
When it comes to verifying data, our tools serve two purposes.
- For a public-facing deployment of our apps (including Ushahidi), we offer tools that allow the user to make a case to the public about a particular view. For example, these are the people in the crowd whom they trust, and what those people had to say about an event.
- For a non-public facing deployment, some of our apps (like Sweeper) can be used to structure data, conditionally filter and view it. This is useful for setting up automated workflows like ‘pass only approved content, taged with location and these tags, and pass that data over to Ushahdi or some other application’.
In both cases the users, the people behind the deployment, are creating their unique baseline for trust, and therefore are putting forth what they consider to be accurate, or favored, content.
Isn’t this bias?
Yes. Any system operated by a human, and I would go further to say machine created by a human, is subject to some sort of bias.
What does it mean to verify data
In the context of most Ushahidi applications ‘verified’ means corroborated or confirmed by a human. This means on the receiving end, the person ‘verifying’ the data is essentially saying “I’m taking the onus to approve this report because something, or someone, has indicated that this is true.”
Does that mean untrue information can be ‘verified’ either intentionally or accidentally? Yes. All of the terms are highly subjective and people have a number of preconceptions about what these things mean. They are mere abstractions that represent user behavior and intended use.
Verification Levels
It is a mistake to assume that because something is ‘verified’ or has a high veracity score, that it is a fact. What these indications are actually telling viewers and/or the deployer is that this is the baseline for accuracy set forth by an editing body (the deployer). Even verifying reports multiple times by independent participants will not account for human bias or fallibility.
The numbers are there because they are an additional layer of context (readable by machines and humans) allowing the deployer(s) to curate information based on the trust profile they’ve set forth through their interactions.
Likewise, viewing the same data geo-spatially simply implies that this is one community’s understanding of the collected data and what they perceive it to represent. It’s simply a faster way to view data to build up a baseline of ‘favor’ and then use the scores to filter out the content is less likely to fit that profile.
- Jon Gosier, Director of Product
