Option to take checkbox/radio/selector options dynamically from document

[ianroberts]

At present the list of available options for radio, checkbox and selector input types must be specified statically as part of the project configuration. For some annotation tasks it will be necessary to make the option list more dynamic, taken from the document JSON. One example could be named entity disambiguation, where each "document" is a snippet including a named entity with several possible DBpedia URIs, and the user's task is to select the correct URI for the entity. This will be a different list of URIs for each document.

The ideal would be a mixture of the two, where some options are configured statically at the project level and some come dynamically from the document. Using the same disambiguation example, each document would supply its own list of possibilities, but we would also want to add a "don't know" option to every task. This could kind of be done with multiple inputs (a radio list of URI options and a separate "don't know" checkbox, and post-filter the output to ignore the URI selection when "don't know" is true) but it's a bit clunky.

Possible implementation idea

Add another alternative to the schema for selector options, so that as well as {"value": "...", "label": "..."} you could include something like {"fromDocument": "property.path"} that pulls data from the document and merges it into the option list. In the simplest case we would mandate that the property.path in the document must itself be something parseable by generateBVOptions (an array of {"value": "...", "label": "..."} objects, or a single object treated as a "value":"label" mapping), or we could get more creative and add configurable formats like a list of strings, single comma-separated string, etc. etc. The full featured version might be along the lines of this (inspired by the motivating use case for the GATE Crowdsourcing plugin)

Project configuration:

{
  "name": "uri",
  "type": "radio",
  "title": "Select the most appropriate URI",
  "options":[
    {"fromDocument": "candidateUris", "format": "delimited", "delimiter": ";"},
    {"value": "none", "label": "None of the above"},
    {"value": "unknown", "label": "Cannot be determined without more context"}
  ]
}

Document CSV:

text	entity	candidateUris
President Bush visited the air base yesterday...	President Bush	http://dbpedia.org/resource/George_W._Bush;http://dbpedia.org/resource/George_H._W._Bush

Result:

Select the most appropriate URI

[ ] http://dbpedia.org/resource/George_W._Bush
[ ] http://dbpedia.org/resource/George_H._W._Bush
[ ] None of the above
[ ] Cannot be determined without more context

[ianroberts]

@iknoorjobs would this cover the kind of use case you had in mind?

[iknoorjobs]

@ianroberts Yes, that's very similar to what I want to do. Here the type is radio but I actually want them as checkboxes. For eg. if something like this could work

  {
    "name": "mylabel",
    "type": "checkbox",
    "title": "Title string",
    "options": [
      {
        "format": "delimited",
        "delimiter": ";",
        "fromDocument": "candidateUris"
      }
    ],
    "optional": true,
    "valError": "Error message when the field fails validation",
    "valSuccess": "Success message when the field is validated",
    "description": "Description string",
    "minSelected": 1
  }

[ianroberts]

Yeah, all three of selector, radio and checkbox input types use the same logic to convert the options configuration into choices in the UI, so any change to this logic would flow to all three types.

[ianroberts]

Implemented in #303