I'm trying to create a JSON schema for the results of doing statistical analysis based on disparate pieces of data.

The current schema I have looks something like this:

    {
        // Basic key information.
        video : "http://www.youtube.com/watch?v=7uwfjpfK0jo",
        start : "00:00:00",
        end : null,

        // For results of analysis, to be populated:
        // *** This is where it gets interesting ***
        analysis : {
            game : {
                value: "Super Street Fighter 4: Arcade Editon Ver. 2012",
                confidence: 0.9725
            }
            teams : [
                {
                    player : {
                        value : "Desk",
                        confidence: 0.95,
                    }
                    characters : [
                        {
                            value : "Hakan",
                            confidence: 0.80
                        }
                    ]
                }
            ]
        }
    }

The issue is the tuples that are used to store a value and the confidence related to that value (i.e. `{ value : "some value", confidence : 0.85 }`), populated after the results of the analysis.

There is something about the JSON being structured this way that has a smell/feels very unwieldy, perhaps due to the nature of JSON.

In .NET (in which I'll be using to work with this data), I'd have a little helper like this:

    public class UnknownValue<T>
    {     
        T Value { get; set; }
        double? Confidence { get; set; }
    }

Which I'd then use like so:

    public class Character 
    {
        public UnknownValue<Character> Name { get; set; }
    }

While the same as the JSON representation, it doesn't have the same smell to me.

Is there a more formalized/cleaner/best practice way of representing these type of tuples (really scalars with a second value attached to it all the time) in JSON, or is the approach above an accepted approach for the type of data I'm trying to store?

Note, I'm this is being represented in JSON because this will ultimately go in a document database (something like [RavenDB][1] or [elasticsearch][2]).  I'm *not* concerned about being able to serialize into the object above, because I can always use [data transfer objects][3] to facilitate getting data into/out of my underlying data store.


  [1]: http://ravendb.net/
  [2]: http://www.elasticsearch.org/
  [3]: http://en.wikipedia.org/wiki/Data_transfer_object