Panorama de estándares del modelo de datos de la ciudad más inteligente, Parte 1: Núcleo

Las ciudades enfrentan muchos retos en su camino para volverse más inteligentes. El intercambio de información es particularmente desafiante entre las agencias ciudadanas. La proliferación de distintas soluciones de proveedor desplegadas a través de fronteras de agencia y departamentales es la raíz del problema. La solución es definir un modelo de datos de cuidad más inteligente común y basado en estándares que determine cómo es estructurada la información y qué representa a nivel semántico. Este artículo se enfoca en los conceptos y estándares centrales que son comunes a través de múltiples dominios de ciudad más inteligentes, tales como la seguridad pública, el transporte y el agua.

Arnaud Le Hors, Senior Software Engineer, IBM

Arnaud Le Hors, un miembro del grupo de estándares de software de IBM, es responsable de dirigir la coordinación de varias actividades de estándares de IBM desde un punto de vista estratégico y técnico. Arnaud ha estado trabajando en estándares abiertos durante 15 años, como miembro del personal de X Consortium y de W3C. Se ha involucrado en todos los aspectos del proceso de desarrollo de estándares, incluyendo el técnico, estratégico, político y legal, tanto internos como externos para un SDO y para una compañía como IBM. Arnaud estuvo involucrado en el desarrollo de estándares tales como HTML y XML y es uno de los arquitectos líderes para Xerces, el analizador de XML desarrollado por Apache Software Foundation.



John Meegan, Senior Software Engineer, IBM

John Meegan es miembro sénior del grupo IBM Software Group Strategy and Technology donde está actualmente enfocado en esfuerzos de estándares para iniciativas de ciudad más inteligente y de la nube de IBM. Antes de que sus estándares funcionaran, invirtió tres años en desarrollar la estrategia de código abierto de IBM Software Group, trabajando con clientes y consultores de la industria para comunicar y refinar la estrategia. También invirtió varios años en la organización Software Group Strategy, donde contribuyó con la formulación de la estrategia de aplicación web de IBM inicial, lo que llevó al lanzamiento eventual de la familia de productos de IBM WebSphere. Recibió un título de Licenciatura en Artes (BA) en Ciencias de la Computación de la Universidad de Columbia.



Keith Wells, Senior Software Engineer, IBM

Keith Wells, es un desarrollador en el equipo de Estándares de Software, ha disfrutado de oportunidades para desarrollar código, demostraciones, tácticas y estrategias activamente con muchos estándares durante los últimos diez años. Keith es técnicamente curioso y siente una pasión y emoción por desarrollar productos interesantes y prácticos, así como colaborar con personas que también tienen diversas habilidades.



12-03-2012

Introducción

Este artículo, el primero en nuestra serie sobre estándares relevantes para el modelado de datos para soluciones de ciudad más inteligente, se enfoca en conceptos centrales comunes a través de múltiples dominios de ciudad más inteligentes, tales como el transporte, la seguridad pública y el agua. Proporcionaremos estándares para otros dominios en futuras partes de esta serie.

Nuestro objetivo principal para la Parte 1 es proporcionar una referencia para los estándares relevantes para el modelado de datos para soluciones de ciudad más inteligente. Identificamos las brechas donde los estándares aún no están definidos. Recomendamos cómo usar estándares existentes y cómo atender brechas de estándares.

La visión de IBM Smarter Cities está basada en la premisa de que el mundo se está volviendo más interconectado, instrumentado e inteligente, y esto constituye una oportunidad para nuevos ahorros, eficiencia y posibilidad para progresar. Bajo esta premisa descansa el elemento fundamental de los estándares.

Los estándares son la clave para:

  • Interoperabilidad
  • Representación e intercambio de datos
  • Agregación
  • Virtualización
  • Flexibilidad

Aunque es posible desarrollar soluciones ad hoc, estas limitan el impacto a largo plazo.

Las ciudades son inherentemente heterogéneas, lo que frecuentemente causa que diversas soluciones de proveedor sean desplegadas a través de fronteras de agencia y departamentales. Como resultado, la colaboración en todas las agencias y el intercambio de información pueden obstaculizarse. Las soluciones de ciudad más inteligente necesitan facilitar la clasificación y la selección de la información pertinente para usar a través de las agencias en una forma estructurada. Establecer un modelo de datos basado en estándares es imperativo.

Los modelos de datos definen cómo es estructurada la información y qué representa a nivel semántico. Por ejemplo, un informe de accidente podría:

  • Definir el contenido.
  • Establecer la estructura del contenido.
  • Establecer las relaciones con otra información.

Puede identificar la ubicación del accidente, por ejemplo, y proporcionar datos representacionales usando una dirección postal, coordenadas gráficas o algún otro sistema de localización.

Para que una agencia procese e interprete correctamente la información proporcionada por otra agencia, necesita entender el modelo de datos subyacente. Cada agencia normalmente usa su propio modelo de datos diseñado para atender sus necesidades específicas dentro de las restricciones impuestas por sistemas de legado.

La reconciliación de la disparidad en los modelos de datos es vital. Definir un modelo de datos común de ciudad más inteligente simplifica el proceso de traducción, ya que la correlación desde y hacia modelos específicos de agencias está confinada al modelo común. Las soluciones de ciudad más inteligente deben considerar y usar diversos estándares para ayudar a definir y aprovechar un modelo de datos común.


Escenario: Obras viales planificadas

Caminar a través de un flujo de punta a punta de un escenario ciudadano puede identificar efectivamente los conceptos clave para un modelo de información de ciudad más inteligente. Podemos posicionar el contexto de estándares existentes e identificar brechas de estándares. El escenario de obras viales planificadas a continuación resalta los conceptos clave comunes en la mayoría de las soluciones de ciudad más inteligente. El intento de esta sección es que sea ilustrativa, y no exhaustiva.

Descripción breve

El escenario de obras viales planificadas es un evento próximo que involucra una importante reparación vial en una ocupada intersección de la ciudad. La reparación vial se origina en la agencia de transporte como una actividad planificada para una fecha y ubicación específicas con duración especificada.

La coordinación de la reparación requiere la determinación del impacto por otros dominios de la ciudad afectados que incluyen autobuses y trenes, agua, servicios públicos, edificios y seguridad pública. La colaboración entre los dominios minimiza efectivamente la interrupción general del flujo de tráfico, facilita una duración más corta de las reparaciones y reduce el costo total.

El personal crítico para la coordinación del escenario de obras viales planificadas incluye:

  • Operadores
  • Supervisores
  • Personal de respuesta
  • Analistas
  • Gestores de activos

Además, un número de indicadores de rendimiento clave (KPIs) es creado y mantenido para realizar el seguimiento de la efectividad de una respuesta específica y sus procedimientos asociados. Los ejemplos de KPIs incluyen:

  • Tiempo de respuesta
  • Tiempo para el cierre
  • Costo para la ciudad
  • Ahorros para la ciudad
  • Impacto para los servicios de la ciudad

Flujo básico de eventos

  1. El gestor de activos en la agencia de transporte planea importantes reparaciones viales, dentro de dos meses, en una ocupada intersección de la ciudad con duración estimada de una semana.
    1. El gestor de activos crea un pedido de trabajo para gestionar la reparación.
  2. Después de recibir el pedido de trabajo, el operador de la agencia de transporte crea un aviso para notificar a otras agencias y departamentos de la ciudad del trabajo de reparación.
  3. Los analistas dentro de las agencias y departamentos afectados realizan el análisis de impacto inicial, el cual pueden optimizar usando normas empresariales y analítica para automatizar procedimientos operativos estándar.

    Después de que determinen los impactos específicos de la agencia, todos realizarán un análisis general colaborativo (consulte la etapa 4).

    1. El departamento de autobuses determina que una de sus rutas de autobús será impactada.
    2. La agencia del agua determina que el mantenimiento de pipas (en la misma área) puede ser sincronizado con la reparación vial.
    3. Los servicios públicos de electricidad determinan que el mantenimiento de infraestructura subterránea (en la misma área) puede ser sincronizado con la reparación vial.
    4. El departamento de vivienda pública determina que varios de sus edificios serán impactados.
    5. El departamento de policía determina que tal vez necesite asignar oficiales de policía en el lugar para dirigir el tráfico durante la hora pico cuando las reparaciones estén activas.
  4. Los supervisores de las agencias impactadas inician una colaboración entre agencias y un análisis de impacto.
    1. Los gestores de activos en todas las agencias/departamentos impactados coordinan y finalizan los planes de acción.
    2. Ya que la reparación vial impactará varias agencias, un supervisor al nivel de la ciudad asume la propiedad general de coordinar el esfuerzo de trabajo.
  5. Los supervisores de caminos, autobuses, agua, servicios públicos, edificios y seguridad pública informan a sus gestores de activos respectivos sobre la ejecución del mantenimiento y la planificación.
    1. El trabajo es coordinado en todas las agencias para asegurar la seguridad y el funcionamiento de la operación.
    2. Se emiten difusiones apropiadas para alertar a la comunidad ciudadana de:
      1. Cierres viales y rutas alternas
      2. Cambios en los horarios de autobuses y planos de las nuevas rutas
      3. Interrupción del servicio del agua para suministro público de la bebida
      4. Interrupción del servicio público indicando un corto de electricidad planificado
      5. Interrupción del servicio de edificios para residentes o propiedades afectadas
    3. El supervisor al nivel de la ciudad se mantiene al tanto del progreso y de la finalización del objetivo.
  6. El trabajo de mantenimiento es completado, a tiempo, en forma coordinada por el personal de la agencia (personal de respuesta).
    1. Los pedidos de trabajo en todas las agencias impactadas se cierran.
    2. Difusiones apropiadas son emitidas para alertar a la comunidad ciudadana.
  7. El supervisor al nivel de la ciudad ejecuta un análisis de costo e impacto post mortem para determinar la efectividad de la respuesta general.

Conceptos de modelo clave

Hay varios conceptos de modelo que son fundamentales para el escenario de obras viales planificadas descrito anteriormente: organización, alerta, incidente, persona, activo, pedido de trabajo, proceso, ubicación de KPI y tiempo. Además, hay fuertes relaciones entre muchos de estos conceptos. La aplicabilidad de estándares existentes y la extensión de las brechas de estándares varían significativamente para cada concepto.

  • Organización
    • Definición: un grupo de personas organizadas para un propósito particular
    • Ejemplos: departamento de policía, departamento de vivienda pública, departamento de autobuses, agencia de transporte, agencia de agua, servicio público de electricidad
    • Atributos clave: nombre, tipo de organización, descripción, identificación, website
    • Relaciones clave: organizaciones (padre-hija), activos, ubicación
    • Evaluación de estándares: National Information Exchange Model (NIEM): NIEM-Core (nc:)OrganizationType, organización UCore (Universal Core)
    Alerta
    • Definición: una advertencia o alarma para un evento inminente
    • Ejemplos: aviso de reparación vial
    • Atributos clave: emisor, descripción, urgencia, severidad, certeza, tiempo de inicio, ubicación, recursos de soporte
    • Relaciones clave: emisor (organización o persona), ubicación, incidente, pedidos de trabajo
    • Evaluación de estándares: El Common Alerting Protocol (CAP) tiene soporte extensivo para el concepto de alerta. Los conceptos de UCore Event también son aplicables.
  • Incidente
    • Definición: una ocurrencia o un evento que pueda requerir una respuesta
    • Ejemplos: reparación vial, accidente automovilístico, brote principal de agua, actividad criminal
    • Atributos clave: fecha y hora del incidente, descripción, ID
    • Relaciones clave: ubicación, alertas, pedidos de trabajo, propietario (organización o persona)
    • Evaluación de estándares: NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, Ontology Event de Arquitectura Orientada al Servicio (SOA)
  • Persona
    • Definición: Un ser humano, un individuo
    • Ejemplos: James, Bob, Sally
    • Atributos clave: nombre completo, nombre dado, nombre de familia, género, fecha de nacimiento, lugar de nacimiento, nacionalidad, país de nacimiento
    • Relaciones clave: empleador, ubicación, dirección, organización, rol (como operador, supervisor, personal de respuesta, analista, gestor de activos)
    • Evaluación de estándares: NIEM:nc:PersonType, UCore Person, SOA Ontology Human Actor
  • Activo
    • Definición: un objeto tangible al que se le puede realizar un seguimiento con el tiempo
    • Ejemplos: camino, pipa de agua, capacitor eléctrico, autobús, edificio
    • Atributos clave: descripción, ID
    • Relaciones clave: organización, persona, fabricante, ubicación, pedido de trabajo, incidente
    • Evaluación de estándares: NIEM:ip: AssetType, UCore Entity
  • Pedido de trabajo
    • Definición: un pedido para hacer algún trabajo; para corregir, reparar o sustituir
    • Ejemplos: reparación vial, mantenimiento de servicios públicos en una válvula principal, reorganización de las rutas de autobuses
    • Atributos clave: descripción, ID, comentario, prioridad, estado, ubicación, fecha/hora de inicio, fecha/hora de finalización
    • Relaciones clave: etapas de trabajo, pedidos de trabajo (padre-hijo), incidente, alerta, organización, historial de mantenimiento, especificación, persona, activos
    • Evaluación de estándares: no hay estándares relevantes identificados en este momento.
  • Proceso y procedimiento
    • Definición: una serie de acciones para conseguir el objetivo
    • Ejemplos: notificación y coordinación de reparación vial
    • Atributos clave: documento de proceso
    • Relaciones clave: etapas de proceso, pedidos de trabajo, incidente, alerta, organización, persona, activos
    • Evaluación de estándares: SOA Ontology Process
  • Indicador clave de rendimiento
    • Definición: una medida o criterio para analizar la condición o el rendimiento de una persona, proceso o cosa
    • Ejemplos: tiempo de respuesta, tiempo para el cierre, costo para la ciudad, ahorros para la ciudad, impacto para los servicios de la ciudad
    • Atributos clave: descripción, medidas, umbrales
    • Relaciones clave: KPI (padre-hijo), organización, incidente, alerta, proceso y procedimiento, activo
    • Evaluación de estándares: no hay estándares relevantes identificados en este momento.
  • Ubicación
    • Definición: un lugar geográfico, punto, posición o área que se identifica por sus coordenadas en un sistema de coordenadas basado en la tierra, por su nombre o por su dirección
    • Ejemplos: ubicación de reparación vial: intersección en la ciudad, ubicación de la pipa de agua
    • Atributos clave: coordenadas geográficas, dirección postal, indicación de fecha y hora
    • Relaciones clave: persona, organización, activo, incidente, alerta
    • Evaluación de estándares: NIEM:nc:LocationType, UCore Location, Geography Markup Language (GML) Point, OpenGIS® Open Location Service (OpenLS)
  • Hora
    • Definición: sistema de medida usado para eventos de secuencia, para comparar la duración de eventos y los intervalos entre ellos y para cuantificar las tasas de cambio tales como los movimientos de los objetos
    • Ejemplos: fecha de inicio, fecha de finalización
    • Atributos clave: años, meses, semanas, días, horas, minutos, segundos, milisegundos
    • Relaciones clave: duración
    • Evaluación de estándares: NIEM:nc:DateTime, W3C DateTimeDescription

Inventario de estándares

Esta sección resalta los estándares existentes que son pertinentes para el modelado de ciudad más inteligente. Proporcionamos una breve descripción del estándar el posicionamiento con otros estándares relevantes. Incluimos recomendaciones sobre cómo debe usar el estándar. Cubrimos la lista de estándares recomendados por National Incident Management System (NIMS) y otros en este documento. (Vea Recursos.)

National Information Exchange Model (NIEM)

NIEM es una infraestructura de intercambio de información basada en XML de EE.UU. que representa una sociedad colaborativa de agencias y organizaciones en todos los niveles del gobierno (federal, estatal, tribal y local) y con la industria privada. (Vea los detalles del website en Recursos.) El propósito de esta sociedad es compartir información crítica en forma efectiva y eficiente en puntos clave de decisión a través de múltiples dominios, que incluyen la justicia, la seguridad pública, la gestión de emergencias y desastres, la inteligencia y la seguridad nacional. NIEM está diseñado para desarrollar, diseminar y soportar estándares y procesos de intercambio de información en toda la empresa que permitirán a las jurisdicciones automatizar el intercambio de información.

El modelo de datos de NIEM consiste en conceptos centrales y específicos del dominio. Comparte y descifra conceptos centrales universalmente entre todos (o casi todos) los dominios. Los ejemplos de entidades que son centrales incluyen:

  • Actividad
  • Dirección
  • Caso
  • Fecha y hora
  • Documento
  • Elemento
  • Incidente
  • Ubicación
  • Organización
  • Persona

Para volverse un componente universal, todos los dominios deben estar de acuerdo en la semántica y la estructura del componente. Una vez establecido, el conjunto de componentes universales de NIEM es estable y relativamente pequeño.

NIEM facilita la inclusión de estándares externos, aunque puede haber solapamiento de semánticas. Por ejemplo, los grupos de sustitución y los tipos de adaptador para componentes geoespaciales han sido definidos para:

  • Open Geospatial Consortium (OGC),
  • Logical Interchange Format (LIF),
  • LandXML,
  • International Association for Interoperability (IAI) y
  • ANSI.

Los conceptos específicos del dominio de NIEM son exclusivos para una sola agencia o unidad gubernamental. Los dominios de NIEM incluyen:

  • Biométricos
  • CBRN (químicos, biológicos, radiológicos y nucleares)
  • Gestión de emergencias
  • Inmigración
  • Protección de infraestructura
  • Inteligencia
  • Comercio internacional
  • Justicia
  • Marítimo
  • Proyección
  • Servicios juveniles y familiares

NIEM ha ganado adopción en muchas agencias federales y estatales de EE.UU. y en gobiernos locales, y también se ha expandido en otros dominios. Además, otras agencias gubernamentales nacionales están considerando NIEM. Por ejemplo, Eurojust y SEMIC-EU han incluido una investigación de NIEM como parte de su desarrollo de estándares de intercambio gubernamental europeo. NIEM, sin embargo, no es considerado un estándar internacional, ni atiende vocabularios o taxonomías internacionales en este momento.

Los esfuerzos de modelado de ciudad más inteligente deben considerar el uso de conceptos centrales de NIEM y específicos del dominio. Para el aspecto central, los conceptos de personas, lugares, eventos y cosas son especialmente relevantes. Los modelos de ciudad más inteligente también deben poder consumir y emitir mensajes compatibles con NIEM.

Universal Core

Universal Core (UCore) es una iniciativa de intercambio de información federal de EE.UU. que soporta la Estrategia de Intercambio de Información Nacional y todas las estrategias departamentales y de agencia asociadas. (Vea Recursos.) UCore permite el intercambio de información al definir una especificación implementable (esquema XML) que contiene representaciones previamente acordadas para los conceptos más comúnmente compartidos y universalmente comprendidos de quién, qué, cuándo y dónde. UCore especifica una infraestructura, metadatos, normas de extensión, marcado de seguridad y esquema físico para permitir el intercambio de contenido entre sistemas distintos. Sin embargo, un objetivo clave en la creación de UCore es mantenerlo simple, fácil de explicar y fácil de implementar.

Para facilitar la adopción, UCore establece Comunidades de Interés, o dominios de conocimiento, para motivar la adopción de vocabularios comunes. Muchas agencias y organizaciones ya tienen formatos para representar y compartir activos de información. Desafortunadamente, esos formatos son frecuentemente incompatibles a través de las fronteras comunitarias. UCore no pretende sustituir el intercambio de datos complejo dentro de dominios altamente desarrollados. UCore permite a cada comunidad continuar representando sus activos de información usando sus esquemas definidos por la comunidad. La información pertinente es extraída de formatos de mensaje existentes (como NIEM) para crear un mensaje compatible con UCore.

El digesto de UCore comunica información sobre entidades, eventos, personas, organizaciones, ubicaciones, colecciones y las relaciones que los enlazan. El digesto proporciona el conjunto común de elementos XML que todos los productores y consumidores de UCore entienden. UCore también proporciona una taxonomía de términos en la forma de un archivo de Web Ontology Language (OWL) para clasificar eventos y entidades. Este archivo lista términos de taxonomía específicos, junto con su definición y origen. Los términos de taxonomía son usados en el digesto como parte del elemento qué .

Desde una perspectiva de modelado de ciudad más inteligente, UCore debe ser usado para definir y modelar los conceptos centrales de entidades y activos, eventos y alertas, personas, organizaciones, ubicaciones y colecciones, junto con las relaciones que los unen. Además, un modelo de ciudad más inteligente debe aprovechar la taxonomía de UCore basada en OWL de términos que clasifican eventos y entidades. Finalmente, un modelo de ciudad más inteligente debe poder consumir y emitir mensajes de UCore.

Common Alerting Protocol (CAP)

El Common Alerting Protocol (CAP) es una de las iniciativas de EDXL. (Vea Recursos.) EDXL es un conjunto de estándares relacionados con incidentes y emergencias para interoperabilidad de datos de OASIS. EDXL es una amplia iniciativa para crear una infraestructura integrada para una amplia gama de estándares de intercambio de datos de emergencia para soportar operaciones, logística, planificación y financiamiento.

CAP estandariza el contenido de alertas y notificaciones en todos los riesgos, incluyendo el cumplimiento de la ley y la seguridad pública, así como riesgos naturales como el clima severo, incendios, terremotos y tsunamis. CAP puede ser usado para definir y modelar el concepto central de una alerta, incluyendo atributos clave tales como categoría, estado, ámbito, certeza, severidad, urgencia, tiempo de inicio, tiempo de expiración, tiempo de respuesta, instrucciones, etc.

Aunque CAP fue creado en el contexto de EDXL para atender las necesidades específicas del dominio de gestión de emergencias, está siendo adoptado en la industria como un protocolo de alerta de propósito general. Como tal, CAP califica como un estándar central para soluciones de ciudad más inteligente, lo que explica su inclusión en este artículo. EDXL, como un todo, es específico para la gestión de emergencias y será discutido en un artículo más adelante específico para el dominio de gestión de emergencias.

Estándares geográficos

El Open Geospatial Consortium (OGC) es una organización internacional de más de cuatrocientas organizaciones ofreciendo una matriz de estándares para servicios geoespaciales y basados en la ubicación. (Vea Recursos.) Estos estándares están disponibles libremente y sin costo y cubren modelos de datos, codificaciones, interfaces y buenas prácticas.

Especificación Abstracta de OGC

LA Especificación Abstracta de OGC proporciona la base conceptual en la cual está construida la Línea de Base de Estándares de OGC, los estándares centrales de OCG. El Modelo de Referencia de OGC describe estos estándares y cómo se relacionan unos con otros. (Vea Recursos.)

La información geoespacial abarca la ubicación y el tiempo. Las ubicaciones pueden ser descritas como ubicaciones civiles, tales como una dirección postal, o como coordenadas numéricas en un sistema de referencia de coordenadas. La Especificación Abstracta de OGC define los sistemas de referencia de coordenadas que tienen una referencia con la tierra. Incluye datos que definen el origen, la orientación y la escala del sistema de coordenadas atado a la tierra.

OpenGIS Geography Markup Language (GML)

El estándar más prominente de OGC, GML, define una gramática de XML para el intercambio de información geoespacial en Internet. El estándar está disponible como un Esquema XML y se ha convertido en la referencia para el transporte y almacenamiento de información geográfica en la industria. (Vea Recursos.)

Ya que GML sólo cubre dispositivos geográficos, las ubicaciones en GML sólo pueden ser expresadas con base en puntos geométricos. En particular, GML no soporta ubicaciones civiles. Por esta razón, GML es sub-óptimo para el desarrollo de un modelo de datos de referencia central para soluciones de ciudad más inteligente. Usar uno de los estándares de alto nivel más enriquecidos que se basa en GML, tal como OpenGIS Location Services (OpenLS), parece ser un mejor enfoque.

OpenLS está diseñado para habilitar aplicaciones basadas en la ubicación y define varios tipos de datos que no son parte de GML, tales como la ubicación. La ubicación de OpenLS abarca muchos tipos de ubicaciones, incluyendo una dirección definida de tal forma que puede acomodar direcciones internacionales, un punto de interés identificado por nombre como el nombre de un restaurant o una posición geográfica definida por sus coordenadas. Todos estos tipos de ubicaciones pueden ser útiles en escenarios de ciudad más inteligente, incluyendo las obras viales planificadas descritas anteriormente.

OpenLS es definido como un Esquema XML, con base en el esquema XML de GML.

Discutiremos otros estándares de OGC, llamados CityGML y KML, más adelante en esta serie.

Time Ontology in OWL

Time Ontology in OWL es un borrador en funcionamiento de W3C que describe el vocabulario y las relaciones para fechas, horas, duraciones y zonas horarias. (Vea Recursos.) Esta ontología permite que los hechos sean expresados sobre el contenido de fecha y hora. Por ejemplo, puede usar esta ontología para determinar conflictos en planificaciones, comparar fechas, describir un intervalo de tiempo particular, calcular el tiempo en una ubicación geográfica particular o simplemente describir información temporal en una página web.

Algunas clases de OWL definidas en esta ontología incluyen Interval, DurationDescription, DateTimeDescription y DayOfWeek.

El concepto del tiempo es ubicuo a través del panorama de ciudad más inteligente: optimizando la planificación de equipos de trabajo para reparar un camino, determinar la hora del día óptima para planificar el trabajo y evitar retrasos de tráfico, difundir una planificación de cortos de agua y electricidad o reorganizar las rutas de autobuses durante un periodo de tiempo cuando el camino esté siendo reparado. W3C Time Ontology atiende un modelo sólido para conceptos temporales en escenarios de ciudad más inteligente como estos.

Ontología de la SOA

La Ontología de la Arquitectura Orientada al Servicio (SOA) de The Open Group (TOG) proporciona una descripción ontológica de OWL y de UML para los conceptos, términos y semánticas centrales de la arquitectura orientada al servicio. (Vea Recursos.) Este vocabulario común permite a las empresas y a ingenieros de software correlacionar dominios empresariales y de marketing con términos técnicos para solucionar problemas y crear oportunidades. La ontología de la SOA crea una base, permite la interoperabilidad de los servicios municipales y promueve la claridad y el entendimiento para desarrollar servicios entre personas empresariales y técnicas.

La Ontología de la SOA describe estos conceptos y sus relaciones: servicio, proceso, tarea, evento, actor humano, efecto, sistema, política, contrato de servicio, interfaz de servicio y elemento.

Este estándar abierto puede proporcionar una base para los conceptos de proceso y de procedimiento incluidos en el escenario de obras viales planificadas descrito anteriormente. También puede ser usado para describir suposiciones funcionales para definir y planificar programas municipales y entrega de servicios basada en web.


Recomendaciones

A medida que las implementaciones del modelo de datos de ciudad más inteligente progresan, debe realizar las siguientes etapas para asegurar la consistencia con los estándares críticos especificados en este artículo:

  • Aprovechar los estándares especificados en la sección dos de este documento para ayudar a identificar y modelar entidades centrales de ciudad más inteligente
  • Diseñar modelos de datos para llevar la información necesaria para una correlación adecuada hacia y desde estos estándares donde sea apropiado. (Aprovechar estos estándares no significa diseñar un modelo de datos de ciudad más inteligente como un remiendo de estos estándares.)
  • Tome en cuenta todos los atributos y relaciones especificados donde múltiples estándares definen la misma entidad (p.ej., organización, persona, ubicación y más).
  • Si entidades nombradas en forma similar existen en múltiples estándares pero son significativamente distintas, considere definir conceptos separados para las entidades.
  • Asegúrese de que su modelo de ciudad más inteligente puede consumir y emitir entidades y conceptos para todos los estándares definidos en la sección dos de este documento.
  • A medida que los modelos de ciudad más inteligente evolucionan y las brechas de los estándares son identificadas, considere contratar equipos de estándares apropiados para ayudar y atender estas brechas.

Conclusión

Los estándares jugarán un rol importante en el desarrollo de modelos de datos de ciudad más inteligente. Este artículo ha identificado un número de estándares críticos aplicables a conceptos centrales que debería usar en el desarrollo de estos modelos de datos. Futuros artículos, extendiéndose en otros dominios, evaluarán estándares adicionales para su inclusión en modelos de datos de ciudad más inteligente.

Índice de Estándares

La información sobre los estándares listados en esta tabla no es exhaustiva. Envíe cualquier información adicional a los autores para su revisión futura.

Estándar Ejemplos de conceptos soportados Despliegues actuales
Common Alerting Protocol (CAP) Categoría, estado, ámbito, certeza, severidad, urgencia, tiempo de inicio, tiempo de expiración, tiempo de respuesta, instrucciones Estándar internacional (OASIS más ITU-T Recommendation X.1303) con despliegues principalmente en EE.UU, que incluyen: Departamento de Seguridad Nacional, Servicio del Clima Nacional, Servicio Geológico de Estados Unidos, Oficina de Servicios de Emergencia de California, Departamento de Transporte de Virginia y RAINS de Oregon.
National Information Exchange Model (NIEM) Actividad, dirección, caso, fecha y hora, documento, elemento, incidente, ubicación, organización, persona Específico de EE.UU. con despliegues que incluyen: Departamento de Seguridad Nacional de EE.UU., Departamento de Justicia de EE.UU., Servicios de Ciudadanía e Inmigración de EE.UU., Agencia Federal de Gestión de Emergencias (FEMA), Programa de Cumplimiento de la Ley en el Intercambio de Información, Logical Entity eXchange Specifications, OneDOJ, y el Departamento de Salud y Servicios Humanos.
OpenGIS Geography Markup Language (GML) Punto Estándar internacional (OGC) que es ampliamente usado en la industria y considerado la referencia en su área.
OpenGIS Location Services (OpenLS) Ubicación Estándar internacional (OGC) que es usado para aplicaciones basadas en la ubicación como aplicaciones de teléfono celular.
Ontología de la SOA Servicio, proceso, tarea, evento, actor humano, efecto, sistema, política, contrato de servicio, interfaz de servicio, elemento Estándar internacional (TOG) que encapsula el vocabulario y las relaciones de la SOA y es usado para describir y modelar soluciones de la SOA.
Universal Core Entidades y activos, eventos y alertas, personas, organizaciones, ubicaciones, colecciones Estándar específico de EE.UU. que es conjuntamente gestionado por el Departamento de Defensa, Justicia y Seguridad Nacional y la Oficina del Director de Inteligencia Nacional. Dentro del Departamento de Defensa, la Infantería de Marina y la Fuerza Aérea parecen estar comprometidos con el soporte de UC.
W3C Time Ontology in OWL Interval, DurationDescription, DateTimeDescription, DayOfWeek Estándar internacional (W3C) con una adopción incierta. Nuestra búsqueda web no reveló ningún despliegue concreto.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Industries, Linux
ArticleID=800880
ArticleTitle=Panorama de estándares del modelo de datos de la ciudad más inteligente, Parte 1: Núcleo
publish-date=03122012