Different formats for Tabular Data

The Data

If we put the data in a table, like a spreadsheet or an HTML table, it looks like this:

Type of Experience	Little or No Experience	Some Experience	Very Familiar
Writing software in any programming language	1	5	4
Frontend Web Development	4	3	3
Server-side (“backend”) Web Development	4	4	2
Using Git to track changes and share code (add, commit, push, pull)	2	5	3

CSV

If we represent the data as CSV (comma separated values), it will look like this:

Type of Experience,Little/No Experience,Some Experience,Very Familiar
Writing software in any programming language,1,5,4
Frontend Web Development,4,3,3
Server-side (“backend”) Web Development,4,4,2
"Using Git to track changes and share code (add, commit, push, pull)",2,5,3

Note that in order to accommodate commas within the values of the "Type of Experience" column, we put those values in quotes.

JSON

JSON gives us a bit more structure. A JSON object is a set of properties and values. Properties and values in a JSON object is an example of the more general pattern of key/value pairs. This concept of keys and values is an important concept when you're creating, manipulating, or exchanging data.

JSON (one object per line):

{"Type of Experience":"Writing software in any programming language","Little/No Experience":1,"Some Experience":5,"Very Familiar":4}
{"Type of Experience":"Frontend Web Development","Little/No Experience":4,"Some Experience":3,"Very Familiar":3}
{"Type of Experience":"Server-side (\“backend\”) Web Development","Little/No Experience":4,"Some Experience":4,"Very Familiar":2}
{"Type of Experience":"Using Git to track changes and share code (add, commit, push, pull)","Little/No Experience":2,"Some Experience":5,"Very Familiar":3}

One JSON object (with line breaks for readability):

{
  "Type of Experience":"Using Git to track changes and share code (add, commit, push, pull)",
  "Little/No Experience":2,
  "Some Experience":5,
  "Very Familiar":3
}

Side topic: Headings as Properties in JSON

Note that the headings from the top of our table are repeated within every JSON object. One drawback of this is that it requires us to update all of the objects whenever we change one of the headings. One option for avoiding this, which has both strengths and drawbacks, would be to store the headings separately. For example, you could use column numbers or simply generate a unique identifier for each property/heading.

JSON with column numbers instead of Values from Header Row:

{
  "col1":"Using Git to track changes and share code (add, commit, push, pull)",
  "col2":2,
  "col3":5,
  "col4":3
}

JSON with unique hashes to identify each property/key:

{
  "87e9bd6":"Using Git to track changes and share code (add, commit, push, pull)",
  "b282c1f":2,
  "35844d9":5,
  "9cb5a83":3
}

Both of these approaches would require you to store the headings somewhere, so you can match heading labels to properties in the data. For example, you could store a list of property ids and labels:

[
  {"property id":"87e9bd6", "label":"Type of Experience"},
  {"property id":"b282c1f", "label":"Little/No Experience"},
  {"property id":"35844d9", "label":"Some Experience"},
  {"property id":"9cb5a83", "label":"Very Familiar"}
]