Skip to content
Looplex Docs

Entidades do Common Data Model

This content is not available in your language yet.

As entidades que compõem o Common Data Model são os Legal Data Models (que são as entidades lógicas), os Legal Data Objects (que são as entidades físicas) e os Legal Snippets, que são agregados de Legal Data Objects com um semântico unitário.

O Legal Data Objet é uma entidade física que pode ser serializada (ou seja, que armazena, transmite e recupera dados) em múltiplos formatos de arquivo (JSON, XML etc.) e que pode ser materializada em qualquer linguagem de programação.

O design dos Legal Data Objects se concentra em documentos, mas ele também é utilizado para a representação de estruturas de dados arbitrárias em outras experiências de conteúdo jurídico, como Casos, Fluxos, Dashboards, análises preditivas etc.; a Looplex desenvolveu inúmeras interfaces de programação de aplicativos (APIs) para auxiliar no processamento de dados dos Legal Data Objects.

Os Legal Data Objects podem ser agregados ou compostos com outros Legal Data Objects. Quando um conjunto de Legal Objects tem sentido semântico unitário, ele se torna um Legal Snippet.

Valores de um objeto reportados contra outro metadado são apenas isso: um valor, seja ele numérico, monetário, texto, gráfico ou mesmo uma imagem ou elemento visual. Um valor 10% pode por exemplo estar associado ao conceito de multa ou cláusula pena.

Mas esse par de valor-conceito não tem muito significado a não ser que o dado seja disponibilizado com informações adicionais de contexto. A multa é relacionada à violação de qual cláusula? Qual é o valor base sobre o qual esse percentual se aplica, o que já foi pago, o preço total do serviço, o quê? Ele é recorrente como uma multa diária ou aplica-se uma única vez? E por aí vai.

A combinação do conceito de um Legal Data Object com os valores e conceitos de outros Legal Data Objects que sejam capazes de instanciar uma regra ou conjunto de regras que tem um significado semântico compreensível e isolável em um documento cria o objeto complexo que chamamos de Legal Snippet.

Um Legal Sippet pode ser uma cláusula contratual, uma proposição lógica ou alegação factual na causa de pedir de uma petição, uma sequência de argumentos, documentos ou provas em favor de uma determinada proposição (subsídios), um andamento na linha de tempo em um caso e tantas outras instanciações mínimas.

Porque o Direito é essencialmente expresso em linguagem natural, um Legal Snippet é quase invariavelmente associado a uma combinação de texto constante, rótulos (displayNames) e variáveis derivadas de conceitos já mapeados.

No entanto, Legal Snippets podem ser manifestados como elementos visuais de interface (Legal Visual Objects), que devem ser considerados se tiverem um sentido semântico próprio.

Um conjunto de Legal Sinippets pode ser agregado em um Tópico (ou Branch em Lawtex). Ele se tornará um objeto complexo identificável sempre que possa ser atribuído a ele um sentido semântico específico à agregação essa agregação. Um tópico pode ser um capítulo (ou cláusula) que contenha as regras de transferência de posse de um imóvel, ou que contenha a causa de pedir próxima de uma petição inicial, ou ainda um conjunto de declarações e garantias de uma das partes, e por aí vai.

Document

Por fim um conjunto de Tópicos pode ser composto em um Documento. O Documento é a instanciação de tópicos e snippets que os advogados e pessoas comuns estão acostumados a associar aos artefatos de conteúdo jurídico: um contrato de compra e venda, uma petição de contestação, uma lei ordinária, um memorando, uma carta de auditoria etc.

O Documento é, assim, uma visão de instanciação de um negócio ou questão jurídica. Porém, uma combinação de Legal Data Objects pode gerar outras visões que tem significado semântico específico para os usuários, como um Dashboard ou um diagrama de Workflow.

Um combo de Documentos e de outros artefatos compostos por diferentes visões de BI, Fluxos, Casos ou mesmo funções, como um RPA, compõem uma Solução ou Legal Solution, sempre que for possível atribuir um sentido semântico maior de uma determina experiência jurídica.

Uma Solução pode ser um fluxo empacotado e parametrizável de gestão contratual de fornecedores, de automação de etapas e gestão de um processo judicial de execução, ou de inventário, ou de qualquer outro tema, ou ainda uma gestão de entidades e governança societária de um grupo de empresas, entre outros múltiplos exemplos.

Se quiser entender os padrões de Design de agregação de entidades, veja aqui.

O Legal Data Model é uma entidade lógica, que especifica como descrever formalmente o esquema (ou “schema”) de elementos de um Legal Data Object (LDO) e pode ser tratado como um objeto de programação.

O esquema de um Legal Data Model é uma representação abstrata das características de uma entidade ou objeto e do relacionamento dele com outros objetos. O processo de criação do esquema de um Legal Data Model envolve a análise de sua estrutura e a definição de cada elemento estrutural encontrado.

As Legal Functions não são parte do Common Data Model (não são esquemas de dados e não são dados), mas precisam ser mencionadas.

Legal Functions ficam armazenadas no EJ-Verse e também são objetos (código) que recebem o produto cartesiano de Legal Data Objects e alteram uma dimensão deles, transformando-os em um outro Legal Data Object. Exemplos de Legal Functions são as transclusões, sendMail, visual law Render, JS Box e outras, que podem ser encontradas na página de referências técnicas da Looplex.

Glossário de objetos definíveis

Trait - Objetos de anotação que são uma expressão de significado semântico. As características podem conter um conjunto de valores de argumentos nomeados.

DataType - Uma coleção nomeada de características para representar conceitos comumente usados ​​que combinam formato de dados, restrições de valor de dados e significados semânticos. Os tipos de dados de exemplo são integer e firstName.

Attribute – Uma descrição simples (tipo de dados) ou complexa (entidade) digitada e nomeada de valores de dados que estão sendo usados ​​para representar uma ideia ou propósito específico. Por exemplo, o tipo de dados firstName pode ser usado para criar um atributo chamado partnerFirstName.

Entity - Um contêiner que reúne uma coleção de características e atributos para que a coleção represente algum conceito lógico, processo de negócios, evento ou outro objeto. Cliente, Compra e Tarefa são exemplos.

Purpose - Uma coleção nomeada de características para representar motivos ou usos comumente usados ​​que um atributo serve em uma entidade. A finalidade pode ser parte da definição da entidade para identificar ideias como “texto de exibição padrão”, “chave primária” ou “coluna de classificação padrão”.

AttributeGroup - Uma coleção nomeada de atributos que funciona como uma macro.

ConstantEntity - Uma associação entre um esquema de entidade e uma matriz constante de valores de dados que existem apenas nos documentos de metadados. Usado para representar tabelas de valores.