Normalmente, descrevemos três elementos críticos na discussão sobre as soluções mais inteligentes do planeta. As três “i”s, como as chamamos, são: instrumentadas, inteligentes e interconectadas.

Elas suportam a ideia de que há uma grande quantidade de dados no mundo para coletarmos e usarmos para gerar inteligência e, a partir disso, podemos ajudar a conduzir uma otimização envolvendo tarefas de negócios críticas.

O importante nessa abordagem é a análise e compreensão dos dados provenientes de muitas fontes em uma ampla variedade de formatos e contextos.

Os designs de aplicativo precisam lidar com esse tipo de dado discrepante, incluindo dados estruturados e não estruturados, dados de sensor (valor atual e histórico), imagens de sensor, áudio e vídeo. Infelizmente, além de esses dados não se ajustarem às estruturas relacionais de persistência padrão, eles também são difíceis de contextualizar.

Considere um aplicativo de tráfego municipal mais inteligente. Sensores de semáforo, sensores de velocidade do departamento de transporte e câmeras de vídeo fornecem dados de tráfego em tempo real. Os dados adicionais fundamentais à previsão precisa do fluxo de tráfego podem vir de uma ampla variedade de fontes, incluindo relatórios climáticos e de acidentes, interrupções no trânsito, eventos do calendário, como festas de final de ano, tendências sazonais como tráfego para ir à praia, eventos especiais como paradas, eventos emergenciais e eventos de notícias significativos. Precisamos entender todos esses dados no contexto e o relacionamento entre os eventos.

Além disso, precisamos de uma compreensão comum dos eventos que podemos consultar dessas várias fontes. Por exemplo, termos básicos como veículo podem se tornar ambíguos entre provedores de fontes de dados se considerarmos distinções como carros, caminhonetes, vans, ônibus ou motocicletas. Algumas características como eixos ou ocupantes podem assumir distinções importantes. Ao mesmo tempo, os dados relevantes que precisamos reunir estão mudando continuamente.

A modelagem semântica pode ajudar a definir os dados e os relacionamentos entre essas entidades. Um modelo de informação fornece a capacidade de abstrair tipos diferentes de dados e fornece uma compreensão de como os elementos dos dados se relacionam. Um modelo semântico é um tipo de modelo de informação que suporta a modelagem de entidades e seus relacionamentos.

Em conjunto, uma ontologia representa essas ideias. Dessa forma, a ontologia é o vocabulário do modelo semântico e fornece a base sobre a qual as consultas do modelo de usuário são formadas. O modelo suporta a representação de entidades e seus relacionamentos, e também pode suportar as restrições desses relacionamentos e entidades. Isso fornece a composição semântica do modelo de informações.

Em nosso exemplo, um modelo semântico poderia nos ajudar a entender relacionamentos como dos sensores de semáforo com as intersecções que eles monitoram. Também ajuda a compreender a associação de qualquer sensor de semáforo com outros sensores na mesma rua ou o relacionamento das ruas que têm dados específicos de sensor com outras ruas com interseção e, coletivamente, como afluentes para as rodovias principais.

O modelo também pode gerar informações parecidas sobre linhas de ônibus ou de metrô. Pode descrever os tipos de serviço disponíveis com os locais atendidos. Os relacionamentos entre estações e endereços, e linhas de serviço e rotas de carro, forneceriam a base para uma compreensão das implicações sobre o tráfego rodoviário de perturbações específicas no serviço de transporte coletivo.

Outra complicação é a possibilidade de que um único aplicativo precise interagir com vários modelos de domínio (ou ontologias de domínio). Um método de conseguir isso é unir ontologias existentes em uma nova ontologia.

Não é necessário unir todas as informações de cada ontologia original, pois talvez não seja possível atender a essa integração logicamente. Além disso, a nova ontologia pode apresentar novos termos e relacionamentos que servem para vincular os itens correspondentes com as ontologias de origem. Um exemplo disso é o IBM Reference Semantic Model que é um componente do produto IBM Integrated Information Core. Analisaremos esse modelo com mais detalhes posteriormente neste artigo.

A compreensão fornecida por meio dos modelos semânticos é fundamental para poder conduzir apropriadamente os insights corretos a partir da instrumentação monitorada que, em última análise, pode levar a processos de negócio de otimização ou, nesse caso, a serviços municipais.

Arquiteturas de aplicativo

Com o passar dos anos, várias abordagens de arquitetura foram definidas para a integração de sistemas e para a representação das informações e processos. Elas incluem:

• Arquiteturas centradas em dados
• Arquiteturas orientadas à mensagem
• Arquiteturas orientadas a serviços
• Arquiteturas centradas em informações
• Arquiteturas baseadas em modelos

Vamos explorar qual a diferença e a relação dessas várias abordagens, quais são as principais características da abordagem de modelo semântico e como empregamos o modelo semântico no produto Integrated Information Core.

Arquiteturas centradas em dados

A arquitetura centrada em dados tem base na definição de dados de negócios relevantes em torno dos quais os sistemas são integrados e os aplicativos são desenvolvidos. Rajiv Joshi, em seu artigo “Data-Oriented Architecture: Loosely Coupling Systems into Systems of Systems” (veja abaixo em Recursos), argumenta que a arquitetura orientada a dados é a melhor maneira de integrar sistemas em tempo real.

Ele descreve o barramento de dados como um componente importante da arquitetura para suportar essa abordagem. O barramento de dados é um complemento para o barramento de serviço corporativo (ESB), que é um componente base de uma arquitetura orientada ao serviço.

Sem dúvida, um exemplo disso é SAP. SAP fornece um conjunto de aplicativos que interagem em torno de um modelo de dados central. Embora SAP suporte outras abordagens de integração para aplicativos externos, o próprio SAP adotou uma abordagem centrada nos dados para comunicação intra-aplicativos.

Master data management (MDM) é outro bom exemplo que pode ser usado como o núcleo de uma arquitetura centrada em dados, suportando nesse caso a integração de aplicativos discrepantes que usam os dados de MDM (por exemplo, informações sobre produtos ou clientes) como dados de referência, complementando os dados que possam ser de propriedade desses aplicativos individuais.

Embora sejam parecidos, os dois exemplos ilustram usos diferentes de um modelo de dados nas arquiteturas do aplicativo. SAP está usando o modelo de dados para troca de informações intra-aplicativos , enquanto MDM está usando o modelo de dados para troca de informações entre aplicativos .

Arquiteturas orientadas à mensagem

Normalmente, uma arquitetura orientada à mensagem depende de dois componentes complementares:

• Um modelo de interação que define padrões como Commands, Request/Reply ou Pub/Sub.
• Um modelo de dados do conteúdo a ser trocado.

Ambos poderiam aproveitar os padrões do segmento do mercado. Java™ Messaging Service (JMS), por exemplo, que faz parte da especificação Java Enterprise Edition, define uma API que pode ser usada para padronização do modelo de interação para aplicativos. OLE for Process Control (OPC) é outro exemplo de um padrão definindo um modelo de interação.

Nesse caso, para acessar metadados que descrevem informações pertencentes a um servidor OPC e para acesso em tempo real das próprias informações (o acesso de série temporal também é suportado).

Também podemos basear o modelo de dados para trocar informações sobre padrões do segmento de mercado. Os exemplos incluem EDI (electronic data interchange), B2MML (implementação XML do padrão ISA-95) e BatchML (implementação XML do padrão ISA-88). Observe que o modelo de dados usado aqui também pode ser usado para o modelo de dados que discutimos na seção “arquitetura centrada em dados” logo abaixo.

Outro exemplo de modelo de dados é o Open Applications Group Integration Specification (OAGIS). Ele define Business Object Documents (BODs) para informações como Itens, Listas de materiais, Pedidos de produção e mais.

Cada um desses BODs tem uma Área de aplicação (cabeçalho) e uma Área de dados. Ambas as seções de um BOD são formadas por campos e estruturas de dados com base em um vocabulário padronizado (fundamentado parcialmente nos Componentes principais de UN/CEFACT e publicado como parte do padrão OAGIS).

Os BODs podem ser estendidos (de uma forma padronizada) pelos usuários e representados (para troca de dados) como documentos XML (parecido com BATCHML e B2MML). Dessa forma, o próprio padrão OAGIS pode servir como o modelo de informações para a troca de dados e pode ser usado como o conteúdo para um modelo de interação com base em JMS, como mostra a figura abaixo.

Colocado de maneira diferente, você pode usar o padrão OAGIS para fornecer os nomes nas ontologias, conforme descrito posteriormente neste artigo. (O padrão implica as relações, mas não as define explicitamente.)

Arquiteturas orientadas a serviços

Os serviços fornecem uma abordagem padronizada para interoperação entre aplicativos ou componentes de aplicativo. É possível implementar os serviços e os aplicativos em sistemas diferentes que executam plataformas diferentes (Java 2 Platform, Enterprise Edition, Windows®, Linux®).

O serviço, que no passado tinha o objetivo de ser uma camada de abstração parecida com CORBA IDL, permite que os aplicativos interajam de uma maneira independente de plataforma, sem precisar conhecer a implementação ou o local do provedor de serviço.

Entre os principais elementos da arquitetura orientada a serviços (SOA) estão:

• Provedor de serviços – um componente da arquitetura fornecendo serviços ao consumidor
• Consumidor do serviço – um componente (cliente) que está consumindo serviços
• Barramento de serviço corporativo – o barramento de integração por meio do qual os serviços são invocados e as informações que fluem entre os componentes são mediadas
• Registro de serviço – um serviço de registro e pesquisa para os serviços existentes em um sistema com base em SOA que pode incluir pesquisa de livros e serviços de invocação
• Coreografia do processo – um elemento importante de SOA em que os processos e fluxos de negócios compostos podem ser coreografados de maneira gerenciada em vários aplicativos

SOA é diferente da arquitetura centrada em dados e da arquitetura orientada por mensagens, pois não há foco nas informações que fluem entre os serviços ou um modelo para isso.

Em vez disso, a meta da SOA é fornecer uma abordagem de arquitetura para a criação de aplicativos compostos, que são um conjunto de processos de negócios compostos envolvendo o aplicativo que está sendo integrado.

Arquiteturas orientadas às informações

As arquiteturas anteriores podem se complementar e faz sentido usá-las juntas. Quando uma arquitetura de mensagens ou centrada em dados é usada em conjunto com a SOA para definir um modelo para o conteúdo que está fluindo pelas mensagens dos serviços, ela gera a base para uma arquitetura orientada às informações.

Esse tipo de arquitetura fornece a base para a composição de processos de negócios que criam coletivamente aplicativos compostos em torno de um modelo de informações. Esse modelo define a forma canônica para troca de dados, ou seja, define o lado canônico das mediações de dados.

Arquiteturas baseadas em modelos

Apesar de essas abordagens já terem comprovado sua utilidade, elas não têm, de uma forma ou de outra, contexto para as informações sobre as quais se está atuando. SOA, combinada com mensagens baseadas em padrão (por exemplo, OAGIS, B2MML e BATCHML) fornece a habilidade de criar e integrar processos compostos e aplicativos para serviços como gerenciamento de pedidos ou rastreamento de produção. No entanto, não resta contexto sobrejacente para as informações que podem ser solicitadas por aplicativos clientes.

A arquitetura baseada em modelo pode desenvolver esse contexto por meio de um modelo sobrejacente do mundo real que fornece um contexto para solicitações de informações. Dessa forma, as solicitações, os serviços associados, as definições de dados e mais podem ser associados a um objeto no modelo que definirá seu significado e fornecerá seu contexto.

Como exemplo, podemos criar um modelo para uma empresa com base em padrões do segmento, como ISA-95 e ISA-88, que podem ser usados para definir a hierarquia empresarial de uma plataforma de perfuração de poço de petróleo.

Esse modelo, no nível mais baixo da hierarquia, pode conter instâncias de equipamento, como bombas ou motores, que podem ser associadas às solicitações de informações e ações. Essa associação fornece o contexto para suportar consultas como: “Encontrar ordens de serviço disponíveis para esta bomba”, “Informar a temperatura atual desse motor” ou “Calcular o valor médio de pH nesse tanque na última semana”.

É possível obter todas essas informações com qualquer uma das arquiteturas descritas anteriormente. No entanto, a abordagem baseada no modelo apresenta o contexto na discussão de uma maneira significativa para os negócios, simplificando a tarefa de acesso às informações e de associação de ações significativas a eventos relacionados aos objetos modelados, que no exemplo são equipamentos para perfuração de poços de petróleo.

Por que usar os modelos semânticos?

Os modelos semânticos permitem que os usuários façam perguntas de uma maneira mais natural sobre o que está acontecendo em um sistema modelado.

Por exemplo, uma empresa de produção de petróleo pode ser composta por cinco regiões demográficas, com cada região contendo de três a cinco plataformas de perfuração. Cada plataforma de perfuração é monitorada por diversos sistemas de controle, cada um com um objetivo diferente. Um desses sistemas de controle pode monitorar a temperatura do petróleo extraído, enquanto outro pode monitorar a vibração em uma bomba.

Um modelo semântico permitirá que o usuário faça uma pergunta como, “Qual é a temperatura do petróleo que está sendo extraído na Plataforma 3?”, sem precisar entender detalhes como qual sistema de controle específico monitora essas informações ou qual sensor físico está reportando a temperatura do petróleo nessa plataforma.

Portanto, podemos usar os modelos semânticos para relacionar o mundo físico como os engenheiros dos sistemas de controle nesse exemplo o conhecem ao mundo real, com o qual os líderes de linha de negócios e os tomadores de decisão estão familiarizados.

No mundo físico, um ponto de controle, como uma válvula ou sensor de temperatura, é conhecido por seu identificador em um sistema de controle específico, possivelmente por meio de uma tag de nome como 14-WW13. Pode ser um dos milhares de identificadores em um determinado sistema de controle e pode haver muitos sistemas de controle parecidos na empresa.

Para complicar ainda mais o problema de referenciamento e agregação de informações, é possível gerenciar outros pontos de dados de interessa por meio de bancos de dados, arquivos, aplicativos ou serviços de componente, e cada um tendo seu próprio método de interface e convenção de nomenclatura para acesso dos dados.

Dessa forma, um valor importante do modelo semântico é o oferecimento de acesso às informações no contexto do mundo real, de uma maneira consistente.

Em uma implementação do modelo semântico, essas informações são identificadas usando triplos da forma sujeito-predicado-objeto, por exemplo:

• Tanque 1 <tem o> Sensor de temperatura 7
• Tanque 1 <faz parte da> Plataforma 4
• Plataforma 4 <faz parte da> Região 1

Esses triplos em conjunto formam a ontologia para a Região 1 e podem ser armazenados em um servidor de modelo, conforme descreveremos com mais detalhes neste artigo.

Essas informações podem ser facilmente transferidas usando o idioma da consulta de modelo para responder perguntas como “Qual é a temperatura do Tanque 1 na Plataforma 4?”, com muito mais facilidade do que sem um modelo semântico relacionando informações de engenharia ao mundo real.

É possível implementar o modelo de mundo real descrito com qualquer um dos tipos de modelos exibidos na figura acima.

O modelo relacional, por exemplo, tem ligações entre entidades estabelecidas por meio de chaves explícitas (primária, estrangeira) e, para relacionamentos de muito com muitos, entidades associativas. A alteração dos relacionamentos nesse caso é difícil, pois exige mudanças na própria estrutura do modelo base, o que pode ser difícil para um banco de dados preenchido.

A consulta desse tipo de dado com base em um modelo relacional também pode ser difícil, porque pode resultar em cláusulas where bastante complicadas ou em junções de tabela significativas.

Os modelos hierárquicos têm limitações bastante parecidas quando se trata de atualizações do mundo real e não são muito flexíveis quando se trata de tentar transferir o modelo horizontalmente.

No entanto, o modelo gráfico, que é a forma como os modelos semânticos são implementados, facilita muito a consulta e a manutenção do modelo após a implementação.

Por exemplo, se você precisar representar um novo relacionamento que não foi previsto durante o design, é possível fazer isso facilmente usando uma representação de armazenamento tripla. Basta adicionar um novo triplo ao armazenamento de dados. Esse é um ponto crítico: as relações fazem parte dos dados, não da estrutura do banco de dados.

Da mesma forma, é possível transferir o modelo de várias perspectivas diferentes para responder às perguntas que não foram pensadas no momento do design. Ao contrário, outros tipos de design de banco de dados podem exigir mudanças estruturais para responder a novas perguntas que surgem após a implementação inicial.

Os modelos de semântica (com base em gráficos) nos permitem fazer inferências com facilidade, de uma maneira não linear. Por exemplo, considere um serviço on-line para compra de livros ou de música.

Um aplicativo como esse deve ser muito bom para fazer sugestões de compras adicionais com base em seus padrões de compra. Isso é muito comum para sites de varejo eletrônico, que fornecem recomendações como “Já que você gostou desse filme, talvez goste também de…” ou “Como você gostou dessa música, provavelmente também gostará da próxima…”.

Uma maneira de conseguir isso é usar um modelo semântico e adicionar relações como as seguintes:

Enya <é parecido com> Celtic Women

Também é possível estabelecer na ontologia que Enya e Celtic Women fazem parte do gênero musical chamado New Age. Essas relações, depois de estabelecidas no modelo, simplificam a oferta desses tipos de sugestões, quando necessário.

Nas próximas seções, analisaremos os detalhes dos modelos semânticos e dos servidores de modelo nos quais eles são implementados.

Web semântica

Conforme definido pelo World Wide Web Consortium (W3C), a Web semântica “fornece uma estrutura comum que permite o compartilhamento e a reutilização de dados entre limites de aplicativo, empresas e comunidade”.

Apesar da Web geralmente se resumir à habilidade de compartilhar documentos, a Web semântica fornece a estrutura para que os computadores possam compartilhar, interrogar com maior prontidão e entender os dados.

A Web semântica suporta a noção de formatos comuns para dados que podem ser apresentados por diversas fontes. Ela também fornece a estrutura para entender os relacionamentos de dados. Isso suporta a interrogação de dados baseados na Web que dependem do significado semântico ao invés de depender de links e referências explícitas (ou implícitas).

A arquitetura da Web semântica, conforme definida por Tim Berners-Lee, é uma estrutura com camadas e uma base em XML para definições de namespace e de esquema para suportar uma sintaxe comum. A próxima camada acima da base XML suporta um Resource Definition Framework (RDF) e esquema RDF. RDF é uma estrutura para representação gráfica de recursos.

Embora ela tenha sido criada para representar as informações sobre os recursos da Web, podemos usar para diversos outros tipos de dados, conforme discutiremos posteriormente. A definição principal de um elemento RDF tem base em triplos na forma sujeito-predicado-objeto. O formato legível por máquinas para RDF é XML (RDF/XML).

Um modelo RDF define essencialmente um gráfico, conforme descrito pelos triplos. Um esquema RDF (também conhecido como Linguagem de descrição do vocabulário RDF) proporciona um conhecimento adicional ao RDF, como os termos que podem ser usados, restrições que se aplicam e quais relacionamentos adicionais existem.

É possível criar um esquema RDF para descrever a taxonomia das classes (ao contrário de apenas recursos no RDF) e relacionamentos formalizados entre os recursos (tipo e subclasse) para definir ontologias simples. É possível criar ontologias mais complexas usando o Web Ontology Language (OWL). O vocabulário de ontologia é a próxima camada da arquitetura da Web semântica.

Como citamos anteriormente, a ontologia fornece uma compreensão dos conceitos (termos e relacionamentos) em um domínio por meio de um vocabulário definido e de uma taxonomia de modelo. Em um domínio de setor específico, podemos usar a ontologia para suportar vários aplicativos. Além disso, a ontologia pode suportar termos aplicáveis de forma geral e relacionamentos que podem envolver diversos domínios.

As ontologias definem as entidades e relacionamentos para representar o conhecimento que desejamos compartilhar entre setores, domínios e aplicativos, de maneira apropriada. Para facilitar isso, as ontologias suportam a herança.

Portanto, é possível capturar um conhecimento mais generalizado (conhecido como ontologias superiores) que pode ser refinado para suportar um domínio específico (ontologias de domínio). Como discutiremos posteriormente neste artigo, o IBM Integrated Information Core Reference Semantic Model fornece um exemplo de uma ontologia superior.

A compreensão semântica dos dados depende de um vocabulário comum que define termos e relacionamentos. O esquema RDF fornece uma estrutura para um vocabulário que suporta tipos e subtipos e a habilidade de definir tipos de dados.

É possível criar ontologias mais detalhadas usando OWL, que depende de esquemas RDF, mas fornece termos de linguagem adicionais em seu próprio namespace. O OWL é definido por meio de espécies ou perfis.

O fornecimento de perfis que restringem o uso de termos pode simplificar as implementações, incluindo os mecanismos de inferência que você pode usar. Discutiremos a inferência e os mecanismos de inferência (raciocinadores) posteriormente neste artigo.

É possível usar o OWL Lite para taxonomias e restrições simples, o OWL DL para expressividade total e o OWL Full no caso de não haver restrições de expressividade.

O Simple Protocol and RDF Query Language (SPARQL) é uma linguagem parecida com SQL para consulta de RDF (incluindo esquema RDF ou OWL). Usamos SPARQL para consultar padrões gráficos RDF e retornar resultados de subgráficos selecionados. É possível usar o SPARQL para consultar ontologias e dados de modelo instanciados.

É necessário diferenciar os modelos em Linguagem de Modelagem Unificada (UML) do OWL. UML é uma linguagem de modelagem usada em engenharia de software para projetar artefatos que envolvem sistemas orientados ao objeto.

Quando falamos sobre o desenvolvimento de aplicativos com base em arquiteturas baseadas em modelo, neste contexto, estamos nos referindo ao aproveitamento de modelos semânticos como o núcleo funcional de um aplicativo, para fornecer um modelo de dados navegável e relacionamentos associados que representam o conhecimento em nosso domínio de destino.

Servidores de modelo

O servidor de modelo (ou gerente de modelo) fornece a estrutura de tempo de execução sobre a qual o modelo será implementado. Um servidor de modelo precisa suportar vários serviços funcionais para persistir e gerenciar o modelo (ontologia) e os dados de instância do modelo.

Também precisa fornecer as ferramentas e interfaces de aplicativo para modelar e instanciar as consultas de dados e atualizações. Vamos analisar esse recurso com mais detalhes usando exemplos de projetos de código aberto como Jena, Joseki, Sesame e Pellet.

Os servidores de modelo podem suportar várias camadas de persistência diferentes que incluem bancos de dados e arquivo (normalmente no formato RDF/XML, embora N3 e Turtle sejam outras duas notações populares).

Ainda que você possa usar bancos de dados relacionais para suportar a persistência de dados RDF, a consulta de dados RDF (dados com base em gráficos) armazenados em um RDB normalmente é ineficiente, e é possível perder a capacidade de alterar o modelo de dados sem alterar o esquema do banco de dados.

Um armazenamento triplo é um banco de dados com uma finalidade especial, projetado especificamente para armazenamento e consulta de dados RDF. A estrutura de dados é otimizada para dados armazenados em uma estrutura tripla que corresponde à forma sujeito-predicado-objeto do RDF. Jena e Sesame fornecem armazenamentos triplos.

Quando pensamos sobre servidores de modelo nesse nível, não há ainda qualquer requisito para compreender a estrutura dos dados persistidos. No entanto, como há a consideração da função de modelo de servidor adicional, a compreensão dos dados se torna relevante. Jena e Sesame fornecem bons exemplos.

Primeiro, devemos observar que Jena fornece uma estrutura Java para desenvolvimento de aplicativos em Web semântica ao invés de fornecer um servidor de modelo completo.

Especificamente, Joseki, um subprojeto de código aberto de Jena, fornece capacidade de servidor por meio de uma interface HTTP para os dados RDF e uma interface para consulta e atualização de SPARQL. Além disso, Jena fornece uma interface de programação para os dados RDF e um mecanismo de inferência.

Com essa capacidade adicional, Jena não precisa entender a ontologia de RDF. Raciocinar ou inferir significa ser capaz de obter fatos que a ontologia não expressa diretamente.

Jena fornece um mecanismo de inferência para suportar o raciocínio em RDF, RDFS e OWL. No entanto, o mecanismo de inferência de Jena não é completo em todos os casos de linguagem. Jena fornece uma interface conectável de modo que outros mecanismos de inferência possam ser integrados.

Por exemplo, Pellet é um raciocinador Java de código aberto que suporta totalmente OWL DL e que pode ser conectado a Jena. Com esse tipo de extensibilidade, Jena suporta linguagens como RDFS e OWL e suporta a inferência de dados de instância e descrições de classe.

Assim como Jena, o Sesame fornece uma estrutura Java que suporta persistência, uma API de interface e inferência. No entanto, o recurso de inferência no Sesame suporta RDF e RDFS, mas não OWL.

Para um conjunto de dados RDF ou RDFS, é possível consultar o Sesame e encontrar as informações implícitas. Como tudo que pode ser inferido também pode ser afirmado, uma abordagem para suportar a inferência é adicionar explicitamente as informações implícitas ao repositório quando os dados são criados inicialmente. Essa é a abordagem do Sesame.

A próxima seção é sobre o modelo semântico fornecido com o produto Integrated Information Core, que estabelece vários padrões de segmento para criar um metamodelo que fornece definições de recurso integradas à estrutura de operações empresariais.

Esse modelo, na forma de uma ontologia e manifestado em um RDF, será implementado em um servidor de modelo fornecido com o Integrated Information Core que suporta alguns dos recursos descritos aqui.

Modelos de semântica e IBM Integrated Information Core

A finalidade do IBM Integrated Information Core é fornecer uma estrutura que simplifica a criação de aplicativos centrados em um modelo de semântica do mundo real e que suporta a integração de dados operacionais em tempo real e aplicativos empresariais relacionados.

O principal componente da arquitetura Integrated Information Core que suporta essa meta é o modelo semântico que, com base nos padrões do segmento de mercado (centrado em grande parte no ISA-95 e no ISA-88), suporta a definição de um modelo empresarial até os ativos e as medições associadas.

O modelo de informações incluído com o Integrated Information Core é o Modelo semântico de referência. Ele atende a nossa definição de modelos semânticos, pois fornece uma abstração do mundo real da empresa e dos ativos em um modelo gráfico.

Por meio dele, os aplicativos podem acessar as informações de sistemas discrepantes com vários métodos de acesso. O modelo de informações no Integrated Information Core contém entidades nomeadas com base em padrões de mercado (que atualmente incluem principalmente ISA-95, ISA-88 e ISO15926) e relacionamentos definidos por esses padrões ou implícitos pela combinação dos padrões em um modelo homogêneo.

O Modelo semântico de referência pode ser consultado por meio de serviços ou (com base na implementação) de uma interface SPARQL.

Outro componente importante da arquitetura Integrated Information Core é a camada de adaptadores cientes do modelo, que suporta a integração de diversos tipos de extremidade (aplicativos acessíveis por OPC, bancos de dados e serviços da Web), e mapas das informações que fluem entre essas extremidades e elementos do modelo.

Há duas visualizações do modelo semântico Integrated Information Core:

1. Modelo de referência (a ontologia)
   Essa visualização define as classes que existem no modelo e as relações entre elas, mas não corresponde a qualquer empresa ou ativo específico.
2. Modelo instanciado
   Essa visualização inclui instâncias das classes com um mapeamento direto às entidades do mundo real. Elas são preenchidas com um conjunto de propriedades (por exemplo, s/n, local, temperatura) e com relacionamentos com outras entidades instanciadas no modelo.

Considere o exemplo de como o modelo base dos padrões de mercado no Integrated Information Core é usado para modelar o mundo real exibido na figura abaixo, que é baseado em um projeto de fabricante de tinta.

Primeiro, como pode ser visto na figura acima, as classes de ISA-95, Enterprise, Site, Area e Production Unit (encontradas como classes de referência no Modelo semântico de referência) são instanciadas. Elas são usadas, junto com uma classe adicional Work Equipment, para definir um modelo físico a partir de um nível empresarial até o nível de peças específicas do equipamento de trabalho.

É no nível Work Equipment, normalmente, que anexamos e mapeamos classes de medição até adaptadores de dados de extremidade e fontes de dados específicos.

Após a instanciação e mapeamento do modelo até as extremidades por meio da camada do adaptador, é possível usá-lo de várias maneiras para conseguir os benefícios empresariais descritos anteriormente:

• Aplicativos na empresa de fabricação de tinta que precisam obter informações sobre um ativo, como um tanque, podem ir até um único local, ou seja, o servidor do modelo que hospeda o modelo instanciado, para acessar essas informações. Isso pode incluir informações em tempo real sobre o tanque (por exemplo, temperatura), informações históricas (como a temperatura média da semana) ou tipos mais complexos de informação (por exemplo, ordens de serviço abertas para esse tanque, ou tanques do mesmo tipo).
• As consultas feitas pelos aplicativos para obter informações operacionais sobre o tanque podem ser feitas usando um método de interface consistente (por exemplo, SPARQL), independentemente da verdadeira fonte das informações, como sistemas SCADA, banco de dados operacional ou um aplicativo (por exemplo, IBM Maximo ou SAP).
• A representação do tanque e da hierarquia empresarial em torno do tanque é consistente e é baseada nos padrões de mercado. Essa forma canônica permanece intacta, independentemente do formato subjacente usado nos sistemas de terminais.
• As informações sobre o tanque podem ser facilmente estendidas para apresentar novas informações consideradas úteis no futuro. Por exemplo, um novo requisito para relacionar às falhas de equipamento em um sistema de gerenciamento de ativo externo pode ser facilmente vinculado ao equipamento no modelo, de modo que as informações sobre a falha possam ser consultadas por meio do mesmo contexto de modelo. O modelo também fornece uma tela, baseada no contexto do mundo real, para simplificar a configuração de aspectos do controle de produção, como cálculo de KPIs (principais indicadores de desempenho), definição das ações necessárias para eventos operacionais e geração de alertas para problemas detectados. Agora, esse tipo de informação pode ser associado a um objeto no modelo e pode ser considerado confidencial para o contexto no modelo.
• Da mesma forma, as relações no modelo semântico facilitam muito para os aplicativos buscarem essas informações no modelo de forma lateral, para responder perguntas que talvez não tenham sido previstas na criação inicial do modelo. Por exemplo, talvez nossa empresa de tintas contenha tipos parecidos de motores que podem atender à mesma função, mas que são provenientes de fornecedores diferentes. Por meio de relações no modelo, como “Motor tipo A <é equivalente ao> Motor tipo B”, podemos produzir com facilidade um relatório mostrando características de desempenho de todos os motores semelhantes que estão sendo usados no momento na produção (em vários locais, se for necessário), de modo que possamos tomar decisões mais adequadas com relação ao fornecedor no futuro. Também podemos concluir que, ao fazer isso, precisamos de uma ação de manutenção para substituir um tipo de modo, uma vez que outro tipo está funcionando muito melhor. Observe nesse exemplo que as relações que mostram equivalência não precisam estar no modelo originalmente implementado e implantado, pois podemos adicioná-las posteriormente com base no novo conhecimento.

Conclusão

Neste artigo, analisamos o valor dos modelos semânticos no desenvolvimento de soluções de aplicativo. Discutimos essa arquitetura no contexto de várias arquiteturas de aplicativo amplamente usadas e conhecidas, centradas em dados, mensagens e serviços.

Descrevemos os modelos semânticos em termos gerais e discutimos como o produto IBM Integrated Information Core proporciona uma base fundamentada no modelo semântico para a criação de aplicativos que geram soluções de negócio.

Descrevemos com detalhes os principais geradores de valor. Resumindo, eles são:

Modelo de entidade de negócios: Use modelos de entidades de negócio (por exemplo, tanques e bombas) e seus relacionamentos para suportar as consultas de dados que podem existir em vários sistemas diferentes no contexto do mundo real. Esse é um conceito eficiente e nos permite estabelecer a inteligência entre as entidades (e sistemas subjacentes) para suportar análises e otimizações voltadas para aspectos como previsão de falhas, detecção de comportamento anormal e detecção e prevenção de problemas de qualidade do produto.

Namespace global: Estabeleça uma definição de nomenclatura comum e um método de acesso às informações. Assim, um aplicativo pode fazer referência às entidades, como ativos que vários subsistemas empresariais podem nomear e identificar de forma diferente, de forma que o aplicativo fique protegido e desconheça os detalhes desses subsistemas (por exemplo, sistemas SCADA ou DCS, Servidores OPC, SAP ou IBM Maximo).

Forma canônica: Defina uma forma canônica para fazer referência às informações associadas às entidades de negócio na empresa. Por exemplo, um tanque sendo usado para misturar tinta pode ter informações sobre a temperatura que podem ser obtidas de servidores OPC de nível inferior, ou ordens de serviço que podem ser obtidas do SAP ou do Maximo. Conforme mencionado anteriormente, é possível usar padrões de mercado para fornecer significados para essa forma canônica, que tem a vantagem de desenvolver definições e vocabulários aceitos para entidades comuns, como equipamento, locais, pessoal e muito mais.

Interface de aplicativo empresarial: Fornece uma interface global para os aplicativos consultarem e atualizarem as entidades de negócio e seus dados associados, de modo que o aplicativo não precise saber qual subsistema detém a propriedade de qualquer entidade específica ou dados associados (por exemplo, servidores OPC, SAP ou IBM Maximo). O aplicativo será fornecido com uma visualização empresarial completa dos dados, com base no modelo do mundo real que corresponde às informações. Isso simplifica muito a adição de novos sistemas subjacentes, pois as especificidades disso ficam ocultas por trás do modelo.

Recursos

Aprender

• IBM Integrated Information Core: obtenha mais informações sobre esse produto.
• IBM Integrated Information Core Information Center: acesse informações para instalação, manutenção e uso desse produto. 
• IBM Service Oriented Architecture: saiba mais sobre essa abordagem de arquitetura de TI centrada nos negócios. 
• W3C Web Services Architecture: Este documento define a arquitetura, identifica os componentes funcionais e define os relacionamentos entre esses componentes para obter as propriedades desejadas da arquitetura geral. 
• Open Applications Group: explore essa comunidade centrada no desenvolvimento de padrões de negócio com base em processos. 
• Core Components Technical Specification – Part 8 of the ebXML Framework: este documento do United Nations Centre for Trade Facilitation and Electronic Business contém informações que orientam a interpretação ou implementação de conceitos de ebXML.
• Ontologies and Semantic Web: acesse mais informações de Marek Obitko. 
• Jena – A Semantic Web Framework for Java: confira essa estrutura Java para desenvolvimento de aplicativos da Web semântica. 
• Introduction to Jena (developerWorks 2004): neste artigo, o desenvolvedor Philip McCarthy mostra como usar o Jena Semantic Web Toolkit para explorar os modelos de dados RDF em seus aplicativos Java.
• W3C – RDF Vocabulary Description Language 1.0: RDF Schema: saiba mais sobre essa linguagem para fins gerais para representação de informações na Web. 
• W3C – RDF Semantic: essa é uma especificação de uma semântica precisa e de sistemas completos correspondentes de regras de inferência, para Resource Description Framework (RDF) e RDF Schema (RDFS). 
• Simple Protocol and RDF Query Language (SPARQL): essa especificação define a sintaxe e as semânticas da linguagem de consulta SPARQL para RDF. 
• Understanding SPARQL (developerWorks 2008): leia esse tutorial que demonstra o uso do SPARQL por meio do exemplo de um sistema de rastreamento e journaling de equipe para uma empresa virtual.
• Fern Halper on semantic models: leia o que esse especialista em análise de dados e de negócios e desenvolvimento de estratégia tem a dizer sobre modelos semânticos. 
• Data-Oriented Architecture: Loosely Coupling Systems into Systems of Systems: Veja um artigo completo de Rajiv Joshi, publicado pela RTC em janeiro de 2008.
• Segmentos de mercado no IBM developerWorks: Obtenha todos os recursos técnicos específicos do segmento de negócio mais recentes para desenvolvedores. 
• Eventos técnicos e webcasts do developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões. 
• DeveloperWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
• Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.

Obter produtos e tecnologias

• Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste on-line no IBM SOA Sandboxe comece a usar ferramentas de desenvolvimento de aplicativo e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.

Discutir

• os blogs do developerWorks: Confira esses blogs e participe. 

Artigo originalmente publicado em http://www.ibm.com/developerworks/br/industry/library/ind-semanticmodels/index.html

Sobre os autores

Tim Hanis é o arquiteto líder no desenvolvimento do WebSphere Sensor Events na IBM em Research Triangle Park, NC.

Dave Noller tem 27 anos de experiência em desenvolvimento de software para aplicativos de fabricação e integração empresarial. Atualmente, Dave está trabalhando como arquiteto chefe de soluções para a Industrial Sector Frameworks na IBM.