Modelo Semântico de Referência Looplex

Engenheiros Jurídicos e desenvolvedores precisam entender alguns dos fundamentos do Modelo Semântico de Referência: Conceitos e Taxonomias, Ontologias e Modelagem de Dados.

Com isso em mente, explicamos ao final como implementamos nosso Modelo Semântico de Referência na Looplex.

Conceitos e taxonomias

A base de todo Modelo Semântico contém a ideia de conceito, que é a definição de um termo que precisa ser – ou pode ser – divulgado em um determinado domínio. O lucro é um conceito que muitas vezes é divulgado em um domínio empresarial; da mesma uma obrigação é um conceito divulgado em um domínio jurídico.

Os conceitos são mais significativos com uma gama de informações de apoio, e permitem a criação explícita das relações entre diferentes conceitos. Os conceitos são definidos por – e referenciados em – normas, regras ou legislações.

Assim, da mesma forma que lucro é o que resta depois que as despesas são retiradas da Receita, uma obrigação jurídica (legalObligation) é “uma relação bilateral transitória que descreve uma ação ou transação (legalTransaction) que um ou mais sujeitos (legalSubject) tem de desempenhar e cuja performance pode ser exigida por outros sujeitos”.

O conceito Obrigação tem uma série de tipos ou rótulos, para diferentes propósitos. A diferença principal é que enquanto os tipos estão mapeados como uma variação conceitual de um conceito, os rótulos alteram apenas o nome de interface (displayName) de uma entidade, porém mantendo-se que o seu significado semântico permanece sendo o mesmo.

Rótulos manifestam o significado especial ou local de um conceito dependendo do contexto em que esse conceito está sendo utilizado. Por isso, rótulos geralmente aparecem nas interfaces que manifestam o conteúdo gerado pelo sistema, como um arquivo do Word, PDF ou PowerPoint que imprimem um contrato, petição ou documento; uma página de internet, um arquivo de dados enviado por API para outro sistema, a ficha de um caso na interface da própria Looplex ou de outro software de gestão, uma planilha Excel, um dashboard de BI etc..

Além disso, um mesmo conceito pode ter mais de um rótulo no mesmo contexto, por exemplo para expressar a variação da ideia em vários idiomas.

As coleções de conceitos relacionados são contidas em uma taxonomia. As taxonomias são o framework de metadados contra o qual as informações podem ser relatadas.

Uma taxonomia é assim um “vocabulário” ou “dicionário”, que pode estar importando uma hierarquia e estrutura padrão de mercado (especificações ISO, LEDES, IFRS, W3C, CVM, Anbima, relatórios bancários da Basileia III CRD IV, estrutura de relatórios de seguros da SUSEP, entre muitos outros), em Lei, doutrina ou jurisprudência (parte geral do Código Civil, LGPD etc.), por um agrupamento de clientes (empresas e escritórios tratando de contratos imobiliários), ou um cliente específico (taxonomia interna de documentos ou fluxos de uma empresa), e que permite a troca de informações jurídicas ou de negócios.

Exemplos de Taxonomia

As taxonomias de conceitos compõem são o primeiro passo para compor a base de uma ontologia.

Ontologias

Uma ontologia é construída a partir de (a) um vocabulário de termos e seus significados (a nossa taxonomia de conceitos); e (b) suas relações, serviços, regras e transações.

Uma ontologia é uma especificação formal que fornece representação de conhecimento fragmentável e reutilizável. Exemplos de ontologias incluem:

1. Taxonomias

2. Vocabulários

3. Mapas de sinônimos ou variações

4. Mapas tópicos

5. Modelos lógicos

Uma especificação de ontologia inclui descrições de conceitos e propriedades em um domínio, relações entre conceitos, restrições sobre como as relações podem ser usadas e indivíduos como membros de conceitos.

Quais são os benefícios de usar uma ontologia?

Ontologias são muito úteis para obter uma compreensão comum do conhecimento jurídica e tornar as suposições explícitas, para que possam ser usadas para apoiar uma série de atividades.

Ontologias suportam a integração de dados para análise (Legal Analytics e BI), aplicam conhecimento de domínio a dados (Common Data Model), suportam a interoperabilidade entre sistemas, permitem aplicativos e conteúdo jurídico automatizado orientados a modelos, reduzem o tempo e o custo do desenvolvimento e melhoram a qualidade dos dados, melhorando metadados.

A linguagem de ontologia da web, ou OWL adiciona meios de modelagem mais poderosos ao RDF e RDFS. É possível fazer verificações de consistência lógica, checks de regras de satisfação e fornece classificação como o tipo de uma instância.

Ontologias também adicionam equivalências de identidade e diferenças de identidade (“entity equivalence” e “identity difference”) tais como sameAs, differentFrom, equivalentClass, and equivalentProperty, bem como definições de classe mais expressivas, como intersecção de classe, união, complemento, disjuntivas e restrições de cardinalidade.

Além disso, Ontologias também oferecem definições de propriedade mais expressivas, como propriedades de objetos e de datatypes, propriedades transitivas, funcionais, simétricas e inversas, e ainda restrições de valor.

Finalmente, ontologias são importantes porque permitem a criação de repositórios que usam schemas e modelos semânticos (Common Data Model). Isso torna o raciocínio automatizado sobre os dados possíveis (e fáceis de implementar) uma vez que as relações mais essenciais entre os conceitos são incorporadas à ontologia.

Modelagem de dados com RDF

O Framework de Descrição de Recursos, mais conhecido como RDF, é um modelo de dados em grafo (graph data model) que descreve formalmente a semântica ou o significado da informação. Ele representa metadados, ou seja, dados sobre dados.

RDF consiste em triplas. Esses triplos são baseados no modelo Entidade-Atributo-Valor (EAV), no qual o sujeito é a entidade, o predicado é o atributo, e o objeto é o valor. Cada triplo tem um identificador único conhecido como Identificador de Recursos Uniformes, ou URI. Os URIs parecem endereços de páginas da Web. As partes de um tripla, o sujeito, predicado e objeto, representam links em uma rede, um grafo.

Na primeira tripla, “Fred hasSpouse Wilma”, Fred é o sujeito, hasSpouse é o predicado, e Wilma é o objeto. Além disso, no próximo triplo, “Fred hasAge 25”, Fred é o sujeito, hasAge é o predicado e 25 é o objeto, ou valor.

Múltiplos triplos se conectam para formar um modelo RDF. O gráfico abaixo descreve os personagens e relacionamentos da série de desenho animado os Flintstones. Podemos identificar facilmente triplos como “WilmaFlintstone livesIn Bedrock” ou “FredFlintstone vive Em Bedrock”. Agora sabemos que os Flintstones vivem em Bedrock, que faz parte do Condado de Cobblestone, na América Pré-Histórica.

O que é RDFS

O RDF Schema, mais conhecido como RDFS, adiciona esquema ao RDF. Ele define um metamodelo de conceitos como Recurso, Classe e Datatype e relacionamentos como subClassOf, subPropertyOf, domínio e intervalo.

O RDFS fornece um meio para definir as classes, propriedades e relacionamentos em um modelo RDF e organizar esses conceitos e relacionamentos em hierarquias. O RDFS especifica regras ou axiomas para os conceitos e relacionamentos. Essas regras podem ser usadas para inferir novas triplas.

Enterprise Knowledge Graph

A combinação de taxonomias, ontologias e framework de descrição de recursos (graph database) permite o surgimento de um Grafo de Conhecimento Empresarial completo (Enterprise Knowledge Graph).

Enterprise Knowledge Graph são incríveis e permitem uma série de funcionalidades e serviços especiais em sistemas de gestão empresarial. O grafo de conhecimento da Looplex possibilita uma gama de aplicações de inteligência em nossa plataforma, desde busca contextual até a implementação de sofisticados modelos de legal analytics.

Para a implementação disso, a Looplex aditou um Modelo Semântico de Referência, que acomoda a existência de múltiplas camadas de dados, coexistência com elementos não padronizados ou mesmo não mapeados e que aproveita modelos e padrões de mercado para apenas estender os elementos necessários para um determinado desafio de automação.

Modelo Semântico de Referência Looplex

Na Looplex seguimos o caminho de estruturação da base de conhecimento focando em fazer uma extensão para o mundo jurídico do maior Common Data Model aberto do mercado.

Porque Ontologias jurídicas não decolam

Projetos de Ontologias jurídicas nos últimos 10 anos falharam repetidas vezes em ter suas implementações práticas resolvidas, pois tentaram criar a totalidade das relações hierárquicas, definição abstrata de todas as entidades em uma taxonomia completa, bem como descrição semântica dos conceitos.

Esse processo é demorado e sujeito a repetidos fracassos, como o histórico de muitas iniciativas e empresas relevaram.

Além disso, para o mapeamento de entidades e dados constantes de contratos, disputas e documentos, grande parte das informações pertencem a outros domínios que não são do Direito, como preço, juros, identificação das partes, lista de serviços e ativos negociados, critérios contábeis de provisionamento e contingências e por aí vai.

Há muitas iniciativas acadêmicas sofisticadas, mas elas também falham na adesão pelos praticantes e profissionais do Direito por não se integrarem a um sistema de gestão de conhecimento (Content Management System, CMS) moderno¹.

O problema parece ser tão grande que enormes e bem financiadas iniciativas fracassaram, de novo e de novo.

Modelo Semântico de Referência

A solução adotada na Looplex passa por três ideias centrais:

• 1. Não reinventar a roda. Somente uma fração dos elementos e entidades em um problema jurídico pertencem propriamente a esse domínio. Seria possível pegar uma ontologia e modelo de dados de mercado e apenas estender ele para a seara do Direito?

• 2. Adoção em etapas. Da mesma forma que adotamos a ideia de desenvolver documentos ricardianos no output de conteúdo, concluímos que deveríamos fazer uma sistematização em etapas do conhecimento jurídico, com definição de apenas um núcleo de entidades e relacionamentos fundamentais que servem como uma base de projeção para iniciativas de padronização de conteúdo de clientes específicos ou de setores de prática jurídica, porém sem a pretensão de sistematização do Direito como um todo.

• 3. Não excluir o advogado do processo. Tomamos uma escolha consciente de não tentar sistematizar todas as operações jurídicas de um contrato ou disputa pela já conhecida dificuldade do Direito Computacional de mapear todos os elementos operativos. Se humanos permanecerem no loop para a interpretação dos elementos mais complexos e se adotarmos diversas heurísticas sem a pretensão de entender todo o seu arcabouço lógico, reduzimos a complexidade do problema uma ordem de magnitude.

Vamos expandir cada uma delas abaixo.

1. Common Data Model da Microsoft

Decidimos então adotar o Common Data Model da Microsoft, que inclui um conjunto de esquemas de dados padronizados e extensíveis que a Microsoft e seus parceiros publicaram. Esta coleção de esquemas predefinidos inclui uma extensa lista de entidades, atributos, metadados semânticos e relacionamentos.

Ele não é igual à forma de representação semântica RDF e RDFS, pois ao estruturar alguns pontos de forma mais rígida, o CDM da Microsoft reduz o escopo de trabalho de mapeamento de quem está criando extensões para seus modelos, ao dispensar a necessidade de uma ontologia completa para sua implementação.

Esses esquemas já representam conceitos e atividades comumente utilizadas em centenas de aplicativos corporativos acessados por milhões de usuários, o que simplifica a criação, agregação e análise de dados.

O Common Data Model da Microsoft tem um núcleo de entidades e relacionamentos com extensão em diversas verticais de mercado, como Vendas, Saúde, Marketing, Finanças, Supply Chain e outros.

Contudo, o CDM da Microsoft não tem uma extensão para a vertical jurídica. Aliás, não há nenhum Modelos de Dados Comum aberto e geral para o Direito que tenha obtido até agora aceitação e adoção relevante no mercado!

O Looplex Legal Common Data Model é uma extensão para o domínio jurídico de todo o metamodelo de conceitos, entidades e estruturas do Common Data Model da Microsoft.

2. Padronização em camadas

Podemos ter uma taxonomia de entidades e esquemas base vindo desde o Common Data Model que pode ser customizada, modificada e estendida em outras taxonomias para um determinado grupo de desafios de automação jurídica. Essas são as Projeções.

O recurso de Projeções fornece uma maneira de personalizar a definição das entidades lógicas, influenciando como a entidade é resolvida pelo modelo de objeto.

Por exemplo, as Projeções podem ser usadas para incluir ou excluir atributos seletivamente de uma entidade base ou para determinar se um atributo de entidade deve ser resolvido incluindo atributos da entidade relacionada ou incluindo apenas atributos-chave estrangeiros. Atributos incluídos podem ser agrupados, reordenados e renomeados, e atributos adicionais de metadados podem ser introduzidos².

Enfim, as Projeções permitem definir, ou “projetar”, diferentes formas de dados derivadas de um conjunto comum de entidades lógicas subjacentes.

Além disso, podemos descer mais um nível de concretude e estabelecer uma camada de uso comum de entidades e dados que não precisam guardar correlação com elementos do modelo de dados comum ou com uma Projeção.

Essa adoção de uma padronização em camadas permite que os elementos de um determinado desafio de conteúdo possam ser convertidos para um formato digital e automatizados mesmo sem classificação e abstração de todas as entidades, operações e serviços nele contidos. Torna-se um processo progressivo e incremental de transformação jurídica digital!

3. Mantenha o especialista no processo!

Não precisamos resolver e definir toda representação ontológica do Direito porque mantemos os advogados e demais profissionais do Direito diretamente envolvidos no fluxo de trabalho.

O fluxo assim continua necessitando de humanos para operar o processamento de input, a interpretação e análise ou ainda para determinar a distribuição e organização dos trabalhos, sempre que nesses contextos haja elementos que não foram inteiramente mapeados.

O resultado disso é que conteúdos e serviços jurídicos podem ser de 30% a 95% automatizados, mas com um esforço de mapeamento e abstração 10 a 100x menor do que iniciativas que pretendem tirar por completo o profissional do Direito do fluxo de trabalho.

Em resumo, o resultado é muito melhor quando apoiamos o trabalho dos advogados para acelerar dramaticamente sua produtividade e entrega, em vez de tentar substituí-lo como outras legal tech vem tentando fazer, sem sucesso!

Footnotes

1. Mais ainda, os limitados CMS que existem para a área não possuem uma integração de contexto com os fluxos de trabalho dos serviços jurídicos, enquanto sistemas legados atuais de gestão de projetos (case management systems) que fazem essa gestão dos fluxos não conseguem se integrar nesses CMS. Por isso a Looplex se organizou como uma plataforma de experiência digital (DXP) para o mercado jurídico. ↩

2. Para entender melhor como implementar Projeções de dados para certas verticais, veja aqui https://learn.microsoft.com/en-us/common-data-model/sdk/convert-logical-entities-resolved-entities ↩