Introdução

Este artigo, o primeiro em nossa série sobre normas relevantes para modelagem de dados para soluções de cidades mais inteligentes, foca em conceitos principais comuns entre diversas áreas da cidade mais inteligente, como transporte, segurança pública e água. Forneceremos normas para outros domínios nas partes futuras desta série.

Nosso objetivo primário para a Parte 1 é fornecer uma referência para as normas relevantes para a modelagem de dados para soluções de cidades mais inteligentes. Nós identificamos lacunas nas quais normas ainda não são definidas. Recomendamos como usar as normas existentes e como lidar com as lacunas nas normas.

A visão de Cidades Mais Inteligentes da IBM se baseia na premissa de que o mundo está se tornando mais interligado, instrumentado e inteligente, e que isso constitui uma oportunidade para nova economia, eficiência e possibilidade de progresso. Subjacente a essa premissa está o elemento de base das normas.

Normas são essenciais para:

• Interoperabilidade
• Representação e troca de dados
• Agregação
• Virtualização
• Flexibilidade

Embora seja possível desenvolver soluções ad hoc, elas limitam o impacto a longo prazo.

Cidades são inerentemente heterogêneas, o que frequentemente faz com que soluções de diferentes fornecedores sejam implementadas entre as fronteiras de agências e departamentos. Como resultado, a colaboração e troca de informações entre agências podem ser prejudicadas. Soluções de cidades mais inteligentes precisam facilitar a triagem e seleção de informações pertinentes para uso entre agências de uma maneira estruturada. Estabelecer um modelo de dados baseado em normas é imperativo.

Modelos de dados definem como as informações são estruturadas e o que elas representam em um nível semântico. Por exemplo, o relatório de um acidente:

• Definiria o conteúdo.
• Estabeleceria a estrutura do conteúdo.
• Estabeleceria relacionamentos com outras informações.

Ele pode identificar o local do acidente, por exemplo, e oferecer dados representacionais usando um endereço postal, coordenadas geográficas ou algum outro sistema de localização.

Para que uma autoridade administrativa processe e interprete corretamente as informações fornecidas por outra autoridade administrativa, ela precisa entender o modelo de dados subjacente. Cada agência geralmente usa seu próprio modelo de dados, criado para lidar com suas necessidades específicas dentro das limitações impostas por sistemas legados.

A reconciliação da disparidade nos modelos de dados é vital. Definir um modelo de dados de cidades mais inteligentes em comum simplifica o processo de tradução, pois o mapeamento de e para os modelos específicos das agências é confinado ao modelo comum. As soluções de cidades mais inteligentes devem considerar e usar diversas normas para ajudar e determinar um modelo de dados comum.

Voltar para parte superior

Cenário: Obras planejadas em rua

Acompanhar o fluxo de ponta a ponta de um cenário urbano típico pode identificar efetivamente conceitos essenciais para um modelo de informações de cidade mais inteligente. Podemos posicionar o contexto das normas existentes e identificar lacunas nas normas. O cenário de obras planejadas em rua abaixo destaca importantes conceitos comuns na maioria das soluções de cidades mais inteligentes. A intenção desta seção é ser ilustrativa e não abrangente.

Breve descrição

O cenário de obras planejadas em rua é um evento futuro que envolve importantes reparos rodoviários em um movimentado cruzamento da cidade. O reparo rodoviário tem origem na agência de transporte como uma atividade planejada para uma data e local específicos com uma duração específica.

A coordenação do reparo requer a determinação do impacto por parte de outros domínios municipais afetados, incluindo ônibus e trens, água, concessionárias de serviços, prédios e segurança pública. A colaboração entre os domínios efetivamente minimiza a interrupção geral ao fluxo do tráfego, facilita a duração menor dos reparos e reduz o custo total.

Equipe essencial para a coordenação do cenário de obras planejadas em rua inclui:

• Operadores
• Supervisores
• Respondentes
• Analistas
• Gerenciadores de recursos

Além disso, alguns principais indicadores de desempenho (KPIs) são criados e mantidos para controlar a efetividade de uma resposta específica e de seus procedimentos associados. Exemplos de KPIs incluem:

• Tempo de resposta
• Tempo para o encerramento
• Custo para a cidade
• Economia para a cidade
• Impacto nos serviços municipais

Fluxo básico dos eventos

1. O gerenciador de recursos na agência de transporte planeja importantes reparos rodoviários, daqui a dois meses, em um movimentado cruzamento, com duração estimada de uma semana.
   1. O gerenciador de recursos cria uma ordem de serviço para gerenciar o reparo.
2. Após receber a ordem de serviço, o operador da agência de transporte cria uma notificação para comunicar a outras agências e departamentos municipais sobre o trabalho de reparo.
3. Analistas nas agências e departamentos afetados realizam análise inicial de impacto, que eles podem otimizar usando regras e análise de negócios para automatizar os procedimentos padrão de operação.

   Após especificarem os impactos específicos de cada agência, todos realizarão uma análise geral colaborativa (consulte a etapa 4).

1. O departamento de ônibus determina que uma de suas rotas será afetada.
2. A agência de água determina que a manutenção da tubulação (na mesma área) pode ser feita ao mesmo tempo que o reparo da via.
3. A empresa de eletricidade determina que a manutenção da infraestrutura subterrânea (na mesma área) pode ser feita ao mesmo tempo que o reparo da via.
4. O departamento de habitação determina que vários de seus prédios serão afetados.
5. O departamento de polícia determina que pode precisar designar policiais ao local para direcionar o tráfego durante a hora do rush, quando os reparos estão ativos.
4. Os supervisores das agências afetadas iniciam uma colaboração e análise de impacto entre as agências.
   1. Gerenciadores de recursos em todas as agências/departamentos afetados coordenam e finalizam os planos de ação.
   2. Como o reparo na via afetará diversas agências, um supervisor no nível da cidade assume a propriedade geral da coordenação do esforço de trabalho.
5. Os supervisores de vias, ônibus, água, concessionárias de serviços, prédios e segurança pública informam a seus respectivos gerenciadores de ativos para executar os planos de manutenção e planejamento.
   1. O trabalho é coordenado entre as agências para garantir segurança e operação tranquila.
   2. São realizadas transmissões apropriadas para alertar a comunidade de cidadãos sobre:
      1. Fechamento de ruas e rotas alternativas
      2. Replanejamento e nova rota de ônibus
      3. Interrupção do serviço de água para fornecimento público
      4. Interrupção dos serviços públicos, indicando o planejamento da indisponibilidade
      5. Interrupção do serviço de prédios para residentes das propriedades afetadas
   3. O supervisor no nível da cidade é informado do progresso e da conclusão da meta.
6. O trabalho de manutenção é concluído, dentro do prazo, de maneira coordenada pelas equipes das agências (respondentes).
   1. Ordens de serviço em todas as agências afetadas são fechadas.
   2. São realizadas transmissões apropriadas para alertar a comunidade de cidadãos.
7. O supervisor no nível da cidade realiza uma análise posterior de custo e impacto para determinar a efetividade da resposta geral.

Principais conceitos do modelo

Há vários conceitos de modelo que são fundamentais no cenário descrito acima de obras planejadas em rua: organização, alerta, incidente, pessoa, ativo, ordem de serviço, processo, local de KPI e tempo. Além disso, há relacionamentos fortes entre vários desses conceitos. A aplicabilidade das normas existentes e a extensão das lacunas das normas variam significativamente para cada conceito.

• Organização

• Definição: um grupo de pessoas organizadas para um fim particular
• Exemplos: departamento de polícia, departamento de habitação, departamento de ônibus, agência de transportes, agência de água, empresa de eletricidade
• Atributos principais: nome, tipo de organização, descrição, identificação, website
• Relacionamentos-chave: organizações (pai-filho), ativos, localização
• Avaliação de normas: National Information Exchange Model (NIEM): NIEM-Core (nc:)OrganizationType, organização de UCore (Universal Core)
• Alert
  • Definição: um aviso ou alarme sobre um evento iminente
  • Exemplos: notificação sobre reparos em rua
  • Atributos-chave: remetente, descrição, urgência, severidade, certeza, hora de início, local, recursos de suporte
  • Relacionamentos-chave: remetente (organização ou pessoa), local, incidente, ordens de serviço
  • Avaliação de normas: o Common Alerting Protocol (CAP) tem suporte extensivo para o conceito de alerta. Os conceitos de Evento de UCore também se aplicam.
• Incidente
  • Definição: uma ocorrência ou um evento que pode exigir uma resposta
  • Exemplos: reparos na rua, acidente de automóvel, rompimento de tubulação de água, atividade criminosa
  • Atributos-chave: data e hora do incidente, descrição, ID
  • Relacionamentos-chave: local, alertas, ordens de serviço, proprietário (organização ou pessoa)
  • Avaliação de normas: NIEM:nc:IncidentType, CAP:alert:incidents, Evento de UCore, Evento de Ontologia de Arquitetura Orientada a Serviços (SOA)
• Pessoa
  • Definição: um ser humano, um indivíduo
  • Exemplos: James, Bob, Sally
  • Atributos-chave: nome completo, nome de batismo, sobrenome, sexo, data de nascimento, local de nascimento, cidadania, país de nascimento
  • Relacionamentos-chave: empregador, local, endereço, organização, função (tais como operador, supervisor, respondente, analista, gerenciador de ativos)
  • Avaliação de normas: NIEM:nc:PersonType, Pessoa de UCore, Agente Humano de Ontologia SOA
• Ativo
  • Definição: um objeto tangível que pode ser controlado no tempo
  • Exemplos: rua, cano de água, capacitor elétrico, ônibus, prédio
  • Atributos-chave: descrição, ID
  • Relacionamentos-chave: organização, pessoa, fabricante, local, ordem de serviço, incidente
  • Avaliação de normas: NIEM:ip: AssetType, Entidade de UCore
• Ordem de serviço
  • Definição: uma ordem para realizar algum trabalho; para corrigir, reparar ou substituir
  • Exemplos: reparos em rua, manutenção de uma válvula principal, alteração na rota de ônibus
  • Atributos-chave: descrição, ID, comentário, prioridade, status, local, data/hora de início, data/hora de fim
  • Relacionamentos-chave: etapas de trabalho, ordens de serviço (pai-filho), incidente, alerta, organização, histórico de manutenção, especificação, pessoa, ativos
  • Avaliação de normas: nenhuma norma relevante identificada no momento.

• Processo e procedimento
  • Definição: uma série de ações para atingir um objetivo
  • Exemplos: notificação e coordenação sobre reparo em rua
  • Atributos-chave: documento de processo
  • Relacionamentos-chave: etapas do processo, ordens de serviço, incidente, alerta, organização, pessoa, ativos
  • Avaliação de normas: Processo de Ontologia SOA
• Key Performance Indicator
  • Definição: uma medição ou critério para avaliar a condição ou desempenho de uma pessoa, processo ou coisa
  • Exemplos: tempo de resposta, tempo para o encerramento, custo para a cidade, economia para a cidade, impacto nos serviços municipais
  • Atributos-chave: descrição, métricas, limites
  • Relacionamentos-chave: KPI (pai-filho), organização, incidente, alerta, processo e procedimento, ativo
  • Avaliação de normas: nenhuma norma relevante identificada no momento.
• Local
  • Definição: um local geográfico, ponto, posição ou área identificada por suas coordenadas em um sistema de coordenadas terrestres, nome ou endereço
  • Exemplos: local de reparos na rua: cruzamento, local da tubulação de água
  • Atributos-chave: coordenadas geográficas, endereço postal, TimeStamp
  • Relacionamentos-chave: pessoa, organização, ativo, incidente, alerta
  • Avaliação de normas: NIEM:nc:LocationType, Local de UCore, Ponto de Linguagem de Marcação Generalizada (GML), OpenGIS® Local de Open Location Service (OpenLS)
• Tempo
  • Definição: sistema de medição usado para sequenciar eventos, comparar as durações de eventos e os intervalos entre eles e quantificar taxas de mudança, como, por exemplo, as movimentações de objetos
  • Exemplo: horário de início, horário de término
  • Atributos-chave: anos, meses, semanas, dias, horas, minutos, segundos, milissegundos
  • Relacionamentos-chave: duração
  • Avaliação de normas: NIEM:nc:DateTime, W3C DateTimeDescription

Voltar para parte superior

Inventário de normas

Esta seção destaca normas existentes que são pertinentes à modelagem de cidades mais inteligentes. Damos uma breve descrição da norma e posicionamento com outras normas relevantes. Incluímos recomendações sobre como usar a norma. Incluímos a lista de normas recomendadas pelo National Incident Management System (NIMS) e outros neste documento. (Consulte Recursos.)

National Information Exchange Model (NIEM)

NIEM é uma estrutura de troca de informações dos EUA baseada em XML, que representa uma colaboração entre agências e organizações em todos os níveis de governo (federal, estadual, tribal e local) e com o segmento de mercado privado. (Consulte o website em Recursos.) O propósito dessa parceria é compartilhar informações críticas de modo efetivo e eficiente nos principais pontos de decisão em domínios diversos, incluindo a Justiça, segurança pública, gerenciamento de emergência e desastre, inteligência e segurança nacional. NIEM foi criado para desenvolver, disseminar e suportar normas e processos de troca de informações corporativos que permitem que jurisdições automatizem o compartilhamento de informações.

O modelo de dados NIEM consiste em conceitos principais e específicos de domínio. Ele compartilha e decifra conceitos principais universalmente em todos (ou quase todos) os domínios. Exemplos de entidades principais incluem:

• Activity
• Endereço
• Caso
• Data e hora
• Documento
• Item
• Incidente
• Local
• Organização
• Pessoa

Para que um componente se torne universal, todos os domínios devem chegar a um acordo em relação à semântica e estrutura do componente. Após ser estabelecido, o conjunto de componentes universais NIEM é estável e relativamente pequeno.

NIEM facilita a inclusão de normas externas, mesmo podendo haver sobreposição semântica. Por exemplo, foram definidos grupos de substituição e tipos de adaptador para componentes geoespaciais externos para:

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

Os conceitos de domínio específico do NIEM são exclusivos de uma única agência ou unidade de governo. Domínios do NIEM incluem:

• Biométrica
• CBRN (chemical, biological, radiological, and nuclear)
• Gerenciamento emergencial
• Imigração
• Proteção de infraestrutura
• Inteligência
• Comércio internacional
• Justiça
• Marítimo
• Triagem
• Serviços para juventude e família

NIEM está sendo adotado por muitas agências federais americanas e governos estaduais e locais, e também expandindo para outros domínios. Além disso, outras agências governamentais nacionais estão considerando adotar o NIEM. Por exemplo, Eurojust e SEMIC-EU incluíram uma investigação do NIEM como parte de seu desenvolvimento de normas de troca governamental europeias. NIEM, no entanto, não é considerada uma norma internacional, e não lida com vocabulários ou taxonomias internacionais no momento.

Esforços de modelagem de cidades mais inteligentes devem considerar o uso de conceitos principais e de domínio específico do NIEM. Para os principais, os conceitos de pessoa, lugares, eventos e coisas são especialmente relevantes. Modelos de cidades mais inteligentes devem poder consumir e emitir mensagem de acordo com NIEM.

Universal Core

Universal Core (UCore) é uma iniciativa federal de compartilhamento de informações nos EUA que suporta a Estratégia Nacional de Compartilhamento de Informações e todas as estratégias associadas de departamentos e agências. (Consulte Recursos.) UCore permite compartilhamento de informações ao definir uma especificação implementável (esquema XML) contendo representações acordadas para os conceitos de compartilhamento mais comum, e de entendimento universal, de quem, o quê, onde e quando. UCore especifica uma estrutura, metadados, regras de extensão, marcação de segurança e esquema físico para permitir compartilhamento de conteúdo entre sistemas diferentes. No entanto, um objetivo principal ao criar o UCore foi mantê-lo simples, fácil de explicar e fácil de implementar.

Para facilitar a adoção, UCore estabelece Comunidades de Interesse, ou domínios de conhecimento, para motivar a adoção de vocabulários comuns. Muitas agências e organizações já têm formatos para representar e compartilhar ativos de informações. Infelizmente, esses formatos são geralmente incompatíveis entre fronteiras comunitárias. Não se espera que UCore substitua o compartilhamento de dados complexo em domínios altamente desenvolvidos. UCore permite que cada comunidade continue representando seus ativos de informações usando esquemas definidos pela comunidade. Informações pertinentes são extraídas de formatos de mensagens existentes (como NIEM) para criar uma mensagem de acordo com UCore.

A compilação UCore comunica informações sobre entidades, eventos, pessoas, organizações, locais, coleções e os relacionamentos que os ligam. A compilação fornece o conjunto comum de elementos XML que todos os produtos e consumidores UCore entendem. UCore também fornece uma taxonomia de termos, em formato de um arquivo Web Ontology Language (OWL), para classificar eventos e entidades. Esse arquivo lista termos taxonômicos específicos com suas definições e origens. Os termos taxonômicos são usados na compilação como parte do HTML what .

Da perspectiva da modelagem de cidades mais inteligentes, UCore deve ser usado para definir e modelar os conceitos principais de entidades e ativos, eventos e alertas, pessoas, organizações, locais e coleções, juntamente com os relacionamentos que os ligam. Além disso, um modelo de cidades mais inteligentes deve utilizar a taxonomia de termos do UCore baseada em OWL que classifica eventos e entidades. Por fim, um modelo de cidades mais inteligentes deve poder consumir e emitir mensagens UCore.

Common Alerting Protocol (CAP)

O Common Alerting Protocol (CAP) é uma das iniciativas EDXL. (Consulte Recursos.) EDXL é um conjunto de normas para interoperabilidade de dados relacionadas a incidente e emergência criado por OASIS. EDXL é uma iniciativa ampla para criar uma estrutura integrada para um grande conjunto de normas de troca de dados de emergência, para suportar operações, logística, planejamento e financiamento.

CAP padroniza o conteúdo de alertas e notificações em todos os riscos, incluindo cumprimento da lei e segurança pública, bem como riscos naturais como clima extremo, incêndios, terremotos e tsunamis. CAP pode ser usado para definir e modelar o conceito principal de um alerta, incluindo atributos-chave como categoria, status, escopo, certeza, severidade, urgência, tempo de ativação, tempo de expiração, tipo de resposta, instruções etc.

Embora CAP tenha sido criado no contexto de EDXL para lidar com as necessidades específicas do domínio de gerenciamento de emergência, está sendo adotado no segmento de mercado como um protocolo de alerta de fins gerais. Como tal, o CAP se qualifica como norma principal para soluções de cidades mais inteligentes, o que explica sua inclusão neste artigo. EDXL, como um todo, é específico para gerenciamento emergencial e será discutido em um artigo próximo específico sobre o domínio de gerenciamento emergencial.

Normas geoespaciais

O Open Geospatial Consortium (OGC) é uma organização internacional de mais de 400 organizações que oferece um array de normas para serviços geoespaciais e baseados em local. (Consulte Recursos.) Essas normas estão disponíveis sem custo, e incluem modelos de dados, codificações, interfaces e melhores práticas.

OGC Abstract Specification

A OGC Abstract Specification fornece a base conceitual na qual OGC Standards Baseline, a principal norma OGC, é desenvolvida. O OGC Reference Model descreve essas normas e como elas se relacionam uma à outra. (Consulte Recursos.)

Informações geoespaciais incluem local e tempo. Locais podem ser descritos como locais cívicos, tais como um endereço postal, ou como coordenadas numéricas em um sistema de referência de coordenadas. A OGC Abstract Specification define sistemas de referência de coordenadas que têm uma referência em relação à Terra. Inclui datum que define a origem, orientação e escala do sistema de coordenadas ligado à Terra.

OpenGIS Geography Markup Language (GML)

A norma mais conhecida do OGC, GML, define uma gramática XML para a troca de informações geoespaciais na Internet. A norma está disponível como um Esquema XML e tornou-se referência para o transporte e armazenamento de informações geográficas no segmento de mercado. (Consulte Recursos.)

Como GML abrange apenas recursos geográficos, locais em GML somente podem ser expressos com base em pontos geométricos. Em particular, GML não suporta locais cívicos. Por esse motivo, o GML não é ideal para o desenvolvimento de modelo de dados de referência principal para soluções de cidades mais inteligentes. Usar uma das normas mais complexas e de nível maior baseadas em GML, como OpenGIS Location Services (OpenLS), parece ser uma abordagem melhor.

OpenLS foi projetado para permitir aplicativos baseados em local e define diversos tipos de dados que não são parte do GML, tais como local. O local do OpenLS inclui diversos tipos de locais, incluindo um endereço definido de maneira que possa acomodar endereços internacionais, um ponto de interesse identificado por nome, como o nome de um restaurante, ou uma posição geográfica definida pelas suas coordenadas. Todos esses tipos de locais podem ser usados em cenários de cidade mais inteligente, incluindo o reparo em rua planejado descrito anteriormente.

OpenLS é definido como um Esquema XML, baseado no esquema XML do GML.

Discutiremos outras normas OGC, a saber CityGML e KML, posteriormente nesta série.

Time Ontology em OWL

Time Ontology em OWL é um rascunho de trabalho do W3C que descreve o vocabulário e relacionamentos de datas, horas, durações e fusos horários. (Consulte Recursos.) Essa ontologia permite que fatos sejam expressos sobre conteúdo de data e hora. Por exemplo, é possível usar essa ontologia para determinar conflitos em planejamentos, comparar datas, descrever um intervalo particular de tempo, calcular a hora em um local geográfico particular ou simplesmente descrever informações temporais em uma página da web.

Algumas classes OWL definidas nessa ontologia incluem Interval, DurationDescription, DateTimeDescription e DayOfWeek.

O conceito de tempo é onipresente em toda a paisagem da cidade mais inteligente: otimizar o planejamento de equipes de trabalho para reparar uma rua, determinar a hora ideal para planejar o trabalho e evitar atrasos de tráfego, transmitir um planejamento de indisponibilidade para água ou eletricidade, ou alterar a rota de ônibus por um período de tempo quando a rua estiver sendo reparada. A Time Ontology do W3C serve como um modelo sólido para conceitos temporais em cenários de cidade mais inteligente como esses.

Ontologia SOA

A Ontologia de Arquitetura Orientada a Serviços (SOA) do The Open Group (TOG) fornece descrição ontológica OWL e UML para os principais conceitos, termos e semântica da arquitetura orientada a serviços. (Consulte Recursos.) Esse vocabulário comum permite que negócios e engenheiros de software mapeiem domínios de negócios e marketing para termos técnicos, para resolver problemas e criar oportunidades. A Ontologia SOA cria uma base, permite interoperabilidade para serviços municipais e promove clareza e entendimento para desenvolver serviços entre equipes de negócios e técnicas.

A Ontologia SOA descreve esses conceitos e seus relacionamentos: serviço, processo, tarefa, evento, agente humano, efeito, sistema, política, contrato de serviço, interface de serviço e elemento.

Esse padrão aberto pode oferecer uma base para os conceitos de processo e procedimento incluídos no cenário de obra em rua planejada descrito anteriormente. Também pode ser usado para descrever suposições de trabalho para definir e planejar programas municipais e entrega de serviços baseada na web.

Voltar para parte superior

Recomendações

À medida que as implementações de modelo de dados de cidades mais inteligentes progridem, você deve fazer o seguinte para garantir consistência com as normas críticas especificadas neste artigo:

• Alavanque as normas especificadas na seção dois deste documento para ajudar a identificar e modelar entidades de negócios de cidades mais inteligentes
• Projete modelos de dados para transportar as informações necessárias para um mapeamento de e para essas normas quando apropriado. (Alavancar essas normas não significa projetar um modelo de dados de cidades mais inteligentes como um retalho dessas normas.)
• Leve em consideração todos os atributos e relacionamentos especificados nos quais diversas normas definem a mesma entidade (ou seja, organização, pessoa, local e mais).
• Se entidades de nome semelhante existirem em diversas normas, mas forem significativamente diferentes, considere definir conceitos em separado para as entidades.
• Garanta que o modelo de cidade mais inteligente seja capaz de consumir e emitir entidades e conceitos para todas as normas definidas na seção dois deste documento.
• À medida que modelos de cidades mais inteligentes evoluem e lacunas em normas são identificadas, considere buscar a participação de órgãos normativos apropriados para assistir e lidar com essas lacunas.

Voltar para parte superior

Conclusão

Normas terão um papel importante no desenvolvimento de modelos de dados de cidades mais inteligentes. Este artigo identificou algumas normas críticas aplicáveis aos conceitos principais que você deve usar no desenvolvimento desses modelos de dados. Artigos futuros, estendendo-se em outros domínios, avaliarão normas adicionais para inclusão em modelos de dados de cidades mais inteligentes.

Índice de Normas

As informações sobre as normas listadas nesta tabela não são abrangentes. Envie qualquer informação adicional para os autores para revisão futura.

Recursos

Aprender

• Saiba mais sobre a iniciativa Cidades Mais Inteligentes IBM visitando a página do projeto.
  
  
• Veja a lista de normas recomendadas do National Incident Management System (NIMS) no website da FEMA.
  
  
• Saiba mais sobre National Information Exchange Model (NIEM).
  
  
• Veja detalhes sobre o UCore.
  
  
• Veja detalhes sobre EDXL.
  
  
• Saiba mais sobre EDXL-CAP.
  
  
• Leia mais sobre as Open Geospatial Consortium.
  
  
• Veja mais detalhes sobre a OGC Abstract Specification.
  
  
• Saiba mais sobre a ferramenta OGC Reference Object Model.
  
  
• Veja mais detalhes sobre GML e OpenLS.
  
  
• Leia mais sobre W3C Time Ontology.
  
  
• Leia a The Open Group SOA Ontology Technical Standard 1.0" (developerWorks dezembro de 2010) para mais informações sobre essa norma.
  
  
• Localize mais detalhes sobre a Ontologia de Arquitetura Orientada a Serviços do The Open Group.
  
  
• Obtenha os recursos técnicos específicos do segmento de mercado para desenvolvedores.
  
  
• Encontre extensas instruções, ferramentas e atualizações de projeto para ajudar a desenvolver com tecnologias de software livre e usá-las com produtos da IBM.
  
  
• Mantenha-se atualizado participando de developerWorks.
  
  
• Siga os tweets do developerWorks no Twitter .
  
  
• Escute os Podcasts do developerWorks para acompanhar entrevistas interessantes e discussões sobre desenvolvimento de software.
  
  

Obter produtos e tecnologias

• Localize recursos de softwares de avaliação por segmento de mercado.
  
  

Discutir

• Conecte-se a outros usuários do developerWorks por meio da comunidade do developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  
• Ajude a desenvolver o grupo de software livre do na comunidade developerWorks.
  
  
• Confira o Blogs do developerWorks e participe.
  
  

Sobre os autores

Arnaud Le Hors, membro do grupo de normas de software IBM, é responsável por conduzir a coordenação de diversas atividades de normas IBM de um ponto de vista estratégico e técnico. Arnaud trabalha em padrões abertos há 15 anos, como membro de equipe do X Consortium e W3C. Ele participou de cada aspecto do processo de desenvolvimento de normas, incluindo técnico, estratégico, político e legal, interna e externamente em um SDO e em empresas como a IBM. Arnaud participou do desenvolvimento de normas como HTML e XML e foi um dos arquitetos chefes do Xerces, o analisador de XML desenvolvimento pela Apache Software Foundation.

Keith Wells, desenvolvedora na equipe de Normas de Software, teve oportunidades de desenvolver ativamente código, demos, táticas e estratégias com várias normas ao longo dos últimos dez anos. Keith tem curiosidade técnica e sente paixão e entusiasmo ao desenvolver produtos interessantes e práticos, e ao colaborar com pessoas que possuem qualificações diferentes.

John Meegan é membro senior do grupo de Estratégia e Tecnologia do IBM Software Group, no qual se concentra atualmente em esforços de normatização para as iniciativas de cidade mais inteligente e de nuvem da IBM. Antes de seu trabalho com normas, ele passou vários anos desenvolvendo a estratégia de software livre do IBM Software Group, trabalhando com clientes e consultores do segmento de mercado para comunicar e refinar a estratégia. Também passou vários anos na organização de Estratégia do Software Group, na qual contribuiu para a formulação da estratégia inicial de servidor de aplicativos da web da IBM, o que levou ao lançamento da família de produtos IBM WebSphere. Ele é bacharel em ciência da computação pela Universidade Columbia.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Cenário: Obras planejadas em rua
• Inventário de normas
• Recomendações
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais