On linked data surveys, rewards and data ownership

Joep Meindertsma, 19 Aug 2021

In this article, we’ll discuss how linked data can make surveys more easy to manage, increase response rates using rewards, create new benefits for users and more.

Why we need Survey interoperability

Surveys are a pretty interesting and complex type of data model. You can think of a Survey as describing three concepts at once:

  1. a data schema / model (datatypes, required fields, etc.)
  2. a UI (the questions show to the user)
  3. and a customer journey (the sequence of questions, sometimes with conditional paths).

Due to this complexity, it should not be a big surprise that there are many approaches to creating a Survey, and this has contributed to the low degree of interoperability of surveys.

That’s a shame, because having interoperable Surveys would be really cool!

Achieving these last two steps requires a high degree of standardization in both the surveys and the responses. The survey and its questions should provide information about:

Making surveys interoperable

A good place to start standardizing, is to use links everywhere. Use links for Properties, use links as identifiers for Surveys, for Responses, for Questions… Links are great, because they can be opened. Read my article on Linked Data if this is new to you.

Okay, so we standardize the Questions, Surveys and Responses using links. But which links? And how? At Ontola, we’ve been building dynamic RDF based forms for our Argu.co e-democracy application. We started out by using the W3C SHACL specification, which is a linked data standard for describing data models. It turned out to be a great first step, as it ticked the first box of concepts in surveys: it describes the schema. But we still have two concepts left to define: the UI and the Journey. For example, the SHACL spec does not provide UI concepts for describing whether to use a radio select or a dropdown, or how to render a helper text. And the Journey should include conditional paths, which is also not possible. These conditions are also important when the rights of a user determines whether that user can edit a certain field. We could either calculate all the form fields dynamically, or we could let the front-end use conditional fields to determine which fields are shown. We opted for the latter, as this resulted in better performance.

So we’re currently working on a Form ontology which adds things like Pages, Groups, helper text and Conditions. As this is still prone to changes and under-specified, we’d rather not share it in its current form, but we do aim to do this in the near future. An open-source implementation of our Survey software can be found on Gitlab.

Rewarding responses

Filling in a survey isn’t the most fun thing to do, so getting people to fill in a survey can be a challenge. That’s why it’s pretty common these days to see surveys that promise a chance to win rewards like nice gadgets (iPads, mostly) or coupons. The first problem with this approach is that the one filling in the survey doesn’t have a clear estimate of what their chances of winning are, which makes the deal a bit less attractive. The second problem is that it requires the respondent to provide privacy sensitive details, such as address. A third problem is that not everybody wants an iPad - money is often a bit more attractive. Ideally, we’d provide a clear and transparent reward, and do so in an anonymous fashion.

A couple of months ago, we discovered the Grant for the Web, a grant that aims to change how we do payments on the internet. We submitted a proposal to implement a solution for the problems stated above: we wanted to build a service that sends a payment to people who completed a survey. Because we wanted to provide a high degree of privacy, we wanted our own services to be completely unaware of the payment address of the receiver. We also wanted to make this project re-usable for other usages (other survey tools, or totally different things). We therefore up building an open source service, called cashlink. It works like this:

In conclusion

« Tutorial: Building a React front-end app with RDF Data, powered by Link and Solid Designing a UI for a Personal Online Datastore »