Objeto de memória Modeling, mesa omm.

Objeto de memória Modeling, mesa omm.

Objeto de memória Modeling, mesa omm.

Abstrato

Este relatório resume as conclusões da memória Modeling Incubadora Grupo objeto. Um formato de memória de objeto baseado em XML é introduzido, que permite a modelagem de eventos ou outras informações sobre artefatos físicos individuais, e que se destina a apoiar o armazenamento de dados dos registos sobre os chamados "etiquetas inteligentes" ligado ao artefacto física. O grupo faz várias recomendações sobre a evolução futura do formato de memória de objeto no W3C; essas conexões de endereço para proveniência modelagem, a incorporação de memórias de objetos em páginas da web, e os benefícios potenciais de uma API de memória objeto.

Status deste documento

Esta seção descreve o status deste documento no momento da sua publicação. Outros documentos podem substituir este documento. Uma lista de finais Incubadora relatórios de grupo está disponível. Veja também a W3C relatórios técnicos índice em http://www.w3.org/TR/.

Incubadora Os grupos têm como objetivo produzir um trabalho que pode ser implementado em um Royalty título gratuito, conforme definido na Política de Patentes do W3C. Os participantes neste Grupo Incubadora fez nenhuma declaração sobre se eles vão oferecer licenças de acordo com os requisitos de licenciamento da Política de Patentes do W3C para partes deste Relatório do Grupo de incubadora que são posteriormente incorporada em uma recomendação W3C.

o missão da Memória Modeling Incubator Group (OMM XG), parte da Actividade Incubadora objeto. foi o seguinte: Para definir um formato de memória objeto. que permite a modelagem de eventos ou outras informações sobre artefatos físicos individuais, de preferência durante a sua vida, e, portanto, implementa um modelo de memória de objeto (OMM).

O formato de memória objeto deve ser concebido para suportar o armazenamento de dados sobre os chamados "etiquetas inteligentes" ligado ao artefacto física. Tais rótulos variam de códigos de barras, para RFID, para os nós sensores – miniaturizado sistemas embarcados capazes de realizar algum processamento, reunindo informações sensoriais e se comunicar com outros nós. O formato de memória objeto implementado em um "etiqueta inteligente" pode fornecer uma memória objeto. que pode servir como um coletor de dados para dados reais relativos a um artefato físico. Associando definições semânticas com os dados armazenados usando o formato de memória de objeto, pode ajudar a unir a Web Semântica com a Internet das Coisas.

Hoje, padrões heterogêneos já estão em uso para descrever as características individuais de um artefato físico em diferentes domínios de aplicação. O formato de memória objeto imaginado tem de complementar e abraçar essas normas dedicados à descrição dos itens físicos. A fim de facilitar a interoperabilidade em cenários que compreende vários domínios de aplicação (por exemplo, processos de negócios abrangendo a produção e logística) e cenários de circuito aberto (por exemplo, linhas de produção com muito diversas etapas do processo), o formato de memória objeto deve fornecer uma maneira padronizada para organizar e acessar o dados selecionados independentes do domínio de aplicação. Além disso, deve funcionar como uma camada tecnologicamente neutra para a entrega de conteúdo a partir de artefatos físicos para aplicações nos processos de negócios que vão desde gerenciamento de ciclo de vida do produto para suporte ao consumidor.

Requisitos gerais para a formatação da memória objeto incluem:

  • Independência do domínio de aplicação;
  • Independência de restrições técnicas impostas pela tecnologia de etiquetas inteligentes;
  • Abertura, flexibilidade, modularidade e escalabilidade

Um formato de memória objeto trata da organização, a descrição e a transformação da informação relacionada com o objeto. Assim, a utilização dos seguintes três componentes desempenha um papel proeminente:

  • Um modelo de estrutura define as características estruturais de uma memória objeto. Deve proporcionar uma abordagem flexível e extensível, de tal modo que qualquer potencial proprietário do objecto será capaz de enriquecer a representação com informação adicional em formatos arbitrários. Este modelo deve apoiar explicitamente os aspectos temporais e incrementais de acumulação de informação ao longo do ciclo de vida do objeto e permitir que descreve o estado do objeto em diferentes pontos no tempo. Além disso, ele deve permitir a descrever componentes activos, tais como sensores, utilizados pelo objecto de adquirir informação a partir do seu ambiente. Além disso, este modelo deve ser concebido de uma forma que facilita a sua adopção, em dispositivos de armazenamento de informações tecnicamente limitados, tais como chips RFID. Além disso, deve permitir um intercâmbio de informação eficiente entre os objetos.
  • Um conjunto de metadados bem definida permite uma caracterização superficial de um objeto físico, sem necessidade de acessar fontes de informações adicionais. Esses metadados (palavras-chave) deve ser usado por qualquer tipo de memória de objeto, a fim de facilitar a troca de informações em cenários com várias partes que interagem com o objeto.
  • Um formato de conversão deve fornecer uma maneira definida, mas flexível para transferir o formato de memória objeto em uma representação combinando os condicionalismos técnicos de vários tipos de rótulos que variam de etiquetas RFID para os nós sensores. Ele deve permitir a definição de mapeamentos entre uma representação baseada em XML do formato de memória objeto e formatos binários arbitrários com potencialmente fortes limitações técnicas.

O formato de memória objeto deve ainda proporcionar mecanismos de apoio: acesso a dados; interpretação de dados; e integridade de dados para informação distribuída ligada a um objeto.

A fim de explorar este tema, a seguinte sequência de trabalho foi planejada:

  1. Análise dos requisitos de armazenamento e processamento de dados no item física e externamente no ambiente. Notas: Isto inclui memórias de processamento de objetos sobre etiqueta inteligente do item físico.
  2. Definição de uma descrição estrutural para memórias objeto, que permite a definição de blocos de conteúdo e histórias de eventos para um objeto individual. Notas: Não há definições formais acordadas para a estrutura de memórias objeto no presente. Criando definições formais acordadas será uma tarefa do grupo incubadora. Além disso, as limitações impostas pelos aspectos físicos de tecnologia de etiquetas inteligentes deve ser tomado em consideração, a fim de permitir uma transferência destas estruturas a partir de cenários com base na web para etiquetas inteligentes.
  3. Definição de estruturas que facilitem o acesso ea descrição do conteúdo armazenado em memórias de objetos, tais como palavras-chave e estruturas de índice. Aqui, um determinado objectivo é definir essas estruturas de uma forma que permite o acesso direto rápido aos dados, mesmo após uma transferência (e conversão potencial) de tais estruturas para etiquetas inteligentes arbitrárias. Notas: Um requisito importante é registrar decomposição do produto em um "mundo aberto", Ou seja, essas estruturas devem estar prontos para extensões.
  4. Definição de uma descrição, que permite a especificação de fontes de dados remotas associadas, tais como sensores relacionados a objetos – fontes que possam alimentar a memória objeto com conteúdo. Notas: Seguindo o conceito relacionado de etiquetas inteligentes, um foco particular será sobre a descrição e tratamento das fontes de informação realmente ligados ao artefato físico.
  5. Definição de estruturas de apoio à reconversão das representações baseadas em XML para outros mais compacto (por exemplo binário), formatos adequados para diferentes tipos de tecnologia de etiquetas inteligentes. Notas: Esta etapa particular exigirão uma descrição formal do processo de mapeamento; a abordagem deve ser aberta e, assim, permitir que provedores de conteúdo para definir os seus próprios esquemas de mapeamento por seus respectivos conteúdos.

Combinando as expectativas iniciais emitidos em seu estatuto social. os esforços do grupo incubadora com foco em itens (1), (2) e (3) durante o seu tempo de execução um ano. O grupo começou a investigar itens (4) e (5); uma proposta correspondente de como lidar com esses temas – também como parte do trabalho futuro – está incluída neste documento. Durante o tempo de execução, o grupo alinhado as suas actividades de acordo com os critérios de sucesso da definição de um (re) estruturação utilizável, que

  1. Descreve uma características individuais e capacidades técnicas do artefato físico.
  2. Permite a representação e organização das histórias individuais de evento (e, portanto, a evolução das propriedades de um único artefato).
  3. Suporta a recuperação e acesso de mudar proprietários e usuários ao longo do ciclo de vida do produto.
  4. Está pronto para a tradução de acordo com (memória) restrições impostas pela tecnologia de etiquetas inteligentes.

Para uma discussão destes critérios com relação ao formato de memória objetivo proposto, por favor consulte a Secção 3.

A OMM XG procurou introduzir novas estruturas somente se necessários para a finalidade específica de modelagem de memória objeto. Por conseguinte, as actividades seguintes são consideradas relacionadas, mas fora do âmbito da finalidade deste grupo. Seus respectivos resultados foram abraçados, sempre que possível, a fim de facilitar a implantação de novos elementos criados como parte do modelo de memória objeto.

Este documento investiga e motiva características estruturais de um modelo para memórias objeto. Ele é destinado a leitores interessados ​​em diversas áreas.

A OMM foi investigada no contexto W3C por várias razões. Estes partilham a ideia de que ele deve ser opcionalmente possível armazenar objeto memórias na Web, a fim de facilitar a construção e comunicação de dados relacionados com o objeto:

  • Um log de eventos pode incluir informações sobre a manipulação de um objeto (por exemplo, mínimo ou máximo temperatura) que poderiam ser sinalizada se um evento crítico é registrado. Uma memória objeto poderia conter registros de leituras dos sensores periódicas (por exemplo, temperatura) que caracterizam o meio ambiente.
  • Um log de eventos poderia documentar processos relevantes durante o ciclo de vida de um objeto como a data de produção, controlo de qualidade e atividades de manutenção. Esta informação é importante quando as memórias de objetos são usados ​​em processos de produção complexos.
  • Um log de eventos pode documentar que as pessoas e / ou dispositivos interagiu com um objeto durante seu ciclo de vida.

Expressão Evento Comum (CEE – http://cee.mitre.org/about.html) é um projeto de normalização activa com foco em como os eventos de computador são descritos, registrados, e trocadas. Ao contrário de outras normas de registo de eventos que estão principalmente preocupados com os logs do servidor web como o formato de arquivo W3C Log Comum (http://www.w3.org/Daemon/User/Config/Logging.html) e formato de arquivo de log estendido do W3C (http: //www.w3.org/TR/WD-logfile.html) CEE visa melhorar os processos globais de auditoria e aumentar a interoperabilidade entre o evento e formatos de log.

CEE consta de um número de diferentes elementos e vai oferecer diferentes níveis de conformidade. A especificação contém de uma sintaxe log (CLS), que descreve como um evento e seus dados são representados. A recolha de possíveis campos de eventos e tipos de valor de registros de eventos são descritos através de um dicionário CEE ea CEE Taxonomia define um conjunto de tags que podem ser usados ​​para categorizar eventos. A comunidade CEE fornece recomendações de log (CELR) que são destinados a proporcionar as melhores práticas que dados para o registo e como registrá-lo. Finalmente outra parte da especificação (CLT) descreve o que é necessário suporte técnico (por exemplo, internacionalização, interfaces para a gravação de eventos) para apoiar o transporte de logs.

A OMM XG recomenda que lidar com o registo de eventos dentro de uma memória objeto da seguinte maneira:

  • Uma única OMM bloco pode ser usado para representar um único evento, tal como ilustrado na Secção 4.1. Seus metadados pode ser explorada para modelar o evento. Limitações desta abordagem são dois: Primeiro de tudo, se um aplicativo cria um grande número de eventos, então este pode "sobrecarregar" uma memória de objeto, e tornando-se assim difícil de lidar em cenários com fortes limitações no armazenamento de empregados e hardware interação. Em segundo lugar, a carga de tais blocos de eventos não é assunto do formato, que pode se tornar um problema se um registro tem de ser estabelecido através de várias aplicações.
  • Em alternativa, um aplicativo pode armazenar um log de eventos como carga útil de um bloco OMM. A opção de armazenar dados remotamente carga útil é de particular vantagem se grandes toras têm de ser representados. A fim de facilitar a comunicação sobre algum objeto entre aplicativos, a OMM XG recomenda contar com um formato de modelagem evento padronizada, em particular CEE.

Esta norma inclui um modelo de dados binários para descrever as principais características do sensor / atuador, bem como mecanismos de registo de eventos diferentes. Diferentes tipos de eventos e resumos (por exemplo, o valor máximo, significa) são dadas. Finalmente uma interface (também binária) para o transdutor é dado.

Por causa de seu foco em representações binárias e seu campo de aplicação restrito, a abordagem provavelmente não é directamente aplicável à nossa abordagem. No entanto, a sua extensa lista de tipos de eventos e mecanismos de registro é interessante.

Uma memória objeto visa permitir às partes diferentes para contribuir com dados para a memória (por exemplo, a fim de registrar a troca de um artefato entre parceiros de negócio), mas também para proporcionar uma distinção clara de todas essas contribuições. Como tal, a proveniência de uma memória objeto é duplo: Primeiro de tudo, a proveniência dos dados contribuíram tem de ser representada. Em segundo lugar e, dependendo dos casos de uso, a memória global pode representar a proveniência de um artefato. Aqui, a proveniência dos dados contidos não está restrito a um determinado assunto. A OMM se baseia em metadados a fim de apoiar a recuperação de dados contidos. A implementação de referência usa metadados baseado no Dublin Core Metadata (ver Secção 2.6), a fim de descrever a proveniência do conteúdo dentro da memória.

Portanto, a OMM está relacionada em certa medida para atividades dedicadas à modelagem de proveniência – como a proveniência Grupo de Trabalho do W3C. que é o objetivo de uma publicação generalizada e uso de informações proveniência dos documentos web, dados e recursos. A OMM podem contribuir para esta atividade. Por sua vez, um modelo de proveniência genérica (ou mapeamento) seria de uso particular para aplicativos baseados em OMM: é provável que cenários envolvendo partes de diferentes domínios de aplicação resultaria em memórias de objetos com conteúdo seguir diferentes modelos de proveniência.

O W3C expressou uma recomendação relativa a um formato eficiente XML Interchange (EXI). Ele especifica uma representação binária compacta para documentos XML, que poderiam ser aplicadas a fim de criar uma representação binária e altamente compacta de um OMM. Dos casos de uso do OMM, compacidade é, no entanto, não é o único requisito de uma representação binária OMM. Por exemplo, a OMM deverá apoiar um processo de produção distribuída (ver Secção 4.1), onde Controladores Lógicos Programáveis ​​(CLP) com capacidade de processamento única limitados são muito comuns. Estes não podem, eventualmente, analisar o completo OMM, mas ainda assim eles precisam ter acesso a determinadas informações da OMM. A fim de apoiar estes dispositivos em processos de fabrico existentes, deve ser possível identificar o endereço de byte exacta de certas partes de informação no OMM.

XML e, consequentemente, não permitem EXI para este, uma vez que, por exemplo, informações de comprimento para valores de atributos não é mantida. Uma representação binária OMM deve, portanto, ser especificado usando outros meios. A especificação de linguagem natural, juntamente com uma implementação de referência foi utilizado em Semprom. Esta abordagem tem, no entanto, não escala facilmente para casos de utilização maiores, deteriorando assim o benefício de normalização. Os mesmos inconvenientes segure por outras representações, como JSON, que são comumente usados ​​como representações mais compactos em vez de XML.

Do lado de fora do domínio de fabrico e de logística, linguagens como ASN.1 têm sido utilizados para identificar codificações binários para mensagens. Especificações ASN.1 são, no entanto, difícil de compreender e não é bem suportado em linguagens de programação. Mais recentemente, a necessidade de definição de codificações binárias ganhou algumas atrações da comunidade open-source e web, quando o Facebook e Google lançou o quadro Thrift e ProtocolBuffer respectivamente. Ambos são integrados em um número crescente de linguagens de programação, tornando a implementação de analisadores e geradores fáceis. Eles foram projetados para atingir um desempenho próximo ao que é possível com formatos binários artesanais, mantendo uma alta legibilidade e extensibilidade.

2.6 O Dublin Core ® Iniciativa de metadados

Juntamente com o modelo de dados genérico do W3C para metadados, a Resource Descritiva Framework (RDF), o Core Comunidade Dublin desenvolveu perfis de aplicação que conduzem à criação de um conjunto de metadados estendido com dados específicos de domínio especial, que nos permitiu usar alguns dos Dublin core metadados para os nossos propósitos e estendê-los com informações adicionais, em vez de definir um novo conjunto completo. Então usamos os atributos do núcleo título, descrição, Format, Criador, Contribuinte, Subject (parcialmente) como base para o nosso conjunto de metadados. Nós alargado a estes tipos de núcleo com recursos adicionais para apoiar as nossas necessidades e complementado-los com informações específicas de memória objeto auxiliar.

Esta seção resume uma proposta relativa a um formato de memória de objeto com base em XML, que implementa um modelo de memória objeto. Formato e modelo foram projetados para ser independente do cenário de aplicação; eles abordam critérios de sucesso do OMM XG (cf. ponto 1.2) da seguinte forma:

  1. O formato geral da memória objeto não impõe restrições especiais na descrição das características individuais de um artefato físico e capacidades técnicas -, a OMM XG considerados tais modelos estar fora do âmbito desta actividade (ver Secção 1.3). Assim, a aplicação (s) são livres para armazenar descrições de objetos detalhados na carga de blocos de memória. Além disso, um cabeçalho de memória e uma tabela de conteúdo fornecer dicas a respeito da presença destes dados.
  2. A memória é dividida em blocos. Ao longo do tempo, os novos blocos podem ser adicionados a fim de completar as informações sobre o objecto. Isto permite a representação e a organização de históricos de eventos individuais e, assim, a evolução das propriedades de um único artefato.
  3. O mecanismo baseado em blocos visa claramente contribuições separadas feitas mudando proprietários do artefato. A fim de proporcionar mais apoio para recuperação e acesso ao longo do ciclo de vida do produto, o formato de memória objeto define um pequeno conjunto de palavras-chave compartilhadas por cada instância de uma memória objeto. Entre outras características, essas palavras-chave permitem especificar informações sobre a proveniência do respectivo bloco.
  4. Protótipos demonstraram que a utilização de blocos é benéfico para uma tradução da memória de acordo com as restrições (memória) de capacidade imposta pela tecnologia de etiquetas inteligentes. Uma aplicação é livre para escolher um subconjunto de blocos da memória para o armazenamento de uma etiqueta presa ao artefato. O formato da memória objecto inclui uma definição de relação de memória, que podem ser empregues para ligar as várias partes de uma memória tão distribuído.

O formato de memória objetivo proposto partições uma memória objeto em vários blocos. Cada bloco contém um fragmento de informação específica e fornece um conjunto de metadados para facilitar as tarefas de busca em si os dados (veja a Figura 1). Esta lista de blocos é complementado com uma tabela opcional de conteúdos (TOC, ver Secção 3.2) e uma seção de cabeçalho. Este cabeçalho contém a versão do OMM, um identificador exclusivo primário ("ID primária") Para esta memória objeto e um link opcional com fontes bloco externos adicionais.

A OMM Header introduz uma nova memória objeto. Ele define a versão de codificação da memória e define um ID primário. Este ID primária é opcional, mas fixo para esta memória uma vez definido. Ele é usado para definir as relações entre uma memória objeto e outras memórias, blocos adicionais (externos), e outras estruturas (ver secção 3.4). Se não houver necessidade de tais relações, em seguida, o ID de primário é opcional; caso contrário, é necessária. IDs adicionais e temporárias para esta memória pode ser definida dentro de uma IDs bloco especial. Além disso, os blocos adicionais podem ser armazenados fora esse arquivo XML e ligados com esta memória dentro do cabeçalho.

Os exemplos a seguir mostra um cabeçalho OMM com a versão 1 ( lt; omm: versiongt ;. required), o URL "http://www.w3.org/2005/Incubator/omm/samples/p1" como identificação primária ( lt; omm: primaryIDgt ;. required) ea URL "http://www.w3.org/2005/Incubator/omm/samples/p1/ext" como fonte de outros blocos OMM ( lt; omm: additionalBlocksgt ;. opcional), que podem ser buscados via http (== gt; Tipo "omm_http").

Cada bloco de memória objeto contém informações sobre um tópico específico. Todos os blocos estão no mesmo nível, o arranjo dos blocos não implica qualquer ordem. Há nenhuma regulamentação de acesso e restrições definidas, então qualquer um que tenha acesso ao arquivo XML é permitido adicionar, alterar ou remover blocos sem quaisquer restrições. Devido a este fato, um aplicativo não pode agir na suposição de que um bloco de informação específica está disponível em um momento específico. Para permitir que usuários e aplicações para identificar blocos relevantes (ver Figura 2) um conjunto de metadados bloco indica o tópico do bloco, que é armazenado no payload bloco.

Figura 2: Um bloco OMM consiste em metadados e carga útil.

A seguinte lista mostra os atributos de metadados em detalhes:

  • identidade
  • Finalidade: Memory identificador exclusivo para este bloco
  • Tipo: String
  • Requeridos
  • Necessidade: O ID do bloco é usado para identificar um bloco dentro da memória da externa (memória ID primária + bloco ID) e para a ligação de entradas de índice para blocos.
  • Exemplo de código para declarar um novo bloco com id "block_123":
  • namespace
    • Objetivo: O namespace declara o conteúdo e sua codificação de uma forma única. blocos OMM bem definidas são identificados com o seu namespace (ver Secção 3.3).
    • Tipo: URL
    • Opcional (necessário se nenhum formato é dado)
    • Necessidade: Usado para declarar a estrutura da carga útil; permite que um aplicativo para selecionar apenas os blocos na verdade é capaz de processar.
    • Exemplo de código para declarar o URL "http://www.w3.org/2005/Incubator/omm/ns/sample" como namespace:
    • Formato
      • Finalidade: Define o formato / codificação da carga bloco, um tipo MIME se destina. texto interno é igual a Dublin Core "Formato" (Veja http://purl.org/dc/elements/1.1/format).
      • Tipo: tipo MIME as string
      • Atributos:
        • Schema (omm:. Esquema opcional): Uma definição de esquema XML para aplicação / xml tipo MIME.
        • Encryption (omm: criptografia opcional.): Um algoritmo de criptografia adicional utilizado para fixar a carga útil (por exemplo AES256)
        • Opcional (necessário se nenhum espaço para nome é dado)
        • Necessidade: Suporta analisadores durante o processamento da memória e utilizado como substituição de namespace ausente.
        • Exemplo de código que mostra um bloco com carga XML ("application / xml"), Nenhuma criptografia ("Nenhum") E uma definição de esquema XML adicional ("http://www.w3.org/2005/Incubator/omm/schema/sample.xsd"):
        • O Criador
          • Objetivo: Indica a data da criação do bloco e a identidade do criador. Igual a Dublin Core "O Criador" (Veja http://purl.org/dc/elements/1.1/creator).
          • Tipo: Um elemento estruturado, contendo uma informação de data e uma entidade (ver exemplo de código).
          • Requeridos
          • Necessidade: Usado para o registo, proveniência e fins de verificação legais.
          • Exemplo de código que mostra informações de criação da entidade criador "195505177" do tipo "DUNS" e timestamp ("30 de janeiro de 2011 18:30"):
          • Contribuinte
            • Objetivo: Indica a data da contribuição bloco e a identidade do contribuinte. Igual a Dublin Core "Contribuinte" (Veja http://purl.org/dc/elements/1.1/contributor).
            • Tipo: Um elemento estruturado, contendo uma informação de data e uma entidade (ver exemplo de código).
            • Opcional
            • Necessidade: Usado para o registo, proveniência e fins de verificação legais.
            • Exemplo de código que mostra informações contribuição da entidade contribuinte "user@example.com" do tipo "o email" e timestamp ("31 de janeiro de 2011 08:12"):
            • Título
              • Objetivo: Fornece um texto claro, multi-linguagem e legível curta; título para o conteúdo do bloco (lt 255 caracteres). Igual a Dublin Core "Título" (Veja http://purl.org/dc/elements/1.1/title).
              • Tipo: String.
              • Atributos:
                • Lang (xml:. Lang obrigatório): indica o idioma do texto do título (ISO 639-1).
                • Requeridos
                • Necessidade: Usada para apresentar texto legível para os usuários finais.
                • Exemplo de código que mostra dois títulos no idioma Inglês e Alemão:
                • Descrição
                  • Objetivo: Fornece um texto claro, multi-linguagem e a descrição legível (versão longa do título) para o conteúdo bloco. Igual a Dublin Core "Descrição" (Veja http://purl.org/dc/elements/1.1/description).
                  • Tipo: String.
                  • Atributos:
                    • Lang (xml:. Lang obrigatório): indica o idioma do texto de descrição (ISO 639-1).
                    • Opcional
                    • Necessidade: Usada para apresentar texto legível para os usuários finais.
                    • Exemplo de código que mostra duas descrições no idioma Inglês e Alemão:
                    • Tipo
                      • Igual a Dublin Core "Tipo" (Veja http://purl.org/dc/elements/1.1/type).
                      • Tipo: String (Dublin Core "Tipo")
                      • Opcional
                      • Necessidade: Informações adicionais para sistemas de reconhecimento de Dublin Core.
                      • Exemplo de código que mostra um bloco tipo de Dublin Core "dataset":
                      • Sujeito
                        • Finalidade: marcas de texto grátis e ontologia conceitos (RDF ou OWL) para descrever a carga bloco. Tag do assentamento permite a criação de uma hierarquia tag. tags aninhadas pode ser analisado apenas como tags padrão, mas também levar um pai / filho semântica (ver exemplo de tag "e12 é subconcept de din é subconcept de normas"). assuntos de texto são baseados em Dublin Core "Sujeito" (Veja http://purl.org/dc/elements/1.1/subject).
                        • Tipo: Um elemento estruturado para a codificação de ontologia e marcas de texto hierárquicos (ver exemplo de código).
                        • Opcional
                        • Necessidade: Permite a livre marcação de blocos.
                        • Exemplo de código que mostra uma tag assunto ontologia base ("http://o.org/def.owl#ManufacturerData"), E duas marcas de texto com base. O primeiro como texto simples ("ingredientes") Eo segundo como o conceito de texto hierárquico ("norms.din.e12")
                        • Ligação
                          • Finalidade: Se a carga de bloco não é incorporado directamente na estrutura XML, em seguida, uma ligação pode ser fornecida para indicar uma relação a um bloco de carga proveniente de saída em qualquer local.
                          • Tipo: Um link para um recurso externo (geralmente um URL).
                          • Atributos:
                            • Tipo (omm: tipo exigido.): Indica o tipo de ligação (por exemplo, URL)
                            • Hash (omm:. Haxixe opcional): Um valor de hash SHA-256 dos dados vinculados, para fins de integridade de dados para garantir que os dados foi modificado.
                            • Opcional (obrigatório, se não houver "carga paga" é dada)
                            • Necessidade: Permite que a terceirização de grandes dados de payload para recursos externos.
                            • Exemplo de código que mostra um link para o recurso externo ("http://www.w3.org/2005/Incubator/omm/samples/p1/ext.xml") Do tipo "URL" e valor de hash adicional ("d32b568cd1b96d459e7291ebf4b25d007f275c9f13149beeb782fac0716613f8"):
                            • carga paga

                              • Objectivo: Permite o armazenamento de carga em linha como alternativa para a estrutura ligada.
                              • Tipo: CDATA (texto simples ou estruturas XML).
                              • Atributos:
                              • Encoding (omm: encoding opcional.): Indica a codificação binária utilizada para esta carga útil (por exemplo, "base64")
                            • Opcional (Obrigatório, se não houver "Ligação" é dada)
                            • Necessidade: inline carga útil, sem a necessidade de qualquer armazenamento externo.
                            • Exemplo de código (1) mostrando uma cadeia de texto simples como carga útil:
                            • Exemplo de código (2) mostrando uma cadeia de texto base64 codificado como carga útil:
                            • Exemplo de código (3) mostra uma estrutura XML incorporado proprietário como carga útil:
                            • A caixa a seguir mostra uma amostra completa de um bloco OMM com vários metadados, link e informações de carga (apenas para este exemplo, uma vez link e carga normalmente não aparecem no mesmo bloco):

                              Figura 3: A Tabela OMM de conteúdo compreende um subconjunto de metadados de cada bloco.

                              A entrada de índice se baseia em um subconjunto de atributos de metadados uma de OMM Bloco (veja a Figura 3). É necessário compartilhar os atributos de identificação da OMM Bloco referenciados ("identidade" e também "namespace", "Formato" ou ambos). Ao usar o mesmo ID no bloco e o índice, a entrada de índice está ligada ao bloco correspondente. Além disso, os atributos "O Criador" e "Título" são recomendados para uma entrada de índice se eles são definidos no bloco correspondente. Todos os outros atributos são opcionais, mas pode ser definido no índice, a fim de fornecer suporte adicional para a busca de uma memória objeto.

                              O seguinte exemplo de código XML mostra uma possível entrada de índice para a OMM Bloco mencionado na Seção 3.2:

                              O formato de memória objeto inclui um pequeno conjunto de modelos relativos à carga útil de um bloco OM. Se um bloco está fazendo referência a um tal modelo, denota-se uma "bloco padronizado". Estes blocos podem ter uma função especial no que respeita a memória do objeto (e, assim, implementar um aspecto da OMM), ou se dirigir aplicações básicas de uma memória objeto. No geral, blocos padronizados são destinadas a facilitar a comunicação entre as diferentes aplicações rodando na mesma memória objeto.

                              O exemplo a seguir ilustra como dois identificadores são atribuídos a um objeto, uma do tipo "URL" ("http://www.w3.org/2005/Incubator/omm/samples/p2") E um de tipo "o email" ("p2@producer.org").

                              É digno de nota que as implementações destes exemplos – que foram exploradas em atividades relacionadas, consulte a Seção 1.1 – dependem de vários tipos de dispositivos de interação e arquiteturas de armazenamento. Combinando a diversidade de situações que podem exigir acesso a um OMM, estes podem até mesmo mudar em um único aplicativo. Por exemplo, o cenário descrito na Secção 4.5 podem requerer híbrido acesso através de um dispositivo móvel para um técnico, bem como através de uma aplicação de controle de desktop por um supervisor, ambos ligados através de um híbrido infra-estrutura que envolve o armazenamento OMM no artefato (através de uma etiqueta inteligente) e um servidor web. Estes aspectos são negligenciados no contexto do presente documento devido ao seu foco no aspecto de modelagem da OMM, mas podem exigir mais atenção.

                              O seguinte exemplo de código XML apresenta o conteúdo da memória (com OMM cabeçalho e tabela OMM de conteúdo e um link para blocos adicionais dessa memória) para os casos de aplicação descritos a seguir:

                              • Timestamps sobre eventos específicos de produção
                              • Encaminhamento acabamento start / roteamento
                              • O início da produção / acabamento de produção
                            • informações do histórico processo
                              • Encaminhamento de sucesso acabado
                              • Routing terminou com erros
                              • verificação de qualidade bem sucedida
                              • eventos inesperados
                              • informações ambiente de processo
                                • ferramentas utilizadas
                                • funcionários envolvidos e suas habilidades
                                • Consumo de energia
                                • Em diferentes cenários (por exemplo, varejo, empresas sociais, coletores) é muitas vezes percebida como desejável ter informações de procedência sobre a origem de um objeto ou interações anteriores com um objeto. O conhecimento sobre a história de um objeto pode afetar o comportamento do consumidor e agregar valor a um objeto. Exemplos disto são adicionadas informações sobre o produtor de um produto, tais como em uma loja de comércio justo, informações sobre proprietários anteriores do objeto em cenários que lidam com bens em segunda mão e, geralmente, de interações das pessoas com um produto ao longo de seu ciclo de vida . Esta informação proveniência pode incluir meios diferentes e pode ser aberta terminou em sua estrutura.

                                  Figura 4: Tales of Things emprega memórias objeto a fim de apoiar os seres humanos na comunicação sobre os objetos.

                                  A OMM quer apoiar o uso de vários identificadores e classificações. OMM oferece uma IDs bloco padronizado. o que facilita o armazenamento de identificadores e classificações dentro do bloco do bloco de elementos XML.

                                  Cenários futuros industriais e automação vai envolver processos de produção descentralizados. Por exemplo, subcontratados serão escolhidos na mosca. Para apoiar esta nova flexibilidade é desejável para coletar todas as informações específicas do produto relacionado com a produção e para armazená-lo nas partes do produto como parte de uma memória objeto.

                                  A OMM é adequado para descrever a única produções etapas e tarefas de manipulação que têm de ser executadas em cada produto. acções de manipulação Só esta abordagem de gestão do conhecimento centrado no produto, no qual os produtos de que necessitam se comunicar ("Preencha 3 comprimidos do tipo A e perto bin com tampa") Ou as estratégias de despacho ("Preferem empregos de tempo críticos") Para os sistemas de produção, permite a concepção eficiente dos processos de produção descentralizadas robustas e flexíveis.

                                  A forma mais simples de um processo de produção descentralizada pode ser implementada com uma memória objeto que só tem informações sobre o produto estática específica (por exemplo, ID do produto, a cor do produto, timestamp de produção, qualidade do produto). Em cada passo de produção, a informação é lida a partir da memória de acordo com os objetos e as acções de manipulação e manuseamento operações são derivadas no processo de controlo e, em seguida, realizado sobre o produto. Portanto, o produto e a informação na sua memória de objecto pode ser considerado "passiva" enquanto que os algoritmos de controlo e manuseio são aplicadas no controlo de processo (de cada módulo de produção).

                                  Este caso de uso aborda sistemas descentralizados para a produção em massa, ajudando a manter um alto grau de automação no processo de produção. A variação entre os produtos individuais armazenados na OMM é limitado ao que a linha de produção automatizada pode atingir.

                                  Em cenários de produção componentes são muitas vezes montados para criar um objeto de valor mais elevado. No caso de objetos de alta classe, como automóveis, turbinas, ou tomógrafos de computador, é razoável supor que mesmo os componentes são importantes o suficiente para ter sua própria memória objeto. Os exemplos podem ser a caixa de velocidades de um automóvel ou a secção de baixa pressão de uma turbina.

                                  Enquanto o novo objecto montado terá sua própria memória de objeto, a informação dos componentes montados devem ficar acessíveis e mutável. Para um manuseamento razoável de que deve ser possível construir-se uma estrutura de dados que reflecte os objectos montagem. Se as peças de produtos de alto valor falhar, essas peças são reparados ou trocados. Deve, portanto, ser possível alterar a estrutura que reflete os objetos de montagem. As peças podem ser adicionados ou removidos, as ligações entre as peças podem ser alteradas. Se uma parte deixa o objeto (é desmantelada) de memória do objeto deve refletir seu ciclo de vida completo, incluindo a sua vida como uma parte do objeto. Isto é, uma parte deve se lembrar onde ele foi. Em contrapartida o objeto inteiro deve também ser capaz de registrar as informações sobre as suas peças desmontadas. (Por exemplo, um automóvel deveria "conhecer" que o motor foi substituído duas vezes. Um motor reinstalado deve saber se ele foi instalado anteriormente em outro carro.)

                                  Figura 5: Uma memória objeto é utilizado para documentar a história montagem de um objeto complexo.

                                  O seguinte exemplo XML mostra um bloco OMM, que descreve dois links para outras memórias objeto. o lt; omm: namespacegt; identifica este bloco como Bloco Estrutura. As duas referências na carga útil são IDs com um atributo relação adicional ("hasPart"), O que mostra que o objeto atual tem uma parte adicional ("http://www.example.com/omm/samples/part1") E outra parte foi, mas não faz mais parte da ("http://www.example.com/omm/samples/part2"). Estas peças, por sua vez terá um bloco Estrutura com uma relação inversa ("é parte de"), Que não é visível no presente exemplo (porque é um elemento de uma outra memória objecto).

                                  Em cenários industriais e automação é desejável ter a capacidade de adicionar informações ao objeto memórias que devem estar indisponível para leitura pública, pois destina-se apenas algum grupo especial do usuário. Por exemplo, usuários de memória objeto pode querer adicionar informações sobre os processos confidenciais de produção, dados baseados em licença ou informações destinados para a comunicação bilateral.

                                  O seguinte exemplo XML mostra um bloco com AES256 criptografado dados binários codificados como texto Base64. A combinação de dados armazenada em lt; omm: namespacegt; e lt; omm: creatorgt; permite aos usuários detectar se eles são capazes de decifrar este bloco ou não (por exemplo, o namespace "encSample" eo criador "user@example.com" indica a chave AES necessário).

                                  A OMM XG conclui que um modelo unificado para as coleções de informação sobre artefatos pode ser alcançado, e propõe uma estrutura para tal modelo de memória objeto. Os casos de uso deste modelo são ilustradas com base em uma implementação baseada em XML deste modelo, o formato de memória objeto. Em relação à direção futura deste trabalho, o grupo formula as seguintes recomendações:

                                  1. Recomendação ("blocos padronizados – modelo"): A padronização de blocos de memória para aplicações específicas (ver secção 3.4) pode exigir uma discussão mais aprofundada. Por um lado, os blocos adicionais padronizados (por exemplo, para determinados domínios ou fases de um ciclo de vida do produto) pode ser introduzido, de modo a facilitar a comunicação entre os intervenientes no processo. Por outro lado, uma especificação mais complexa pode aumentar os esforços necessários para integrar o modelo objecto de memória em sistemas já existentes. Portanto, a OMM XG recomenda a investigar, com base em aplicações OMM, se e quais blocos devem ser padronizados.
                                  2. Recomendação ("modelo – proveniência"): Como discutido na Seção 2.4. avanços em matéria de modelagem de proveniência pode sugerir uma adaptação dos aspectos proveniência dentro do modelo de memória objeto e objeto formato de memória. A OMM XG estabelecido um contacto à proveniência Grupo de Trabalho do W3C e recomenda a investigar este tópico em cooperação com este grupo.
                                  3. Recomendação ("formato"): O formato de memória objecto usado no contexto do presente documento baseia-se num esquema XML particular. No entanto, outros formatos podem implementar o modelo de memória objeto assim. Por exemplo, a sua estrutura semelhante e tratamento de metadados pode qualificar o Atom Syndication Format como uma ferramenta para expressar um modelo de memória objeto. A fim de ilustrar a viabilidade de tais definições alternativas, a OMM XG preparado exemplos de formatos de memória objeto alternativas com foco especial sobre a incorporação de uma memória objeto em páginas da web, por exemplo, com base no RDFa. ou HTML5 e microdados.
                                  4. Recomendação ("formato binário"): A OMM XG recomenda a dedicar atenção aos pontos em aberto de acordo com a seqüência de trabalho especificado na Seção 1.2. Estes enfatizam o papel do ambiente de hardware e software em que um modelo de memória objeto seria implantado. Como discutido na Seção 2.5. capacidade e processamento de memória limitações dos dispositivos presentes em um ambiente como esse sugerem um formato de memória objeto altamente eficiente, por exemplo, na base de uma representação binária. A fim de explorar este tema, a OMM XG conduzida primeiras experiências relativas a um formato binário OMM.
                                  5. Recomendação ("interface"): Alguns casos de uso sugerem que o formato de memória objeto pode ser encontrado em dispositivos, bem como estruturas baseadas na web e interação híbrido envolvendo os dois aspectos podem ocorrer (ver, por exemplo, a Seção 4.5). Portanto, o grupo recomenda adicionar uma meta adicional para o charter – a especificação de um modelo API memória objeto, que apoia e unifica a interação com dispositivos que transportam uma memória objeto. Como um primeiro passo, o grupo estabeleceu contato com o dispositivo W3C APIs Grupo de Trabalho, a fim de discutir este objetivo.

                                  Como consequência destas observações, a OMM XG recomenda para continuar investigando o tema da modelagem de memória objeto dentro do W3C – no âmbito de actividades afins aos tópicos mencionados na Seção 1.4 ou como objecto de uma nova atividade.

                                  Nós gostaria de agradecer Jörg Neidig, Thorbjørn Hansen, Markus Miche, Boris Brandherm, Jörg Baus, e Massimo Romanelli para os seus conselhos e apoio.

                                  posts relacionados

                                  • Omt mesa – Resultados do conteúdo, mesa OMT portátil.

                                    Berlusconi e Five Star o risco de cauda – OMT a má notícia para a Alemanha. tópicos abertos que nossa cobertura italiana traz para a mesa do novo governo, Mecanismo Europeu de Estabilidade – WOW .com …

                                  • Oakworks Nova Mesa de Massagem limitada …

                                    A Nova Massagem Pacote Tabela Oakworks inclui tudo que você precisa para começar seu negócio de massagem móvel a um preço incrível. O Nova é a tabela de Oakwood top-of-the-line de massagem e …

                                  • Plants uma lista de Z, planta uma lista de Z.

                                    A descrição do conteúdo, criação e utilização da lista Planta segue. A Lista de planta não é perfeito e representa um trabalho em andamento. O nosso objectivo era produzir uma lista de ‘melhor esforço’ para …

                                  • Raised Bed Jardinagem Construção Blog …

                                    Como construir uma cama levantada fora de blocos de concreto Construindo uma cama levantada fora de blocos de concreto é fácil e se você assistir os anúncios locais provavelmente você pode obter o material para livre (que eu fiz para …

                                  • Pele pontos circulares vermelho, pele pontos circulares vermelho.

                                    Tenha algum de vocês experimentaram manchas secas aleatórios todo o seu rosto? Tentei esfregar meu rosto no chuveiro, que leva a pele morta de distância, mas deixa manchas escuras. Como posso me livrar dele? Eu sinto…

                                  • assuntos regulatórios certificação …

                                    Desde o início de 1980, O Grupo de Reguladores, Inc. (TRG) realizou inúmeros cursos sobre a regulação escrita, o processo de regulamentação e orientação agência. Os cursos de formação listadas na …