Organización de Datos BriefPD

La Figura 15 describe los conceptos principales involucrados en la definición de un proyecto de medición. Esta nueva organización permite lograr un contenido a intercambiar mediante mensajes que es:

• Integrado: Es posible definir múltiples definiciones de proyectos de medición simultáneamente a través de un único mensaje, mientras que se incluyen todos los conceptos necesarios para implementar la medición,

• Autocontenido: La totalidad de la definición del proyecto de medición es organizada y contenida dentro de un mismo mensaje,

• Jerárquicamente organizada: Todos los conceptos se organizan siguiendo un orden de navegación conveniente basado en la ontología ECINCAMI (Ver Figura 12). Por ejemplo, a partir de una categoría de entidad bajo monitoreo es posible conocer los atributos característicos a cuantificar.

• Consistente: Cada concepto involucrado en la definición del proyecto tiene su correlato en la ontología ECINCAMI.

88 Figura 15 Conceptos Principales de la Definición de Proyecto Integrada. Una Descripción Autocontenida Basada en

una Ontología de Medición

La nueva organización jerárquica puede informar un conjunto de proyectos de medición en forma simultánea. La raíz del mensaje se indica con un fondo blanco (Ver etiqueta IPD en Figura 15) y tiene asociada una etiqueta MeasurementProjects (Rectángulo con fondo amarillo y línea punteada) que permite agrupar un conjunto de proyectos de medición. Cada elemento dentro de la etiqueta MeasurementProject describe uno o más conceptos requeridos para el proyecto de medición (sintetizado en la Figura 12). El punto de partida para el proyecto es la descripción es la necesidad de información (elemento InformationNeed). A partir de allí, se describe la categoría de entidad a monitorear (elemento EntityCategory) y el contexto cuando estuviere presente (etiqueta Context). Bajo la categoría de entidad se definen los atributos (junto con el modo de cuantificarlos a través de métricas y fuentes de datos asociadas), entidades, estados de entidad, modelos de transición de estados, e indicadores ponderados (junto con los recomendadores asociados). Por otro lado, bajo el elemento del contexto se definen las propiedades contextuales (también indicando el modo de cuantificarlas mediante métricas y fuentes de datos asociadas), escenarios, y modelos de transición. Debido a que la propiedad de contexto es un atributo (Ver la

89

especialización en Figura 12), la interpretación de datos es realizada mediante los indicadores a través de los atributos que se cuantifican (por ejemplo, humedad ambiental).

El orden de navegación basado en la ontología ECINCAMI (Ver Figura 12) describe el modo en que los conceptos y dependencias son organizados. Esta organización jerárquica e integrada permite generar un mensaje conteniendo múltiples proyectos de medición concurrentemente.

El mensaje se genera de acuerdo con la organización jerárquica de conceptos introducida en la Figura 15. El punto de partida lo representa el elemento IPD representando la raíz del mensaje. Entonces, cada elemento que lo compone es alcanzado mientras desciende recursivamente a lo largo de la jerarquía. Cada atributo de clase (sea o no compuesto) es leído o escrito en un orden estricto definido por la clase. Cada clase incorpora un identificador que asocia el elemento de texto con su significado.

Figura 16 Un Fragmento Comentado del Mensaje Asociado con la Definición del Proyecto de Medición Integrada

La Tabla 14 describe los identificadores asociados con cada uno de los conceptos de la ontología ECINCAMI. De este modo, cuando se necesita escribir una instancia de la clase Scale, “{|SCA|” indica el inicio del concepto.

{|SCA|IDS1;My Scale1;RATIO;{ID1;Meters1;Some description1;m;m;meters}|SCA|}

Start of a concept End of a concept

ID related to the concept (e.g., Scale)

ID name ScaleType

Composed Element (e.g., Unit)

SI_name SI_symbol symbol description name IDUnit BriefPD

JSON

{"ID":"IDS1","name":"My Scale1","scaleType":"RATIO","unit":{"IDUnit":

"ID1","name":"Meters1","description":"Some description1","symbol":"m",

"SI_symbol":"m","SI_name":"meters"}}

XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Scale>

<ID>IDS1</ID>

<name>My Scale1</name>

<scaleType>RATIO</scaleType>

<unit>

<IDUnit>ID1</IDUnit>

<name>Meters1</name>

<description>Some description1</description>

<symbol>m</symbol>

<SI_symbol>m</SI_symbol>

<SI_name>meters</SI_name>

</unit>

</Scale> String length 75 175 379

BriefPD JSON XML

90 Tabla 14 Identificadores para los Conceptos descritos en la ontología ECINCAMI.

Class ID Class ID

Actionable ALE InformationNeed INF

Actionables ALES IPD IPD

Attribute ATT MeasurementProject MPR

Attributes ATS MeasurementProjects MPS

Constraint CO Metric ME

Constraints COS Metrics MES

Context CTX Range RGE

ContextProperties CPS Recommender REC

ContextProperty CP Scale SCA

DataSource DS Scenario SCE

DataSources DSS ScenarioProperties SPS

DecisionCriteria DCA ScenarioProperty SP

DecisionCriterion DC Scenarios SNS

ECMetadata EC StateTransition ST

ECState EST StateTransitionModel STM

ECStateProperties ECS Transitions TRA

ECStates STS Values VUS

Entities ETS WeightedIndicator WIN

Entity ENT WeightedIndicators WIS

EntityCategory ECT

El primer elemento luego del identificador de concepto corresponde al primer atributo de la clase, es decir, ID para Scale (Ver Figura 16). Luego, se escriben los atributos name y scaleType separados por “;”. Como se puede observar en la Figura 16, scaleType es una enumeración y Unit corresponde con una instancia compuesta. Por ese motivo, luego del punto y como aparece una nueva llave izquierda “{” comenzando el nuevo concepto, pero sin indicar un ID. Esto se debe a que la instancia Unit no contiene atributos compuestos. Así, los atributos de Unit se escriben en orden separados por punto y coma. El punto y coma siempre se encuentra presente entre los atributos, aunque no al inicio o fin. De este modo, no se utilizan etiquetas para incorporar el valor de cada atributo (las únicas etiquetas corresponden con los identificadores de la clase).

Este aspecto representa una ventaja en el tamaño del mensaje debido al ahorro que produce, como puede apreciarse en la Figura 16 contrastando el mismo mensaje entre los formatos BriefPD, JSON, y XML. Es decir, mientras que BriefPD requiere 75 caracteres para representar la relación entre escala, tipo de escala y unidad, XML y JSON requieren 379 y 175 caracteres respectivamente. Este ahorro se soporta en evitar usar etiquetas y aprovechando la jerarquía de conceptos.

BriefPD puede ser convertido hacia y desde representaciones JSON y XML. El contenido puede leerse sencillamente siguiendo las reglas de generación indicadas soportando la interoperabilidad sintáctica. A su vez, cada concepto es emparejado e

91

interpretado de acuerdo con una jerarquía soportada por la ontología ECINCAMI, soportando la interoperabilidad semántica.

Debido a que el mensaje generado es una jerarquía natural de conceptos guiado por una ontología, es posible seguir la idea de árbol de Merkle [119]–[122] para verificación de integridad. Cada nivel del árbol (o jerarquía) puede computar una huella recursivamente utilizando los datos del nivel. De este modo, la raíz de árbol o jerarquía obtiene una única huella calculada a partir del contenido del mensaje. Ello permite comparar dos mensajes o proyectos (de acuerdo con el nivel de concepto a comparar) para determinar si son iguales a través del contraste de sus respectivas huellas.

Adicionalmente, dado dos definiciones del proyecto de medición organizadas de acuerdo con el orden de navegación introducido, es posible compararlas parcialmente para encontrar diferencias mediante las huellas por nivel. A partir de ello, se puede actualizar parcial e incrementalmente la definición del proyecto reemplazando parte del árbol o jerarquía.