Overview

ROBOT fornece uma forma padronizada mas configurável para suportar o ciclo de vida do desenvolvimento de ontologia através de uma biblioteca de funcionalidade comum de alto nível e uma interface de linha de comando. O robô baseia-se na API OWL e é compatível com todos os sintaxes ontológicos que a API OWL suporta: RDF/XML, OWL/XML, tartaruga, sintaxe funcional OWL, sintaxe Manchester OWL, e formato OBO. O código fonte é escrito em Java e está disponível em nosso repositório GitHub sob uma licença open source (BSD 3). Ele também é lançado como uma biblioteca Java na Maven Central. O código robô pode ser usado a partir de qualquer linguagem de programação que roda na máquina virtual Java (JVM). A ferramenta de linha de comandos é empacotada como um arquivo JAR que pode ser executado em Unix (incluindo macOS e Linux), Windows e outras plataformas suportadas pelo JVM. Este arquivo JAR está disponível para download a partir do site GitHub robô, juntamente com scripts específicos da plataforma para usar ‘robô’ a partir da linha de comando. As instruções de instalação e a documentação estão disponíveis em http://robot.obolibrary.org.

Arquitectura

descrevemos previamente a arquitectura básica da ferramenta , que resumimos aqui.

o código-fonte do ROBOT consiste em duas partes: “robot-core” e “robot-command”. ‘robot-core’ é uma biblioteca que suporta tarefas comuns de desenvolvimento de ontologia, que chamamos de “operações”. o ‘robot-comando’ fornece uma interface de linha de comando dividida em “comandos”, cada um dos quais envolve uma operação de ‘robot-núcleo’.

A maioria das operações de robôs empacotam funcionalidades de baixo nível fornecidas pela OWL API em funcionalidades de alto nível comuns aos fluxos de trabalho de desenvolvimento ontológico na comunidade OBO. Para melhor compatibilidade, temos como objetivo combinar a versão exata da API OWL usada pelo robô com a versão exata usada pela última versão protegida. Algumas operações usam Apache Jena . Cada operação funciona com objetos Java que representam ontologias de coruja, raciocínios de coruja, classes de coruja, etc., enquanto cada comando trabalha com strings e arquivos de opção de linha de comando. Os comandos também executam várias etapas de conversão e validação. A interface de linha de comando usa a biblioteca Apache Commons CLI para processar comandos.

cada operação tem um conjunto de testes de unidade construídos com o JUnit que são executados cada vez que o produto final (o arquivo JAR) é gerado. Cada comando em robô é documentado em sua própria página web (por exemplo, http://robot.obolibrary.org/reason). As páginas web são de autoria no formato Markdown e contêm exemplos embutidos de linha de comando que são processados e executados como parte de nossos testes de integração, com os resultados comparados com um conjunto de saídas “padrão-ouro”. A funcionalidade ‘diff’ do robô é usada na comparação de arquivos de ontologia, caso contrário é usada a comparação padrão de arquivos. Isso ajuda a garantir a correção e consistência da documentação e do Código. Os testes de unidade e os testes de integração são executados em qualquer pedido de puxar para a base de código através de Travis continuous integration (Travis CI) , de modo que as contribuições para a base de código são verificadas.

comandos e operações

ROBOT fornece actualmente 15 operações (na biblioteca’ robot-core’) e 19 comandos (para a interface da linha de comandos). Alguns comandos são bastante especializados, e a maioria dos projetos de ontologia não fará uso de todos eles. Aqui nós fornecemos uma visão geral dos comandos mais comuns e gerais. Em cada caso, a funcionalidade principal é suportada por operações na biblioteca ‘robot-core’, que pode ser usada independentemente da interface de linha de comando de qualquer linguagem de programação que corre na JVM.

Convert

uma variedade de formatos ontológicos OWL são suportados, incluindo RDF/XML, Turtle, Manchester, formato OBO, e muito mais. Para permitir uma maior interoperabilidade, o robô inclui um comando “convert” para mudar entre os formatos de ontologia suportados. Uma lista completa de formatos suportados pode ser encontrada na documentação ‘convert’.

raciocínio

raciocínio é uma das operações mais importantes no robô. O comando “razão” abrange dois usos: validação lógica de uma ontologia e classificação automática. Em ambos os casos, os usuários podem escolher o seu reasoner preferido, que é usado para realizar inferência. Ontologias grandes como a ontologia do Gene normalmente usam alces, que realiza raciocínio rapidamente usando o perfil da coruja EL. Ontologias menores com axiomatização mais rica, como a ontologia das relações, normalmente usam uma “Owl DL reasoner” completa como Ermitão .

Quando o comando’ reason ‘ é invocado numa ontologia de entrada, o robô iniciará um reasoner usando a interface do Reasoner da API OWL. As inferências resultantes são verificadas para garantir que a ontologia é logicamente coerente: a ontologia deve ser consistente e não ter classes não-tributáveis (i.e., classes que não podem ser instanciadas sem introduzir uma inconsistência). Se a ontologia é incoerente, isto é relatado e a execução pára. O robô pode, opcionalmente, realizar verificações adicionais, tais como garantir que não se inferem duas classes como sendo post-reasoning equivalentes.se a ontologia for consistente, o robô executará a Classificação automática. Todos os axiomas “subclassos” diretamente inferidos são adicionados à ontologia. A geração de outros tipos de axiomas pode ser configurada.

a afirmação de todos os axiomas inferidos é muitas vezes um passo fundamental no processo de liberação para ontologias Biomédicas. Muitas dessas classes de ontologia afirmam apenas uma única superclasse chamada (‘uma subclasse de B’, onde B é outra classe na ontologia), e zero ou mais superclasses anônimas e/ou classes anônimas equivalentes (‘uma subclasse de/equivalente (R algum B)’, onde R é uma propriedade de objeto). Essas classes anônimas permitem que o reasonista Faça inferências, que são então afirmadas. Portanto, na versão de lançamento de uma ontologia, uma classe pode ter mais de uma superclasse chamada.

o comando ‘reason’ tem comandos “helper” adicionais. O comando “relax” afirma que uma subclasse de axiomas de acordo com uma regra estrutural simples: uma expressão “a equivalentTo (R algum B) e … “implica” uma subclasse de R algum B”. Isso pode ser útil como consumidores de bio-ontologias muitas vezes esperam navegar por essas expressões, por exemplo, partonomia em GO e Uberon. O comando ‘relax’ alivia o desenvolvedor de ontologia da necessidade de afirmá-los, além dos axiomas de equivalência, e como tal, também é muitas vezes incluído em fluxos de trabalho de lançamento. Finalmente, o comando’ reduzir ‘remove subclasse redundante de axiomas, e pode ser usado depois de’ relaxar ‘ para remover axiomas duplicados que foram afirmados nessa etapa.

o comando’ materializar ‘usa uma expressão que materializa o Reasoner (EMR) para afirmar expressões inferidas da forma’ a subClassOf R some B’. Onde o comando “razão” afirma inferidas superclasses chamadas, “materialize” afirma superclasses anônimas. Isto não faz parte do ciclo de lançamento padrão, mas pode ser benéfico para a criação de subconjuntos ontológicos completos.

trabalhando com ontologias externas

a Fundação OBO tem como objetivo coordenar ontologias de forma modular, de modo que partes de algumas ontologias podem ser usadas como blocos de construção para outras ontologias. Por exemplo, a ontologia das entidades químicas de ChEBI é usada para construir definições de coruja para processos metabólicos e atividades na ontologia genética . Há uma variedade de estratégias diferentes para alavancar ontologias externas e gerenciar dependências entre ontologias, dependendo do caso de uso.o comando ‘extract’ cria um módulo baseado num conjunto de Entidades a extrair (a “semente”). Existem quatro métodos de extração diferentes (conforme especificado pela opção “– method”): MIREOT, TOP, BOT e STAR.o método de extração de MIREOT do robô é baseado no princípio do mesmo nome e requer que uma ou mais Entidades “de baixo” sejam especificadas. Opcionalmente, uma ou mais entidades “top” também podem ser especificadas. O comando extrai todas as Entidades de nível” inferior “e seus ancestrais até o nível” superior ” da ontologia de entrada. Se nenhuma entidade ” top ” é fornecida, os antepassados até a entidade de nível superior (‘owl: Thing’) são incluídos.

os métodos TOP, BOT e STAR fazem uso da implementação do módulo de extração sintática da localidade OWL API (SLME), que é garantida para capturar todas as informações logicamente relevantes para o conjunto de sementes . O método BOT (“bottom”) inclui todas as relações entre as Entidades de entrada e seus ancestrais. O método TOP inclui todas as relações entre as Entidades de entrada e seus descendentes. Finalmente, o método STAR apenas inclui todas as relações entre entidades de entrada. O método STAR produz as menores Saídas, enquanto o método TOP normalmente produz as maiores saídas.

A fim de suportar a proveniência do termo ontológico, o comando’ extract ‘tem uma opção’ –annotate-with-source true ‘ que irá anotar cada termo extraído com o URL da ontologia de origem da qual é extraído.

remover e filtrar

os comandos’ remover’ e’ filtro ‘ são usados para operações de grão fino nos axiomas da coruja. ‘remover’ permite aos usuários escolher quais conjuntos de axiomas eles desejam remover de uma ontologia alvo. o ‘filtro’ faz o oposto, de modo que apenas axiomas selecionados são copiados da entrada para uma nova ontologia de saída.

estes dois comandos funcionam começando com um conjunto de entidades semente, então aplicando vários seletores para encontrar entidades relacionadas, e finalmente selecionando quais tipos de axiomas para remover ou filtrar. Nós esperamos apenas um pequeno número de “Usuários de energia” para usar este recurso diretamente, mas esses comandos eventualmente fornecerão uma base para outros comandos de nível superior.

estes comandos podem ser usados para gerar subconjuntos de ontologia baseados em anotações, filtrando ou removendo entidades com a anotação especificada. Ontologias OBO Foundry muitas vezes anotam classes com a propriedade ‘no subconjunto’ para especificar onde uma classe pode ser usada. O selector de anotações permite que um utilizador forneça um valor de anotação completo ou um padrão correspondente com a expressão regular.

Merge

o comando ‘merge’ combina duas ou mais ontologias de entrada separadas numa única ontologia. Ele também fornece a capacidade de juntar todas as ontologias importadas de uma única ontologia de entrada em uma ontologia principal, que é muitas vezes usado ao criar uma versão.

A junção das ontologias importadas (indicadas pelas declarações de importação) na ontologia de entrada é realizada automaticamente, de modo que o utilizador não precisa de listar cada ontologia importada como uma entrada. Oferecemos a opção (‘–collapse-import-closure false’) para desligar esta funcionalidade, suportando os casos em que os utilizadores podem fundir múltiplas ontologias de entrada que têm declarações de importação, mas querem manter as suas importações separadas.

questionando e reportando

ontologia workflows tipicamente incluem operações de consulta sobre a ontologia, produzindo relatórios que podem ser informativos para editores e usuários da ontologia — por exemplo, uma tabela de todas as classes mais suas definições textuais. As operações de consulta também podem ser usadas para verificações de validação. A linguagem de consulta SPARQL fornece uma forma universal e declarativa para mantenedores de ontologia para criar relatórios de Ontologia e verificações de validação . O ROBOT oferece uma forma conveniente de efectuar consultas com o comando “query”, ou verificações de validação com a opção “Verificar”. Além disso, o comando’ report ‘ inclui um pacote configurável de consultas padrão para projetos OBO que podem ser usados em qualquer fluxo de trabalho ontológico, sem exigir que o mantenedor esteja familiarizado com o SPARQL.

Query

ROBOT’s’ query ‘ command runns SPARQL queries on ontologies or other RDF resources. Isto pode ser usado por um mantenedor de ontologia para realizar consultas interativas, ou mais tipicamente para incluir consultas padrão em um fluxo de trabalho de ontologia. O comando ‘query’ envolve uma das poucas operações que usa Apache Jena , em vez de OWL API. A API Jena permite que o robô carregue uma ontologia como uma coleção de triplos contidos por um objeto modelo RDF. Ele fornece um motor de consulta SPARQL para esses modelos, que usamos para executar todas as consultas.

‘SPARQL SELECT’ queries produce a comma – or tab-separated table of results. Perguntar se as consultas produzem um ficheiro com um valor booleano. As pesquisas ‘SPARQL CONSTRUCT’ produzem um arquivo RDF, que pode ser processado posteriormente pelo robô ou mesclado de volta para a ontologia carregada. ‘CONSTRUCT’s provide a convenient way of performing “macro” style expansion . Consultas “SPARQL UPDATE” inserir e/ou remover dados diretamente em uma ontologia (como um modelo RDF). O robô converte o modelo RDF atualizado de volta para um objeto ontológico da API OWL para ser salvo em qualquer um dos sintaxes suportados.

o comando ‘ query ‘suporta uma opção para carregar ontologias importadas como gráficos nomeados com a opção’ –use-graphs’. Se isso for definido como ‘true’, as importações podem ser questionadas como grafos nomeados (o nome é que o IRI da ontologia) e o grafo padrão é uma união de todos os grafos. Usar o gráfico padrão é semelhante à realização de uma “junção” de todas as importações antes de questionar, mas a distinção entre importações seria perdida em uma “junção”.

verificar

o comando “Verificar” é uma variação na execução de “seleccionar SPARQL”. As consultas são usadas para garantir que uma ontologia se conforma a um conjunto predeterminado de condições; por exemplo, garantindo que nenhuma classe tem múltiplas definições textuais. Dada uma consulta selecionada, ‘verificar’ terá sucesso (ou seja, sair com o código de Estado 0) se não forem retornados resultados. = = Ligações externas = = , exit with a non-zero status code) if any results are return from the query. Então, dada uma consulta SPARQL que seleciona dados inválidos, o comando’ Verificar ‘ irá verificar que a ontologia (ou outro recurso) não contém quaisquer dados inválidos.

Report

o comando ‘report’ é uma extensão da ‘consulta’ e’ verificar ‘ que fornece uma série de verificações de qualidade configuráveis (CQ) para uma ontologia e devolve uma folha de cálculo ou uma saída YAML das violações. A planilha é saída em formato separado por vírgulas ou tabulações e fácil de ler para um usuário, enquanto a saída YAML pode ser facilmente processada por outros programas.

As verificações de CQ incluem verificações de anotação, verificações lógicas e verificações de metadados. As anotações são importantes para facilitar a compreensão humana, pelo que o comando “relatório” encontra casos em que anotações em falta ou duplicadas podem causar problemas. Verificações lógicas olham para a coerência estrutural e consistência da ontologia. Por último, o “report” identifica os metadados ontológicos em falta, tal como especificado nas recomendações da OBO Foundry.

Existem três níveis de violações que são relatadas: erro, aviso e informação. Um erro é o mais grave, como um rótulo em falta ou duplicado. Por padrão, o comando’ report ‘ falha se houver alguma violação de nível de erro, interrompendo quaisquer processos de construção automatizados. Estes tipos de violações devem ser fixados antes de publicar uma ontologia. As violações do nível de alerta devem ser fixadas o mais rapidamente possível, por exemplo, as equivalências de classe 1 Para 1 inferidas, que normalmente não são intencionais em projetos OBO. INFO é para correções recomendadas que ajudam a manter a consistência em ontologias OBO Foundry, como começar uma definição com uma letra maiúscula e terminar com um período. ‘relatório’ pode ser configurado com uma opção de linha de comando para falhar em um nível de violação diferente ou para nunca falhar, independentemente de quaisquer violações. Documentamos cada verificação de CQ com uma sugestão para uma correção manual que o usuário pode aplicar.

a default “profile” with report levels for each QC check is provided by ROBOT, but users are also able to create their own profiles. Nestes perfis, eles podem alterar os níveis de violação de verificações individuais, optar por excluir certas verificações, e adicionar suas próprias verificações como consultas SPARQL. Por exemplo, algumas ontologias podem categorizar uma classe sem uma definição textual como um erro, enquanto outras podem categorizar isso como um aviso. Um de nossos objetivos é convergir em um Perfil padrão que seja maximalmente útil para o conjunto de todas as ontologias na biblioteca OBO, incentivando a adoção de controles de qualidade comuns.

reparar

embora a maioria dos problemas levantados por “validar” e “relatório” devam ser corrigidos manualmente, o robô também fornece um comando de “reparação” que pode corrigir automaticamente certos problemas. A implementação atual irá mesclar anotações em axiomas duplicados e atualizar referências a classes obsoletas quando elas são anotadas com uma substituição sugerida. Tencionamos alargar a “reparação” a uma gama mais vasta de problemas comuns para os quais a solução correcta é clara.

desenvolvimento de ontologia Templated

ROBOT fornece um sistema de geração de termo ontológico orientado por modelo. Os usuários também têm a opção de conectar seu próprio sistema de geração de termo em seu fluxo de trabalho, como padrões de design de coruja simples morto (DOS-DPs) .

uma enorme quantidade de dados é armazenada em planilhas e bases de dados, e formatos tabulares são bem adaptados para muitos tipos de dados. O comando ‘modelo’ do ROBOT permite aos utilizadores converter dados tabulares para o formato RDF/OWL. Um modelo de robô é simplesmente um arquivo de valores separados por tabulações (TSV) ou valores separados por vírgulas (CSV) com algumas convenções especiais, que são delineadas na documentação do ‘modelo’ do robô .

estes modelos podem ser usados para o desenvolvimento de ontologia modular. As planilhas de modelos podem ser mantidas como parte do repositório de código fonte da ontologia, e em vez de editar diretamente o arquivo de ontologia, os desenvolvedores editam linhas na planilha que correspondem aos Termos na ontologia. O comando’ template’ é então usado para gerar um módulo da ontologia, que é incluído como uma declaração de importação na versão dos editores da ontologia e fundido durante o processo de lançamento.um fluxo de trabalho consiste de um conjunto de Tarefas coordenadas por algum sistema de fluxo de trabalho. Os fluxos de trabalho de ontologia consistem em Tarefas como executar verificações de CQ, construir módulos de importação, raciocinar sobre ontologias, e gerar vários produtos de liberação de ontologia.

robô em si não é um gerenciador de fluxo de trabalho, embora permita que vários comandos sejam acorrentados em um comando longo. Ao acorrentar comandos do robô, a ontologia de saída de um comando é passada diretamente como a entrada para o próximo comando. Por exemplo, o encadeamento pode ser usado para substituir dois comandos que fundem ontologias e, em seguida, raciocinar sobre o produto resultante da fusão:

`merge robô –input ont-1.coruja … entrada ont-2.owl — output fundiu-se.coruja.

robot reason –input mesclou.coruja … saída racional.coruja`.

em vez de criar o produto resultante da fusão e executar a ‘razão’ sobre isso, pode ser feito num comando:

`junção de robots –entrada ont-1.coruja … entrada ont-2.owl reason — output reasoned.coruja`.

A principal vantagem do encadeamento é que ontologias não precisam ser serializadas e processadas entre cada passo; o mesmo objeto ontológico OWL API é mantido na memória e passado através da cadeia de comandos Robots. Para grandes ontologias, o encadeamento pode melhorar muito o desempenho do robô.

porque comandos Robots podem ser executados na linha de comandos, um número de diferentes sistemas de fluxo de trabalho pode ser usado. Destacamos o uso do GNU Make , que é tipicamente usado para compilar software. Um Makefile consiste de um conjunto de regras usadas para fazer “alvos”. No desenvolvimento de ontologia, o Makefile é usado para tarefas automatizadas, como preparar uma ontologia para lançamento. Neste caso, os alvos são normalmente arquivos de ontologia. As “receitas” para as regras são comandos de Sistema de estilo Unix, realizados pelo comando ‘make’.os comandos Robots podem ser usados como” receitas “para fazer os”alvos”. Um fluxo de trabalho típico não usará todos os 19 comandos do robô. Por exemplo, nem todos os projetos de ontologia podem usar modelos de robôs e, portanto, nem todos os fluxos de trabalho de lançamento precisam incluir o comando ‘template’. Os desenvolvedores de ontologia podem decidir quais comandos são necessários para executar o lançamento e construir um fluxo de trabalho em torno desses comandos. A figura 1 mostra uma maneira padrão na qual uma seleção de comandos de robô é combinada para um fluxo de trabalho de lançamento.

o fluxo de trabalho de libertação do robô. Um fluxo de trabalho típico de lançamento usando robô. A ontologia editar o ficheiro ONT-edit.owl é verificado pela primeira vez como um controle de qualidade com robô ‘verificar’. Em seguida, Arquivos de texto contendo listas de termos ontológicos externos no diretório de importações são usados para regenerar módulos de importação usando ‘extrato’, garantindo que as importações estão atualizadas. ONT-edit.owl é então passado através de uma série de comandos robôs (‘reason’, ‘relax’, ‘reduce’, e ‘annotate’) para gerar o lançamento, ONT.coruja. Finalmente, ONT.owl é convertido para o formato OBO

Em Primeiro Lugar, os controlos de qualidade são executados sobre a versão dos editores da ontologia com’ relatório ‘ou’ verificar’. Estes procuram classes equivalentes, seguindo espaços em branco em anotações, auto-referências, sintaxe de referência cruzada incorrecta e etiquetas em falta. Os resultados são gravados em um diretório de ‘relatórios/’ especificado. Se houver alguma violação de nível de erro, a tarefa vai falhar e escrever as violações em uma tabela para que eles possam ser facilmente identificados. Este passo permite aos desenvolvedores ver rapidamente se novas mudanças introduziram quaisquer problemas dentro da ontologia e corrigi-los antes de lançar.

assumindo que o passo inicial de verificação do CQ terminou com sucesso, o próximo passo é criar os módulos de importação. O robô “extrato” é executado para cada entrada em uma lista de importações, que têm os correspondentes arquivos termos (para o conjunto de sementes) no diretório ” importações/”. Isto cria todos os módulos de importação no mesmo directório ” importações/”. Isto garante que quando uma ontologia é lançada com termos externos, todos os Termos externos estão atualizados com as versões lançadas das ontologias de origem. O lançamento de termos externos ultrapassados pode causar confusão, uma vez que o termo irá mostrar tanto os antigos como os novos detalhes nos Serviços de pesquisa ontológica, como o Ontobee e o serviço de pesquisa ontológica . Verificações adicionais de CQ podem ser executadas sobre a ontologia completa com as importações usando o comando ‘Verificar’ ou executando ‘relatório’ novamente.por último, os principais produtos de libertação são criados: o ficheiro coruja e o ficheiro OBO. Para criar a versão OWL, o arquivo dos editores é passado através de uma série de comandos de robôs acorrentados:’ reason’,’ relax’,’ reduce ‘e’ annotate’. Esta série de comandos ajuda a garantir que a ontologia liberada é fácil de navegar e entender, bem como livre de quaisquer axiomas redundantes. Se algum destes comandos falhar, o processo Make terminará com a mensagem de erro correspondente. Por exemplo, se uma ontologia é incoerente, o passo “razão” falhará. Finalmente, o comando’ anotar ‘ adiciona a versão IRI aos meta-dados de ontologia. Este arquivo OWL é então convertido para o formato OBO, no ponto em que todos os alvos são copiados para um diretório de lançamento datado.

o Kit de desenvolvimento de Ontologia

Criando um Makefile para coordenar todos estes passos pode ser um desafio. Nós tornamos isso mais fácil para desenvolvedores de ontologia fornecendo um Kit de desenvolvimento de Ontologia (ODK) . Isto pode ser usado para criar um repositório GitHub seguindo um layout padrão, com um Makefile padrão seguindo o fluxo de trabalho detalhado acima. O repositório de GitHub resultante também será configurado automaticamente para executar as etapas de validação (como ‘report’) do fluxo de trabalho através de Travis CI . O fluxo de trabalho também pode ser executado usando Docker com recipientes ODK liberados no Dockerhub . Isso permite a execução fácil de fluxos de trabalho em qualquer computador local de um desenvolvedor de ontologia, com Travis CI, ou através de ferramentas de construção escalável, como Jenkins .

ODK constrói sobre robô e demonstra a utilidade do robô, mas uma discussão completa está além do escopo deste artigo.