Ancestors Note Book: uma aplicação para memorabilia e genealogia, baseada em ontologias

João Manuel Pós de Mina Grenhas Ancestors Note Book: uma aplicação para memorabilia e genealogia, baseada em ontologias Dissertação de Mestrado Mestrado em Engenharia Informática Trabalho efetuado sob a orientação do Professor José João Almeida, UMinho, D. I. Coorientador: Rui Castro Mendes, UMinho, D. I. Abril de 2022 João Manuel Pós de Mina Grenhas Ancestors Note Book: uma aplicação para memorabilia e genealogia, baseada em ontologias Dissertação de Mestrado Mestrado em Engenharia Informática Trabalho efetuado sob a orientação do Professor José João Almeida, UMinho, D. I. Coorientador: Rui Castro Mendes, UMinho, D. I. Abril de 2022 Direitos de autor e Condições de utilização do trabalho por terceiros Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho: Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ Ancestors Note Book v Agradecimentos Agradeço à minha esposa todo o apoio e motivação, tornando exequível esta longa jornada. Agradeço à Módula C toda a tolerância horária, concedendo o tempo necessário a este projeto (e a outros do mesmo mestrado). Agradeço aos orientadores toda a disponibilidade e aconselhamento, todas as ideias, toda a tolerância da agenda, e toda a inteligente abertura em respeitar caminhos de desenvolvimento por vezes inesperados. Ancestors Note Book vi Declaração de Integridade Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. Ancestors Note Book vii Resumo O tema desta dissertação de mestrado desenrolou-se no âmbito das humanidades digitais, pretendendo desenhar e construir um toolkit de apoio ao registo e processamento de histórias de família, micro-história, documentos, fotografias, elementos genealógicos e histórias de instituição, com especial interesse na inferência de indivíduos. Foi desenvolvido um protótipo de aplicação web de uso pessoal, sobre Flask/Python, configurável (e reutilizável, salvo ajustes), como prova de conceito a suportar uma ontologia OWL2 sobre o domínio do problema. ANB = Ancestors Note Book = Ontologia AncestorsNB, para Memorabilia e Genealogia, Relações humanas e Ambiente + Filosofia Wiki + Inferência Interativa e Dinâmica + SPARQL + Geração de formulários O domínio do problema induziu naturalmente uma arquitetura de ontologia, à qual foi dada persistência num ficheiro de texto em sintaxe Turtle, carregada pela aplicação num grafo RDFLib. A ontologia é expansível, mas já inclui à partida relacionamentos de genealogia de pessoas, com diversos graus de parentesco, e ainda relacionamento no âmbito social, institucional e geográfico, para pessoas, organizações e lugares. Ainda no âmbito da memorabilia, prevê-se o registo e referência de eventos, fotografias, documentos, multimédia, histórias de família, artigos sobre qualquer assunto. Na aplicação, acolhe-se uma filosofia Wiki, no sentido em que proporciona uma apresentação gráfica (suportada em mardkdown e html), navegação por hiperligações (internas ou externas), e edição. Em virtualmente qualquer classe ontológica, a apresentação prettyprint de indivíduos e os formulários de ingestão permitem templating e alguma configuração. A apresentação prettyprint prevê documentos de variada morfologia, incluindo texto, PDF, markdown e multimédia. Permite-se ao utilizador a ingestão de informação em lote (na sintaxe Turtle, por edição direta ou via ficheiro), e CRUD interativo (via formulários ou SPARQL), num ambiente operacional rico, com pesquisas de utilizador combinadas com navegação, além de facilitar a inferência sobre indivíduos, sejam pessoas ou não. A inferência é interativa (i.e., a pedido interativo do utilizador) e/ou dinâmica (por etiquetagem no conteúdo de um campo configurado como elegível para este efeito), jogando com classes, ID de indivíduo, nomes e datas. A inferência pode ter posicionamento genealógico: basta que seja encontrado um grau de parentesco. Tanto a inferência como os motores de pesquisa interativa se baseiam num tratamento rico de nomes e moradas em Português, em que a normalização prevê grafias antigas, além de acentos e partículas de ligação (de, da, do, etc.). Ancestors Note Book viii Palavras-Chave: Humanidades digitais, ontologias OWL2, genealogia, inferência, prototipagem de aplicações web para ontologias, geração de formulários html, RDFLib, processamento de linguagem natural. Ancestors Note Book 1 1. Introdução 1.1. Contextualização e Motivação No âmbito da memorabilia, há histórias – orais ou escritas –, documentos, fotografias – possivelmente datadas e anotadas –, que levam a descobertas potencialmente muito ricas, ou simplesmente interessantes/curiosas/cómicas, não só para as famílias relacionadas, como para a própria comunidade, e poderão até conduzir a resultados com interesse histórico ou mesmo literário. No entanto, a desorganização, antiguidade e ambiguidade dessas informações pode exigir um esforço de investigação e dispêndio de tempo nem sempre disponíveis. Basta pensar que, dentro da família (e na própria comunidade), existe grande repetição de nomes próprios, e mesmo do primeiro e último nome, pelo que, ao serem aflorados ao acaso, não contribuem para a identificação do interveniente, especialmente se for desconhecido do utilizador. Neste jogo de identificação e relacionamento, ao entrarem datas e lugares, pode ser viável uma identificação, se soubermos mais sobre as pessoas da família e comunidade envolvente, nomeadamente dados pessoais e relacionamentos mútuos, ou mesmo relacionamentos ilustres (pessoas por alguma razão famosas, das quais sempre se recolhe e regista dados diversos). Por exemplo, se dada pessoa participou na Primeira Grande Guerra, mesmo que seja referido simplesmente pelo “José”, mesmo que tenha parentes com o mesmo nome, poderá reduzir-se o âmbito de procura dentro do domínio definido. No âmbito das genealogias, é também viável inferir graus de parentesco através do simples registo dos progenitores, além do cônjuge. Estes relacionamentos, e outros, poderão enriquecer uma rede que poderá ser muito útil neste contexto de esforço de identificação de pessoas ou outra descoberta de informação, como ao referir “o Joãozinho, filho do tio José”, ou “o famoso professor de música da Maria”, ou “a casa onde nasceu F”. Todos estes tópicos são elegíveis para um enquadramento por humanidades digitais. 1.2. Objetivos Em termos de humanidades digitais, podemos pensar, à partida, e sempre num contexto digital, em dicionários enciclopédicos, wiki documentais baseados em hipertexto. Entendese haver potencial em tentar aliar esses tópicos com a facilidade de carregar informação, e a possibilidade de ter relacionamentos sociais (genealógicos ou não) para facilitar a identificação de indivíduos e contextualizar. Resumidamente, pretende-se chegar a um sistema que ofereça: Ancestors Note Book 2  um tratamento rico de nomes em Português, com um toolkit de funcionalidade variada sobre o domínio das humanidades digitais;  uma ontologia rica para este domínio: ontologia de base (classes e propriedades), que cada instalação poderá enriquecer, em estrutura e povoamento (os indivíduos);  uma DSL para carregar informação na ontologia, mas que também lhe possa adicionar estrutura e indivíduos, como referido no ponto anterior;  um motor de inferência (constraint solver) para restrições no domínio geográfico, genealógico e temporal. Esmiuçando, este projeto tem por objetivo o desenho e construção de um toolkit de apoio ao registo e processamento de histórias de família, micro-história, elementos genealógicos e histórias de instituição:  Pretende-se um sistema que, dado um texto ou artigo, ajude a identificar e associar/inserir pessoas ou entidades concretas, para o que será necessário: o Desambiguar nomes pela ortografia: os nomes a analisar poderão estar abreviados (exemplos: JJ, J.J.), ou reduzidos a primeiros nomes (José, José João), ou nomes por que as pessoas não são usualmente tratadas (José Almeida), ou com grafia diferente, seja por erro (Jose Joao, Joes) ou por diferenças ortográficas históricas (Victor x Vítor, Thomaz x Tomás). o Desambiguar pessoas/entidades pelo contexto de lugares, datas (expressas ou implícitas) e eventos, que possam ser comparados com os conhecidos (nascimento e morte, idade maior, meia idade, idade avançada). o O sistema poderá aceitar constraints para ajudar a refinar soluções. Pretende-se um constraint solver para restrições no domínio geográfico, genealógico, temporal – no âmbito do período de vida humano (como data de óbito >= data de nascimento, idade para serviço militar em comparação com eventos como batalhas, etc.). o Em caso de elegibilidade de várias instâncias (pessoas/entidades/eventos/...) possíveis, o utilizador poderá ajudar a escolher, perante uma lista (desejavelmente ordenada por probabilidade), com eventual identificação de relacionamentos entre essas pessoas ou entidades, recorrendo à análise de datas, eventos e lugares.  O utilizador deve poder efetuar compilações, entendidas como compilações de documentos e eventos da ontologia, entre outros, e poder inserir anotações, fotos/imagens, ou mesmo uma árvore genealógica gerada pelo sistema.  O sistema deve facultar a navegação pela informação.  O projeto parece induzir naturalmente, em termos abstratos, uma ontologia para: o pessoas ou organizações, e seus relacionamentos: Ancestors Note Book 3  pessoais (exemplo: “Fulano de Tal” conhece “Sicrano, Famoso Músico”),  familiares (graus de parentesco)  e outros.  Pessoas – guardar: nome oficial e variantes, alcunhas, títulos, período de vida, pai, mãe, cônjuge, local onde nasceu (freguesia, concelho, etc.), locais onde residiu (com datas). o wiki de documentos do tipo genérico artigo, podendo incluir fotografias/imagens (outra média?) datadas e anotadas, histórias de vida/família, biografias, artigos jornalísticos, documentos históricos e outros (história de instituições, de lugares, cronologias, etc.); o eventos familiares, curriculares, históricos e outros.  Será útil que o sistema reconheça uma Domain Specific Language (DSL) para carregar informação a guardar ou analisar, a partir de um ficheiro de texto. Esta DSL deve prever o enriquecimento da ontologia, como por exemplo em termos de classes e relações. 1.3. Convenções e Definições Convenções Convenciona-se para uso do projeto os graus de parentesco em Português. Glossário Dado o potencial volume de termos a definir, optou-se por dividir o glossário em dois, passíveis de consulta no fim deste documento:  Glossário Genealógico: para termos no contexto da genealogia.  Glossário Geral: para outros termos em contexto. Siglas, acrónimos e abreviaturas ANB Ancestors Note Book – tema desta dissertação API Application Programming Interface BD Base de Dados, o mesmo que DB (Database) Cf. Confrontar, ver também CRUD Create, Read, Update and Delete – cf. REST DSL Domain Specific Language Endereço IP Endereço de Protocolo da Internet, Internet Protocol address (IP address) Ex./Exs. Exemplo, exemplos Ancestors Note Book 4 HTTP Hypertext Transfer Protocol, Protocolo de Transferência de Hipertexto ID Identificador. No contexto atual, tipicamente um ID ontológico, RDF/Turtle. IRI Internationalized Resource Identifier MVC Model View Controller, um padrão de arquitetura de software N/A Não aplicável OOP Object Oriented Programming, o mesmo que POO PF Programação Funcional PLN, NPL Processamento de Linguagem Natural, Natural Language Processing POO Programação orientada a objetos, o mesmo que OOP RDF Resource Description Framework REST Representational State Transfer RGPD Regulamento Geral de Proteção de Dados – cf. General Data Protection Regulation – GDPR. SGBD Sistema Gestor de Base de Dados SPARQL SPARQL Protocol And RDF Query Language Turtle RDF 1.1 Turtle, i.e. Terse RDF Triple Language UI User Interface – Interface com o utilizador UML Unified Modeling Language URI Uniform Resource Identifier – recentemente, este termo vem sendo preterido em favor do IRI. 1.4. Factos e Assunções Relevantes Factos Tradicionalmente, toda a pessoa humana tem sexo masculino ou feminino, e um pai e uma mãe, biológicos. Algum ou ambos os progenitores podem ser desconhecidos, ou de género indeterminado. A reprodução medicamente assistida, conjugada ou não com mudanças de sexo, podem introduzir complexidade na avaliação de géneros dos progenitores. O grau de parentesco por consanguinidade, de uma pessoa em relação a outra, nunca se altera ao longo do tempo. Pode alterar-se o cônjuge, mas mesmo alguns relacionamentos por afinidade mantêm-se, nem que seja de um ponto de vista social – suponhamos o caso de uma união/casamento com filhos, que têm os seus avós paternos e maternos: a separação/divórcio não quebra a ligação entre netos e avós, logo por transitividade poderemos afirmar que os relacionamentos por afinidade se mantêm, nem que seja psicologicamente… Por exemplo, novamente o divórcio: em relação aos pais do ex-marido, a ex-esposa passa a ex-nora, e não a “completa desconhecida”. Ancestors Note Book 5 Assunções Relevantes (Nada a referir até ao momento.) 1.5. Opções e Restrições Em termos de sintaxe da ontologia, estabeleceu-se como regra geral uma preferência de trabalhar com a sintaxe Turtle, por ser habitual no SPARQL e mais legível do que outros formatos, nomeadamente RDF/XML, embora, sendo um subconjunto simplificado de Notation3, esta também se considere interessante (cf. https://en.wikipedia.org/wiki/ Notation3). Esta opção assume-se ao mostrar a informação numa perspetiva mais formal, mas, em termos da visualização, poderá ainda amenizar-se termos e IRI, procurando a legibilidade centrada no utilizador. 1.6. Conclusão O projeto nasce duma necessidade prática de registar, sobre a nossa família ou comunidade, aquilo que provavelmente mais ninguém registará, ou lembrará, e nessa situação será irremediavelmente perdido, com o passar do tempo! Para responder a esta necessidade, há o desejo duma ferramenta poderosa e versátil, além de agradável. Dadas as nossas pretensões, defendemos caminhar para a seguinte fórmula exploratória: Ancestors Note Book = Ontologia para Memorabilia e Genealogia, Relações humanas e Ambiente + Filosofia wiki + Inferência Lema: Preservar as preciosas memórias da família e comunidade, descobrir todo o tipo de relações. Ancestors Note Book 6 2. Estado da Arte Esta secção pretende abordar tópicos do estado da arte do domínio em questão: ontologias, genealogias e humanidades digitais. 2.1. Ontologias Definição de Ontologia Interessa-nos, no âmbito desta dissertação, endereçar o significado de ontologia no âmbito das ciências da computação. (Existe outro significado no domínio da filosofia.) No âmbito das ontologias relação é sinónimo de relacionamento; instância é sinónimo de indivíduo. Definições 1. “explicit specification of a conceptualization”, i.e., “uma especificação explícita de uma concetualização”, Gruber, 1993. 2. “formal specification of a shared conceptualization”, i.e., “especificação formal de uma concetualização compartilhada”, Borst, 1997. 3. “An ontology is a formal, explicit specification of a shared conceptualization”, Studer et al., 1998; i.e., a fusão de 1 e 2, “Uma ontologia é uma especificação explícita e formal de uma concetualização compartilhada”. 4. [AH2017]+: Ontologia: O = (C, H, I, R, P, A, O), onde:  C: conjunto de classes  H: conjunto de relações hierárquicas (taxonómicas) entre classes  I: conjunto de relações entre as classes e as suas instâncias  R: conjunto de relações não taxonómicas  P: conjunto de propriedades das classes da ontologia  A: conjunto de axiomas  O1: conjunto de instâncias das classes (i.e., o povoamento) 5. Definição informal provavelmente questionável: “Pega-se numa panela feita de classes, propriedades, relações e axiomas, junta-se instâncias (indivíduos) e talvez mais relações não taxonómicas, e mexe-se bem com um motor de inferência. Poderá ir ao forno numa aplicação web, preferencialmente com persistência sob SGBD orientado a grafos.” 1 Adicionado à definição AH2017. Ancestors Note Book 7 Objetivos Uma ontologia tem por objetivo a representação computacional de conhecimento de um modo mais simples (a um nível mais próximo do cérebro humano, por conceitos, relações, propriedades e axiomas), e sua inferência (reasoning), sendo usada em áreas como a inteligência artificial, web semântica, engenharia de software e arquitetura da informação. (Cf. https://pt.wikipedia.org/wiki/Ontologia_(ciência_da_computação), https://en.wikipedia.org/wiki/Ontology_(information_science), entre outras.) As relações não taxonómicas duma ontologia acrescentam semântica. As queries a uma ontologia estão facilitadas (cf. SPARQL). Cf. https://graphdb.ontotext.com/documentation/standard/introduction-to-semanticweb.html, para uma introdução interessante ao tema. Linguagens e Ferramentas Ontologias Linguagens Algumas linguagens usadas para descrever ontologias são XML, XML Schema, RDF, RDF Schema, OWL (1 e 2) e SKOS (Simple Knowledge Organization System). As linguagens para ontologia são geralmente declarativas. “The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. Ontologies are a formal way to describe taxonomies and classification networks, essentially defining the structure of knowledge for various domains: the nouns representing classes of objects and the verbs representing relations between the objects.” Origem: https://en.wikipedia.org/wiki/Web_Ontology_Language [03/01/2021] OWL 2 (Web Ontology Language, Manchester Syntax (Second Edition)) é das linguagens mais usadas. Reconhecem-se algumas limitações às ontologias, em termos de: property constructs; no modo como OWL emprega constraints (restrições)… cf. Anexo II. Dada a sua relevância neste domínio, achei por bem reproduzir, ainda no Anexo II, uma lição em Inglês, sobre OWL – cf. secção Lição sobre OWL. Editores de ontologias Protégé: Foi o editor usado neste projeto para desenhar a ontologia. A ferramenta Protégé permite manusear ontologias (criar, editar, importar, exportar) e possui um reasoner considerado muito completo, o HermiT, da Universidade de Oxford. O Protégé suporta OWL 2 e aparenta ser, atualmente, das ferramentas mais usadas e consensuais, a julgar pelas menções encontradas na web. Outros editores: WebODE, OntoEdit. Ancestors Note Book 8 Livrarias Para a fase de codificação, existem livrarias, em particular do universo da linguagem Python, que podem ajudar:  RDFLib (também disponibiliza SPARQL)  rdflib-web (para Flask)  Owlready2 DSL Uma DSL (domain-specific language), sendo tipicamente feita à medida de uma necessidade concreta, fornece uma sintaxe para reconhecer, e possivelmente agir, sobre um conjunto de informação e/ou comandos. Uma DSL tem a vantagem de fornecer um meio expedito de preparar, offline, informação e/ou comandos a processar posteriormente de modo automático. Numa aplicação aberta a todo o tipo de utilizadores, a sintaxe deve ser acessível, seja porque o utilizador tem facilidade em com ela lidar, seja por haver conversores disponíveis (entre um documento do utilizador e a sintaxe destino). Tem a vantagem, em particular, de facilitar o reaproveitamento de trabalho anterior. Existem atualmente técnicas relativamente ágeis para desenhar e testar DSL. Uma das ferramentas em contexto, bastante popular, é o ANTLR. Software e Projetos Relacionados É importante ter em conta que há projetos públicos, alguns abertos, cuja especificação e experiência acumulada se poderão aproveitar. No contexto genérico das ontologias, dá-se apenas estes exemplos:  The FOAF Project – http://www.foaf-project.org/  DBpedia – https://wiki.dbpedia.org/ “DBpedia (from "DB" for "database") is a project aiming to extract structured content from the information created in the Wikipedia project. This structured information is made available on the World Wide Web. DBpedia allows users to semantically query relationships and properties of Wikipedia resources, including links to other related datasets. In 2008, Tim Berners-Lee described DBpedia as one of the most famous parts of the decentralized Linked Data effort.”  LinkingOpenData – https://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData “The Open Data Movement aims at making data freely available to everyone. There are already various interesting open data sets available on the Web. Examples include Ancestors Note Book 9 Wikipedia, Wikibooks, Geonames, MusicBrainz, WordNet, the DBLP bibliography and many more which are published under Creative Commons or Talis licenses. The goal of the W3C SWEO Linking Open Data community project is to extend the Web with a data commons by publishing various open data sets as RDF on the Web and by setting RDF links between data items from different data sources. RDF links enable you to navigate from a data item within one data source to related data items within other sources using a Semantic Web browser. RDF links can also be followed by the crawlers of Semantic Web search engines, which may provide sophisticated search and query capabilities over crawled data. As query results are structured data and not just links to HTML pages, they can be used within other applications.” Projetos Open Source Também há projetos de código aberto muito interessantes no âmbito específico desta dissertação. Despertaram-me a atenção os seguintes. OntoWiki – Semantic Data Wiki and Linked Data Publishing Engine Endereço: http://ontowiki.net/ Este projeto mereceu especial atenção, por parecer promissor. http://docs.ontowiki.net/: “OntoWiki is a semantic application as well as a framework which acts as a hardened basement for your application in the Semantic Web context. One of its main purposes is to assist you managing your knowledge. Knowledge means here machine readable data organized as RDF/XML, Notation3, Turtle as well as Talis(JSON). You organize your knowledge using a feature-rich user interface managing classes, properties and resources.” Pontos a favor:  Open source.  Disponibiliza um navegador da ontologia.  Suporta vários formatos ontológicos, incluindo Turtle.  Suporta SPARQL 1.0.  Suporta SGBD como Vituoso ou MySQL, ou outro à escolha (backend independent).  Linked Data server: permite obter dados adicionais na web (“fetch additional data from the web”). No entanto, alguns elementos da sua arquitetura revelaram-se dificultadores:  Escrito em PHP 5.2 (que seria mais uma frente para desbravar), apesar de anunciar que permite extensões escritas noutras linguagens, como JavaScript.  Precisa do servidor Apache (ou nginx), algo pesado.  A instalação revelou-se difícil sobre Microsoft Windows… Gramps – Research, organize and share your family tree with Gramps Ancestors Note Book 10 Endereço: https://gramps-project.org/ “Gramps is a free software project and community. We strive to produce a genealogy program that is both intuitive for hobbyists and feature-complete for professional genealogists. It is a community project, created, developed and governed by genealogists.” Caraterísticas relevantes:  Open source.  Escrito em Python.  Aparência agradável.  Muito grande.  Ligação a SGBD SQLite ou BerkeleyDB, ou seja, desvia-se dum SGBD orientado a grafos, como pretendemos nesta dissertação.  Consta que dificulta a composição de livros. Zim – A Desktop Wiki Endereço: https://zim-wiki.org/ “Zim is a graphical text editor used to maintain a collection of wiki pages.” Eis um editor que poderá revelar-se interessante para o projeto, quanto mais não seja para descobrir padrões, a traduzir em requisitos do projeto. Conclusões Revelou-se difícil encontrar um projeto aberto já existente que fosse de feição a esta dissertação, i.e., que combinasse: ser escrito em Python ou JavaScript; BD orientada a grafos (com SPARQL); fácil instalação e modificação. 2.2. Genealogias Definição de Genealogia O que é a genealogia? Vejam-se algumas definições. Na Infopédia Origem: https://www.infopedia.pt/dicionarios/lingua-portuguesa/genealogia [15/11/2020]: genealogia nome feminino 1. HISTÓRIA ciência auxiliar da história que estuda a origem e a sucessão das famílias, descrevendo as relações de parentesco entre as gerações 2. obra ou documento onde se expõe cronologicamente a linha de gerações anteriores a um indivíduo, a uma família ou a um grupo Ancestors Note Book 17 Machine Learning É muito sensível ao contexto. Por ser uma área muito extensa, não foi aprofundada no contexto desta dissertação. Keyword spotting From Wikipedia, the free encyclopedia, 06/03/2021. “Keyword spotting (or more simply, word spotting) is a problem that was historically first defined in the context of speech processing. In speech processing, keyword spotting deals with the identification of keywords in utterances. Keyword spotting is also defined as a separate, but related, problem in the context of document image processing. In document image processing, keyword spotting is the problem of finding all instances of a query word that exist in a scanned document image, without fully recognizing it.” No trabalho em causa, estamos preocupados especialmente com inferência de indivíduos da ontologia a partir de nomes próprios e datas (ainda que possivelmente reduzidas ao ano), além de graus de parentesco. Racional: Numa história ou fotografia, aparecem, frequentemente, não os nomes completos, mas apenas os nomes próprios, eventualmente associados a um grau de parentesco. Para desambiguar, poderão ser essenciais o grau de parentesco, uma data ou ano, de nascimento ou dum evento. Ex.: “foto do tio Serafim tirada em …”. Isto realça o nosso interesse na genealogia para efeitos de inferência de ID (não tanto para descobrir linhagens). Ancestors Note Book 18 3. Levantamento e Análise de Requisitos O domínio em causa parece conduzir-nos naturalmente a uma ontologia rica. Como se pode derivar dos objetivos do projeto (cf. secção respetiva no capítulo 1), este não pretende focar-se principalmente na genealogia numa perspetiva de linhagens, nem concorrer com outras dissertações desse âmbito, nem tão pouco com aplicações comerciais já no mercado e que levam bastante vantagem. A genealogia servirá, sim, de suporte à inferência, na identificação de pessoas (além de lugares, eventos, etc.) em fotografias e histórias (de família e outras). Vem-me frequentemente à memória diálogos entre os meus pais, em que, referenciando um deles certo relacionamento pessoal pelo nome próprio (e mesmo com apelidos e alcunhas), o outro não identifica a pessoa até se explicitar que era, por exemplo, irmã/irmão, filha/o, prima/o de alguém, ou seja, até chegar a um relacionamento seu conhecido. Daqui se intui que a parte genealógica referente a graus de parentesco poderá ser determinante. 3.1. Do levantamento de requisitos A recolha de requisitos partiu dos objetivos do projeto. Ocorreu alguma recolha de impressões de outras aplicações, de brainstorming, especialmente com o orientador da tese, e de introspeção (também partilhada com o orientador). Não foram realizados inquéritos públicos. É claro que pode ter-se chegado, enfim, a um conjunto de requisitos algo subjetivo, mas por outro lado pareceu-me tratar-se de um tema sobre o qual o orientador, Prof. José João Almeida, já leva anos de reflexão e experiência. Deste modo, encontrei no orientador um “cliente” informado e esclarecido sobre o que lhe poderia interessar pessoalmente, o que é mais do que se pode dizer de muitas entrevistas a potenciais clientes, a menos que já trabalhem intensivamente com alguma aplicação… Ao fim de cerca de trinta anos de experiência a trabalhar em engenharia de software, constato que só depois de começarem a trabalhar com a aplicação é que os utilizadores conseguem fazer chegar pedidos de melhoria… Não considero, portanto, que tenha havido necessariamente uma grande perda por falta de diversidade de opinião, até porque muitos requisitos estão ainda por implementar. Ainda assim, deve sempre ter-se a humildade de ouvir opiniões e desejos, mesmo quando se adivinha que serão muito trabalhosos. 3.2. Lista de Entregáveis (Deliverables) ANB Ontology Ontologia, na perspetiva das humanidades digitais, sobre: Ancestors Note Book 19  Pessoas singulares e coletivas (organizações), e respetivos relacionamentos: o familiares (graus de parentesco); o sociais (ex.: “Fulano de Tal” conhece “Sicrano, Famoso Músico”); e o outros eventuais.  Locais de interesse.  Documentos de diversa natureza, a relacionar com indivíduos.  Eventos de diversa ordem: familiar, social e histórica. Cf. capítulo Arquitetura e Desenho da Ontologia. ANB Web App Aplicação web para gestão CRUD da ontologia, visualização gráfica, carregamento de informação. O carregamento de informação e inferência de nomes estão demarcados no entregável NameTK. ANB DSL Módulo para carregar informação na ontologia, seja de indivíduos ou para enriquecerlhe a estrutura (cf. capítulo 5). O carregamento deve estar disponível a partir de ficheiro, numa sintaxe a definir, ou via copy-paste. ANB NameTK “Name ToolKit”: Módulo de pesquisa de nomes, com inferência de indivíduos da ontologia: inferência e desambiguação de identificadores de instâncias da classe Pessoa, ou Org, guiado por nomes, datas e relacionamentos. 3.3. Técnica de Priorização Por se considerar um padrão intuitivo, optou-se pela priorização de requisitos segundo a técnica MoSCoW: ● Must – Tem de ter (requisitos que têm de ser considerados); ● Should – Deveria ter (requisitos que deveriam ser considerados); ● Could – Poderia ter (requisitos desejáveis, mas não necessários); ● Would/Won’t – Interessante ter (requisitos que poderão, ou não, ser considerados, no futuro). A etiquetagem foi feita intuitivamente, dando prioridade aos requisitos essenciais para CRUD, simplisticamente falando. Ancestors Note Book 20 3.4. Requisitos Funcionais ou de Dados (Nota: Confrontar informação de apoio no anexo Técnicas de Levantamento de Requisitos.) Para apresentação dos requisitos optou-se pelo cartão Volere (descrito nos anexos). A numeração dos requisitos funcionais será um numeral sequencial com prefixo RF. O item Description do cartão é inscrito no título de cada secção respetiva. Esta opção destina-se a plasmar os requisitos no índice, para facilitar a identificação neste documento. RF1: O sistema deve permitir CRUD de indivíduos da ontologia Requirement #: RF1 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para se poder povoar e gerir a ontologia por via da aplicação. Originator: Brainstorming; padrão Fit Criterion: Como sugestão, em cada área de interação disponibilizada para cada classe da ontologia, o utilizador poderá chamar um formulário para poder acionar CRUD, contexto em que Update e Create permitirão editar. Poderão existir outras formas de realizar estas tarefas – cf. RF6. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado (interativamente e via SPARQL). RF2: O sistema deve permitir visualizar listas de dados da ontologia Requirement #: RF2 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para conhecer coleções de dados relacionados e permitir a consequente navegação pela ontologia. Originator: Introspeção; padrão Fit Criterion: Nos contextos elegíveis, será mostrada a informação na forma de tabela, com hiperligações para a origem dos itens listados. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. RF3: O sistema deve permitir visualizar os dados de cada instância da ontologia Requirement #: RF3 Requirement Type: Funcional Event/BUC/PUC #: Ancestors Note Book 21 Rationale: Poder conhecer, de maneira integrada, os dados duma instância e suas relações. Originator: Introspeção; padrão Fit Criterion: Nos contextos elegíveis, será apresentada a informação na forma duma página web, com toda a informação relevante duma instância, com hiperligações para informação associada. Cada classe poderá ter uma página desenhada à medida das suas necessidades. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. RF4: O sistema deve permitir visualizar a genealogia duma pessoa Requirement #: RF4 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para conhecer, de maneira mais abrangente, os relacionamentos familiares duma pessoa, sem descurar outros relacionamentos pessoais. Originator: Brainstorming; padrão Fit Criterion: Nos contextos elegíveis, será mostrada a informação na forma duma página web, com os relacionamentos familiares, e outros pessoais, duma instância, com hiperligações para permitir navegar. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado no âmbito do RF3. RF5: O sistema deve permitir navegar pelos relacionamentos entre indivíduos Requirement #: RF5 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para conhecer, de maneira mais abrangente, a informação específica das instâncias e seus relacionamentos. Originator: Brainstorming; padrão hipertexto/web Fit Criterion: Nos contextos elegíveis, existirão hiperligações para navegar, pelos relacionamentos, para as páginas específicas das instâncias, senão para navegar pela informação em forma de tabela. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. Ancestors Note Book 22 RF6: O sistema deve disponibilizar interface SPARQL para CRUD Requirement #: RF6 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Recorrer ao padrão SPARQL para dispor duma ferramenta versátil, ainda que especializada, de gestão da ontologia. Originator: Introspeção Fit Criterion: Deverá existir uma página onde se possa introduzir e executar queries SPARQL, obtendo os resultados em forma tabular ou de debug, conforme opção do utilizador. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: RNF1, RNF2 Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. RF7: O sistema deve permitir carregar dados via ficheiro de texto conforme DSL Requirement #: RF7 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Permitir recolha e preparação offline de informação a carregar. Permitir carregar informação com menos interação. Permitir reaproveitar edições de anteriores de ficheiros, que poderão ser facilmente adaptados, evitando trabalho e poupando tempo. Originator: Brainstorming; padrão Fit Criterion: Nos contextos elegíveis, será disponibilizada uma opção para indicar um ficheiro de texto, conforme com uma especificação DSL, para carregar informação na ontologia. O fluxo poderá passar por uma área tampão, onde o utilizador terá de confirmar a operação de inserção e atualização de informação. Na ocorrência de erros, será desejável obter um log de mensagens. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Especificação DSL Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado sobre a sintaxe Turtle. RF8: O sistema deve permitir a definição interativa de hiperligações a indivíduos da ontologia Requirement #: RF8 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para permitir, orientado ao contexto, enriquecer a ontologia com hiperligações ou relacionamentos. Originator: Brainstorming Fit Criterion: Em textos de resumo, descrição, transcrição, deverá ser possível selecionar palavras inferir e a estabelecer hiperligações a instâncias. Esta tarefa deverá ser assistida Ancestors Note Book 23 pela aplicação, dando a escolher as instâncias mais prováveis. O utilizador marca o texto a analisar e usará algum controlo para pedir uma marcação que será disponibilizada como hiperligação ao utilizador. Customer Satisfaction: Customer Dissatisfaction: Priority: Should Dependencies: NameTK Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado – cf. inferência interativa/dinâmica e âncoras html. RF9: O sistema deve permitir adicionar estrutura à ontologia Requirement #: RF9 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Para permitir enriquecer a ontologia com classes e relações necessárias. Originator: Brainstorming Fit Criterion: Deverá existir um modo de introduzir/modificar triplos no contexto de estrutura de ontologia, como classes, atributos e relacionamentos. Customer Satisfaction: Customer Dissatisfaction: Priority: Should Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado – cf. áreas DSL e SPARQL. 3.5. Requisitos Não Funcionais A numeração dos requisitos não funcionais será um numeral sequencial com prefixo RNF. Aparência (O essencial da aparência da aplicação.) Seguem-se sugestões. Poderá tentar seguir-se, de um modo geral, o estado da arte da aparência de aplicações web. Genealogia A página de genealogia duma pessoa poderá ser organizada como na figura seguinte, preferencialmente com fotografias, nome abreviado e período de vida (nascimento e idade, ou então nascimento, óbito e idade à data de falecimento). Poderão ser selecionadas apenas partes desta interface – cf. o padrão Pedigree Chart. Dada a quantidade de informação, poderá ser útil haver controlos que esperem pelo clique do utilizador antes de desdobrar mais informação. Poder-se-á ainda considerar o seguinte padrão de display, com sete linhas: Ancestors Note Book 24 1. Pessoa de referência (seja i) 2. Pai 3. Mãe 4. Avô paterno 5. Avó paterna 6. Avô materno 7. Avó materna Em que linha (i*2) =>pai de i, linha (i*2 + 1) => mãe de i (numeração de Sosa-Stradonitz). Figura 3 – Pessoa: sugestão de apresentação em árvore Exemplo de informação acompanhada de fotos: Ancestors Note Book 25 Pessoa A página de informação duma pessoa poderá ser assim: Nome Completo Foto e outros dados pessoais… Relacionamentos familiares Genealogia (hiperligação para a página de genealogia, cf. secção anterior) Listagem de relacionamentos (listagem de hiperligações) Relacionamentos pessoais (listagem de hiperligações) Cronologia (de eventos com que a pessoa está associada por relacionamentos ontológicos) Completa (todos os eventos associados) Familiar (eventos de tipo familiar) Curricular (eventos de tipo curricular) Histórica (eventos de tipo histórico) Outros relacionamentos (listagem de hiperligações de relacionamentos não contidos nas opções acima) Usabilidade (Facilidade de utilização e outras considerações de usabilidade.) RNF1: O sistema deve apresentar os dados em formato simplificado Requirement #: RNF1 Requirement Type: Usabilidade Event/BUC/PUC #: Rationale: Numa utilização regular, a facilidade de visualização confere facilidade e eficácia de utilização, melhorando essa experiência. O “ruído visual” dos IRI completos introduzirá complexidade desnecessária e poderá desmotivar o utilizador. Originator: Brainstorming Fit Criterion: Os IRI serão apresentados limpos de prefixos ontológicos. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. Ancestors Note Book 26 RNF2: O sistema deve permitir visualizar os dados em formato de debug Requirement #: RNF2 Requirement Type: Usabilidade Event/BUC/PUC #: Rationale: Para inspeção rigorosa aos dados. Originator: Introspeção Fit Criterion: Os IRI serão apresentados completos, incluindo prefixos ontológicos. Serão mostrados todos os dados retornados por pedidos ao SGBD. Customer Satisfaction: Customer Dissatisfaction: Priority: Must Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Implementado. RNF4: O sistema deve permitir interação pela linha de comandos Requirement #: RNF4 Requirement Type: Usabilidade Event/BUC/PUC #: Rationale: Para permitir flexibilidade de utilização. Originator: Brainstorming Fit Criterion: Deverá existir uma interface para comunicar com o sistema via linha de comandos do sistema operativo. Customer Satisfaction: 4 Customer Dissatisfaction: 3 Priority: Should Dependencies: Conflicts: Supporting Materials: History: Criado em jan/2021. Desempenho (Quão rápida, quão extensa, quão precisa uma funcionalidade tem de ser.) Operacionais (Ambiente de operação do produto, físico ou não, e considerações sobre esse ambiente.) RNF3: O sistema deve ter a arquitetura duma aplicação web Requirement #: RNF3 Requirement Type: Operacional Event/BUC/PUC #: Rationale: Obter um padrão state of the art em termos de usabilidade, aparência, disponibilidade, ferramentas de suporte ao desenvolvimento, entre outros. O sistema poderá ser instalado num servidor. Originator: Brainstorming, padrão corrente. Fit Criterion: A aplicação ficará disponível via navegador web. Será desenvolvida com Ancestors Note Book 33 Nota: Quanto mais rica for a informação acerca de uma pessoa, mais facilmente poderá ser identificada em textos, fotos e outros média.  Profissão: Profissão de uma pessoa. Destacados II:  conhece: Inspirado em foaf:knows, relaciona indivíduos que se conheçam. O significado é amplo, mas implica alguma reciprocidade na relação.  temCasa: Casa de residência, passada ou presente, duma pessoa.  temCasaNasc: Casa onde nasceu uma pessoa.  temLocalNasc: Local de nascimento de uma pessoa.  tipoEvento: Tipo de evento, com o objetivo de separar cronologias por esta tipificação.  tipoDoc: Enumeração “áudio”, “artigo”, “carta”, “certidão”, “imagem”, “vídeo”, “outro”.  tipoLocal: “edifício”, "arruamento", "lugar", "freguesia", “região”, "país" – conjunto a definir.  temProfissão: Relaciona uma pessoa com a sua profissão. Anos e datas:  ano: Ano de referência por excelência. Alternativo a data, quando não se souber. Formato: Ano 'aaaa', em que 'a' são dígitos 0-9 e indicam o ano. Exemplos: '2021', '2000'.  anoFinal: Ano em que termina dado evento ou período, ou ano do óbito, ano de demolição, etc. Alternativo ao termo dataFinal.  data: Data de referência por excelência, num indivíduo. Pode ser uma data de início, como fundação, ou construção, a complementar, eventualmente, com dataFinal. Para pessoas, ver dataNasc (e eventualmente dataÓbito). Formato: ISO 'aaaa-mm-dd', em que 'a' são dígitos 0-9 e indicam o ano; 'm' dígitos do mês, 'd' dígitos do dia. Exemplo: "2021-01-31". Como alternativa, ver os atributos ano e anoFinal.  dataFinal: Data ISO, de fim de dado evento ou período, ou data de demolição de um imóvel. Para pessoas, ver dataÓbito. Como alternativa, usar anoFinal. Datas especializadas:  dataBatismo: Data de batismo religioso (cristão) de uma pessoa.  dataCasamento: Data de casamento de duas pessoas.  dataNasc: Data de nascimento de uma pessoa.  dataÓbito: Data de falecimento de uma pessoa. Endereço postal, pela ordem lógica:  arruamento: Designação de um arruamento – nome de rua, avenida, etc., sem números de porta nem andar. Pode conter abreviaturas e numerais. Exemplos: "Avenida da Liberdade"; "Rua Dom Pedro V", “Rua do Regimento de Infantaria 8 Ancestors Note Book 34 Braga”.  numPorta: Número de porta (nº de polícia) dum endereço. Pode conter letras.  andar: Andar de um endereço. Pode conter abreviaturas e letras. Exemplos: “r/c”, “R/C”, “Rés-do-chão”, “1º”, “1º andar”, “1ºB”, “1º Esqº“, “1º Esquerdo“, etc.  localidade: nome duma localidade.  códigoPostal: Código postal propriamente dito, sem designação da localidade.  morada (alternativo aos anteriores): Um endereço postal, ou pelo menos uma localização. Exemplo: Rua Dom Pedro V, 99, 8º Esquerdo Traseiras – São Victor – 4710-374 BRAGA. Poderá também indicar o país.  país: Nome de um país. Nomes e âmbito pessoal:  alcunha: Alcunha de uma pessoa. Uma pessoa pode ter várias alcunhas.  apelidoMaterno: Apelido(s) herdado(s) da mãe.  apelidoPaterno: Apelido(s) herdado(s) do pai.  cônjuge: Nome completo do cônjuge de uma pessoa.  designação: Designação de um item, humanamente inteligível, descrição curta, mas relevante.  nome: Nome de pessoa, preferencialmente completo.  nomeAlternativo: Nome duma pessoa, alternativo ao de registo, ou como variante do nome completo, que ocorre com frequência. Pode haver vários... Não confundir com alcunha.  nomeComGralhas: Nome de pessoa, gralhado, que é comum ou expectável.  nomeMãe: Nome da mãe.  nomePai: Nome do pai. Texto, média, anotação:  html: Conteúdo html para apresentação numa secção a isso destinada.  imagem: Nome ou caminho de um ficheiro de imagem no sistema de ficheiros. o versoImg: Nome ou caminho de um ficheiro de imagem no sistema de ficheiros, tipicamente contendo o verso de uma imagem.  json: Dados em formato JSON, provavelmente uma lista.  nota: Anotação textual específica.  obs: Observações livres. Tipicamente, serão para consumo interno e preferencialmente não impressas.  path: Caminho no sistema de ficheiros. Eventualmente, para um ficheiro que guarda uma digitalização.  resumo: Resumo de um conteúdo ou perfil de um indivíduo, i.e., uma descrição mais pormenorizada do que um mero título, mas dificilmente uma transcrição.  sexo: Género sexual de uma pessoa. "M" ou "F".  títuloDignitário: Título atribuído à pessoa. Denominação honorífica. Designação ou qualificação de uma relação social, de uma função, de uma dignidade. Ex.: “Engenheiro”, “Dr.”, “Doutor”. Ancestors Note Book 35  transcrição: Transcrição, supostamente integral, de um documento.  url: Endereço web por excelência sobre determinado assunto. 4. Definir classes e hierarquia de classes (Definir classes e hierarquia de classes – onde, a partir da lista de termos, se eliminam redundâncias e se definem as classes da ontologia (organizadas em hierarquia).) As classes são: Animal, Casa, Compilação, Doc, Evento, Local, Org, Pessoa. Nota sobre a classe Casa: eventualmente, poderia ser uma subclasse de Local, depois de bem definida esta; no entanto, remete-se para as precauções da Arquitetura de Software, que defende que a criação de subclasses aumenta sempre a complexidade das soluções (e consequente manutenção), sendo preferível começar com duas classes de algum modo relacionadas, em vez de estabelecer à partida uma herança que é “para sempre”.) Durante o desenvolvimento do projeto, novas classes e hierarquias foram surgindo, donde se destaca a seguinte hierarquia (subclasses apresentadas sob indentação): Doc Carta (Transcrição e anotação de correspondência.) HistóriaDeFamília (História de família.) HistóriaDeInfância (Histórias de infância, por exemplo sobre crianças e jovens.) Img (Imagens, com desejável descrição. Podem corresponder a fotografias com existência em papel.) Org CasaDeFotografia (Casa de fotografia. Autor ou detentor de direitos enquanto pessoa coletiva. Para autores individuais, usar Pessoa.) 5. Definir propriedades das classes (Definir propriedades das classes, i.e., atributos e relações, específicos das classes.) Nota: Atributos (data properties) e relações (object properties) não mencionados terão domínio e/ou contradomínio aberto (i.e., não especificado, extrínseco). Ancestors Note Book 36 Figura 5 – Vislumbre da hierarquia de relações do ANB Animal Atributos: designação, dataNasc, dataÓbito, ano, anoFinal, imagem, resumo, obs, etc. Relações: conheceAnimal. Casa Atributos: designação, data, dataFinal, ano, anoFinal, imagem, resumo, obs, etc. Relações: temCasa, temCasaNasc. CasaDeFotografia Atributos: designação, data, dataFinal, ano, anoFinal, imagem, resumo, obs, etc. Relações: éCasaDeFotografiaDe, temCasaDeFotografia. Ancestors Note Book 37 Compilação Atributos: designação, data, ano, imagem, resumo, obs, etc. Relações: n/a. Doc Atributos: numClichê, tipoDoc, designação, data, dataFinal, ano, anoFinal, imagem, resumo, obs, etc. Relações: éAutorDe, refere, temBiografia, temReferênciaEm, temDoc. Evento Atributos: tipoEvento, designação, data, dataFinal, ano, anoFinal, imagem, resumo, obs, etc. Relações: temEvento Local Atributos: tipoLocal, designação, data ou ano, imagem, localidade, resumo, obs, etc. Relações: temLocalização, conheceLocal, temLocalNasc. Exemplo:  ID: “cp_P_4700”  códigoPostal: “P-4700”  designação: “Braga, Portugal”  localidade: “Braga, centro da cidade” Org Organização Atributos: marca, volumeDeNegócios, url, designação, data ou ano, imagem, resumo, obs, etc. Relações: conheceOrg. Pessoa Atributos: alcunha, apelidoMaterno, apelidoPaterno, biografia, dataBatismo, dataCasamento, dataNasc, dataÓbito, imagem, localNasc, morada, nome, nomeAlternativo, nomeComGralhas, nomeCônjuge, nomeMãe, nomePai, obs, sexo, títuloDignitário, etc. Relações3: 3 São pelo menos 127 relações com domínio e/ou contradomínio em Pessoa, daí indicar-se apenas algumas mais Ancestors Note Book 38  temAvó, temAvô, temCônjuge, temEsposa, temEsposo, …, temFilha, temFilho, …, temIrmã, temIrmão, …, éAvóDe, éAvôDe, …, éTioOuTiaDe;  oMesmoQue, …, temBiografia, …, temProfissão, temReferênciaEm, …, éPadrinhoOuMadrinhaDe. Dos atributos extrínsecos, sugere-se genericamente o uso de data, dataFinal, imagem, obs, resumo, transcrição, url, entre outros. 6. Definir restrições (Definir restrições, como tipos de dados dos atributos, domínio e contradomínio de relações e outras restrições. O domínio, ou contradomínio, deve ser aberto/extrínseco ou associado a apenas uma classe – cf. secção Do domínio e contradomínio.) Legenda: [A]  [B] => A é o domínio (opcional) e B o contradomínio (opcional). Atributos  alcunha: Pessoa  xsd:string.  apelidoMaterno: Pessoa  xsd:string.  apelidoPaterno: Pessoa  xsd:string.  biografia: Pessoa  xsd:string.  data<…>:  xsd:date. “aaaa” => ano; “aaaa-mm-dd” => data de calendário  dataBatismo: Pessoa  xsd:date.  dataCasamento: Pessoa  xsd:date.  dataNasc:  xsd:date. A usar em Pessoa e Animal.  dataÓbito: Pessoa U Animal  xsd:date.  imagem:  xsd:string.  json:  xsd:string, em formato JSON.  localNasc: Pessoa  xsd:string.  marca: Org  xsd:string.  nome:  xsd:string.  nomeCônjuge: Pessoa  xsd:string.  nomeMãe: Pessoa  xsd:string.  nomePai: Pessoa  xsd:string.  obs:  xsd:string.  sexo:  xsd:string. “M” (masculino) ou “F” (feminino).  tipoDoc:  xsd:string. “áudio” | “artigo” | “carta” | “certidão” | “imagem” | “vídeo” | “outro”.  tipoEvento: Evento  xsd:string. Valores permitidos: o "F" (evento de âmbito familiar) – exemplo: casamento, divórcio; o "C" (evento de âmbito curricular) – exemplo: graduação académica, serviço exemplificativas. Ancestors Note Book 39 militar; o "H" (evento de âmbito histórico) – exemplo: “25 de abril”.  tipoLocal:  xsd:string. "arruamento" | "lugar" | "freguesia" | "país" | … conjunto a definir.  títuloDignitário: Pessoa  xsd:string.  volumeDeNegócios: rdf:type owl:FunctionalProperty; Org  xsd:decimal. Relações sem parentesco  conhece: Pessoa  Pessoa; Symmetric; Irreflexive  conheceAnimal: Pessoa  Animal  conheceLocal: Pessoa Local  conheceOrg: Pessoa  Org  oMesmoQue:  ; Irreflexive  refere: Doc  Pessoa; inversa: temReferênciaEm  temAutor:  Pessoa; inversa: éAutorDe  temBiografia: Pessoa  Doc; inversa: éBiografiaDe  temCasa:  Casa  temCasaDeFotografia: Img CasaDeFotografia; inversa: éCasaDeFotografiaDe  temCasaNasc: Pessoa  Casa  temDoc:  Doc; inversa: éDocDe  temEvento:  Evento  temInteresseEm:  ; Irreflexive  temLocalização:  Local  temLocalNasc: Pessoa  Local  temPadrinhoOuMadriCasamento; inversa: éPadrinhoOuMadriCasamentoDe o temMadrinhaDeCasamento o temPadrinhoDeCasamento  temPadrinhoOuMadrinha; inversa: éPadrinhoOuMadrinhaDe o temMadrinha o temPadrinho  temProfissão: Pessoa  Profissão  temReferênciaEm: Pessoa  Doc; inversa: refere Relações de parentesco (Apenas um excerto, remete-se mais uma vez para a ontologia:) Acima das relações associadas a parentescos foi definida temParentesco, que alberga todo o tipo de relações de parentesco familiar entre pessoas, de sangue ou por afinidade. Não abriga relacionamentos como padrinho ou madrinha, de batismo ou casamento, estes definidos em paralelo. Os relacionamentos foram divididos por sexo, e agrupados sob um outro, que não Ancestors Note Book 40 distingue o sexo4. Como expectável, o domínio e contradomínio são herdados pelas subpropriedades, já as caraterísticas5 não. temParentesco: Pessoa  Pessoa; Symmetric, Irreflexive  temAvôOuAvó: Asymmetric, Irreflexive; inversa: éAvôOuAvóDe o temAvó: Asymmetric, Irreflexive; inversa: éAvóDe o temAvô: Asymmetric, Irreflexive; inversa: éAvôDe  temCunhadoOuCunhada: Symmetric, Irreflexive; inversa: éCunhadoOuCunhadaDe o temCunhada: Asymmetric, Irreflexive; inversa: éCunhadaDe o temCunhado: Asymmetric, Irreflexive; inversa: éCunhadoDe  temCônjuge: Symmetric, Irreflexive o temEsposa: Asymmetric, Irreflexive; inversa: éEsposaDe o temEsposo: Asymmetric, Irreflexive; inversa: éEsposoDe  temIrmãoOuIrmã: Symmetric, Irreflexive, Transitive; inversa: éIrmãoOuIrmãDe o temIrmã: Asymmetric, Irreflexive, Transitive; inversa: éIrmãDe o temIrmão: Asymmetric, Irreflexive, Transitive; inversa: éIrmãoDe  temProgenitor: Asymmetric, Irreflexive; inversa: éProgenitorDe o temMãe: Asymmetric, Functional, Irreflexive; inversa: éMãeDe o temPai: Asymmetric, Functional, Irreflexive; inversa: éPaiDe … Das caraterísticas das propriedades Caraterísticas, como Irreflexive, são importantes na definição duma relação. Neste projeto, não houve tempo para as validar no código, exceto no que diz respeito a Functional, como descrito na secção owl:FunctionalProperty. Por experiência própria, refira-se que certas caraterísticas, isoladas ou combinadas, poderão levar o reasoner a falhar, pelo que poderá ser preferencial evitar defini-las na ontologia e estabelecer validações à medida nas aplicações… Do domínio e contradomínio Em relação a rdfs:range e rdfs:domain, sejam referentes a atributos ou relacionamentos, deve realçar-se que as classes, por essa via associadas, não passam a ser donas do termo. Isto deduz-se do seguinte: 4 Exemplo: temAvôOuAvó. A nomenclatura com “Ou” acaba por facilitar, em geral, a deteção e processamento de graus de parentesco, uma vez que não se perde a designação dos graus de parentesco por baixo, ainda que se tenha seguido um caminho diferente com temCônjuge e temProgenitor. 5 property characteristics, no Inglês, que no OWL são mais concretamente escritas como owl:AsymmetricProperty, owl:FunctionalProperty, owl:InverseFunctionalProperty, owl:IrreflexiveProperty, owl:ReflexiveProperty, owl:SymmetricProperty, owl:TransitiveProperty. Ancestors Note Book 41 Do RDF Schema 1.16 retiramos, resumidamente, que:  «3.1 (…) rdfs:range is an instance of rdf:Property that is used to state that the values of a property are instances of one or more classes.»  «3.2 (…) rdfs:domain is an instance of rdf:Property that is used to state that any resource that has a given property is an instance of one or more classes.» Da documentação do Protégé, em relação às mesmas propriedades, vem que:  Domains (Intersection) - The selected property has each class expression listed in this section in its domain. If a given property has a given class in its domain this means that any individual that has a value for the property (i.e. is the subject of a relation along the property), will be inferred to be an instance of that domain class. For example, if John hasParent Mary and Person is listed in the domain of hasParent, then John will be inferred to be an instance of Person. Note that domain does not mean that, “the class Person has hasParent as a property”.  Ranges (Intersection) - The selected property has each class expression listed in this section in its range. If a given property has a given class in its range this means that any individual that is the value for the property (i.e. is the object of a relation along the property), will be inferred to be an instance of that range class. For example, if John hasParent Mary and Person is listed in the range of hasParent, then Mary will be inferred to be an instance of Person. Note that range does not mean that, “the class Person is a value for the hasParent property”. Posto isto, faça-se o seguinte teste no Protégé (exemplo na sintaxe Turtle): :temDoc a owl:ObjectProperty ; rdfs:domain :Doc , :Pessoa ; rdfs:range :Doc . :doc__001 a :Doc , owl:NamedIndividual . :pedro a :Pessoa , owl:NamedIndividual ; :temDoc :doc__001 .  inferência (:pedro a :Pessoa , :Doc .) – ao correr o reasoner HermiT (1.3.8.413). Ou seja, o reasoner infere, devido ao triplo (:pedro :temDoc :doc__001.), que pedro é também uma instância da classe Doc, devido a temDoc incluir o domínio Doc. E não adianta estabelecer (:Doc owl:disjointWith :Pessoa .): o reasoner declara que a ontologia está inconsistente. Assim, pareceu-me preferível que, se for necessário ter atributos ou relacionamentos associados a uma classe, seja com domínio ou contradomínio, então que sejam exclusivos dessa classe, ou seja, tenham no máximo uma classe em rdfs:domain ou rdfs:range. Por esta razão, de modo a evitar a complexidade decorrente da proliferação de atributos, dependentes da classe, com pequenas variantes no nome, optei 6 cf. https://www.w3.org/TR/rdf-schema#ch_range e https://www.w3.org/TR/rdf-schema#ch_domain Ancestors Note Book 42 por deixar diversos Domain e/ou Range em aberto, na ontologia final. 7. Criar indivíduos (instâncias) (Criar indivíduos (instâncias das classes).) Os indivíduos serão inseridos por via da aplicação, seja interativamente ou em lote, via opção DSL (e possivelmente outras, em acomodação a padrões como GEDCOM). Nesta secção, limito-me a dar exemplos de indivíduos da classe Pessoa:  ID: João_M_P_M_Grenhas_d1968; alternativas a analisar para ID: o nome inteiro: João_Manuel_Pós_Mina_Grenhas_d1968; o sem data de nascimento: João_M_P_M_Grenhas_d0000; o 1º, 2º e último nome inteiros: Joao_Manuel_P_M_Grenhas_d1968; nome “João Manuel Pós de Mina Grenhas”; sexo “M”; dataNasc “1968-01-19”; apelidoPaterno “Grenhas”; apelidoMaterno “Pós de Mina”; nomeAlternativo “João Manuel Pós-de-Mina Grenhas” (com hífens), “João Manuel Grenhas” (nome incompleto); outros nomes “alternativos” poderão ser omitidos por serem uma função: o calculados do nome completo, compondo primeiro e último vocábulo, ou dois primeiros e último: “João Grenhas”, “João Manuel Grenhas”; o com iniciais (com ou sem ponto, separadas ou não por espaço): “JGrenhas”, “JMGrenhas”, “J G”, “JG”, “J.G.”, “J M G”, etc.; nomeComGralhas “Pós-de-Minas” (donde se deriva “Pós-Minas”), “Pós Minas”; “Granhas”, “Grelhas”, “Grainhas”; outras gralhas poderão ser omitidas por serem uma função que acrescente ou retire o plural, ou troque masculino com feminino: Grenhas => Grenha, Grenho, Grenhos; Granhas => Granha, Granho, Granhos.  ID: jose_joao_antunes_guimaraes_dias_almeida_d0000; nome “José João Antunes Guimarães Dias Almeida”; alcunha “JJ”; apelidoMaterno “Antunes Guimarães”; apelidoPaterno “Dias Almeida”. Ancestors Note Book 49  myLists – Módulo auxiliar sobre listas.  myMdFormat – Formatação de texto markdown para apresentação HTML.  myStrings – Biblioteca sobre strings. LibOnto/ – módulos próprios de livraria, de ontologia, sobre RDFLib:  myIdFormat – Módulo de formatação de ID de ontologia e URI.  myRdflib_Engine – Motor sobre o módulo rdflib para coleção de informação com tratamento para apresentação html.  myRdflib_Graph – Biblioteca de camada sobre rdflib.Graph e os seus metadados.  myRdflib_Plate – Biblioteca de camada sobre o módulo rdflib.  mySparql_Nav – Biblioteca para gerar SPARQL no contexto da navegação na aplicação.  mySparql_Plate – Biblioteca que usa ou retorna SPARQL para situações diversas.  mySparql_Regex – Funções que usam RegEx sobre queries SPARQL. rout_app/ – roteadores, i.e., módulos que dão resposta a pedidos REST:  dsl – Tratamento das rotas associadas a /dsl.  sparql – Tratamento das rotas associadas a /sparqlExe.  searchEng – Tratamento das rotas associadas aos motores de busca.  searchEng_rdflib – Satisfação de pedidos de rotas das procuras associadas aos motores de busca, na situação de satisfação via módulo rdflib.  searchEng_SPARQL – Satisfação de pedidos de rotas das procuras associadas aos motores de busca, na situação de satisfação via SPARQL.  utils – Tratamento das rotas associadas a /utils.  indivTp – Tratamento das rotas associadas ao template genérico para prettyprint de indivíduos.  indivTpIn – Ingestão interativa de dados de indivíduos (inserção, alteração, ...). Roteador da inferência interativa.  pessoa_criar – Criação de indivíduos da classe Pessoa. Criação automática de relações de parentesco.  resourceShow – Router para fornecer e apresentar ficheiros privados.  upload – Tratamento das rotas associadas a uploads.  docTp – Router associado ao modelo da ontoclasse Doc.  eventoTp – Router associado ao modelo da ontoclasse Evento.  localTp – Router associado ao modelo da ontoclasse Local.  oclasseTp – Tratamento das rotas associadas a prettyprint de indivíduos owl:Class.  ontoTp – Tratamento das rotas associadas à apresentação da estrutura da ontologia.  orgTp – Router associado ao modelo da ontoclasse Org.  pessoaTp – Router associado ao modelo da ontoclasse Pessoa. Ancestors Note Book 50  sparqlQTp – Router associado ao modelo da ontoclasse SparqlQuery. downloadsFolder/ – pasta de ficheiros temporários de download. uploadsFolder/ – pasta de ficheiros temporários de upload. Persistência ANB.ttl – ficheiro de persistência da ontologia, na sintaxe Turtle. (O nome é configurável em env.py.) ontoResources/ – ficheiros (imagens, documentos, etc.) carregados pela aplicação, tipicamente referenciados pelo grafo, e organizados nas seguintes pastas em função da extensão do ficheiro:  Aud/ – áudio: mid, midi, mp3, wav.  Docs/ – ficheiros não enquadrados nas restantes pastas, nomeadamente txt, md.  Imgs/ – ficheiros de imagens: gif, jpg, jpeg, png.  PDF/ – ficheiros pdf.  Vid/ – ficheiros de vídeo: mp4, ogg, webm. Diagramas UML Apresentação Os módulos de apresentação organizam-se conforme o seguinte diagrama de classes UML. Já quanto às restantes camadas, a sintaxe do Python facilita bastante conhecer todas as dependências, plasmadas no cabeçalho de cada módulo. Ancestors Note Book 51 6. Resultados e Discussão Este capítulo apresenta, por secção, alguns resultados que se destacaram, ao mesmo tempo que procura elaborar a sua análise crítica. Da execução do projeto resultou, globalmente, a ontologia AncestorsNB (i.e., ANB, i.e., Ancestors Note Book) e uma aplicação web, homónima, que carrega e permite gerir a referida ontologia, segundo a arquitetura descrita no capítulo respetivo. 6.1. Como iniciar Sem pretender ser um manual de utilização, esta secção surge da necessidade de abordar tópicos básicos de utilização da aplicação (por relevarem opções filosóficas e padrões), sem prejuízo da consulta à opção Ajuda, na aplicação, aliás transcrita no Anexo VI. A aplicação espera encontrar, na raiz da pasta de instalação, o ficheiro de ontologia, ANB.ttl, na sintaxe Turtle. O nome é configurável em env.py, logo no início, e depois seguemse diversas configurações de ambiente. As áreas Procurar e SPARQL permitem pesquisas diversas. SPARQL permite todo o tipo de questões SPARQL, sejam query ou update – questões malformadas resultarão numa pyparsing.ParseException. Realça-se a apresentação dos resultados, de pesquisas e navegação SPARQL, sob a forma de tabelas com hiperligações, onde elegível, que usam sistematicamente rotas da aplicação para navegar dentro da mesma área de interface, produzindo SPARQL, mais ou menos silenciosamente, para obter os dados. Além de proporcionar a facilidade de navegar e consultar informação, torna-se viável editar a qualquer momento a questão SPARQL automaticamente gerada neste contexto (já que é sempre mostrada na zona de edição). Nas referidas tabelas, destaca-se a hiperligação (-i-), lateral aos ID e com a mesma funcionalidade do botão de aparência semelhante na barra de botões de submissão – i.e., acesso direto à página de visualização aprimorada (prettyprint) de um ID. A navegação sistemática por hiperligações via SPARQL foi das coisas mais trabalhosas, dada alguma diversidade de símbolos, entre literais e URI. Assim, todos os URI da ontologia são apresentados como uma hiperligação de navegação, que por meio de SPARQL procura ver onde o URI é usado, à esquerda e à direita dos triplos. URI externos à ontologia, tiveram de ser protegidos nas rotas e inseridos no SPARQL entre carateres menor e maior – exemplo, “<http://example.com>”). Alternativamente, qualquer atributo do tipo string aceitará um endereço HTTP, que reconhecerá como hiperligação. Tirando este, os Literal (ex.: nomes de pessoas, numéricos e outros) não terão hiperligações. Com esta simplificação obteve-se, penso, uma interface mais limpa e mais intuitiva. Esta foi uma opção tomada a meio do caminho, por se ter verificado que as hiperligações nos Literal conduziam a resultados pouco interessantes, porque, se por Ancestors Note Book 52 um lado poderia ajudar ao clicar no nome do pai/mãe/cônjuge, por outro introduz, curiosamente, alguma complexidade, visto ser necessário evitar que a hiperligação seja demasiado grande e contenha certos carateres, como newline e “?”, que quebrariam rotas, e outros carateres poderiam exigir url encoding/decoding, dificultando desnecessariamente a programação e a apresentação. Adicionalmente, estamos interessados em que: 1. literais do tipo URL (http://example.com) saltem diretamente para o destino (o que introduziria uma diferença de interface, já que as hiperligações em literais não teriam todas o mesmo comportamento), 2. literais muito grandes sejam apresentados como colapsáveis, para uma aparência mais agradável das tabelas, que por serem responsivas reagem à largura das colunas. 6.2. Do código fonte Procurou-se escrever código com elevada adaptibilidade evolutiva, a prever evoluções futuras do projeto. Tipicamente, isto leva a estruturar por módulos, a descobrir padrões e templating, documentação, e muito mais. Procurou-se desenvolver um sistema que não seja demasiado dependente da ontologia, para que possa ser adaptado a outras ontologias. Foi nesta atitude que, como sempre devia ser, se tentou recolher inspiração em atributos de qualidade como os que são listados no Anexo I. Houve algumas preocupações quanto à arquitetura do código (cf. secção 5.5 Estruturas):  Separação em pastas segundo as camadas da arquitetura;  Separação por módulos;  Documentação de parâmetros, variáveis e blocos de código;  Funções pequenas e com poucos parâmetros, sempre que possível;  Identificadores camelCase, snake_case e combinações, sempre com foco no significado e legibilidade; alterna-se entre o Português e o Inglês, o que tira alguma uniformidade, embora resulte naturalmente de um certo bilinguismo de que sofro, admito…;  Prefixação de nomes de variáveis e parâmetros segundo o seu tipo, prática comum na comunidade Xbase, mas que considero de uso generalizável e muito útil: cf. Anexo IV e README_desenv.md (que acompanha a instalação da aplicação);  Testes unitários: Os módulos terminados em “_tst” contêm testes unitários.  Testes automáticos: Não foram sistemáticos. Mas, especialmente, foi concebido um módulo, inference_autotst.py, para realização de testes automáticos à inferência de ID, por esta se ter revelado muito sensível a pequenas modificações ao código. Estes testes, refira-se, são dependentes dos dados no grafo (para cada caso, testa-se o resultado esperado). O módulo não é parte integrante da aplicação, mas, ainda assim, necessita do contexto normal da aplicação, que além de ser Flask tem um estado, o Ancestors Note Book 53 que obrigou a “descobrir” as seguintes linhas de código para que pudesse correr separadamente: app = Flask(__name__) with app.app_context(): inference_autotst(). Como correr: dentro do editor de texto, botão “Run Python File”, ou na linha de comandos, com «Python inference_autotst.py». Finalmente, logo que oportuno seria interessante correr um analisador de métricas de código. 6.3. Motores de busca Um motor de busca, ou pesquisa, é extremamente importante na obtenção rápida de informação cuja forma pode não ser bem conhecida. É verdade que o SPARQL é poderoso, mas muito técnico para uso direto por um utilizador leigo, e, quando se pretende contornar acentos, por exemplo, começa a tornar-se muito verboso e trabalhoso. Figura 8 – Motores de busca da opção Procurar Assim, foram sendo desenhados e implementados vários motores de busca, alguns dos quais algo especializados, que são disponibilizados na opção Procurar:  Fácil: Permite, de modo bastante abrangente, a pesquisa por sujeito, predicado e/ou objeto, com determinadas facilidades, especialmente em termos de acentos e maiúsculas/minúsculas, em nomes. Prevê a pesquisa posicionada genealogicamente, por exemplo procurar Predicado = “mae”, “mãe” ou “temMãe”, “éMãeDe”, sendo nestes dois últimos casos case sensitive para ajudar a distinguir casos como “avô” e “avó”. Para uma pesquisa de triplos mais orientada à sintaxe Turtle, usar a procura Triplos. Ancestors Note Book 54  Nome: Procura orientada a nome, designação, alcunhas, nome com gralhas, nome em grafia antiga, entre outros. Por exemplo, procurar “Ruy” equivale a procurar “Rui”, ou “rui”, e vice-versa.  Morada: Procura orientada a moradas. Como, alternativamente a “morada”, existem atributos desagregados para “arruamento”, “numPorta”, “andar”, “localidade”, “códPostal”, quando encontrados serão mostrados nesta pesquisa pela ordem lógica (o que também sucede nas páginas prettyprint de indivíduos).  ID: Procura orientada a ID, em particular de Pessoa, que pode incluir a data de nascimento. Permite pesquisar anos de nascimento entre parêntesis, com os últimos dois dígitos opcionais, que serão adaptados para pesquisar nos ID de Pessoa. Neste âmbito, seria útil permitir ainda intervalos (99xx – 99xx). Exemplos: 1) Fulano de Tal (18xx), encontrando pessoas com esse nome que tenham no ID uma data ou ano de nascimento em toda a gama do século 19. 2) Maria da Atouguia (196x), neste caso na gama da década de 60.  Triplos: Também permite a pesquisa por sujeito, predicado e/ou objeto, mas exige mais rigor na introdução de dados, como modo de restringir a pesquisa. Aspas e maiúsculas importam em literais. Exemplos: 1) Predicado = :alcunha; Objeto = “Xpto”. 2) Objeto = ObjectProperty. Mais tarde, esta pesquisa poderá eventualmente ser incluída na pesquisa Fácil, de modo a reduzir a profusão de opções. Foi sobrevivendo por ter sido a primeira a ser implementada… Os diversos motores, conforme o caso, aceitam pesquisa de subcadeias de carateres e elementos Turtle. Em certos casos, pode ser mostrada uma segunda tabela, por baixo da primeira, com outros resultados (via iniciais da cadeia procurada), menos assertivos, mas que poderão ajudar quando a pesquisa mais exigente não estiver a ajudar. Os três botões à esquerda permitem executar a questão e apresentam os resultados na zona inferior da janela, numa tabela com hiperligações:  Executar: apresenta os resultados numa filosofia prettyprint, mais legível.  Turtle: apresenta os resultados na sintaxe Turtle.  Prefixos RDF: mostra os IRI completos, com prefixos RDF (começados por “http…”, ex.: “ http://www.semanticweb.org/grenhasMEI/AncestorsNB#Pessoa”). Sobre os restantes botões na base do formulário:  Debug: executa a pesquisa e mostra os resultados numa janela de texto, apresentando a lista de objetos retornada pelo RDFLib.  SPARQL: muda para a área de pesquisa SPARQL, tentando gerar uma questão tão aproximada quando possível segundo os padrões do SPARQL.  Descarregar: Quando mostrado, dá a opção de descarregar os triplos encontrados, na sintaxe Turtle.  Reiniciar: Volta a entrar pela rota inicial da área atual. Ancestors Note Book 55 6.4. SGBD Orientado a Grafos A opção pela orientação, da aplicação, a guardar a informação em grafos (por contraponto a outros SGBD, particularmente SGBDR) foi motivada pelo facto de este paradigma:  acrescentar inovação, a nível de base de conhecimento, e logo uma oportunidade de aprender e ganhar mais experiência neste domínio;  estar nitidamente a emergir e a assistir-se a uma crescente utilização, talvez pelo motivo da sua adequação a certos problemas; ser especialmente adequado a carregar ontologias e respetivas instâncias (há quem defina que ontology + data = knowledge graph 9). A aplicação carrega o ficheiro ANB.ttl num grafo RDFLib, em memória, mas gravado para ANB.ttl sempre que ocorram modificações. Quando se verifica ser necessário aceder ao grafo, é testada a timestamp do ficheiro, e se tiver mudado volta a carregar-se em memória – isto faz-se não apenas se ANB.ttl for mais atual (possivelmente por gravação via processador de texto), mas também se for mais antigo, porque pode ter-se reposto uma cópia de segurança. Embora não seja materialmente impossível implementar ontologias com SGBDR, a opção por um grafo, implícito no ficheiro ANB.ttl e explícito no objeto RDFLib em memória, é consensualmente a mais desejável para gerir ontologias, dada a teoria de grafos subjacente e a facilidade de efetuar queries SPARQL. Com RDFLib 5 e Python 3.8, tive a perceção de ser bastante mais eficiente usar os métodos RDFLib orientados ao grafo, em vez de SPARQL. A experiência de utilização era em muitos casos evidentemente mais fluida com queries não SPARQL. Depois de atualizar para RDFLib 6 e Python 3.10, a diferença percecionada de eficiência parece mais dependente das queries, mas carecia de métricas mais rigorosas. Dada a génese dos grafos, pode ser preciso fazer várias travessias e acessos a um grafo para obter um conjunto de informação específico, o que acaba por se refletir na eficiência. Então qual é a vantagem de um grafo? É a sua especial adequação a processos de inferência, que também foram explorados nesta dissertação, como descrito na secção de Inferência de ID. Uma coisa que se revelou bastante trabalhosa foi a recorrente necessidade de conversão de URI, necessária entre os seguintes formatos:  objetos RDFLib (ex.: «rdflib.term.URIRef('http://www.semanticweb.org/AncestorsNB#temMãe’)»),  RDF (ex.: 'http://www.semanticweb.org/AncestorsNB#temMãe’),  Turtle (ex.: ‘:temMãe’) – por vezes referido na literatura como exemplo de um formato abreviado, 9 https://enterprise-knowledge.com/whats-the-difference-between-an-ontology-and-a-knowledge-graph/ Ancestors Note Book 56  prettyprint (ex.: ‘tem mãe’, em grelhas de dados, ou ainda na página aprimorada, onde se procura (ID, rdfs:label), ex.: ‘mãe^’). O formato prettyprint nunca será reversível, já os restantes estão em permanente correspondência e conversão, conforme as necessidades. Para mecanizar esta necessidade, criaram-se módulos de recolha de prefixos e namespaces, guardados em variáveis, complementados com configurações que indicam a chave de prefixo da nossa ontologia (tipicamente “:”), a lista de prefixos e namespaces padrão (como 'owl:', 'rdf:', 'rdfs:', 'xsd:', 'xml:'), etc. Neste âmbito, procurei nomenclatura desambiguadora, especialmente ao nível da codificação:  abbreviated uri – ex.: “rdf:type”  prefix key (ou prefix name) – ex.: “rdf”  prefix – ex.: “rdf:”  namespace – “ex.: http://www.w3.org/1999/02/22-rdf-syntax-ns#”  rdf-uri – ex.: “http://www.w3.org/1999/02/22-rdf-syntax-ns#type” SPARQL na aplicação Além das travessias ao grafo RDFLib, via respetivas funções e métodos, usou-se amiúde o SPARQL, seja para queries mais complexas, seja para queries que neste paradigma resultam mais simples e legíveis, por contraponto a travessias múltiplas. A passagem a um SGBD de grafos, como GraphDB, Virtuoso ou Neo4J, poderá ser desafiante. Não é que deixe de ser viável usar os métodos RDFLib, mas o subgrafo pretendido (mesmo que não seja todo o grafo) terá de ser carregado em cada episódio, pelo que a eficiência dependerá do tempo desse carregamento. A opção futura por um SGBD como os referidos terá de ser cautelosamente avaliada, com justificação apenas na quantidade de informação ou nalguma vantagem competitiva do SGBD em questão. Por avaliar, ainda, ficou o uso de RDFLib sobre grafos externos, via HTTP, o que também se poderá aplicar a SGBD de grafos disponibilizados necessariamente como API. Área SPARQL A aplicação disponibiliza, ao utilizador, uma opção para inscrever questões SPARQL, sejam do tipo query ou update. Deste modo, o utilizador pode agir sobre o grafo com todo o poder do SPARQL, permitindo contornar alguma lacuna funcional da aplicação. Ancestors Note Book 57 Figura 9 – Área acessível pela opção SPARQL A questão de arranque tem tratamento especial de acesso aos indivíduos e classes da ontologia. É nessa zona que se pode editar a questão pretendida. Nos botões de cima, dá-se a hipótese, da direita para a esquerda, de:  gravar a questão (cf. botão homónimo), que pede uma descrição resumida;  escolher um elemento da lista de questões guardadas (cf. botão homónimo), que espera pela seleção do utilizador, carrega a questão no editor e fica à espera de edição ou ordem para executar a questão;  saltar para a área da classe SparqlQuery, com interesse no separador Indivíduos da classe, já que pode ser mais fácil deste modo identificar a questão e mandar logo carregá-la na área SPARQL; ao clicar no ID de um indivíduo específico também se dá a possibilidade de carregar a questão. Os três botões à esquerda permitem executar a questão e apresentam os resultados na zona inferior da janela, numa tabela com hiperligações:  Executar: apresenta os resultados numa filosofia prettyprint, mais legível.  Turtle: apresenta os resultados na sintaxe Turtle.  Prefixos RDF: mostra os IRI completos, com prefixos RDF (começados por “http…”, ex.: “ http://www.semanticweb.org/grenhasMEI/AncestorsNB#Pessoa”). Ancestors Note Book 58 Sobre os restantes botões na base do editor:  Debug: executa a questão e mostra os resultados numa janela de texto, apresentando a lista de objetos retornada pelo RDFLib.  Limpar resultados: apaga a tabela ou janela de apresentação inferior.  Reiniciar: Volta a entrar pela rota inicial da área atual;  (-i-): Frequentemente, disponibiliza-se este botão, para acesso direto à página de visualização aprimorada (prettyprint) de um ID. Personalização RDFLib do SPARQL Sentiu-se necessidade de afinar as questões SPARQL automáticas, de modo a retirarem acentos em procuras de nomes (de pessoas, ruas, etc.), e (uma vez que o padrão SPARQL 1.1 não tem, ainda, funções com esse fim explícito) foi necessário elaborar sobre as funções básicas, o que revelou questões SPARQL um pouco extensas. Chegou-se a questões como a seguinte, para procurar o nome “joao” (já depois de normalizada a cadeia, porque o utilizador poderá procurar “joão” ou “João”, etc.): SELECT DISTINCT ?s ?p ?nome WHERE { ?s :nome|:designação ?nome . ?s ?p ?nome . BIND (replace(lcase(str(?nome)),'\\.',' ') as ?nome_low) . BIND (replace( replace( replace( replace( replace( replace( ?nome_low, 'ç','c'), 'ã|á|â|à|ä','a'), 'é|ê|è','e'), 'í','i'), 'õ|ó|ô|ò|ö','o'), 'ú|ü','u') as ?nome_norm) . FILTER (regex(?nome_norm,"joao",'i')) } No primeiro BIND, converte-se um nome, elegível, para minúsculas, e retiram-se os pontos, sendo o resultado atribuído a uma variável de conveniência, ?nome_low. No segundo BIND, procede-se então à retirada de diacríticos, explicitamente indicados, sendo o resultado atribuído a outra variável de conveniência, ?nome_norm. Mais tarde, explorou-se a possibilidade que o RDFLib oferece para personalizar o comportamento dos resultados no SPARQL, por exemplo para poder usar uma função da aplicação que retire os acentos e outras partículas. Devo dizer que achei o caminho um pouco tortuoso, pelas seguintes razões:  é fácil obter erros difíceis de perceber; para conseguir um ambiente estável, a personalização tende a tornar-se global a todas as queries, tornando-as potencialmente mais lentas;  a função de personalização lida com objetos RDFLib complexos e que achei mal documentados;  o exemplo na documentação do RDFLib não parecia ser de feição – cf. https://rdflib.readthedocs.io/en/stable/_modules/examples/custom_eval.html;  os exemplos disponíveis nos fóruns são escassos – cf. «https://stackoverflow.com/questions/43976691/custom-sparql-functions-inrdflib», que se revelou bastante útil depois de adaptações. Ancestors Note Book 65 Figura 10 – Página da opção Ontologia Ao colapsar um grupo, obtém-se uma lista de hiperligações, cada uma para a página prettyprint individualizada do termo. A separação, visual e operacional, dos relacionamentos de parentesco de outros, pareceu-me natural e desejável, por serem muitos, por a mistura poder dificultar a escolha, e porque, naturalmente, quem procura um relacionamento de parentesco provavelmente não está interessado noutra coisa, e vice-versa. No caso do separador Classes, seria aberto o conteúdo mostrado na figura da secção seguinte. Das Classes e Subclasses No momento de escrita desta tese, a árvore de classes anunciava-se com a seguinte hierarquia. Ancestors Note Book 66 Figura 11 – Página da Ontologia, colapsável das Classes O sistema, pela sua arquitetura, aceita modificação à ontologia, logo às classes. É sabido, pelo menos no âmbito da disciplina de Arquiteturas de Software, que a existência de subclasses deve muitas vezes ser bem equacionada, porque aumenta a complexidade por via da herança, que, regra geral, é para toda a vida. Uma alternativa aconselhada costuma ser criar uma classe autónoma, com ligação à candidata a superclasse. Já em ontologias, parece ser costume haver uma opção despreocupada pela adoção de subclasses, que é frequente fazerem todo o sentido. No caso ANB em contexto, faz todo o sentido, por exemplo, ter Carta (define cartas, missivas) e Img (define imagens, fotografias, etc.) como subclasses de Doc (define qualquer documento, genericamente, com possibilidade de tipificação para distinguir). No entanto, ao ter definições e configurações associadas a Doc, pretendemos imediatamente que qualquer subclasse herde essas configurações, se não for definida. Isso implicou implementações em que se começa a procurar pela classe em jogo e, se esta não estiver configurada, se vai subindo até encontrar uma superclasse configurada. Não se implementou a fusão de configurações: se uma subclasse redefinir configurações de apresentação ou ingestão, tem de indicar tudo o que pretende. Pode parecer mais redundante, mas é também mais flexível e fácil de abarcar, senão, ao analisar e configurar uma subclasse teria de se analisar todas as superclasses. 6.6. Página de utilidades A página de utilidades foi implementada como página acessória, donde se realça: Ancestors Note Book 67  Carregar ficheiros de recursos (imagens, documentos, músicas, vídeos, etc.), para a pasta ontoResources, desde que não existam.  Calcular e inserir automaticamente diversos relacionamentos de parentesco, em duas opções para: o Calcular e inserir indivíduos correspondentes a progenitores e cônjuge de cada indivíduo, e respetivos relacionamentos de parentesco com esse indivíduo de partida. o Calcular e inserir relacionamentos correspondentes a diversos outros graus de parentesco, em função dos relacionamentos de cada indivíduo com progenitores e cônjuge. 6.7. Prettyprint O prettyprint existe a dois níveis no sistema: em menor grau, na apresentação de tabelas, de resultados dos motores de busca e da navegação SPARQL; em maior grau, na apresentação da página de um indivíduo ou termo da ontologia, e navegação subsequente ao clicar em hiperligações. No primeiro caso, procura-se uma melhor legibilidade das tabelas: os ID de indivíduos da classe Pessoa são estripados de “_” e o ano de nascimento e sexo apresentados entre parêntesis; os atributos duma morada são apresentados na sua ordem lógica (arruamento, n.º de porta, n.º de andar, localidade e código postal). Os nomes dos termos são convertidos para minúsculas e metido um espaço antes de cada maiúscula – exemplo, “:temMãe” passa a “tem mãe”. Esta filosofia também foi aplicada na apresentação referida no segundo caso, salvo ao navegar para páginas de termos de ontologia, apresentadas em Turtle, por se considerar que alterar muito a aparência do termo poderia levar a mais confusão do que vantagem. No segundo caso, referente à apresentação de páginas de indivíduos e termos da ontologia: para a mostra de termos dá-se preferência a definições rdfs:label; adicionalmente, concebeu-se uma apresentação universal da página de um indivíduo ou termo, com templating opcional orientado à classe (e herdado por subclasses), como explicado nas seguintes secções. Apresentação Jinja2 O templating de apresentação dos dados de um indivíduo assume várias facetas:  existe um modelo universal de apresentação, indivTp.jinja2, por defeito alimentado pelo roteador indivTp_router (cf. indivTp.py), mas está prevista a opção por conceber modelos especializados, do Jinja2 e/ou do roteador;  a nível do roteador, existe a possibilidade de, facilmente, construir um objeto de configuração para definir que atributos se pretende ver, e por que ordem, mesmo continuando a usar o modelo universal indivTp.jinja2 – esta é uma parte do Ancestors Note Book 68 templating de classe;  no roteador anteriormente referido, pode ainda efetuar-se a configuração do formulário de ingestão, mas isso já é assunto para a secção Ingestão de Dados. Em resumo: conseguiu criar-se um template Jinja2 que pretende, regra geral, visualizar a informação de dado indivíduo de qualquer classe, e ainda de properties (DatatypeProperty, ObjectProperty, etc.). Pode refinar-se a ordem de apresentação num roteador, e mesmo assim usar esse modelo genérico para apresentação, ou então construir um específico, o que não chegou a ser necessário. Figura 12 – Página prettyprint de um indivíduo da classe Pessoa Para imprimir, de momento baseamo-nos na função padrão respetiva do navegador web11, que permite imprimir, inclusive para PDF se existir um controlador de impressora PDF instalado no sistema operativo. É verdade que aparecem os botões de controlo (Alterar Dados, etc.), pelo que seria útil haver, na mesma página prettyprint, um controlo para uma rota que mostrasse a página mais “limpa”, sem os referidos controlos, que ao imprimir já não iriam sair. Em referência ao exemplo da figura acima, é óbvio que, depois de colapsar Biografia, ou outro que exista no contexto, ao imprimir também serão contemplados. Seguese um exemplo: 11 Cf. tecla Ctrl+P, ou menu do navegador. Ancestors Note Book 69 Destaca-se seguidamente algumas áreas da apresentação padronizada da página de um indivíduo. Em cima, à direita: ícone principal de um indivíduo (atributo imagem da ontologia). Pode haver uma segunda imagem alternativa (atributo versoImg, verso duma fotografia ou outra perspetiva, como por exemplo uma imagem de perfil ou o interior de um edifício). Pode clicar-se em cada imagem para ver em tamanho maior. Não sendo indicado, existem ícones padronizados, para mostrar na ausência duma imagem específica. Figura 13 – Ícones padronizados para indivíduos sem imagem Da esquerda para a direita, a figura anterior contempla ícones para:  Termos de ontologia em geral, incluindo classes não personalizadas.  Classe Pessoa. Ancestors Note Book 70  Classe Org.  Classe Local.  Classe Doc.  Classe Evento. Para a classe Doc, estão ainda previstos ícones para diversos tipos de documentos, quando existir ficheiro associado por via do termo imagem: ao clicar no ícone existe um tratamento específico da visualização, e descarregamento. Nas imagens (ficheiros de extensão gif, jpg, jpeg, png), mostra-se logo a imagem. Para os restantes, foram selecionados ícones apropriados. Figura 14 – Ícones padronizados para ficheiros Da esquerda para a direita, a figura anterior contempla ícones para PDF (ficheiros de extensão pdf), TXT (txt), documentos diversos (nomeadamente markdown), áudio (mid, midi, mp3, wav), vídeo (mp4, ogg, webm). Voltando à página prettyprint, em cima, à esquerda: <Acerca de> (nome ou designação, senão ID); por baixo, subtipo (ex.: sexo ou tipo de documento); depois, o Tipo (a classe) e ID. Por baixo, o resumo. Depois, informação sobre o indivíduo, em duas tabelas: 1. Atributos e relacionamentos do indivíduo com terceiros, i.e., triplos onde o indivíduo aparece à esquerda, tipicamente a informação mais pretendida. 2. Relacionamentos com o indivíduo, i.e., triplos onde o indivíduo aparece à direita. Finalmente, botões de ação, e abaixo, quando elegível, separadores colapsáveis associados a campos multilinha, como biografia, transcrição, notas, etc… (conforme configurado no template da classe em causa). Nestes campos pode usar-se a inferência interativa. Templating de classe Apresentação estática Como referido na secção anterior, é possível afinar a ordem de apresentação de termos, e até esconder os que se quiser, e continuar a usar o modelo universal de apresentação, indivTp.jinja2, uma vez que o router é que escolhe que modelo usar, ao fazer algo como Ancestors Note Book 71 return render_template('indivTp.jinja2', … O que é então necessário para este efeito? Tomemos como exemplo o roteador localTp.py (modelação da UI da ontoclasse Local). Para afinar a UI, é preciso algo como a seguir: 1. from env import SetFields_PpIns, SetPpTpInfo 2. from flask import render_template 3. from LibOnto.myRdflib_Graph import NossoGrafo 4. from myTpFormat import DadosTp, DaImgIndiv, GetTp_id 5. 6. yInfoOrder = { 7. "Principal": 8. {"PorOrdem": ["nomeAlternativo", "url"], 9. "OrdemAlfabética": []}, 10. "Secundário": 11. {"PorOrdem": ["nomeComGralhas", "morada", "arruamento", "numPorta", 12. "andar", "localidade", "códPostal", "país", "temDoc"], 13. "OrdemAlfabética": []}, 14. "EmAnexo": 15. {"PorOrdem": [], "OrdemAlfabética": []}, 16. "Esconder": 17. ["data", "dataFinal", "ano", "anoFinal", "designação", "imagem", 18. "versoImg", "tipoLocal", "resumo", "rdf:type", "transcrição"], 19. "CollapsibleText": 20. [["transcrição", {}]] 21. } 22. SetPpTpInfo("Local", yInfoOrder) 23. 24. 25. def localTp_router(request): 26. jinja_parms = {} 27. # --- Obter dados específicos a passar ao template Jinja. 28. DadosTp(jinja_parms, request, yInfoOrder, None, ":designação", 29. ["", ":tipoLocal"]) 30. 31. cID = GetTp_id(request) 32. g = NossoGrafo() 33. # Imagem do verso 34. DaImgIndiv(g, cID, "profileLoc.png", None, None, 35. ":versoImg", jinja_parms, "_back") 36. # Imagem da frente 37. DaImgIndiv(g, cID, "profileLoc.png", None, 38. "Imagem indistinta (bolha de localização)", ":imagem", 39. jinja_parms, "") 40. 41. return render_template('indivTp.jinja2', **jinja_parms) Cf. linha 6, atribuição de yInfoOrder:  "Principal" e "Secundário": Duas zonas consecutivas de informação, a pedir listas de termos da ontologia. Serve para selecionar apresentação de atributos e relacionamentos do indivíduo com terceiros, i.e., triplos onde o indivíduo aparece à esquerda, tipicamente a informação mais pretendida. “PorOrdem”: os termos serão listados pela ordem específica em que surgem na lista. “OrdemAlfabética”: os termos serão listados pela ordem alfabética.  "EmAnexo": Usado para selecionar apresentação de relacionamentos com o Ancestors Note Book 72 indivíduo, i.e., triplos onde o indivíduo aparece à direita.  "Esconder": Termos a esconder da visualização, tipicamente por serem redundantes. Como exemplo, datas já contempladas no cabeçalho da página apresentada, ou relacionamentos owl:inverseOf.  “CollapsibleText”: Termos a mostrar na zona inferior da página, na forma de separadores colapsáveis – indicar um mapeamento (função parcial) em que cada chave é o termo, e a correspondência prevê configurações futuras ainda não necessárias. Finalmente, em app.py: 1. SetRoute_Pp("Local", "/localTp") # Registar a rota prettyprint da ontoclasse. 2. 3. #Router prettyprint da ontoclasse: 4. @app.route("/localTp") 5. def localTp(): 6. return localTp_router(request) Formulários de ingestão São automaticamente gerados todos os formulários de ingestão de dados, da responsabilidade do roteador indivTpIn_router (cf. indivTpIn.py) e do modelo de apresentação indivTpIn.jinja2, que funcionam como modelos universais. Assim, é possível ter uma ontoclasse sem especificidades de formulário, sendo gerado um formulário padrão – cf. botões de acesso, na secção de Ingestão interativa. Ancestors Note Book 73 Figura 15 – Formulário de dados automático da classe Local Mas também os formulários de ingestão podem ser configurados e afinados, com pouco esforço. Continuando com o exemplo do roteador localTp.py (modelação da UI da ontoclasse Local), essa afinação consegue-se do seguinte modo: 1. SetFields_PpIns("Local", [ 2. ["tipoLocal", {'required': True, 'autofocus': True, 3. 'placeholder': "arruamento, lugar, freguesia, país, ..."}], 4. ["designação", {'required': True}], 5. ["data", {'type': "date"}], 6. ["ano", { 7. 'placeholder': "9999 (alternativo ao campo data)"}], 8. ["resumo", {'required': True, 'textarea': True}], 9. ["url", {}], 10. ["transcrição", {'textarea': True, 'rows': "2"}], 11. # Prop. 'type' == "file" => botão para Escolher Ficheiro e upload automático. 12. ["imagem", {'type': "file"}] 13. ]) Ancestors Note Book 74 Para cada termo, temos um objeto/dicionário que associa elementos e atributos html a valores pretendidos ao gerar o formulário. Por exemplo, o termo tipoLocal será um campo unilinear, com label “tipo local*”, e o devido <input …>: <input id="tipoLocal" name="tipoLocal" class="form-control form-control-md rounded-left" onblur="setId(this.id)" required autofocus placeholder="arruamento, lugar, freguesia, país, ..." title="'edifício', 'arruamento', 'lugar', 'freguesia', 'região', 'país', ..."> Handicap: ainda são efetuadas poucas validações aos valores inseridos em formulário pelo utilizador. Neste âmbito, não é preciso fazer mais registos em app.py. Mas, e se quiséssemos personalizar o roteador indivTpIn_router? Então teríamos de escrever um novo roteador, e fazer o seu registo em app.py, como no exemplo feito para a classe SparqlQuery: 1. # --- Rotas de ingestão de dados. Estas rotas serão atribuídas aos botões do template jinja, cf. uso de GetRoute_TpIn(). 2. # Rota de inserção de indivíduos da ontoclasse SparqlQuery. 3. SetRoute_PpIns("SparqlQuery", "/sparqlQTpIns") 4. 5. # Rota de alteração de dados da ontoclasse SparqlQuery. 6. SetRoute_PpAlt("SparqlQuery", "/indivTpIn") 7. 8. @app.route("/sparqlQTpIns") 9. def sparqlQTpIns(): 10. return sparqlTpIns_router(request) 6.8. Ingestão de Dados A filosofia de rapidez do desenvolvimento continuou pelo capítulo da ingestão de dados, que se desenrola a diferentes níveis, conforme já abordado e agora completado nas seguintes secções: ingestão automatizada, via opção DSL; ingestão interativa, via formulários html (automaticamente gerados, com possibilidade de configuração a nível da ontoclasse); ingestão automática por inferência, a pedido, via opção Utilidades. Os campos de texto multilinha aceitam formatação Markdown e/ou HTML. Estes campos distinguem-se na sintaxe Turtle por terem aspas triplas, enquanto que nos formulários por serem um elemento textarea. Área DSL Esta área proporciona uma ingestão bastante livre, na sintaxe Turtle, por upload de ficheiro ou por edição direta, com análise básica de consistência. É verdade que outros formatos poderão ser desejados (cf. secção sobre trabalho futuro), no entanto realça-se que será sempre possível utilizar previamente algum tipo de conversor, de um desses outros formatos para Turtle, e depois carregar o ficheiro resultante. Deste modo, poderá evitar-se complicar demasiadamente a aplicação, até porque será difícil satisfazer todas as pretensões. Lembre-se que, no âmbito de implementar requisitos e funcionalidades, a obtenção da primeira versão nem sempre é o mais trabalhoso difícil, e até Ancestors Note Book 81  facilita a prototipagem e correção rápida, por edição direta do ficheiro;  facilita desenhar a ontologia noutra ferramenta (experimentou-se Protégé) e trazer o ficheiro exportado por essa ferramenta, em sintaxe Turtle, para carregar na aplicação;  a ontologia é carregada em memória na primeira vez que se pretende o grafo correspondente, e depois automaticamente quando se deteta alteração da timestamp do ficheiro. O uso a partir de memória torna o sistema eficiente. Quando a ontologia for muito grande, poderá demorar um pouco mais na primeira vez que é carregada, e ao gravar. 7.2. Trabalho futuro Durante o projeto, várias ideias houve que acabaram por não ter implementação, essencialmente por falta de tempo, mas poderão ter muito interesse numa abordagem futura, se corresponderem a reais necessidades. As primeiras da lista começaram, inclusive, a tomar a forma de requisito já um pouco mais estruturado, mas por pedirem mais análise não se considerou todas as secções do cartão de Volere. Depois, seguem-se ideias que entendi merecerem registo, ainda que incipientes. Naturalmente, outras poderão emergir como interessantes. Nomeadamente, tudo o que facilite e melhore a experiência do utilizador motiva à utilização do sistema, potenciando o seu futuro desenvolvimento. Pessoalmente, defendo o desenvolvimento e adoção de ambientes com uma curva de aprendizagem rápida. Tenho constatado que nascem permanentemente aplicações, sistemas, arquiteturas, conceitos, tecnologias, etc., e nem sempre há muito tempo (ou energia anímica) para “tirar mais um curso” como pré-condição de utilização, ou então a devida exploração do sistema revela-se demasiado penosa se não for de manifesto interesse. Um sistema deve facilitar a instalação e uso imediatos, ou quase, ainda que possa, depois, exigir mais formação para uma utilização mais rica e produtiva, mas nessa altura o utilizador já se encontra mais motivado a dedicar-lhe tempo e esforço. Seja como for, poderão futuramente acrescentar-se funcionalidades como explorado nas secções seguintes. RFf112: Permitir inserção interativa fácil de termos sobre indivíduos Requirement #: RFf1 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Facilitar a inserção de informação associada a um indivíduo. Originator: Brainstorming Fit Criterion: No contexto da página aprimorada de um indivíduo, deve facilitar-se o acesso interativo a campos para escolher um termo (atributo ou relacionamento) e respetivo valor a introduzir. A escolha do termo deve fazer sugestões em função do que se escreve, baseado na ontologia subjacente. Ex.: ao escrever “avô” (ou mesmo “avo”), deve dar-se a escolher 12 O “f” refere-se a “futuro”. Ancestors Note Book 82 termos como temAvô, éAvôDe, entre outros (ou mesmo temAvó, éAvóDe). A escolha poderá basear-se num menu pop-up. Ex. – Termo Valor <caixa para escrever><controlo para ver lista de termos> <caixa para valor> RFf2: Imprimir uma compilação Requirement #: RFf2 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Facilitar a publicação de assuntos relacionados via um indivíduo da classe Compilação. Originator: Brainstorming Fit Criterion: Poder escolher um indivíduo da classe Compilação e gerar uma página ou documento (ex.: no formato PDF) com os atributos e informação associada via relacionamentos da Compilação. A geração de uma página responsiva poderia permitir, pelo simples ajustar da largura do navegador, ajustar a disposição de elementos conforme pretendido para output. RFf3: Disponibilizar editor de texto com controlos markdown ou afins Requirement #: RF3 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Aumentar a usabilidade, melhorar a experiência de utilização. Originator: Brainstorming Fit Criterion: Permitir uma configuração na aplicação que sinalize certos campos para recorrerem ao editor wiki, e nas áreas elegíveis da aplicação, permitir abrir o referido editor. Dicas: observar zim-wiki, ontowiki, docuwiki, mediawiki, wikipedia, etc. RFf4: Pesquisar iniciais em nomes apenas ao indicar maiúsculas Requirement #: RF4 Requirement Type: Funcional Event/BUC/PUC #: Rationale: Facilitar a afinação da procura, alternando entre procurar ou não com recurso a iniciais de nomes, para limitar a quantidade de resultados. Originator: Brainstorming Fit Criterion: Nos motores Procurar, o utilizador usar Maiúsculas poderia ser tido como indicação de pretender pesquisar pelas iniciais de nomes e ID. Ex.: Pesquisar joão manuel não teria em conta iniciais, já João Manuel, ou mesmo J M, teria. No sistema, por outro lado, já se pode indicar iniciais (maiúscula ou minúscula, seguida de ponto) para restringir a pesquisa – ex.: “J. Manuel” pesquisa nomes com a inicial explícita “J.” ou ID com “…_J_...”. Completar a ajuda No anexo Página de ajuda transcreve-se a ajuda da aplicação, acessível pela opção homónima. A ajuda é sempre pouca e está sempre incompleta. Assim, não será difícil adivinhar que precise de mais conteúdos e exemplos. Ancestors Note Book 83 Clonar instalações da aplicação Analisar e disponibilizar um modo fácil de clonar a aplicação para uso com outras ontologias. Provavelmente, o nome do ficheiro TTL será diferente, a configurar em env.py. Havendo apenas um ficheiro TTL, a aplicação poderia assumi-lo sem ter de ser configurado. A respeito de carregar outras ontologias, e conforme já constatado com a famosa ontologia pizza, será necessário reconhecer simultaneamente um prefixo vazio e outro não vazio, como prefixos de raiz da ontologia. Exemplo: @prefix : <http://www.co-ode.org/ontologies/pizza/pizza.owl#> . @prefix pizza: <http://www.co-ode.org/ontologies/pizza/pizza.owl#> . Melhorar a validação de campos em formulários Os formulários de ingestão (i.e., inserção ou alteração de dados) beneficiarão da validação de campos, caso contrário o servidor poderá recusar a operação, por vezes de modo silencioso. Assim:  Quando a validação for efetuada pelo servidor e falhar, deve ser retornado um aviso a mostrar ao utilizador – ex.: um conteúdo mostrado no início da página produzida.  Quando a validação for efetuada pelo formulário, deve ser emitido um alerta e permanecer na página. Poder imprimir para PDF Atualmente, usando as funções do navegador web e um controlador PDF instalado no sistema, já é possível imprimir para PDF. Contudo, seria mais agradável imprimir sem ver todos os controlos da página, como botões de ação (Alterar Dados, etc.). Aceitar Notation3 A sintaxe Notation3/N313 poderá ser considerada no futuro, para a persistência da própria ontologia, visto ser um superconjunto de Turtle e o RDFLib permitir carregar aquele formato. Note-se que a opção por uma sintaxe é importante porque, ao carregar a ontologia num grafo, torna-se necessário especificar a sintaxe do ficheiro, e acaba por definir uma parte da interface com o utilizador. Cf. https://en.wikipedia.org/wiki/Notation3. Poder descarregar informação em diferentes formatos Poder descarregar informação em diferentes formatos, como PDF, Markdown, Latex, ou mesmo CSV, nos diversos ambientes da aplicação. A este respeito, além de livrarias específicas do Python, como Pandoc, também poderão ser explorados templates Jinja2. 13 Não confundir com N-Triples. Ancestors Note Book 84 Poder importar informação noutros formatos A aplicação prevê importar no formato Turtle. Poderá haver interesse em carregar informação noutros formatos, como Markdown ou CSV, mas com uma estrutura prédefinida via DSL -- cf. YAML como metadados. Refira-se que será sempre possível utilizar previamente (via linha de comandos ou ia alguma aplicação) algum tipo de conversor, de um qualquer formatos específico para Turtle, e depois carregar o ficheiro resultante. Deste modo, poderá evitar-se complicar demasiadamente a aplicação, até porque será difícil satisfazer todas as pretensões e respetiva evolução – os requisitos evoluem, logo os formatos pretendidos também irão evoluir, infelizmente para o programador... Em referência à conversão entre formatos, lembre-se de livrarias específicas do universo Python, como Pandoc. GEDCOM Usar uma biblioteca Python para importar e exportar dados segundo GEDCOM, por ser um formato padrão muito difundido, em particular a pensar na área de genealogia da ontologia. Cf., por exemplo: conversores para Turtle; xmlgedcom, entre outros. Resolver axiomas owl:propertyChainAxiom Analisar se é útil usar/derivar a função VrfAxioma, já aproveitada na inferência interativa, para testar/inferir indivíduos a partir de axiomas definidos na ontologia, como por exemplo :temNeta owl:propertyChainAxiom ( :temFilhoOuFilha :temFilha ), embora este caso já esteja previsto na geração automática possibilitada pela opção Utilidades -> Genealogia(…). Analisador de consistência do knowledge graph Um reasoner bem escolhido poderá ajudar nesta tarefa. Recomenda-se cuidado a selecionar reasoners que possam entrar em deadlock. Substituição global de um ID que se revelou insatisfatório. Na arquitetura atual, esta tarefa pode fazer-se por meio de um simples editor de texto sobre o ficheiro da ontologia, ANB.ttl, com recurso a uma substituição global. Remoção seletiva de relacionamentos Pode fazer-se via SPARQL (exemplos): 1. Remoção dos relacionamentos com ID à direita: DELETE WHERE { ?s ?p :indiv . ?p a owl:ObjectProperty . } 2. Remoção dos relacionamentos com ID à esquerda: DELETE WHERE { :indiv ?p ?o . ?p a owl:ObjectProperty . } Ancestors Note Book 85 Área DSL  Havendo dúvidas sobre triplos, poderiam ser automaticamente adicionados a candidatosTtl, para análise futura. Ou seja, implementar uma opção “Inserir mesmo assim”, que selecionaria os triplos considerados inválidos e os desviaria para candidatosTtl. Nesta situação, poderá ter de decidir se gera ID para diferenciar doutro existente ou não (caso em que vai fundir ou reescrever a informação… cuidado!). Lembra-se o termo ontológico oMesmoQue (ou owl:sameAs), que pode usar-se para associar ID com outros já existentes. Na introdução de triplos de definição de ontologia, poderá ser necessário cuidados especiais.  Poder carregar informação numa sintaxe markdown. Como alternativa, será útil avaliar da existência de conversores de markdown para Turtle. Ainda assim, deixa-se alguns exemplos:  indivíduo com fotografia: id: f_55 ficheiro foto55.jpg resumo: <…> transcrição: <…> <…>  carta: --- id: C044 type: carta from: Olga Pedrário from-address: Rua Frederico Eyer, 141, Gávea / Rio de Janeiro, Brasil to: ETL to-address: Rua Egas Moniz, 6, 1º / Porto / Portugal date: 1954-08-20 transc: jj about: - estudo - berceuse --- Querido Eurico… Inferência Reconhecer intervalos temporais, em pesquisas O sistema já permite indicar casos “(99..)”, em expressão regular “\(\d\d..\)” (em particular, aceita-se “x” como aliás para “.”). Exemplos: “(1969)”, “(196x)”, “(196.)”, “(19xx)”, “(19..)”. Seria ainda mais útil poder indicar intervalos “\(\d\d..-\d\d..\)”, de modo a abranger casos Ancestors Note Book 86 mais ambíguos em termos de viragem de século. Exemplo: “(189x-191x)”. Revisitar objetivos desta tese Sugere-se revisitar os objetivos da tese, especialmente em termos de inferência, uma vez que o recurso tempo acabou por adiar indefinidamente alguns, como:  Desambiguar pessoas/entidades pelo contexto de lugares, datas (expressas ou implícitas) e eventos, que possam ser comparados com os conhecidos (nascimento e morte, idade maior, meia idade, idade avançada).  O sistema poderá aceitar constraints para ajudar a refinar soluções. Pretende-se um constraint solver para restrições no domínio geográfico, genealógico, temporal – no âmbito do período de vida humano (como data de óbito >= data de nascimento, idade para serviço militar em comparação com eventos como batalhas, etc.). Implementar a funcionalidade do termo candidatosTtl Cf.: :candidatosTtl a owl:DatatypeProperty ; rdfs:comment "Triplos em Turtle, pendentes de análise e inserção." ; rdfs:range xsd:string . Este termo poderia receber uma lista livre de triplos na sintaxe Turtle, pendentes de análise e inserção, a tratar por uma opção específica, que iria analisar a sintaxe e semântica, desambiguando e pedindo ajuda para os introduzir na ontologia. Numa primeira abordagem, podem considerar-se apenas triplos em que entrem owl:NamedIndividual, ainda que só num dos lados do triplo. Posteriormente, poderá pensar-se na definição de termos da ontologia. Qualquer dos termos pode não existir na ontologia (e induzir inserção automática), ou ser substituído por um já existente. Exs.:  (:João :frequenta :Eduardo . ), sendo :João o cliente do barbeiro :Eduardo. Eventualmente, frequenta poderia ser substituído por conhece.  (:João :éPaiDe :Maria .) Como :éPaiDe já existe, deduz-que que :João e :Maria são da classe :Pessoa, podendo ser automaticamente inseridos se não existirem. Ainda assim, lembre-se que existe no sistema uma opção, DSL, que permite, na hora, analisar e introduzir na ontologia triplos de toda a natureza. A referida análise não é ainda a ideal e pode ser melhorada. Níveis de utilização Implementar diferentes níveis de utilização, por razões de segurança. Assim, determinados níveis não poderiam remover informação, por exemplo. Ancestors Note Book 87 Bibliografia [AM2019] José João Almeida, Rui Castro Mendes (2019). Hunting Ancestors: a unified approach for discovering genealogical information [AH2017] Cristiana Araújo, Pedro Henriques (2017). Introdução às Ontologias, apresentação de diapositivos, unidade curricular de Gramáticas na Compreensão de Software 2017/2018. [FWCT2013] Lee Feigenbaum, Gregory Todd Williams, Kendall Grant Clark, Elias Torres (2013). SPARQL 1.1 Protocol, W3C Recommendation 21 March 2013. Cf. https://www.w3.org/TR/sparql11-protocol. [HP2012] M. Horridge and P. F. Patel-Schneider (2012). OWL 2 Web Ontology Language Manchester Syntax (Second Edition). W3C Working Group Note 11 December 2012. Cf. https://www.w3.org/2012/pdf/NOTE-owl2-manchester-syntax20121211.pdf. [MPP2012] Boris Motik, Peter F. Patel-Schneider, Bijan Parsia. OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax (Second Edition). Eds. W3C Recommendation, 11 December 2012, http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/. Latest version available at http://www.w3.org/ TR/owl2-syntax/. [NM2000] Natalya F. Noy and Deborah L. McGuinness (2000?). Ontology Development 101: A Guide to Creating Your First Ontology, Stanford University. [Ram2020] José Carlos Ramalho (2020). Tutorial: Protégé-OWL (parte II), apresentação de diapositivos. [Rib2017] Frederico Moreira Ribeiro (2017). Especificação de uma Ontologia para Genealogia, Master dissertation, Master Degree in Computer Science, Universidade do Minho. [SSMJ2015] Robert Stevens, Margaret Stevens, Nicolas Matentzoglu and Simon Jupp (November 25, 2015). Manchester Family History Advanced OWL Tutorial, Edition 1.1. Cf. http://mowl-power.cs.man.ac.uk/fhkbtutorial/resources/FHKBtutorial_v1_1.pdf [Stur2020] Thomas F. Sturm (2020). The genealogytree package Manual for version 2.01 (2020/07/28). Cf. http://mirrors.ctan.org/macros/latex/contrib/genealogytree/ genealogytree.pdf Ancestors Note Book 88 Glossário Geral Nota: Para termos no contexto da genealogia, recorrer ao Glossário Genealógico. entidade (latim medieval entitas, -atis) nome feminino 1. Tudo o que é concreto. 2. Ente; ser; indivíduo. 3. Instituição, organismo ou outra pessoa jurídica com funções específicas (ex.: entidade bancária; entidade privada; entidade pública). 4. [Informal] Importância. "entidade", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2020, https://dicionario.priberam.org/entidade [consultado em 03-02-2021]. indivíduo inglês: individual No âmbito desta tese e das ontologias, um indivíduo corresponde grosso modo a uma instância duma ontoclasse, com associação por via de um identificador (ID), que neste trabalho se considera globalmente único. Exemplo muito resumido, na sintaxe Turtle: :M_Isilda_S_Mendes a :Pessoa, a owl:NamedIndividual. Cf. https://en.wikipedia.org/wiki/Ontology_components [consultado em 27-11-2021]. memorabilia |memòràbílià| (palavra latina, plural neutro substantivado de memorabilis, -e, memorável) nome feminino plural 1. Conjunto de coisas ou acontecimentos memoráveis. 2. Conjunto de objetos. "memorabília", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2020, https://dicionario.priberam.org/memorabilia [consultado em 24-01-2021]. ontoclasse No âmbito desta tese, refere-se a uma classe da ontologia. (Porquê um termo novo? Porque, em programação e arquiteturas de software, classes há-as de muitas naturezas… e se com um simples termo conseguimos desambiguar o contexto, porque não um termo novo?) Ancestors Note Book 89 reasoner “A semantic reasoner, reasoning engine, rules engine, or simply a reasoner, is a piece of software able to infer logical consequences from a set of asserted facts or axioms.” Origem: https://en.wikipedia.org/wiki/Semantic_reasoner [02/01/2021] taxonomia nome feminino Teoria ou nomenclatura das descrições e classificações científicas. = TAXINOMIA "taxonomia", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2020, https://dicionario.priberam.org/taxonomia [consultado em 24-01-2021]. nome feminino 1. conjunto de princípios e métodos de classificação dos diversos elementos de uma área científica; sistema de categorização 2. BIOLOGIA ramo da sistemática que, considerando a semelhança e dissemelhança de características dos seres vivos, os descreve e agrupa em categorias organizadas e hierarquizadas (como o tipo, a família, o género, a espécie, etc.); biotaxia https://www.infopedia.pt/dicionarios/lingua-portuguesa/taxinomia [24-01-2021] wiki “Um wiki é uma publicação com hipertexto, colaborativamente editada e gerida pela sua própria audiência, diretamente via web browser. Num wiki típico, o texto é escrito com uma linguagem de marcação e frequentemente editado com a ajuda de um editor de texto enriquecido. Um wiki é executado por um software wiki, um tipo de sistema de gestão de conteúdos, mas diverge da maioria de outro tipo de sistemas, inclusive software de blog, no sentido em que o conteúdo é criado sem qualquer dono ou líder definido. Os wikis possuem pouca estrutura inerente, o que permite que a estrutura seja melhorada de acordo com as necessidades dos utilizadores.” https://pt.wikipedia.org/wiki/Wiki e https://en.wikipedia.org/wiki/Wiki [26/01/2021]. xsd “XML Schema Definition, commonly known as XSD, is a way to describe precisely the XML language. XSDs check the validity of structure and vocabulary of an XML document against the grammatical rules of the appropriate XML language.” https://www.tutorialspoint.com/xsd/index.htm [26/01/2021] Ancestors Note Book 90 Glossário Genealógico Incluem-se nesta secção alguns termos específicos do âmbito. Não se pretende ser exaustivo, mas abordar alguns termos eventualmente menos conhecidos. Abreviaturas nesta secção: poderá ser necessário consultar a origem da informação, referida ao cabo de cada definição. agregado familiar Conjunto de pessoas que vive em comunhão de bens e habitação. ancestral an·ces·tral (francês ancestral; inglês: ancestor) adjetivo de dois géneros 1. Dos antepassados. 2. Muito antigo. 3. Avito. adjetivo de dois géneros e nome de dois géneros 4. Que ou quem pertence a uma geração anterior. = ANTECEDENTE, ANTEPASSADO Origem: https://dicionario.priberam.org/ancestral [15/11/2020]. ascendente as·cen·den·te (inglês: ancestor) adjetivo de dois géneros De quem se descende. nome de dois géneros Antepassado. ascendentes nome masculino plural Geração ou gerações anteriores. = AVÓS, ASCENDÊNCIA, ASCENDENTES Origem: https://dicionario.priberam.org/ascendente [15/11/2020]. nome de 2 géneros Ancestors Note Book 97 Anexo II. Particularidades das Ontologias Este anexo foi reservado para excertos de artigos e referências sob o tema em epígrafe. OWL Constraints Limitations of Ontologies, in https://www.ontotext.com/knowledgehub/fundamentals/ what-are-ontologies/, 05/01/2021: “While ontologies provide a rich set of tools for modeling data, their usability comes with certain limitations. One such limitation is the available property constructs. For example, while providing powerful class constructs, the most recent version of the Web Ontology Language – OWL2 has a somewhat limited set of property constructs. Another limitation comes from the way OWL employs constraints. They serve to specify how data should be structured and prevent adding data inconsistent with these constraints. This, however, is not always beneficial. Often, data imported from a new source into the RDF triplestore would be structurally inconsistent with the constraints set using OWL. Consequently, this new data would have to be modified before being integrated with what is already loaded in the triplestore. A novel alternative to using ontologies to model data is using the Shapes Constraint Language (SHACL) for validating RDF graphs against a set of constraints. A shape specifies metadata about a type of resource – how it is used, how it should be used and how it must be used. As such, similarly to OWL, SHACL can be applied to validate data. Unlike OWL, however, SHACL can be applied to validate data that is already available in the triplestore.” Lição sobre OWL Reproduz-se aqui, pela sua relevância, uma lição, em Inglês, sobre OWL, obtida de https://cambridgesemantics.com/blog/semantic-university/learn-owl-rdfs/owl-referenceshumans/: Classes and Resources One area in which OWL goes significantly beyond RDFS14, is that it allows you to construct some fairly complex, but useful, relationships among classes. Some of the most common building blocks for doing so are listed below. 14 https://cambridgesemantics.com/blog/semantic-university/learn-owl-rdfs/rdfs-vs-owl/ Ancestors Note Book 98 Classes and Resources Property Used to say that… Example intersectionOf …any instance of the first class is also an instance of all classes in the specified list :Mother owl:intersection Of ( :Woman :Parent ) unionOf …any instance of the first class is an instance of at least one of the classes in the specified list :Parent owl:unionOf ( :Mother :Father ) complementOf …the first class is equivalent to everything not in the second class :Parent owl:complementOf :NonParent disjointWith …the first class and second class have no members in common :Man owl:disjointWith : Woman equivalentClass …the first class and the second class contain all the same members :AdultFemaleHuman owl:equivalentClass :Woman sameAs …the first resource refers to the exact same thing as the second resource :JimFromWork owl:same As :MyNeighborJim differentFrom …the first resource refers to something different from the second resource :BobFromWork owl:differe ntFrom :MyNeighborBob Properties As with RDFS, properties in OWL are used to link things together. OWL provides a rich and complex vocabulary for saying things about these links. Basic Property Types Kind of Property Used to say… Example Explanation DatatypeProperty …that this property links to simple data values ex:hasBirthday This property links to a date, which is a simple data value ObjectProperty …that this property links to another resource ex:hasSpouse This property links to a person, which is another resource Logical Relationships Kind of Property Used to say… Example Explanation TransitiveProperty …that if this property links A to B, and B to C, then it also links A to C. ex:tallerThan If Ann is taller than Bob, and Bob is taller than Chuck, then Ann is taller than Chuck SymmetricProperty …that if the property ex:hasSpouse If Ann is Bob’s Ancestors Note Book 99 relates A to B, then it always relates B to A as well. spouse, then Bob is Ann’s spouse too AsymmetricProper ty …that if the property relates A to B, then it never relates B to A. ex:tallerThan If Ann is taller than Bob, then Bob can’t be taller than Ann ReflexiveProperty …that this property always links something to itself. ex:livesWith Everybody lives with themselves IrreflexiveProperty …that this property never links something to itself. ex:hasSpouse Nobody is their own spouse FunctionalProperty …that this property only ever links to at most one thing. ex:hasBirthday You only have one birthday InverseFunctionalP roperty …that the subject of this property is uniquely identified by the value of this property. ex:hasDLNum ber I am the only person with my driver’s license number Properties Linking Properties Property Used to say that… Example inverseOf …the two properties are the inverse of each other. For example, if Ann’s child is Bob, then Bob’s parent is Ann. :hasChild owl:inverseOf :hasParent equivalentProperty …two properties are exactly the same :hasBirthPlace owl:equivalentProperty :hasBirthLocation Restrictions In RDFS, you could impose constraints on properties simply by specifying the domain and range. For example, if you asserted the range of :hasBirthday is xsd:date, then all statements using :hasBirthday should have an xsd:date as their object. OWL lets you do this too, but it also introduces the concepts of restrictions, enumerations, and dataranges which are much more powerful. (Note: In the Turtle RDF syntax, these constructs are usually specified using the bracketed blank node syntax, which we’ll use below.) Restrictions and Enumerations Parameter Used to say… Example Explanation Ancestors Note Book 100 cardinality min-cardinality max-cardinality …that the property can have a certain number of values (objects). :Automobile owl:equivalentcl ass [ rdf:type owl:Restriction ; owl:cardinality “4”^^xsd:int ; owl:onProperty :hasWheel ] . All automobiles have 4 wheels (e.g., as opposed to a bicycle). oneOf …that all instances of a class come from the specified list :BobsChildren owl:equivalentClass [ rdf:type owl:Class ; owl:oneOf ( :Bill :John :Mary ) ] . The class ‘BobsChildren ’ has the three items: Bill, John, and Mary hasValue …that all objects of that property have the specified value :BobsChildren owl:equivalent Class [ rdf:type owl:Restriction ; owl:onProperty :hasParent ; owl:hasValue :Bob ] . Each instance of BobsChildren has ‘Bob’ as the object of its :hasParent property. someValuesFrom …that at least one object of that property is a member of the specified class. :Parent owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] . Any instance of the ‘Parent’ class has at least one child that is a Person allValuesFrom …that all objects of that property are members of the specified class :Vegetarian owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :eats ; owl:allValuesFrom :NonMeat ] . The class ‘Vegetarian’ is equivalent to the class of things that only eat nonmeat. Ancestors Note Book 101 Anexo III. Técnicas de Levantamento de Requisitos O Cartão de Volere (em inglês, Volere requirement shell). Figura 17 – Cartão de Volere comentado em Inglês No contexto deste relatório, elaborou-se a seguinte representação deste cartão. Por uma questão de adequação a equipas com membros de diferentes línguas, optou-se pelo modelo com etiquetas em Inglês, ainda que neste documento o cartão seja preenchido em Português. Requirement #: Requirement Type: Event/BUC/PUC #: Description: (Sugestão: colocar como título da subsecção, para se ver no índice.) Rationale: Originator: Fit Criterion: Customer Satisfaction: Customer Dissatisfaction: Priority: Dependencies: Conflicts: Supporting Materials: History: Criado a <data>. [Implementado a <data>.] Ancestors Note Book 102 Requirement Type: Tipo de requerimento. Colocar em relação com as secções da lista de requisitos deste documento. Por exemplo, abreviando: ● Funcional ● Dados ● Aparência ● Usabilidade ● Desempenho ● Operacional ● Manutenção/Portabilidade/Suporte ● Segurança ● Cultural/Político ● Legal Description: Descrição resumida, mas objetiva. Poderá ser colocada nomo título da secção para ser mostrada no índice do documento. Valores para Originator: ● Estado da arte (padrão de facto que se impõe) ● Brainstorming (resultante da discussão em grupo) ● Introspeção (quando nasce da nossa imaginação individual) ● Entrevista com S... ● Sr./Sra. F… ● Padrão History: Parece útil ir afixando uma etiqueta “Implementado”, quando o requisito tiver fechado o seu ciclo de desenvolvimento. Informação obrigatória: se o requisito foi descartado, e nesse caso se originou outro(s). Ancestors Note Book 103 Anexo IV. Nomenclatura de identificadores Prefixos usados em variáveis, numa inspiração com origem nas práticas do Xbase:  Simples: o o: "object". Ex.: oMyObject. o a: "array", tipicamente uma lista. o c: "character", "carateres" <=> string, str no Python. Exs.: cString, cNome. o l: "logic", "lógico" (booleano). Exs.: lSucesso, lOK. o n: "numeric", "numérico", seja inteiro ou real. Ex.: nValor. o t: "tuple" (cf. Python). o y: Prefixo para "dictionary" (cf. Python); se estabelecermos um paralelo com os objetos JavaScript, "o" também serviria. o x: "expression", qualquer tipo, o mesmo que "Unknown" no Python.  Compostos (exs.:): o ac: Prefixo para "array of character string" <=> lista de strings; ex.: acNomes. o aa: Array of arrays. o oc: "object" ou "string". Ancestors Note Book 104 Anexo V. Funções personalizadas no SPARQL do RDFLib É possível, com o RDFLib, indicar uma função para personalizar cálculos durante as questões SPARQL. A documentação chama-lhes algo como custom evaluation function, e exemplifica (em https://rdflib.readthedocs.io/en/stable/_modules/examples/custom_eval.html), mas, como referido no capítulo 6, secção Personalização RDFLib do SPARQL, este exemplo pode não ser o mais profícuo, pelo que serve o presente anexo para exemplificar como personalizar o RDFLib SPARQL para normalizar uma string para pesquisa, convertendo para minúsculas e retirando diacríticos. Lembra-se que a alternativa seria elaborar questões como a seguinte, para procurar “joao”: SELECT DISTINCT ?s ?p ?nome WHERE { ?s :nome|:designação ?nome . ?s ?p ?nome . BIND (replace(lcase(str(?nome)),'\\.',' ') as ?nome_low) . BIND (replace( replace( replace( replace( replace( replace( ?nome_low, 'ç','c'), 'ã|á|â|à|ä','a'), 'é|ê|è','e'), 'í','i'), 'õ|ó|ô|ò|ö','o'), 'ú|ü','u') as ?nome_norm) . FILTER (regex(?nome_norm,"joao",'i')) } Ao invés, teremos uma questão assim: PREFIX custom: <//custom/> SELECT DISTINCT ?s ?p ?nome WHERE { ?s :nome|foaf:name|:nomePai|:nomeMãe|:nomeCônjuge|:email|:designação ?nome . ?s ?p ?nome . BIND(custom:SPARQL_NormNome(?nome) AS ?o_norm) FILTER (regex(?o_norm,"joao",'i')) } Para que a questão possa correr com sucesso, é necessário ter o seguinte código: Em searchEng_SPARQL.py: import rdflib.plugins.sparql from SPARQL_rdflib_custom import SPARQL_NormNome rdflib.plugins.sparql.CUSTOM_EVALS['SPARQL_NormNome'] = SPARQL_NormNome E algures mais tarde a questão será executada… Mas, para funcionar, falta ainda o seguinte módulo, seja SPARQL_rdflib_custom.py: # Módulos personalizados de normalização from Lib.jg_base_iter import StdStrNorm from myNames import NormGrafiaNome_Str # Importações necessárias from rdflib.namespace import Namespace from rdflib.plugins.sparql.evaluate import evalPart from rdflib.plugins.sparql.evalutils import _eval from rdflib.plugins.sparql.sparql import SPARQLError from rdflib.term import Literal, URIRef Ancestors Note Book 105 # --- Criar antecipadamente o IRI para poupar processamento. Usado abaixo. # Namespace('//custom/') é o namespace que convencionámos para esta técnica. # Nas questões invoca-se via «custom:etc». SPARQL_StdStrNorm_IRI = URIRef(Namespace('//custom/') + 'SPARQL_StdStrNorm') SPARQL_NormNome_IRI = URIRef(Namespace('//custom/') + 'SPARQL_NormNome') # --- def SPARQL_NormNome(ctx, part) -> object: ''' Função de personalização exemplo para uso numa questão SPARQL do RDFLib. :param ctx: <class 'rdflib.plugins.sparql.sparql.QueryContext'> :param part: <class 'rdflib.plugins.sparql.parserutils.CompValue'> :return: <class 'rdflib.plugins.sparql.processor.SPARQLResult'> ''' # Esta parte trata a implementação básica de adicionar novas funções: if part.name == 'Extend': cs = [] # A informação é obtida e guardada, e passada por um gerador: for c in evalPart(ctx, part.p): lDefaultBehaviour = True if hasattr(part.expr, 'iri'): # Existe um IRI. # Isto irá verificar se foram mencionadas funções personalizadas. if part.expr.iri == SPARQL_NormNome_IRI: # Cálculos personalizados. # Primeiro, obtemos os parâmetros passados em variáveis, # por exemplo ?nome. argument1 = str(GetCustomParm(1, ctx, part, c)) # 1º parm # Este objeto será guardado como valor de saída. evaluation = Literal(NormGrafiaNome_Str( argument1, lMaisNorm=False)) lDefaultBehaviour = False elif part.expr.iri == SPARQL_StdStrNorm_IRI: argument1 = str(GetCustomParm(1, ctx, part, c)) evaluation = Literal(StdStrNorm(argument1)) lDefaultBehaviour = False else: raise NotImplementedError() if lDefaultBehaviour: # Comportamento padrão. # Entra aqui em linhas em que não existe a função/funções em causa. evaluation = _eval(part.expr, c.forget(ctx, _except=part._vars)) if isinstance(evaluation, SPARQLError): raise evaluation cs.append(c.merge({part.var: evaluation})) return cs # Tratamento padrão de erro e retorno. raise NotImplementedError() def GetCustomParm(nParmNumber, ctx, part, c): ''' Camada que obtém um objeto com o valor do parâmetro nParmNumber. ''' return _eval(part.expr.expr[nParmNumber-1], Ancestors Note Book 106 c.forget(ctx, _except=part.expr._vars))