Explorando o FIBO usando os recursos de inferência e caminho de propriedade do GraphDB

Introdução

Uma ontologia ou um gráfico de conhecimento de qualquer tamanho apreciável requer algum esforço por parte do consumidor antes de se tornar uma ferramenta útil. O conhecimento do domínio do assunto é sempre útil, mas raramente suficiente, pois há muitas escolhas a serem feitas na representação do conhecimento do domínio como dados em um gráfico. Alinhar a forma do conhecimento de domínio em sua mente com a forma do conhecimento representado no gráfico é essencial. Neste artigo, discutiremos alguns dos recursos do GraphDB que dão suporte a esse alinhamento.

Visão geral do FIBO

A Ontologia de Negócios do Setor Financeiro (FIBO) é um modelo conceitual do setor financeiro que foi desenvolvido pelo Enterprise Data Management Council (EDMC). O EDMC apóia um processo aberto para a manutenção e desenvolvimento contínuos do FIBO. O objetivo do FIBO é fornecer um significado preciso aos artefatos de dados que descrevem o negócio de finanças, independentemente da forma que os artefatos de dados possam assumir. O FIBO contém as entidades e associações que descrevem as informações necessárias para criar, estender e integrar aplicativos de negócios financeiros. FIBO é especificado usando RDF(S) e OWL. Portanto, é passível de análise usando inferência SPARQL e OWL. Na versão usada para este artigo (Produção do 2º trimestre de 2020), ele contém:

• 122 namespaces, que representam a estrutura do módulo;
• 1.542 classes;
• 1.328 conceitos;
• 535 predicados.

Desde seu lançamento inicial em 2017, ele cresceu para incluir e se alinhar a vários padrões existentes e se beneficiou da ampla participação do setor financeiro. Desde suas raízes em uma pasta de trabalho do Excel conhecida como Repositório Semântico, o FIBO se tornou uma ontologia sofisticada baseada em RDF e OWL. Em seu caminho, o processo produziu uma série de efeitos colaterais benéficos, incluindo as melhores práticas de engenharia de ontologias, como estabilidade textual para RDF, de modo que sistemas tradicionais de controle de versão baseados em texto possam ser empregados, padrões rigorosos de metadados resultantes do relacionamento próximo que o esforço desfrutou com o Object Management Group (OMG) e uso rigoroso dos recursos de raciocínio do OWL. Mais detalhes podem ser encontrados aqui.

O conteúdo do FIBO é disponibilizado em uma variedade de veículos. Há uma ontologia RDF e OWL, que é a entidade principal que contém o conhecimento de negócios que é disponibilizado em várias serializações, incluindo: RDF-XML, Turtle, JSON-LD e N-Quads/N-Triples. Além disso, existem:

• Vocabulário FIBO Taxonomia baseada em SKOS para uso com ferramentas de gerenciamento de taxonomia que está disponível nas serializações RDF-XML, Turtle e JSON-LD.
• Dicionário de dados FIBO que está disponível como .csv e .xlsx. Ele contém a classe operacional em FIBO e suas propriedades acompanhantes.
• O FIBO-DM é um modelo de dados corporativos disponível como modelos de dados conceituais e lógicos do SAP PowerDesigner.

Neste artigo, vamos nos concentrar na ontologia e no vocabulário FIBO, pois ambos são codificados usando RDF e, portanto, passíveis de análise usando raciocínio SPARQL e OWL.

Um conto de duas hierarquias

Todos os conceitos contidos no vocabulário FIBO são definidos por entidades na ontologia FIBO. Isso fornece informações contextuais avançadas que um aplicativo que usa o vocabulário pode disponibilizar para o usuário. Por exemplo, fibo-v-be:DomesticUltimateParent é definido pela entidade fibo-be-oac-cctl:DomesticUltimateParent.

Os conceitos no vocabulário FIBO participam de uma hierarquia definida pelos predicados skos:wider e skos:narrower. Na figura acima, a Parte de Participação Controladora Total é um conceito mais amplo do que a Controladora Final Doméstica. No vocabulário publicado, apenas skos:wider é usado. Conforme declarado nas especificações do SKOS, “as propriedades skos:wider e skos:narrower são inversas uma da outra. Sempre que um conceito X é mais amplo do que outro conceito Y, então Y é um conceito mais restrito de X de acordo com o modelo de dados SKOS”. Portanto, há uma relação skos:narrower implícita de fibo-v-be:TotalControllingInterestParty para fibo-v-be:DomesticUltimateParent.

Dada a hierarquia no vocabulário e a hierarquia na ontologia, quais são as relações entre os elementos da hierarquia? Cada superclasse de fibo-be-oac-cctl:DomesticUltimateParent tem conceitos correspondentes no vocabulário? Esses conceitos participam da hierarquia transitiva skos:broaderTransitive/skos:narrowerTransitive com fibo-v-be:DomesticUltimateParent? No restante deste post, usaremos o GraphDB para responder a essas perguntas.

Carregando FIBO no GraphDB

O GraphDB é um armazenamento triplo escalável de alto desempenho da Ontotext, anteriormente conhecido como OWLIM. Em sua encarnação atual, versão 9.4.1, ele suporta raciocínio RDF 1.1, SPARQL 1.1 e OWL 2, além de várias ferramentas específicas do produto para navegação, visualização, análise e federação. Ele fornece APIs acessíveis pela web (incluindo o protocolo SPARQL para endpoints) e, portanto, pode ser usado com qualquer linguagem de programação. Como você verá na seção a seguir, o suporte para SPARQL 1.1, caminhos de propriedade de especificação, funciona lado a lado com o raciocínio OWL 2.

A primeira etapa no uso do GraphDB é criar um repositório. Isso é feito navegando até o formulário Setup -> Repositories > Create Repository. Os campos críticos neste formulário são:

• ID do repositório, no nosso caso, inseriremos .FIBO
• Conjunto de regras, que no nosso caso deve ser definido como selecionado no menu.OWL 2-RL (Optimized)
• A caixa “Usar índice de contexto” deve ser marcada, pois a Ontologia FIBO contém gráficos nomeados que refletem a estrutura modular da ontologia.

Os campos restantes no formulário podem ser deixados com seus valores padrão, conforme mostrado na captura de tela a seguir:

O próximo passo é importar os gráficos RDF. Existem três que são necessários:

1. No site de ontologia EDMC FIBO, precisamos da distribuição N-Quads compactada FIBO Production. A versão específica usada no artigo é 2020 Q2 Production.
2. No site de vocabulário EDMC FIBO, precisamos da distribuição TTL compactada FIBO-V Production. A versão específica usada no artigo é 2020 Q2 Production.
3. Do W3C, precisamos do SKOS Simple Knowledge Organization System http://www.w3.org/2004/02/skos/core#. O W3C implementa o recurso de redirecionamento HTTP 303. Como resultado, esse URI produzirá HTML quando referenciado em um navegador da Web e RDF quando importado para o GraphDB.

Por uma questão de eficiência, é melhor baixar os componentes FIBO para um disco local, de preferência no diretório de importação do GraphDB, enquanto o SKOS pode ser facilmente baixado pela Internet.

Importar o vocabulário do disco leva um segundo, enquanto importar a ontologia leva um minuto e dez segundos. A importação do SKOS pela Internet leva dois segundos. Em termos de desempenho, deve-se notar que é durante o processamento de importação que a inferência é realizada. O vocabulário é baseado no SKOS, que faz um uso muito leve dos elementos estruturantes que geram novos triplos e, portanto, o vocabulário e o gráfico SKOS são importados rapidamente. A ontologia leva muito mais tempo devido ao uso sofisticado de OWL empregado em sua construção. Como resultado, as 106.187 declarações explícitas dos gráficos importados resultam em 405.493 declarações inferidas para um total geral de 511.680 declarações. Deve-se notar que todas as instruções inferidas são criadas no grafo padrão, que também contém todas as instruções dos grafos nomeados [1].

Pode-se obter uma visão geral da ontologia usando o diagrama de hierarquia de classes (no menu Explorar do GraphDB Workbench), que representa as subclasses como círculos aninhados em suas superclasses:

Raciocínio no GraphDB

A especificação OWL 2 Web Ontology Language Profiles (Second Edition) suporta vários regimes de raciocínio diferentes. O GraphDB fornece implementações para alguns desses perfis de linguagem. No GraphDB, o perfil de idioma é determinado por um conjunto de regras e é especificado no nível do repositório. O reasoner (um mecanismo de regras proprietário) é chamado sempre que triplos são adicionados ao repositório, seja por meio da operação SPARQL INSERT ou importando gráficos. O efeito de qualquer um dos conjuntos de regras, além de Vazio (sem inferência), é fazer com que triplos implícitos adicionais sejam materializados e armazenados, além dos inseridos explicitamente. Um recurso exclusivo do GraphDB é que, após o commit da operação SPARQL DELETE, as instruções inferidas, que não são mais inferíveis, seriam retiradas. A natureza dos triplos criados depende do conteúdo do repositório e das regras especificadas no conjunto de regras selecionado. Por exemplo, se a definição de dois predicados indicar que eles são inversos um ao outro, quando um deles for encontrado em um triplo, um triplo com a propriedade inversa correspondente será criado.

Para trabalhar com o FIBO, escolhemos o perfil de linguagem OWL 2 RL, que é voltado para aplicativos que exigem raciocínio escalável sem sacrificar muito poder expressivo. Experimentamos carregar o FIBO com o conjunto de regras RDF Schema (RDFS), que é muito mais simples e fornece suporte apenas para rdfs:subPropertyOf, rdfs:subClassOf, rdfs:domain e rdfs:range. Como esperado, o carregamento de dados com o raciocínio RDFS foi muito mais rápido: demorou menos de um segundo para carregar o arquivo NQ de ontologia FIBO, contra mais de um minuto com o OWL 2 RL. Também inferiu apenas 170.804 declarações implícitas (mais de 2 vezes menos que OWL 2 RL). A desvantagem é que, com o RDFS, omitimos algumas inferências importantes. Por exemplo, a consulta a seguir (executada no repositório RDFS) extrairá esses relacionamentos de subclasse, que aparecem no repositório OWL 2 RL, mas estão ausentes no RDFS:

SELECT * WHERE {
  { SERVICE <repository:FIBO-RL> {
      ?sub_class rdfs:subClassOf ?super_class
      FILTER(?sub_class != ?super_class)
      FILTER(?super_class != owl:Thing)
      FILTER(contains(str(?sub_class),'fibo')
          && contains(str(?super_class),'fibo'))
  }  }
  FILTER NOT EXISTS {
          ?sub_class rdfs:subClassOf ?super_class
  }
}

Aqui, usamos a chamada federação interna do GraphDB, que permite a consulta eficiente de dados em repositórios de uma mesma instância de banco de dados. Aqui seguem os relacionamentos de subclasse, que estão ausentes no repositório com o raciocínio RDFS:

Fundamentalmente, isso ocorre porque as definições do conceito incluem construtos, com os quais um raciocinador RDFS não pode lidar. Como um exemplo simples, as classes Rate e Ratio são definidas para serem equivalentes com a seguinte instrução

Em todos os perfis de linguagem do OWL 2, isso implica que eles são subclasses uns dos outros, mas isso não faz parte da semântica do RDF Schema.

Aumentando o raciocínio com caminhos de propriedade

Os caminhos de propriedade são um recurso do SPARQL que fornece a capacidade de abranger os nós em um gráfico RDF além do triplo básico. Um triplo é o caminho de propriedade mais simples disponível no SPARQL.

Na ontologia FIBO, a hierarquia de classes é representada por um predicado transitivo, rdfs:subClassOf. A hierarquia de conceitos de vocabulário FIBO tem conceitos em um predicado intransitivo, skos:broader. Isso significa que a hierarquia de classes da ontologia, que corresponde à noção mais comum de hierarquias de classes em linguagens de programação como JAVA, PYTHON e C++, e linguagens de especificação como UML, está sendo mapeada para um predicado que, quando a semântica especificada é estritamente respeitada, significa menos do que os autores pretendiam. O mapeamento tem perdas, pois a intenção pretendida não é representada com precisão.

O consumidor do vocabulário que sofre como resultado é aquele que requer apenas o vocabulário, com o objetivo de fornecer um contexto mais amplo para seu próprio vocabulário específico de domínio. Este usuário deve distinguir entre a estrutura de seu vocabulário e a estrutura do vocabulário da FIBO. Como a hierarquia espelha implicitamente a estrutura de classe transitiva da ontologia, a integração em qualquer ponto requer que o vocabulário externo se comprometa / se enrede com a hierarquia FIBO implícita.

Como a intenção da hierarquia da ontologia FIBO na verdade mapeia para os predicados skos:broaderTransitive e skos:narrower_transitive, pode-se melhorar o problema do mapeamento pelo uso de inferência. Usando um repositório GraphDB com o conjunto de regras OWL 2 RL (otimizado), todos os triplos necessários para uma interface limpa são criados. No topo da hierarquia de propriedades semânticas do SKOS está skos:semanticRelation. Este predicado fornece a estrutura necessária para a representação visual e navegação do conteúdo do vocabulário. Os triplos s_kos:wider_ e skos:narrower estão disponíveis para baixo compromisso ontológico com FIBO. Os skos:broader_transitive e skos:narrower_transitive estão disponíveis para alto compromisso ontológico com o FIBO. A escolha é deixada para o consumidor e pode ser atualizada aos poucos ou por política, a critério do consumidor, usando SPARQL.

Um exemplo concreto da utilidade de caminhos de propriedade e inferência é uma verificação de lint das duas hierarquias. Por definição, todo conceito de vocabulário é definido por uma entidade na ontologia. Quais entidades participam das hierarquias de classe dos conceitos mapeados que não têm entradas de vocabulário relacionadas?

Restrições de integridade estrutural

Analisando os gráficos com SPARQL

Essa consulta localiza classes que estão conectadas a um conceito por meio de subclasses na hierarquia de classes, mas não têm uma conexão com ele por meio da hierarquia de conceitos do vocabulário FIBO.

Consulta de lint

SELECT DISTINCT ?parentEntity  where {
    ?concept a skos:Concept ; 
             rdfs:isDefinedBy ?entity . 
    # Every concept is defined by an entity
    ?entity rdfs:subClassOf ?parentEntity .
    # Exclude restrictions
    FILTER(ISIRI(?parentEntity)) 
    # Only consider resources in the FIBO namespaces
    FILTER(CONTAINS(str(?parentEntity),'fibo')) 
    FILTER NOT EXISTS { 
        # Find where there is no semantic relation
        # between concept and related concept
        ?relatedConcept rdfs:isDefinedBy ?parentEntity .
        # Consider the entire set of 
        # related concepts in the hierarchy
        ?concept (skos:semanticRelation)+ ?relatedConcept 
    }
}

O uso de caminhos de propriedade com skos:semanticRelation fornece metade da viagem de ida e volta entre o vocabulário e a ontologia, rdfs:subClassOf fornece a outra.

O sinal de adição (+) após skos:semanticRelation indica que esse predicado deve ser usado como um caminho que conecta o sujeito e o objeto do caminho por uma ou mais correspondências de rdfs:subClassOf. Há uma variedade de operações que podem ser aplicadas em caminhos de propriedade, cuja discussão está fora do escopo deste artigo. O leitor interessado deve consultar a Recomendação do W3C da linguagem de consulta SPARQL 1.1 de 21 de março de 2013.

Agora que temos um repositório contendo as instruções RDF explícitas e implícitas para a ontologia FIBO e o vocabulário FIBO, podemos executar a consulta lint, que produz uma lista de classes que não atendem à verificação de integridade apresentada acima: as superclasses devem ser vinculadas a conceitos relacionados no vocabulário a conceitos vinculados às subclasses correspondentes.

Conclusão

O FIBO é um exemplo de engenharia de ontologias muito sofisticada realizada por pessoas com amplo conhecimento do setor financeiro e por pessoas com profundo conhecimento de ontologias e como gerenciá-las. Não é algo em que se possa simplesmente ‘ler o código’. Para obter o máximo de utilidade do FIBO, é necessário empregar uma ferramenta sofisticada e fácil de usar, como o GraphDB, para que a riqueza de conhecimento que ela contém possa ser melhor empregada em seu caso de uso específico. Demonstramos que, como esperado, o OWL2 RL é uma escolha melhor do que o RDFS para raciocinar sobre FIBO. Combinados com o raciocínio, os caminhos de propriedade são capazes de detectar alguns problemas estruturais. Isso demonstra que tais técnicas fornecem ferramentas úteis para garantir a qualidade de ontologias e gráficos de conhecimento grandes, complexos.

Este é o primeiro post introdutório de uma série que demonstrará como os mecanismos de banco de dados gráficos e a tecnologia semântica podem ser usados para lidar com ontologias e dados no setor de serviços financeiros.

Artigo Original