Representar cantidades físicas en JSON: valor, unidad y precisión como campos separados

Objetivo

Intercambiar cantidades medidas o calculadas en JSON de modo que quien consume pueda saber el número, la unidad y cuánto del número es significativo sin adivinarlo a partir del nombre de un campo.

Requisitos previos

Una lista de los tipos de cantidad que transporta la interfaz (longitud, masa, duración, temperatura; el dinero se trata por separado), una decisión sobre un vocabulario de unidades, y un acuerdo sobre si cada campo es de unidad fija (todos los productores usan la misma unidad) o de unidad mixta (el productor elige).

Pasos

1. Para cada tipo de cantidad, elegir una unidad canónica para almacenamiento y cálculo, preferiblemente la unidad SI o una unidad derivada coherente (metros, kilogramos, segundos), y convertir en el límite.
2. Campos de unidad fija: poner la unidad en el nombre del campo (duration_ms, distance_m) y usar un número JSON simple. Esto es compacto y difícil de interpretar mal.
3. Campos de unidad mixta (valores introducidos por el usuario, instrumentos con sus propias unidades): usar un objeto {"value": 12.5, "unit": "kg"} con unit tomado de un vocabulario controlado. UCUM (citado) proporciona códigos de unidad legibles por máquina en ASCII; define símbolos sensibles a mayúsculas (kg, Cel, [in_i]) y una variante separada insensible a mayúsculas, así que hay que indicar qué variante usa la interfaz.
4. Transportar la precisión de forma explícita cuando importe: un campo uncertainty o resolution separado, no ceros finales. RFC 7946 (citada) establece esta regla para las coordenadas, indicando que el número de dígitos no debe interpretarse como una indicación de incertidumbre; los analizadores no preservan el número de dígitos, así que la regla vale para cualquier cantidad.
5. Usar una cadena que contenga una representación decimal cuando importe el valor decimal exacto (una lectura copiada de una pantalla, un límite regulatorio); usar números JSON para valores que son aproximados por naturaleza.
6. Validar en el esquema: una enumeración para unit, un rango numérico por unidad, y una regla de que value y unit aparecen juntos o no aparecen en absoluto.
7. Tratar la temperatura de forma especial: UCUM clasifica el grado Celsius como una unidad especial en una escala que no es de razón, convertida con un desplazamiento en lugar de un factor y excluida de la multiplicación y la exponenciación; almacenar kelvin o Celsius e indicar cuál.

Resultado esperado

Quien consume puede convertir cualquier valor a su unidad canónica de forma mecánica, los desajustes de unidad se detectan mediante la validación del esquema en lugar de manifestarse como resultados incorrectos, y las afirmaciones de precisión son explícitas en lugar de inferidas del formato.

Límites y base de verificación

El procedimiento es una propuesta derivada de las especificaciones citadas; no se afirma ninguna medición de su efecto. No cubre los importes monetarios, que tienen sus propias reglas (unidades menores por moneda), ni las unidades compuestas cuyos códigos deben componerse (kg.m/s2 en la sintaxis de UCUM). Los vocabularios de unidades difieren (UCUM, códigos UN/CEFACT, ontologías); mezclarlos en una interfaz anula el propósito, así que hay que elegir uno y registrar la elección en el esquema.