Apresentação Giancarlo na PUC-Rio
https://www.youtube.com/watch?v=UehUTBN2Nyo
KG foram criados em Twente em 1982.
Eu comento com quatro observações, que acho que não são nada controversas. A primeira é a seguinte: todo sistema de software representa uma porção da realidade e embute uma determinada teoria sobre o mundo. Todo sistema de software é inevitável. Qualquer estrutura de informação faz isso. Qualquer coisa que não tenha só semântica formal — semântica formal é um jogo, né, que vai mapear um pedaço de matemática para outro pedaço de matemática — precisa fazer um compromisso ontológico. Eu estou usando "semântica" aqui no sentido que todo mundo fora da computação e da lógica usa, de mapeamento de uma conceituação compartilhada. Qualquer coisa que tenha isso é chamada tradicionalmente de real world semantics (semântica do mundo real).
Por exemplo, se você pega um mapa de metrô de Amsterdã, para essa coisa fazer sentido, o significado por trás dela tem uma determinada ontologia — um conjunto, uma teoria sobre uma visão de mundo na qual existem coisas chamadas linhas, compostas de estações ordenadas de uma determinada forma, interagindo com outras linhas, com propriedades como direção, e assim por diante. Essa visão de mundo faz a coisa fazer sentido e adquirir significado.
O mais mundano dos bancos de dados também faz um compromisso ontológico. Por exemplo, esse banco de dados sobre transplantes acredita na existência de coisas como pessoas — algumas vivas, outras mortas — que seguem algumas regras, como "toda pessoa tem que estar viva ou morta", e pessoas que faleceram não voltam à vida. Existem coisas como transplantes, que são entidades, e para elas existirem, outras coisas precisam existir, como pelo menos um cirurgião, um doador e um receptor. Essas entidades têm uma teoria sobre o mundo e o banco de dados acredita na existência delas, com suas propriedades, suas relações, seguindo determinadas regras.
Eu gosto de uma frase do Donald Knuth que diz que "programar é a atividade de dizer a um outro ser humano o que você quer que o computador faça, não é falar para o computador o que você quer que ele faça". Ou seja, de outra forma, se você estiver escrevendo código em Python e tiver variáveis do tipo cliente, fornecedor, ordem de pedido, valor, você está fazendo um compromisso ontológico sobre a existência dessas coisas e suas relações. Essa ideia é bem importante na computação.
Por exemplo, nesse artigo de 1967, um cara chamado George Millie — criador de uma coisa chamada Milly Automata — ele foi também orientador de doutorado de Peter Chen, o criador das entidades de relacionamento. Nesse artigo, Millie fala meio que reclamando que as pessoas estavam muito focadas na manipulação de dados e nos aspectos formais das coisas. Ele disse: "Problema ótimo, isso tudo é interessante, mas o problema primordial é entender a relação entre os símbolos e o mundo real". Ele dizia que "dados são fragmentos de uma teoria do mundo" e que o processamento de dados, se usarmos o vocabulário da época, tem a ver com a manipulação dessas estruturas e dessas teorias sobre o mundo. E isso é uma questão ontológica.
Essa foi a primeira menção de ontologia em computação, em 1967. Alguns até dizem que a primeira menção teria sido no artigo do P. Ha, uma década depois, mas o primeiro artigo realmente sobre ontologia na computação foi o de Millie. Ele ainda cita um filósofo chamado Quine, para quem a definição de ontologia é exatamente isso: o conjunto das coisas com as quais você precisa se comprometer para que uma determinada descrição faça sentido e seja verdadeira.
A primeira noção de ontologia que estamos falando aqui é isso: ontologia (com "o" minúsculo) é uma teoria sobre o tipo de entidades e relações que uma determinada descrição pressupõe existir. E, como estou dizendo, isso é absolutamente inevitável. Qualquer coisa que não seja apenas um pedaço de matemática se compromete com isso. Todo mundo que já programou, ou criou um banco de dados, já fez ontologia — frequentemente sem ter as técnicas e ferramentas para fazer isso de forma adequada.
Mas isso é absolutamente inevitável. Talvez essa seja a primeira "mensagem" da conversa: a alternativa à ontologia não é a "não-ontologia", é a "má ontologia". Você vai fazer isso de qualquer jeito, se programar em Python ou misturar todas essas regras em um código, vai acabar fazendo uma má ontologia.
A segunda observação é a seguinte: claramente não temos mais, nos sistemas de informação, aquele tipo de desenvolvimento chamado greenfield development, que é criar sistemas do zero, sistemas que vão permanecer desconectados de outros sistemas. Todo o desenvolvimento de software moderno é feito de forma coletiva e distribuída, criando coisas a partir da integração de sistemas já existentes ou criando coisas que vão se integrar a outros sistemas no futuro. Por exemplo, se olharmos para isso sob a perspectiva de Big Data, há esse modelo de quatro V's: volume, velocidade, variedade e veracidade. O problema não está em volume e velocidade — sabemos como lidar com isso. O problema está nos outros dois: particularmente na variedade — variedade não só sintática, mas também semântica. A maior parte do esforço é dedicada a lidar com isso. Por quê? Porque todos os problemas interessantes que queremos responder em ciência, governo e organizações só podem ser respondidos conectando sistemas de informação que foram criados por pessoas em pontos diferentes do espaço e do tempo.
Por exemplo, se você quiser saber todas as empresas que têm contrato com um órgão governamental e que doaram dinheiro para campanhas políticas de um candidato que pode tomar decisões sobre esse contrato, isso é uma pergunta relevante, né? A questão é: você precisa integrar várias informações de diferentes sistemas para responder isso. E o problema não é tão simples quanto parece. Você vai ter que integrar cinco, seis sistemas diferentes e entender como esses sistemas se conectam. Isso é um problema de interoperabilidade.
<aqui>
O problema de interoperabilidade é, em qualquer área, como relacionar as ontologias desses sistemas. Não estou falando de ontologia como um artefato, mas sim como uma visão de mundo, o que está embutido em cada um desses sistemas. Interoperabilidade semântica, no final das contas, é entender a relação entre essas diferentes visões de mundo.
Por exemplo, é fácil definir "pessoa" de um lado e "pessoa" do outro, mas qual é a relação entre essas coisas? Ou se tenho um "transplante" de um lado e um "transplante" do outro, qual é a relação? Para entender essas relações entre sistemas, precisamos entender as relações entre os referentes desses sistemas no mundo real. A relação pode ser uma de identidade, mas como saber se é de identidade? E o que significa isso?
Identidade é uma relação de equivalência — reflexiva, simétrica, transitiva. Além disso, obedece ao que é chamado de "lei de Leibniz": duas coisas são iguais se têm as mesmas propriedades em todos os mundos possíveis. Isso é uma relação muito forte. Imagina que você diga que "essa pessoa é a mesma pessoa" e essa relação se propaga por toda a cadeia. Então, ter certeza de que é uma relação de identidade é muito difícil.
E se não for uma relação de identidade, quais são as outras opções? Talvez uma relação de "parte de", ou de dependência. E quais são os tipos de dependência? Por exemplo, a minha dor de cabeça depende de mim: ela só existe se eu existir. Mas há outros tipos de dependência, como quando digo que para ser estudante, você tem que estudar em uma instituição de ensino. Essa é uma dependência existencial. Mas quando digo que, para eu existir, meus pais precisam ter existido antes de mim, é uma dependência genérica — meus pais não precisam existir ao mesmo tempo que eu.
Então, o que precisamos fazer? Precisamos descobrir três coisas: primeiro, descobrir as ontologias embutidas nesses sistemas; segundo, revelá-las, expor que ontologias são essas; e terceiro, entender qual é a relação entre os elementos dessas diversas ontologias. Para isso, precisamos de uma caixa de ferramentas conceituais. Eu já falei de algumas delas: entender o que é "parte de", dependência, que tipo de estruturas taxonômicas ou relações taxonômicas eu posso estabelecer entre as coisas, e assim por diante. Ontologia com "O" maiúsculo é exatamente isso: é uma área cujo objetivo é a produção dessas caixas de ferramentas conceituais, independentes de domínio, mas que podem ser usadas para fazer as três coisas que mencionei, nos mais diversos domínios.
Em computação, frequentemente, quando as pessoas falam de ontologia, estão falando de um artefato. Eu usei a palavra "ontologia" de duas maneiras diferentes: uma visão de mundo, um conjunto de entidades, propriedades e relações — uma teoria sobre o mundo ou sobre uma porção do mundo que estou pressupondo. E, por outro lado, um conjunto de técnicas para encontrar, produzir ou descobrir essas coisas por trás das minhas descrições ou dados.
Um terceiro uso da palavra é como uma representação dessa teoria — ou seja, o artefato em si.
Em domínios críticos, a gente precisa que essas representações — ou seja, um tipo de modelo conceitual, em teoria um modelo conceitual de referência — sirvam como contratos de significado. Não são apenas entidades para estruturar dados; são um contrato dizendo ao mundo qual é a sua visão sobre aquela área. Então, se houver um modelo sobre casamentos, ao ler esse modelo, eu preciso entender exatamente qual é a visão dele sobre casamento: aceita casamento entre pessoas do mesmo sexo? Apenas de sexos diferentes? Pode-se casar com pessoas já falecidas? Pode-se casar com várias pessoas ao mesmo tempo? Em qualquer combinação de sexo, vivas ou mortas? Todas essas são possibilidades.
Se seus modelos forem muito frouxos e não tiverem as restrições adequadas, o contrato está permitindo mais do que você gostaria. Isso se conecta fortemente à diferença entre problemas de verificação e validação.
Verificação é quando checamos se o modelo é consistente, ou seja, sem erros. Uma teoria lógica seria mostrar que ela é consistente.
Validação, por outro lado, é se esse modelo representa a visão de mundo que deveria representar. São questões bem diferentes.
Podemos entender validação da seguinte forma: se eu tenho um determinado modelo e um conjunto de interpretações possíveis daquele modelo, mas também um conjunto de interpretações desejadas para ele. Se meu modelo for muito frouxo, por exemplo, falando do modelo de casamento, tiver algo como "pessoa casada com zero ou mais", isso cria a ilusão de que ele é interessante porque é flexível, mas, na verdade, não é isso que você quer.
Se esse modelo for visto como um tipo de contrato — o único modo pelo qual ele pode realmente dar suporte às tarefas de interoperabilidade — ele está dizendo que sua visão de casamento é a mais liberal possível, ou seja, que se pode casar com várias pessoas ao mesmo tempo, pessoas mortas ou ainda vivas.
Por outro lado, eu poderia ter um modelo excessivamente restritivo, onde, por exemplo, só se permite casar com pessoas de sexos diferentes. Isso excluiria como interpretações válidas algo que você desejaria. O problema de criar esse modelo é encontrar o conjunto de restrições que tornem essas duas coisas iguais: as interpretações possíveis e as interpretações desejadas.
Isso é particularmente importante por causa do problema de interoperabilidade. Se os meus modelos, e consequentemente os sistemas baseados nesses modelos, forem muito frouxos, posso ter uma interseção entre as interpretações possíveis, mas não entre as interpretações desejadas. Isso é o que chamamos de "acordo falso", ou seja, quando achamos que estamos falando a mesma coisa, mas não estamos. O problema não é se discordamos sobre o que é casamento, mas se acreditamos que concordamos, quando, na verdade, não estamos falando a mesma coisa.
Por fim, exatamente nesses domínios críticos, onde os problemas de interoperabilidade têm um custo muito alto — pense na área da saúde, segurança, inclusive segurança nacional, ou na área financeira ou espacial — essas técnicas que estamos discutindo estão sendo adotadas fortemente. Isso ocorre porque essas áreas precisam integrar muitos dados e precisam dessas garantias. Esses modelos são importantes porque, em domínios complexos, a escala e a complexidade aumentam. Um amigo meu chama isso de "ridiculousgram" — o modelo real. E como sabemos se esse modelo representa nossa visão de mundo?
Isso nos leva ao problema da validação. Como posso saber se o modelo realmente diz o que eu quero que ele diga se não consigo nem navegar pela complexidade dele? Uma das coisas que temos investigado por muito tempo é como usar a caixa de ferramentas conceituais — ou ontologia com "O" maiúsculo — para apoiar a construção de modelos de domínio confiáveis.
Esses modelos de domínio devem ser confiáveis, e, consequentemente, os softwares baseados neles também devem ser confiáveis. Para que um modelo seja confiável, ele precisa preservar algumas propriedades: precisa ser consistente, logicamente minimamente e ontologicamente, resiliente a mudanças (de modo que as mudanças não se propaguem de forma incontrolada), preciso, explicável, transparente semanticamente e cognitivamente tratável, reutilizável entre várias aplicações, interoperável e passível de evolução.
<aqui>
Essas propriedades são essenciais quando criamos modelos para ecossistemas organizacionais complexos. Em sistemas mais simples ou em softwares stand-alone, em domínios pequenos e estáveis, essas questões não são tão urgentes. No entanto, para domínios complexos, como os que discutimos, a criação de modelos com essas características é um desafio.
O que temos feito para criar essas linguagens e elementos? Criamos teorias. Ou seja, representamos artefatos que representam as diversas ferramentas daquela caixa de ferramentas conceitual. Um conjunto de microteorias para realizar tarefas como: entender domínios, fazer esclarecimento conceitual, ancoramento semântico de conceitos, integrar coisas, achar relações entre conceitos, etc.
Essas microteorias falam sobre tipos, estruturas taxonômicas, tipos de ordem superior, teoria de relações, teoria de dependências, teoria de processos e eventos, papéis, situações, causalidade, entre outros. Um conjunto de teorias lógicas integradas que, eventualmente, formam o que é chamado de ontologia de fundamentação (em particular, a "Unified Foundational Ontology" — UFO), que está avançando para se tornar um padrão ISO.
A partir dessas teorias, conseguimos criar um conjunto de ferramentas de engenharia que, inclusive, escondem algumas das complexidades dessas teorias. Essas ferramentas são centradas em uma linguagem de modelagem chamada OntoUML, sobre a qual falarei em breve. Ela me permite criar modelos com essas características desejadas.
Temos também metodologias, ferramentas computacionais, catálogos de padrões e antipadrões, geradores de código, simuladores para validação (como simulação visual e gestão da complexidade), ferramentas para aprendizado de axiomas, autorreparo dos modelos, enriquecimento automático, e muito mais.
Essas ferramentas e a linguagem associada têm uma relação íntima com a ontologia, já que as primitivas de modelagem e seus construtos refletem as distinções ontológicas propostas por essa ontologia. Ou seja, a linguagem tem construções que correspondem às diferentes relações e tipos de entidades do domínio.
Então, se eu tenho um conjunto de relações, todo o resto da linguagem vai refletir, na sua sintaxe, esses diferentes tipos de relações. A linguagem tem, na sua gramática, um conjunto de restrições sintáticas que refletem a axiomatização dessa ontologia. A ideia é que você fique restrito a criar modelos dentro dessa linguagem, que façam sentido e respeitem a estrutura dessa ontologia.
Isso acontece com qualquer linguagem que não seja ontologicamente neutra. Mas, se você pegar uma linguagem mais ontologicamente neutra, como uma lógica de primeira ordem, ou uma linguagem mais simples, como essa, o grau de liberdade é muito grande, porque o sistema é muito simples, do ponto de vista ontológico. Você pode fazer qualquer coisa, desde que respeite as regras sintáticas mais básicas.
Quando você tem uma ontologia mais rica, com uma caixa de ferramentas mais sofisticada, essas microteorias restringem como os construtos da linguagem podem ser usados, e eles só podem ser usados de maneira muito específica. Ou seja, a linguagem vira uma coisa restrita. Se você tem conceitos bem definidos, com relações fortes entre eles, você vai ter que representar essas coisas de forma específica. E você passa a modelar instanciando essas estruturas. Isso leva à criação de clusters de conceitos e padrões de design. A linguagem, então, vira uma linguagem de padrões. As primitivas da linguagem não são mais coisas de baixa granularidade, como classes, relações e atributos, mas são design patterns (padrões de design). A gente vai ver isso mais adiante.
Por exemplo, uma extensão da UML. Mas, ao invés de ter só a noção geral de classe, você vai ter distinções mais precisas entre tipos de classe. Então, você tem o que chamamos de kind, que são os tipos que definem o que as coisas realmente são no domínio – ou seja, o que elas são essencialmente. Eles classificam as instâncias em todas as situações possíveis. As instâncias não podem ser de outro tipo que não seja aquele tipo essencial (tipo estático). Nesse exemplo, temos quatro kinds: pessoa, coração, cérebro e organização.
Por exemplo, todos nós somos do tipo pessoa. Eu sou essencialmente uma pessoa, mas posso ser contingentemente saudável ou doente. Posso deixar de ser saudável e virar uma pessoa doente, por exemplo. Esses tipos são dinâmicos, mas o critério de classificação dinâmica é algo intrínseco a mim. Então, a minha condição de ser saudável ou doente é uma fase da minha identidade, mas eu sou sempre essencialmente uma pessoa.
Esses tipos dinâmicos podem ser chamados de papéis. Por exemplo, ser paciente é um papel que uma pessoa desempenha em uma relação específica com uma instituição de saúde. Para ser paciente, você tem que estar sendo tratado por algum provedor de saúde. Já os mixins são tipos que podem ser instanciados por coisas de vários kinds. Por exemplo, um healthcare provider pode ser tanto uma pessoa quanto uma organização. Um mixim atravessa vários kinds, podendo ser dinâmico ou estático.
Se a gente olhar isso do ponto de vista geométrico, o universo das instâncias pode ser visto como uma tecelagem de kinds, ou seja, o universo é todo particionado de forma exaustiva entre esses kinds. E tudo que pertence a um kind não pode ser de outro kind. Esses mixins são como sombras que se movem dentro do espaço de um kind, cruzando a fronteira de vários kinds. Eles podem ser dinâmicos, relacionais e classificar ou desclassificar coisas.
Esses mixins não são restritos apenas ao tempo, eles podem também representar mundos possíveis e situações específicas, não necessariamente temporais. Então, um healthcare provider é uma estrutura desse tipo que pode ser instanciada por coisas de tipos diferentes, como uma pessoa ou uma organização.
Poderia o contexto determinar o papel para um kind?
<aqui>
Agora, temos também aspectos, que são objetos existencialmente dependentes de outras entidades. Isso não tem a ver com o que se chama de aspect-oriented programming (programação orientada a aspectos). Um aspecto é basicamente uma propriedade reificada, ou seja, um objeto que só existe se outra entidade existir. Por exemplo, a minha dor de cabeça só existe se eu existir. Ou a minha habilidade de falar inglês só existe se eu existir. Mas esses aspectos têm um comportamento dinâmico, ou seja, podem mudar ao longo do tempo. A dor de cabeça pode se intensificar, e a habilidade de falar inglês pode melhorar ou piorar com o tempo.
Esses aspectos podem ser dependentes de uma única entidade, ou de várias. Eles conectam coisas. Por exemplo, um contrato de emprego é um objeto que conecta um empregado e uma empresa. Esses objetos têm propriedades essenciais e acidentais. Um sintoma é um tipo de aspecto, por exemplo. Ele pode ser leve ou severo, e essas são fases do sintoma.
Já o tratamento pode ser especializado em subtipos dinâmicos, como ativo ou suspenso. O tratamento pode também desempenhar papéis. Por exemplo, ser um tratamento assegurado é um papel desempenhado pelo tratamento, dependendo de um seguro de saúde.
<aqui>
Esses conceitos ajudam a modelar o mundo de forma mais precisa, e ao fazer isso, a gente deixa explícita a nossa visão de mundo. E, portanto, conseguimos identificar que nem todas as pessoas veem o mesmo domínio da mesma maneira. Se olhássemos isso do ponto de vista lógico, seriam predicados unários. Mesmo intuitivamente, a gente sabe que a relação entre tipos e instâncias não é a mesma.
Por exemplo, Mick Jagger: ele é necessariamente uma pessoa, mas contingentemente um cantor, economista, ou cidadão britânico. Esses são papéis, porque são dinâmicos e relacionais. Já ser uma pessoa viva ou adulta são fases, que são dinâmicas, mas não relacionais. E coisas como "item de herança cultural" ou "item assegurado" são mixins, porque cruzam diferentes tipos.
Essas distinções – se algo é estático ou não, se agrupa coisas do mesmo tipo essencial ou não – são fundamentais para entender como representar as coisas de forma precisa. E a partir dessas distinções, a gente sabe exatamente qual construto usar para representar cada entidade no nosso modelo. Por exemplo, "estudante" é um papel, porque depende de estar ligado a uma instituição de ensino. Não é uma especialização estática, mas sim relacional.
E, claro, existem regras ontológicas que se tornam regras gramaticais. Por exemplo, você não pode criar um papel sem definir o tipo que instancia aquele papel. Não pode ter um papel sem uma relação definida, como "estar matriculado em uma instituição de ensino", porque essa relação faz parte da definição do que é ser estudante.
Essas regras podem ser verificadas automaticamente em ferramentas de modelagem. Se você quebrar alguma dessas regras, o modelo não compila, ou seja, ele não é válido. Então, se você tentar especializar um kind incorretamente, ou violar a definição de um papel, o modelo vai apontar esse erro.
Né, mas tem uma maneira mais interessante de pensar sobre isso. Ao invés de pensar que tem várias coisas que você não pode fazer, a gente deveria pensar que tem poucas coisas que a gente pode fazer com esse papel. Essas regras aqui restringem tanto o uso desse construto que a única maneira que esse construto pode aparecer no modelo é se ele eventualmente especializar um único kind.
Se ele for definido numa relação, no escopo de uma relação tal que o que é chamado de association, no oposto daquele construto, tem uma cardinalidade mínima de pelo menos um. Ou seja, que define essa condição de relação. E aí, esse construto se manifesta como um tipo de padrão.
Deixa eu dar um foco nisso daqui: na importância de representar essa entidade aqui explicitamente. Que que ele tá fazendo aqui? Qual a relação com essa relação?
Se a gente usa uma notação tradicional onde as relações são representadas simplesmente como um conjunto de duplas — nesse caso, de pares ordenados — que que acontece? Essas cardinalidades são necessariamente ambíguas. Então, esse modelo tá dizendo o quê? Olha, um paciente é tratado por um ou mais hospitais, vamos dizer assim, para simplificar, e um hospital trata um ou mais pacientes.
A pergunta é: essas cardinalidades querem dizer o quê? Posso dar para vocês oito maneiras diferentes de interpretar essas cardinalidades. Por exemplo, o que que faz com que essa relação aqui seja verdadeira?
Lembra a condição relacional para alguém ser um paciente: é participar de um tratamento envolvendo uma unidade médica aqui, né, no hospital. Mas agora, dado um tratamento, eu posso ter:
- Um paciente, uma unidade médica, e ambos podem participar de vários tratamentos;
- Vários pacientes, uma unidade médica, e todos podem participar de vários tratamentos;
- Ou vários tratamentos, várias unidades médicas, todos participando de vários tratamentos.
Um paciente, várias unidades médicas... Isso tem a ver com a semântica do que é essa relação.
Uma conceituação na qual se você tem várias unidades te tratando no hospital, todos esses são tratamentos diferentes, é muito diferente da semântica na qual todo mundo pode participar do mesmo tratamento. Se eu represento explicitamente essa entidade que faz com que essa relação seja verdadeira — o tratamento, aquele relator — eu elimino essa ambiguidade.
Esse modelo tá me dizendo: olha, tratamentos aqui envolvem um único paciente e uma unidade médica, mas eles podem participar de vários tratamentos.
Essas cardinalidades aqui, como vou mostrar para vocês — vou trocar aquelas de cima — e aquelas vão permanecer as mesmas, demonstrando que elas colapsam várias interpretações diferentes.
Olha, nessa outra interpretação — essa é que a gente tinha — nessa outra, agora eu troquei. Esse é o mundo meio esquisito no qual um tratamento pode envolver vários pacientes e várias unidades médicas, mas o paciente só pode participar de um tratamento, e a unidade médica só pode atender a um tratamento. Vou trocar de novo aqui: posso ter vários. Todo mundo pode participar de vários. Essas cardinalidades permanecem as mesmas. Ou seja, elas são incapazes de diferenciar todos esses casos. Essa relação aqui é uma relação que chama derivação. Ela conecta as instâncias de tratamento com esses pares ordenados. Não é relação association class do UML, para quem já viu.
Essa cardinalidade aqui é derivada dessas duas, né? Automaticamente, porque se um tratamento só pode conectar um paciente e uma unidade médica, eu só posso ter um par ordenado aqui derivado de um tratamento. Mas essa daqui não. Essa tá te dizendo outra coisa: tá te dizendo quantas vezes você pode ser tratado pelo mesmo hospital, quantos tratamentos podem existir entre a mesma pessoa e o mesmo hospital.
Um tipo de pack-semantics per relation. Se isso daqui fosse n, aí isso aqui seria um para n também. Eu poderia derivar vários pares ordenados da mesma relação entre tratamento, paciente e hospital.
Se eu tivesse só isso, não tem como saber. João hospital 1, João hospital 2, João TR... Não sei se, por exemplo, o tratamento conecta João com hospital 1 e 2, e tem um outro tratamento aqui que conecta João com hospital 3. Não tem como saber. Isso aqui não te dá informação suficiente para você reconstruir o que tá acontecendo por trás.
Isso também é um padrão da linguagem. Toda vez que eu tenho uma relação desse tipo, eu sou obrigado a representar explicitamente essas relações, esse relator e essas relações de dependência existencial com as suas cardinalidades.
Como eu tava dizendo, a linguagem é uma linguagem de padrões. E aí eu posso construir um editor que leva isso em consideração. Aqui, por exemplo, olha: pessoa é um kind, pessoa falecida é uma fase. E aí a linguagem sabe: se é uma fase, tem que ter pelo menos uma outra fase. Você sempre pode sair da fase, mas você não pode sair do kind. Você tem que se mover para outra fase do mesmo kind.
Aqui organização é um kind. Organização ativa é uma fase, mesma história, mesmo padrão: sempre pode deixar essa fase, não pode deixar esse kind. Você vai se mover para outra fase do mesmo kind. E organização extinta.
Um padrão um pouco mais interessante: eu quero modelar um mixin, aqueles role mixin. E aí eu vou dizer: "cliente pessoal é um papel desempenhado por pessoas vivas; clientes corporativos é um papel desempenhado por organizações ativas". O role mixin, nesse caso, é cliente. O relator, contexto relacional, é um contrato de serviço. E o papel complementar é o papel de fornecedor desempenhado por pessoas ativas. Eu instancio isso, basicamente preenchendo esses três formulários, ou seja, distanciando esses três padrões. Esse é um modelo pequeno, mas não é um modelo trivial; a maioria das pessoas erraria esse modelo. Essa relação aqui é uma relação que as pessoas acham muito complicada. As pessoas fazem isso: cliente pode ser pessoa ou organização. Usam pessoa ou organização, como se fosse um kind, isso é um kind, isso é um papel. Isso gera uma contradição lógica, é um anti padrão muito comum.
Esses modelos crescem muito e alguns desses modelos vão ter milhares de classes. E a questão é: como é que a gente pode fazer gestão de complexidade desses modelos? Que tipo de ferramenta a gente pode oferecer para modularização, para abstração, para extrair viewpoints diferentes do modelo? Pensa como seria fazer isso com uma linguagem neutra, tipo UML, o ER, ou OWL, ou qualquer coisa desse tipo. Dever de casa é assim: eu te dou um modelo com 5000 classes, você escreve um algoritmo que gera um resumo com 20 classes, mas que realmente captura a essência do que aquele modelo é. Imagina como seria fazer isso numa linguagem tipo UML. Você não tem informação nenhuma porque todas as classes e relações são iguais. Então as pessoas tentam coisas completamente malucas, tipo PageRank: "deixa eu ver a classe que chega mais relações nela". Mas é uma maneira muito pouco sofisticada.
Aqui você tem muito mais informação porque tem mais semântica sobre o que essas classes querem dizer. E aí a gente tem vários algoritmos sobre isso. Um, tem muito simples, mas é extremamente eficiente: é o seguinte, você separa as entidades e os contextos por relator.
O que é contexto aqui?
Pensar, por exemplo, meu caso: eu tenho várias facetas da minha vida. Eu sou professor na Holanda. Eu sou professor na Suécia. Eu sou cidadão brasileiro, mas também sou cidadão italiano. E eu pertenço ao clube. Todas essas coisas são facetas diferentes, e tudo que está relacionado às relações que tenho dentro da Universidade de Twente são completamente disjuntas das relações que tenho na Universidade de Estocolmo. Sim, as relações de orientação, alocação de custo, tudo isso é independente, são clusters independentes. Mas ali eu tenho uma cadeia de dependência.
Então essa intuição, o que esse algoritmo faz? Ele pega, para cada um desses relatores, ele vai navegar, verificar quais são os papéis desempenhados nesse contexto. E ele vai navegando até atribuir identidade para todos aqueles papéis, até chegar nesses kinds.
Faz isso para o employment, para o car ownership. Esse é um pouco mais interessante. Esse daqui, o que ele faz? Se ele achar um mixin daquele, ele não vai conseguir achar identidade para cima, então vai ter que descer para o nível dos portais e ir navegando até achar esses kinds. E aí automaticamente ele gera esses clusters. Gera o Car Rental, o employment, o car ownership, e o marriage. É um algoritmo extremamente eficiente do ponto de vista computacional e que não precisa de nenhuma intervenção humana. A gente fez experimentos que mostram que as pessoas preferiam essa modularização do que outros algoritmos alternativos de otimização.
A mesma coisa para o algoritmo de abstração. Agora, aqui, o algoritmo
faz o seguinte: ele abstrai para os kinds. Ele pega todas as
informações e fala: "deixa eu ver o que as coisas são essencialmente nesse domínio." E ele vai abstraindo tudo até chegar nesse nível de kind. Então um modelo desse tipo vira uma coisa desse tipo.
Agora, deixa eu falar um pouco sobre reusabilidade em implementações diferentes.
Essa visão que estou defendendo aqui separa o problema de modelagem conceitual do problema de design e de implementação. Quando você está fazendo modelagem conceitual e criando esses contratos de significado, o que você quer garantir? Que aquilo represente de maneira fidedigna a porção do mundo que você deseja representar e que essa representação seja eficiente para um ser humano fazer coisas como comunicar, compreender o domínio, resolver problemas, negociar significado, entre outras.
Uma vez que você tem essa representação, pode considerar requisitos não funcionais, de design e de implementação, gerando implementações diferentes para aquele modelo. Por exemplo, a partir desse modelo OntoUML, geramos várias implementações, incluindo bancos relacionais de forma automática.
Temos uma estratégia que utiliza o algoritmo de abstração mencionado anteriormente. Um problema frequente é o mapeamento objeto-relacional, onde surgem dúvidas: você gera uma tabela para cada classe? Para a hierarquia inteira? Ou uma tabela para um caminho entre a classe raiz e a classe folha?
Com o algoritmo de abstração, conseguimos fazer um "one table per kind". Isso traz benefícios tanto do ponto de vista computacional quanto cognitivo. Fizemos experimentos com usuários que não conheciam ontologias, e eles preferiram essa abordagem. Além disso, geramos transformações para outras linguagens, como uma utilizada no contexto de web semântica, permitindo raciocínio automatizado.
<aqui>
No entanto, há desafios com linguagens menos expressivas, onde as coisas não podem mudar de classe, como o caso de um estudante que deixa de ser estudante. Desenvolvemos estratégias para lidar com essa limitação e mapear essas mudanças no tempo.
Mapeamos padrões de transformação que permitem gerar especificações automaticamente. Isso elimina a necessidade de lidar diretamente com a complexidade de certas linguagens ou lógicas, tornando o processo mais eficiente. Além disso, conseguimos expor a ontologia embutida em uma visão de mundo ou sistema, representando explicitamente os conceitos e evitando falsos acordos, como os exemplos que dei sobre "pessoa" e "transplante".
Por exemplo, conceitos aparentemente iguais em dois modelos podem ser diferentes. Um "transplante" pode ser um relator que conecta cirurgião, doador e receptor, enquanto outro pode representar uma licença para realizar um tipo de transplante. Essa diferenciação é crucial para evitar ambiguidades em sistemas interoperáveis.
<aqui>
A semântica das relações também pode variar muito. Modelos que aparentam ser iguais em termos de classes e cardinalidades podem, na verdade, representar conceitos distintos. Por isso, usamos restrições adicionais no modelo para garantir que as interpretações possíveis correspondam às desejadas.
Por fim, enfrentamos o problema de validação. Isso vai além da verificação de consistência; envolve garantir que o modelo reflita corretamente as intenções do modelador. Para isso, usamos técnicas de simulação visual, confrontando o modelador com instâncias possíveis geradas pelo modelo. Assim, ele pode identificar e corrigir interpretações indesejadas.
Essa abordagem nos permitiu criar um repositório com mais de 200 modelos, utilizado para pesquisa orientada a dados. Identificamos anti-padrões frequentes, como relacionalidades que conectam papéis especializados no mesmo centro sem impedir ambiguidades. Por exemplo, modelos que permitem que uma mesma pessoa seja doador, receptor e cirurgião no mesmo transplante.
Desenvolvemos ferramentas para detectar esses anti-padrões e propor correções automáticas. Também criamos um catálogo desses anti-padrões, ajudando modeladores a evitá-los. Essas ferramentas são especialmente úteis em modelos grandes e complexos, com milhares de classes e relações.
Com isso, avançamos na direção de modelos mais robustos, compreensíveis e interoperáveis, capazes de representar domínios complexos sem ambiguidades.
Nessa área, uma das coisas que a gente vem fazendo é detectar certas estruturas que, quando presentes nos modelos, causam essa dissociação entre os modelos possíveis e os modelos desejados. Ou seja, estruturas que ativam o nosso viés cognitivo. Muitas vezes, a gente não percebe algo que é tão óbvio. Por exemplo, se você tem isso, inclusive, é um anti-padrão. Se você tem um relator desse tipo, um contexto relacional conectando papéis que especializam o mesmo kind, é claro que pode ser a mesma instância preenchendo todos os papéis. Mas, na verdade, há vários outros modelos indesejados. Um em que estou doando o coração para o Sérgio e realizando o transplante, ou outro em que estou doando o coração para mim mesmo e o Sérgio está realizando o transplante. Tudo isso é instância possível desse modelo, e a gente não percebe. Esse é um anti-padrão.
Simulamos esses modelos por um bom tempo e detectamos essas estruturas. Uma vez detectadas, você pode embutir isso na ferramenta. Ela passa a identificar e avisar: "Se você tiver isso aqui, estará aceitando essas interpretações possíveis. Qual delas você quer excluir?" Aí você responde, e ela inclui exceções para eliminar aquilo. Por exemplo, você quer que os três sejam disjuntos no escopo do transplante? Ou que dois sejam disjuntos? Quais dois? Ou você quer que sejam disjuntos de maneira geral? Isso te dá essas possibilidades. Implementamos ferramentas de detecção de anti-padrões e propostas de retificação dos modelos.
Criamos um catálogo desses anti-padrões, muitos dos quais as pessoas não percebem. Por exemplo, se eu tiver dois tipos, uma relação entre esses dois tipos, outros dois tipos especializando os dois primeiros, e uma relação entre esses dois, frequentemente existe uma restrição entre essas duas relações que as pessoas não percebem que gostariam de colocar.
Na ontologia de ECG, no modelo de ECG, o coração é composto de ventrículos. Para o coração desempenhar o papel de bomba sanguínea, o ventrículo tem que desempenhar um papel de bomba sanguínea. Quando simulamos esse modelo, observamos algo interessante: meu coração é composto de um ventrículo, o coração da Fernanda é composto de um ventrículo, mas quando meu coração bombeia sangue, ele faz isso com o ventrículo dela. Isso é uma instância possível daquele modelo, que ninguém percebe. Estamos falando de um modelo com quatro classes e duas relações; imagine 5.000 ou 15.000.
Pegamos um repositório e começamos a fazer estatísticas sobre a presença desses anti-padrões. Por exemplo, aquele padrão do coração aparecia em metade dos modelos. Num conjunto de 817, isolamos aleatoriamente 50 modelos e encontramos 817 instâncias desse padrão. Um outro anti-padrão, chamado "Association Cycle", apareceu em 92% dos modelos, porque é um problema sério. Esses ciclos são perigosos, e frequentemente esquecemos de restrições ligadas a eles. Em 50 modelos, esse ciclo apareceu 1.800 vezes. Já o do transplante apareceu em 25% dos modelos.
O que fizemos, então? Pegamos um dos modelos mais robustos, com cerca de 5.000 classes, produzido por uma organização profissional, uma agência governamental, com um grupo de 12 pessoas trabalhando durante dois anos. Oferecemos a ferramenta a eles para detectar se aquilo era erro. Em 88% dos casos, os anti-padrões eram erros, e conseguimos corrigi-los automaticamente em 97% dos casos. O anti-padrão do transplante era erro em 56% dos casos, e corrigimos automaticamente 77% deles. Já o "Association Cycle" era erro em 70% dos casos, e corrigimos 71% automaticamente. Cada anti-padrão que é um erro representa uma falha no contrato do modelo.
Essa situação é tão presente que, se você não validar o modelo, ele estará errado. Afirmo com convicção: qualquer modelo não trivial que for validado terá pelo menos alguns anti-padrões. Por exemplo, este aqui permite uma interpretação indesejada, mas possível: o mesmo indivíduo pode ser o "Health Care Provider" e o paciente ao mesmo tempo. Difícil perceber isso mesmo num modelo pequeno. Quando simulamos, isso aparece: nesse tratamento, o "Provider" e o paciente são a mesma pessoa.
Para resolver, utilizamos a linguagem Alloy, que transforma especificações lógicas em problemas de "Constraint Satisfaction" e gera modelos visuais. Criamos uma semântica modal para visualização, permitindo ao usuário ver os modelos lógicos de maneira interativa. Por exemplo, ele pode definir quais instâncias deseja incluir ou excluir. Isso facilita a validação do modelo.
Focamos também em padrões ligados à modelagem multinível. Por exemplo, "pessoas" têm instâncias como "adulto", que é um subtipo de pessoa, e assim por diante. Esse tipo de modelagem gera muitos anti-padrões. Detectamos e corrigimos esses problemas em grandes repositórios, como o Wikidata, onde erros desse tipo apareciam em 85% das modelagens.
Por fim, desenvolvemos abordagens simbólicas e subsimbólicas para ajudar na evolução de modelos legados, incluindo técnicas de "stereotype prediction" e algoritmos interativos para corrigir modelos de maneira eficiente. Nosso objetivo é construir sistemas confiáveis, com modelos resilientes, explicáveis e interoperáveis. Isso requer ferramentas que amplifiquem a inteligência do usuário, combinando aprendizado de máquina e técnicas dedutivas para facilitar a tarefa de modelagem.
Aí resolvemos fazer outra coisa. Pensamos: “Vamos tentar checar antipadrões e estruturas muito grandes.” E decidimos focar no Wikidata. Em particular, queríamos verificar padrões ligados àquele conceito de tipos com coexistência, chamados de modelagem multinível. Por exemplo, temos Pessoa. Uma instância de Adulto é um subtipo de Pessoa. Todo Adulto é uma instância de Pessoa e um indivíduo. Adulto também é uma instância de uma classe de segunda ordem chamada Persona Phase, que representa fases etárias. Assim, John é uma instância de Adulto, e Adulto é uma instância desse conceito. Há vários antipadrões associados a essa modelagem multinível.
Um exemplo ocorre no Wikidata, onde há várias relações de especialização. O problema é que o Wikidata é construído coletivamente, e alguns termos são polissêmicos, o que leva pessoas a tratá-los como instâncias ou classes, sem checagem. Por exemplo, antes de corrigirem, havia profissões como Criador, Cientista e Cientista da Computação. Mas, ao mesmo tempo, Cientista era tratado como instância de profissão, o que levava à conclusão errada de que Tim Berners-Lee é uma profissão.
Esse antipadrão era tão comum que, ao analisarmos o Wikidata, identificamos que havia 3.371 classes em taxonomias. No entanto, 17.819 classes cruzavam níveis taxonômicos, e em 85% dos casos os modelos estavam errados. Mas é possível detectar e corrigir automaticamente.
Por fim, falando sobre a evolução de modelos, imagine que estamos usando o sistema para gerar simulações de instâncias possíveis. O usuário valida essas instâncias, dizendo o que quer e o que não quer. Por exemplo, “Quero casamento com várias pessoas, mas não com ninguém morto.” Ou “Você pode doar para outra pessoa e realizar um transplante, mas não para si mesmo.” Nesse processo, o usuário anota o que deseja ou rejeita, criando uma base de exemplos e contraexemplos.
Juntando essa base com a teoria original, podemos aprender as restrições que devem ser incluídas no modelo. Isso excluiria os contraexemplos e validaria os exemplos. Por exemplo, se um modelo diz que uma pessoa pode estar viva e morta ao mesmo tempo, podemos usar as validações para restringir esse comportamento e gerar um modelo mais robusto.
Essa abordagem é necessária porque os antipadrões derivam de nossas falhas cognitivas, enquanto os padrões vêm da teoria. Existem poucas formas de fazer as coisas corretamente, mas infinitas maneiras de cometer erros. Portanto, ao reunir essas validações da comunidade, podemos usar técnicas de aprendizado para identificar e corrigir antipadrões.
Agora, sobre um problema atual: o legado de modelos criados de forma diversa. Há milhões de modelos construídos sem padronização. Nossa ideia é ajudar a transpor esses modelos para uma linguagem mais formal e ancorá-los em ontologias. Recentemente, testamos duas abordagens. Na subsimbólica, usamos redes convolucionais e modelos de linguagem para prever estereótipos e classificar conceitos em ontologias. Na abordagem simbólica, aproveitamos a gramática restrita da linguagem. Por exemplo, se sabemos que algo é um Papel, já restringimos as opções para elementos relacionados.
Descobrimos que, ao marcar apenas 10% das classes de um modelo como conhecidas (seed), conseguimos inferir o restante de maneira eficiente. Esse processo interativo é mais eficaz e demonstra o valor de métodos simbólicos. Agora, exploramos como combinar essa abordagem com técnicas de aprendizado, como adversarial learning, para melhorar ainda mais as validações iniciais.
A mensagem principal é que sistemas confiáveis dependem de modelos confiáveis. Esses modelos devem ser resilientes, explicáveis, interoperáveis, reutilizáveis e evolutivos. Construir tais modelos exige linguagens precisas com semântica consistente e técnicas específicas, como model finding, verificação técnica, detecção de padrões e antipadrões, e aprendizado de máquina. Tudo isso para apoiar os usuários na difícil tarefa de criar modelos confiáveis.
Todo sistema utiliza um modelo, mais ou menos explícito. Esses modelos confiáveis precisam ser confiáveis (reliable), resilientes (resilient), explicáveis (explainable), interoperáveis (interoperable), reutilizáveis (reusable), e evolutivos (evolvable). Para construir modelos com essas propriedades, são necessárias técnicas muito específicas. Isso representa um verdadeiro projeto de humildade, um reconhecimento da nossa incapacidade de lidar com a complexidade inerente a essas tarefas.
Precisamos de linguagens que sejam realmente precisas, com uma semântica consistente e um tipo de semântica ontológica sólida. Além disso, precisamos de um programa de amplificação da inteligência (Intelligence Amplification - IA), em vez de inteligência artificial (Artificial Intelligence - AI).
Nesse esforço, temos experimentado de tudo: técnicas de model finding, verificação formal, detecção e mineração de repositórios para identificar padrões e antipadrões. Utilizamos tudo que está ao nosso alcance, incluindo machine learning, abordagens indutivas, dedutivas, e métodos híbridos. Até mesmo o aprendizado por meio de programas é um tipo de machine learning. A ideia é combinar todas essas ferramentas para ajudar os usuários a enfrentar a difícil tarefa de construir modelos com essas propriedades.
Comentários
Postar um comentário
Sinta-se a vontade para comentar. Críticas construtivas são sempre bem vindas.