Principios de diseño

1. Semántico, no estructural

Los conceptos tienen significado. Una Persona (Person) no es un conjunto de campos; es una entidad con nombre y una definición escrita para practicantes del dominio. El problema de interoperabilidad radica en la divergencia de vocabulario: los sistemas usan nombres diferentes para las mismas entidades del mundo real, y cuando esos nombres codifican decisiones semánticas distintas, las correspondencias entre ellos pierden información. PublicSchema provee definiciones compartidas que hacen explícitas las equivalencias y preservan el significado a través de los sistemas.

2. Descriptivo, no normativo

Nada es obligatorio. Los sistemas adoptan los conceptos, propiedades y vocabularios que les aplican. PublicSchema describe cómo se ven los datos de prestación en todos los sistemas; no impone qué debe recopilar ningún sistema.

3. Basado en evidencia e incremental

Los datos de convergencia impulsan las prioridades. Una propiedad presente en 6 de 6 sistemas vale la pena estandarizar antes que una presente en 2 de 6. Comience con lo que está confirmado y extiéndalo cuando la adopción revele una necesidad genuina.

La convergencia de organismos de normalización complementa la convergencia entre sistemas al nivel del supertipo abstracto. Cada concepto abstracto informa system_count: 0/{total} frente al corpus de sistemas mapeados en v1 porque ningún sistema mapeado expone un supertipo con ese nombre; las evidencias de convergencia se asignan a los subtipos concretos. Esta convención se aplica uniformemente a los cuatro supertipos abstractos principales (Agent, Event, Party, Profile), a los categorizadores abstractos intermedios (Group, VitalEvent) e Instrument. Las abstracciones mismas están alineadas con normas ampliamente desplegadas (PROV-O para Agent y Event, FOAF/schema.org para Agent y Organization, FHIR QuestionnaireResponse para Profile, DPV para el enfoque de consentimiento de Party). La convergencia entre esas normas es evidencia aceptable para introducir un supertipo abstracto, siempre que los subtipos conserven su propia evidencia de sistemas mapeados. Véase ADR-008 para la aplicación de este patrón a Agent y Organization.

4. Lenguaje sencillo para practicantes

Las definiciones están escritas para responsables de políticas y gestores de programas, no para desarrolladores. "Los estados del ciclo de vida de una inscripción en un programa" es preferible a "una enumeración de códigos de estado aplicables a la entidad de registro de personas beneficiarias".

5. Supertipos abstractos

Algunos conceptos existen solo como fundamentos compartidos para subtipos más específicos. Agent, Event, Party y Profile llevan abstract: true, lo que significa que definen propiedades comunes pero nunca se instancian directamente. Los subtipos (por ejemplo, FunctioningProfile, ScoringEvent, Organization) heredan esas propiedades y agregan las suyas. Agent es el supertipo del lado del actor (Person, Organization, SoftwareAgent); Party es el supertipo del lado del beneficiario (Person, Group). Person pertenece a ambos. Consulte ADR-006 y ADR-008.

6. Separación entre observación y puntuación

La recopilación y la puntuación de datos son pasos distintos, con actores, marcas de tiempo y pistas de auditoría diferentes. Los subtipos de Profile registran las respuestas estructuradas de una aplicación única de instrumento y también pueden llevar resultados derivados de aplicar la regla de puntuación canónica del instrumento (por ejemplo, el identificador de discapacidad WG-SS en FunctioningProfile, o un puntaje PMT en SocioEconomicProfile). ScoringEvent registra el acto de aplicar una regla no estándar, un umbral alternativo o recalcular un puntaje tras una revisión de regla. Esta separación permite a los sistemas recalcular puntajes sin re-recopilar datos, manteniendo los resultados canónicos cerca de las observaciones que los produjeron. Subtipos de Profile específicos de dominio publicados en esquemas hermanos siguen el mismo patrón. Consulte ADR-006, ADR-010 y ADR-011.

7. Categorías de propiedades

Las propiedades se agrupan por categoría temática (por ejemplo, funcionamiento, nutrición, vivienda) en lugar de listarse de forma plana. Las categorías se definen en schema/categories.yaml y se representan como agrupaciones visuales en las páginas de detalle de conceptos. Esto ayuda a los profesionales a localizar las propiedades relevantes en conceptos que llevan muchas.

8. Metadatos de instrumento

Las propiedades que registran el contexto de recopilación (modo de administración, informante, relación con el informante, aplicabilidad por edad) acompañan los datos de observación, sin un archivo de metadatos separado. Esto garantiza que un registro de Profile sea autodescriptivo: un consumidor puede determinar cómo se recopilaron los datos sin consultar un registro externo. Consulte schema-design.md sección 7 para detalles de aplicabilidad por edad.

Véase también

• Diseño de esquema: nomenclatura, alcance y modelado
• Diseño de vocabulario: conjuntos de valores controlados y correspondencias de sistemas
• Versionado y madurez: garantías de estabilidad y reglas de evolución
• Divulgación selectiva: diseño de privacidad para credenciales