First pass at a complete JSON version of the open demographics questions

[hestenet]

I've taken a first pass at putting all of the questions into a JSON schema, based on the example in /docs-source/references/example.json and the discussions in these issues:

• Long versus Short version of question options #43
• Indicating that questions should allow a self-identify box #44
• Indicating that questions should allow a "Prefer not to answer" choice  #45

I know this risks having to redo a lot of work if the standard for the format continues to evolve, but I simply found it easier to just attempt to make a go of it with what we had so far. I think this would also allows us to begin experiment with consuming the machine readable version and identify any additional issues with the data model.

For the most part I think things worked very well! I have opened a couple of new issues based on doing this exercise:

• Questions with multi-part answers (e.g: language and fluency) #46
• Populating response values from other sources when consuming the machine readable version #47

I hope this is helpful.

[hestenet]

@sparklingrobots - I'd be curious to know if you find this useful for the gender module

[drnikko]

Hi! I didn't see an email for this come through so I'm sorry about the delay, but will take a look this weekend. Thanks so much for doing this!!

[hestenet]

No problem! Let me know if you see anything that needs tweaking.

[hestenet]

Just wanted to ping a reminder about this pull request. Dhanya on our team is about to open a new project to start a Drupal module that can consume the JSON feed.

Is it looking like this can be merged?

[drumm]

How should deprecation be handled? If an option or question is removed, I imagine implementors will want to know this, and either discard or archive data.

[drnikko]

I’m on vacation this week, and without a laptop. It looks like a good first pass to me but I’d like to hear from @sparklingrobots or @alexmccabe before merging.

…

On Mon, Aug 6, 2018 at 10:59 AM Neil Drumm ***@***.***> wrote: How should deprecation be handled? If an option or question is removed, I imagine implementors will want to know this, and either discard or archive data. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPj25jZ3ewukNhHfUvn8FT8QbrHL_4dks5uOIQXgaJpZM4UysOx> .

[alexmccabe]

@drnikki I'm assuming you've got the wrong Alex McCabe here, I've no idea what this is.

[sugaroverflow]

probably meant to tag @alexdmccabe 😅

[alexdmccabe]

Couple of issues:

---

I think the short description and long description seem redundant, e.g.:

    "short-description": "Age of the person.",
    "long-description": "The age bracket of the respondent.",

    "short-description": "The person's disabilities.",
    "long-description": "The disabilities a person identifies as having based on the definitions given by the ADA.",

    "short-description": "The person's education",
    "long-description": "The respondent's highest level of educational attainment.",

---

There's a null in the midst of the gender choices.

---

Use of - instead of _ for separators, e.g.:

  "category-gender": {
    "id": "gender",
    "short-description": "The person's gender identity.",
    "long-description": "The respondent's gender identification.",
    "questions": {
      "transgender-identity": {
        "type": "select-one",
        "self-identify": "false",
        "prefer-not-to-answer": "false",
        "does-not-apply": "false",

The thing that is catching me is actually the question IDs (like "transgender-identity"), because I'm trying to base column names on them, which is causing issues with MySQL. It's

MySQL [drupal]> DESCRIBE field_data_field_gender;
+-----------------------------------+------------------+------+-----+---------+-------+
| Field                             | Type             | Null | Key | Default | Extra |
+-----------------------------------+------------------+------+-----+---------+-------+
| entity_type                       | varchar(128)     | NO   | PRI |         |       |
| bundle                            | varchar(128)     | NO   | MUL |         |       |
| deleted                           | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id                         | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id                       | int(10) unsigned | YES  | MUL | NULL    |       |
| language                          | varchar(32)      | NO   | PRI |         |       |
| delta                             | int(10) unsigned | NO   | PRI | NULL    |       |
| field_gender_transgender-identity | varchar(255)     | NO   |     | NULL    |       |
| field_gender_gender-diversity     | varchar(255)     | NO   |     | NULL    |       |
| field_gender_intersex             | varchar(255)     | NO   |     | NULL    |       |
| field_gender_gender-spectrum      | text             | NO   |     | NULL    |       |
+-----------------------------------+------------------+------+-----+---------+-------+

vs

MySQL [drupal]> DESCRIBE field_data_field_gender;
+-----------------------------------+------------------+------+-----+---------+-------+
| Field                             | Type             | Null | Key | Default | Extra |
+-----------------------------------+------------------+------+-----+---------+-------+
| entity_type                       | varchar(128)     | NO   | PRI |         |       |
| bundle                            | varchar(128)     | NO   | MUL |         |       |
| deleted                           | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id                         | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id                       | int(10) unsigned | YES  | MUL | NULL    |       |
| language                          | varchar(32)      | NO   | PRI |         |       |
| delta                             | int(10) unsigned | NO   | PRI | NULL    |       |
| field_gender_transgender_identity | varchar(255)     | NO   |     | NULL    |       |
| field_gender_gender_diversity     | varchar(255)     | NO   |     | NULL    |       |
| field_gender_intersex             | varchar(255)     | NO   |     | NULL    |       |
| field_gender_gender_spectrum      | text             | NO   |     | NULL    |       |
+-----------------------------------+------------------+------+-----+---------+-------+

I don't know how you generated this JSON file, or if you did it by hand, but it would super handy to use _ instead of - for separators throughout.

---

All of that said, I can take a crack at actually making these changes. I'm not super familiar with GitHub workflow, but I think I'd be making a PR to your branch that has a PR open to Nikki's branch?

[hestenet]

I think the notion behind the short and long description was that the short could be displayed as inline help text on field display, and the long description could perhaps be hidden behind a help link to provide more context. Agree that it might be unnecessary or redundant for many use cases though.

Nice catch on the null

Agree with swapping - for _

It was just hand edited in SublimeText so a find-replace operation is probably the way to go.

---

Re: GitHub workflows, yes, I think you have to run a PR to my branch, and then we can hopefully run it through the pachinko machine back to Nikki's project.