André Luiz Almeida Marins. Modelos Conceituais para Proveniência

Transcrição

1 1 André Luiz Almeida Marins Modelos Conceituais para Proveniência Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós- Graduação em Informática da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Marco Antonio Casanova Orientador Departamento de Informática PUC-Rio Prof. Antonio Luz Furtado Departamento de Informática PUC-Rio Profª. Karin Koogan Breitman Departamento de Informática PUC-Rio Profª. Melissa Lemos Cavaliére Departamento de Informática PUC-Rio Prof. José Eugenio Leal Coordenador Setorial do Centro Técnico Científico PUC-Rio Rio de Janeiro, 18 de março de 2008

2 2 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. André Luiz Almeida Marins Graduado em Engenharia de Computação pela Pontifícia Universidade Católica do Rio de Janeiro (1996), com especialização em Gestão Executiva no Programa de Desenvolvimento Gerencial (PDG Senior Exec) pelo Instituto Brasileiro de Mercado de Capitais (2001), Atualmente é pesquisador do Laboratório Tecgraf e atua nas áreas de Banco de Dados, Proveniência e Rastreabilidade. Marins, André Luiz Almeida Ficha Catalográfica Modelos Conceituais para Proveniência / André Luiz Almeida Marins; orientador: Marco Antonio Casanova f.; 30 cm Dissertação (Mestrado em Informática) Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática. Inclui bibliografia. 1. Informática Teses. 2. Proveniência. 3. Rastreabilidade. 4. Modelagem Conceitual. 5. Alinhamento de Ontologias. I. Casanova, Marco Antonio. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título. CDD: 004

3 3 Agradecimentos Aos patrocinadores CNPQ e PUC-Rio pelas bolsas de fomento e isenção, obrigado. À Noemi, Hugo, Paulo, Costa, Gustavo, Fábio, Rosana e Eduardo pelas referências creditadas e a eterna amizade, muito obrigado! Um provérbio árabe que adaptei diz que há quatro tipos de pessoas: aquelas que não sabem e não identificam o que não sabem (tolas); algumas que não sabem e reconhecem que não sabem (humildes); outras que sabem, mas não compreendem o que sabem (aprendizes); e as que sabem e conhecem o que sabem (mestres). Às vezes, precisei me perder para me encontrar. Percebi que não sabia e, doutores-filósofos me indicaram a direção. Lutei, persisti e corrigi o percurso. Ao Marco (Casa) - professor, orientador e amigo - agradeço os ensinamentos práticos e teóricos, pessoais e profissionais. (Re)conheci pessoas incríveis que levarei comigo por toda a vida. Elegi duas que representam com louvor todas as demais não mencionadas. Daniela e Ricardo, vocês são demais. Nas horas mais difíceis assegure. Nas fáceis ratifique. Em ambas, reifique: o amor, o afeto, a amizade. O produto vira serviço exclusivo, terra fértil e água fresca para felicidade que encanta produtor e consumidor. Também registre, registre muito, registre tudo. Para que na falta de memória, a história seja preservada. Para aprender e ensinar depois de apreender. Para sorrir ou chorar, mas viver. Obrigado a minha família, minha base. Renata, você é única, voemos juntos. Rosely e Hélio, minha genética e educação tem raízes nobres em vocês. Rachel e Zuleika, duas gerações diferentes que complementam a minha e, com elas sou muito, mas muito, muito mais feliz. A todos que contribuíram para o sucesso desta pesquisa reitero: tenho a certeza que tudo é efêmero. Não obstante, as experiências que vivi, estão em meu coração e as levarei sempre comigo. Obrigado por tudo! Vamos em frente!

4 4 Resumo Marins, André Luiz Almeida; Casanova, Marco Antonio. Modelos Conceituais para Proveniência. Rio de Janeiro, p[ALAM1]. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Sistemas de informação, desenvolvidos para diversos setores econômicos, necessitam com maior freqüência de capacidade de rastreabilidade dos dados. Para habilitar tal capacidade, é necessário modelar a proveniência dos dados. A proveniência permite testar conformidade com a legislação, repetição de experimentos e controle de qualidade, entre outros. Habilita também a identificação [ALAM2]de participantes (determinantes ou aderentes) como pessoas, organizações, agentes de software entre outros e, permite associá-los a atividades, eventos ou processos. Pode ser utilizada para estabelecer níveis de confiança para as transformações dos dados. Esta dissertação propõe um modelo genérico de proveniência criado com base no alinhamento de recortes de ontologias de alto nível, padrões internacionais e propostas de padrões que tratam direta ou indiretamente de conceitos relacionados à proveniência. As contribuições da dissertação são, portanto em duas direções: um modelo conceitual para proveniência - bem fundamentado que facilita a interoperabilidade e a aplicação da estratégia de projeto conceitual baseada em alinhamento de ontologias. Palavras-chave ontologias. Proveniência; rastreabilidade; modelagem conceitual; alinhamento de

5 5 Abstract Marins, André Luiz Almeida; Casanova, Marco Antonio. Provenance Conceptual Models. Rio de Janeiro, p[ALAM3]. MSc. Dissertation - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Information systems, developed for several economic segments, increasingly demand data traceability functionality. To endow information systems with such capacity, we depend on data provenance modeling. Provenance enables legal compliance, experiment validation, and quality control, among others. Provenance also helps identifying participants (determinants or immanents) like people, organizations, software agents among others, as well as their association with activities, events or processes. It can also be used to establish levels of trust for data transformations. This dissertation proposes a generic conceptual model for provenance, designed by aligning fragments of upper ontologies, international standards and broadly recognized projects. The contributions are in two directions: a provenance conceptual model - extensively documented that facilitates interoperability and the application of a design methodology based on ontology alignment. Keywords Provenance; traceability; conceptual modeling; ontology alignment.

6 6 Sumário 1 Introdução Motivação Problema Metodologia Objetivo Planejado Realizado Organização do Texto 24 2 Contexto para Proveniência O Conceito de Proveniência Definição de Dicionário Proveniência como Metadado Dublin Core Warwick Framework ISO 19115: Linhagem Anotação l Mapeamento de Conceitos de História Proveniência e Ciclo de Vida A Sétima Pergunta de Proveniência Ontologia Parcial para Proveniência (prévia 1) Aspectos de Projetos baseados em Proveniência Ontologias de Alto Nível Preliminares DOLCE SUMO OPENCYC COSMO e o Alinhamento entre Ontologias de Alto Nível Ontologia Parcial para Proveniência (prévia 2) Padrões e Projetos cobrindo o conceito de proveniência Preliminares Padrões 51

7 ISO 14721:2003 (OAIS) ISO 21127:2006 (CIDOC CRM) Alinhamento entre Padrões e Ontologias de Alto Nível Projetos FRBRoo INDECS Harmony Alinhamento entre Projetos e o Padrão ISO FRBRoo / CIDOC CRM Harmony / CIDOC CRM Ontologia Parcial para Proveniência (prévia 3) 93 3 Modelo de Proveniência Preliminares Motivação Estratégia de Projeto (Proveniência no Centro) Tática de Projeto (PPCO) Metaproveniência Modelo Conceitual Preliminares Modelo Mínimo (3P) Classes Propriedades Expansões PO (Partial Order) TR (TRaceability TRace and TRack) RQR (Reification of Qualified Relations) DISP (Determinant, Immanent, Source Product) CH (Cultural Heritage) Aplicações do Modelo de Proveniência Preliminares Aplicações de Desktop Semântico Generalização para Design Rationale Centro de Informações Serviço de Proveniência na Web para ferramenta de Gerenciamento de Configuração de Software 151

8 Especificação do Serviço Requisitos Descrição das Operações Arquitetura Ambiente de Desenvolvimento Catálogo TDK Modelo Físico construído por Reuso e Adaptação Abstração para o Modelo Físico - Ferramenta BI Estudo da Ferramenta Trac Preliminares Mapeamento para o Modelo de Proveniência Respostas do Serviço de Proveniência na Web Conclusões Referências Bibliográficas 182

9 9 Lista de figuras Figura 1: Rastreabilidade na Cadeia Produtiva baseado em (Bechini et al., 2005) 15 Figura 2: Ontologia parcial para proveniência 20 Figura 3: Modelo conceitual genérico para proveniência (seção 3.6) 23 Figura 4: Visão de História de Mario Bunge (Ram, 2006a) 32 Figura 5: Ciclo de vida da informação (Ram, 2006a) 34 Figura 6: Ontologia parcial para proveniência (prévia 1) 36 Figura 7: Taxonomia de Aspectos de Proveniência de Dados (Simmhan et al., 2005) 38 Figura 8: Hierarquia de especialização parcial da ontologia DOLCE (Semy et al., 2004) 44 Figura 9: Hierarquia de especialização parcial da ontologia SUMO (Semy et al., 2004) 46 Figura 10: Hierarquia de especialização parcial da ontologia OpenCyc (Semy et al., 2004) 48 Figura 11: Ontologia parcial para Proveniência (prévia 2) 50 Figura 12: Detalhamento de informação de contexto (Lavoie et al., 2002) 55 Figura 13: Detalhamento de informação de proveniência (Lavoie et al., 2002) 55 Figura 14: Algumas classes do CIDOC CRM e destaque para o evento no centro 58 Figura 15: Taxonomia para E2 Temporal Entity (Doerr, 2005) 60 Figura 16: Algumas classes da ISO 21127:2006 expressas com elementos do Dublin Core baseado em (Doerr, 2005) 62 Figura 17: Representação Gráfica do CIDOC CRM Core DTD (Sinclair et al., 2006a) 65 Figura 18: Exemplo utilizando o CRM Core (Sinclair et al., 2006a) 66 Figura 19: Exemplo XML do CIDOC CRM Core (Sinclair et al., 2006a) 68 Figura 20: Relação entre projetos estudados e a ISO 21127: Figura 21: Visão Geral do Modelo FRBR baseado em (FRBR Review Group, 1998) 71 Figura 22: Instanciações para o Grupo 1 baseado em (Tillett, 2003) 72 Figura 23: Principais classes e relacionamentos INDECS adaptado de (Bearman et al., 1999) 75

10 10 Figura 24: Visão centralizada da classe Evento no modelo INDECS adaptada de (Rust & Bide, 2000) 78 Figura 25: Taxonomia para Modelo ABC baseado em (Doerr et al., 2003) 80 Figura 26: Exemplo de Instanciação do modelo ABC (Lagoze & Hunter, 2001) 82 Figura 27: Alinhamento de classes dos modelos FRBRoo e CIDOC CRM (ISO 21127:2006) baseado em (Bouef & Doerr, 2007) 85 Figura 28: Alinhamento parcial das classes dos modelos ABC e CIDOC CRM (ISO 21127:2006) baseado em (Doerr et al., 2003) 90 Figura 29: Alinhamento parcial de propriedades entre modelos ABC e CIDOC CRM (ISO 21127:2006) baseado em (Doerr et al., 2003) 92 Figura 30: Ontologia parcial para Proveniência (prévia 3) 93 Figura 31: CODeP Participation reificado (Gangemi, 2005) 101 Figura 32: Padrão de Ontologia D&S proposto em (Masolo et al., 2003) 103 Figura 33: CODeP DnS simplificado em (Gangemi, 2006) 104 Figura 34: Entidades do modelo INDECS (Rust & Bide, 2000) 108 Figura 35: A classe E52 Time-Span, outras classes e relacionamentos da ISO 21127: Figura 36: Diagrama UML com principais classes e relacionamentos do modelo conceitual e ilustrado com conceitos abstratos (Wh-questions) 116 Figura 37: Rastreabilidade na Cadeia Produtiva baseado em (Bechini et al., 2005) 126 Figura 38: Três notações gráficas para especificação de procedimentos (Sowa, 2001a) 128 Figura 39: Arquitetura Simplificada para Desktop Semântico 141 Figura 40: Arquitetura de Busca em Desktop Semântico baseada no Beagle Figura 41: Resultado de uma consulta semântica 143 Figura 42: Conceitos de Proveniência ajudam a organizar e classificar o resultado de uma consulta semântica. 144 Figura 43: Modelo Kuaba e conceitos abstratos adaptado de (Medeiros, 2006) 145 Figura 44: Modelo Funcional de um Centro de Informações adaptado da ISO 14721: Figura 45 Arquitetura do Web Provenance Service (WPS) 155 Figura 46: Principais Tabelas do Catálogo TDK Adaptado 158 Figura 47: Abstração BI para o modelo físico 160 Figura 48: Tela de Entrada do Trac 161

11 11 Figura 49: Abstração BI para o esquema do banco de dados do Trac 162 Figura 50: Rastreabilidade de ChangeSets 163 Figura 51: Referências cruzadas entre Ticket e ChangeSet apresentada no Ticket 164 Figura 52: Referências cruzadas entre ChangeSet e Ticket apresentada no Timeline 164 Figura 53: Página de Roadmap da ferramenta Trac que apresenta os milestones existentes no projeto 168 Figura 54: Resultado com todos os eventos no banco de dados de proveniência. 170 Figura 55: Eventos de Commit do Subversion que correspondem a ChangeSets 172 Figura 56: ChangeSet 1129 que concluiu o ticket # Figura 57: Tickets do Milestone Branch Figura 58: Tickets #4, #9 e #20 e respectivos IDs de participantes 175

12 12 Lista de tabelas Tabela 1: Mapeamento entre conceitos de História e Proveniência (Ram, 2006a) 31 Tabela 2: Alinhamento parcial de Ontologias de Alto Nível 49 Tabela 3: Exemplo de um pacote de informação (informação de conteúdo + informação de descrição de preservação) (NBR 15472:2007) 54 Tabela 4: Propriedades que apresentam as classes Evento, Agente e Ação como classe-domínio ou classe-imagem (ISO ). 61 Tabela 5: Alinhamento parcial sugerido entre ontologias de alto nível e padrões ISO adaptado de (Casanova et al., 2007) 69 Tabela 6: Alinhamento parcial entre modelo INDECS e FRBR baseado em (Rust, 2005) 76 Tabela 7: Detalhamento da interpretação de abstrações e manifestações do modelo INDECS baseado em (Rust, 2005) 77 Tabela 8: Conceitos de proveniência do modelo INDECS 78 Tabela 9: Alinhamento parcial entre os modelos ABC e Dublin Core adaptado de (Hunter, 2000) 82 Tabela 10: Alinhamento parcial de classes entre modelos FRBRoo e CIDOC CRM (Doerr et al., 2007) 85 Tabela 11: Hierarquia de especialização do modelo FRBRoo para a classe F11 Event 86 Tabela 12: Propriedades que representam a importância da classe Evento no modelo FRBRoo 87 Tabela 13: Propriedades que representam a importância da classe Evento no modelo FRBRoo (continuação da Tabela 12) 88 Tabela 14: Alinhamento parcial de classes entre modelos ABC e CIDOC CRM (Doerr et al., 2003) 90 Tabela 15: Alinhamento parcial de propriedades entre modelos ABC e CIDOC CRM (Doerr et al., 2003) 91 Tabela 16: Propriedades que capturariam parcialmente a noção de razão (Reason) 108 Tabela 17: Mapeamento de conceitos abstratos de proveniência 110 Tabela 18: Hierarquia parcial de especialização após descarte dos conceitos abstratos 111

13 13 Tabela 19: Descrição das Propriedades do Modelo de Proveniência 124 Tabela 20: Descrição das Propriedades do Modelo de Proveniência (parte 1 de 2) 136 Tabela 21: Descrição das propriedades da expansão (parte 2 de 2) 137 Tabela 22: Analogia entre Design Rationale e Proveniência 146 Tabela 23: Mapeamento entre conceitos do Trac em classes do modelo de proveniência 166 Tabela 24: Consulta SQL (prepared query) para a operação getobject que especifica o tipo do objeto que deve ser retornado 171 Tabela 25: Linguagem para alinhamento entre ontologias (Scharffe & Bruijn, 2005) 179

14 1 Introdução Não há ciência sem proveniência. Não é possível dar crédito a um experimento se não há como repetí-lo. Em ciência, assim como em muitos outros campos, as informações relativas às metodologias e mecanismos pelos quais os resultados são obtidos podem ser tão importantes quanto os resultados propriamente ditos. A identificação dos agentes envolvidos também é essencial. Por exemplo, em um leilão de obras de arte, as informações sobre o atual proprietário, bem como os proprietários anteriores, são extremamente relevantes para os potenciais compradores. Analogamente, em uma caixa postal abarrotada de mensagens eletrônicas, o remetente de uma mensagem é sem dúvida um filtro que determina a ordem de leitura. Esses e outros dados relacionados estão presentes ao longo do ciclo produtivo acadêmico ou de negócios e são de fundamental importância porque descrevem a origem dos dados. São metadados e representam a proveniência desses dados. O rastro desses dados gera um conjunto de metadados de proveniência intrínsecos ao ciclo produtivo. A rastreabilidade dos dados aparece como um requisito cada vez mais presente nos sistemas de informação atuais, refletindo a crescente demanda por conformidade e confiabilidade das fontes produtivas. Por outro lado, a interoperabilidade também é característica essencial e necessária ao planejamento de um sistema de informação. A capacidade de interoperar está diretamente ligada à estratégia adotada para a concepção do respectivo modelo do banco de dados. Se um sistema de informação é bem sucedido, isso significa que atende qualitativamente e quantitativamente a seus usuários. Mas, para ser estratégico, deve ser capaz de interoperar com outros sistemas existentes e futuros. Nesse caso, a adoção de esquemas (de exportação dos dados) padronizados seria uma solução mais plausível do que o alinhamento à posteriori dos esquemas. Porém, surpreendentemente, existe um considerável número de padrões que a comunidade de banco de dados parece ignorar durante a construção de novos modelos. Neste capítulo, apresentamos inicialmente a motivação desta dissertação (seção 1.1). Em seguida, descrevemos o problema de pesquisa abordado que combina as questões de proveniência e interoperabilidade e, um resumo da

15 Introdução 15 solução proposta para o problema estabelecido (seção 1.2). Detalhamos a metodologia para esta pesquisa (seção 1.3), apresentamos o objetivo planejado e realizado (seção 1.4) e, por fim, a estrutura desta dissertação (seção 1.5) Motivação A Figura 1 (Bechini et al., 2005) ilustra a cadeia produtiva de lotes (de um produto qualquer) e as atividades relacionadas à produção dos lotes. Os pequenos retângulos verticais são atividades e os círculos são lotes. Cada par (atividade, lote) pertence a um agrupamento que identifica uma etapa da cadeia produtiva. Esses agrupamentos, localizados no topo da Figura 1, são: Fornecedor, Produtor, Transformador ou Distribuidor. Neste exemplo, uma atividade precede sempre um lote que pode estar ligado também à outra atividade da cadeia produtiva. Interessa-nos rastrear os lotes que estejam relacionados a um incidente com um determinado lote, destacado no canto superior direito. Figura 1: Rastreabilidade na Cadeia Produtiva baseado em (Bechini et al., 2005) Rastrear um lote em um ponto específico da produção é determinante na identificação de outros lotes de materiais que foram utilizados como insumos.

16 Introdução 16 Isso se torna crítico para a análise do impacto ocasionado, por exemplo, pela contaminação de uma cadeia de produção de alimentos, ou mesmo pelo recall de veículos que apresentam problemas no sistema de freio. Dentro dessa mesma cadeia é indispensável a identificação de participantes (determinantes ou aderentes) como pessoas, organizações, agentes de software entre outros e, permite associá-los a atividades, eventos ou processos. Pode ser utilizada para estabelecer níveis de confiança para as transformações dos dados. Na literatura, é comum encontrarmos o conceito de rastreabilidade aplicado a objetos físicos, como é o caso na Figura 1, que trata de rastreabilidade de alimentos (food traceability). Por outro lado, o termo proveniência é usualmente utilizado para descrever a origem de dados. Interessa-nos estabelecer aqui que a capacidade de rastrear dados depende diretamente da existência da proveniência. Para compreender essa dependência, faremos uma analogia entre proveniência de dados e rastreabilidade de lotes físicos de materiais. Se ao longo da cadeia produtiva há o registro de todas as atividades que aconteceram, é possível rastrear cada lote relacionado ao incidente. Se juntamente a essas atividades há também o registro de dados que descrevem a origem de cada lote, então rastrear os dados de um determinado lote é consultar dados que descrevem a origem de cada lote. Interpretamos rastreabilidade como a capacidade de realizar consultas para rastrear a origem (trace) e rastrear o destino (track) (Dorp, 2004). Na Figura 1 as setas pontilhadas identificam a direção dessas consultas na cadeia produtiva. Ao seguir as setas a partir do lote que simboliza o incidente é possível rastrear os dados de todos os lotes relacionados. Portanto, rastrear dados é realizar consultas a proveniência. Essas consultas não são uma exclusividade da área industrial e estão presentes também em outras áreas. Por exemplo, na área de gerência de configuração de software (Staa, 2003), especificamente no versionamento de software, localizar o rastro para a origem identifica possíveis causas de um componente defeituoso. De forma complementar, identificar o rastro para o destino viabiliza a análise de impacto de componentes construídos a partir de um componente potencialmente defeituoso. Assim, aqui também é essencial consultar a proveniência sobre as diferentes versões de componentes existentes.

17 Introdução Problema Nesta seção, introduziremos o problema de modelar proveniência de um ponto de vista comum a diferentes áreas de aplicação. De acordo com a motivação exposta (seção 1.1), a rastreabilidade dos dados é uma necessidade essencial nos dias de hoje e depende da capacidade de realizar consultas a proveniência. Essas consultas por sua vez dependem da coleta e do armazenamento dos metadados de proveniência ao longo de uma cadeia produtiva. Não há atualmente um modelo de proveniência, proposto a partir de padrões existentes, que descreva uma forma genérica para esse armazenamento. Por outro lado, há diferentes áreas que se beneficiariam de um modelo deste tipo. Entre elas estão: Engenharia de Software, na demanda por rastreabilidade de requisitos, por exemplo, identificando a proveniência de artefatos que não possuam requisitos; e-science, na necessidade de repetição de experimentos, por exemplo, com a verificação dos métodos e valores utilizados e obtidos durante o processamento de um fluxo de experimentos; Industrial, na imposição de conformidade através de legislações vigentes, por exemplo, com a capacidade de consulta a proveniência dos eventos de uma cadeia produtiva atendendo a normas governamentais para o setor de produção de alimentos; Gestão de Conteúdo Digital, na auditoria e histórico de logs, por exemplo, na identificação do editor e outros dados de proveniência que descrevam o contexto das alterações de um documento digital; Preservação Digital, na preservação de documentos arquivísticos a longo prazo, por exemplo, na identificação dos eventos de arquivamento para garantir e creditar a autenticidade da fonte produtora que repassa esses documentos para arquivamento; Gestão de Projetos, na análise de tarefas realizadas contra as planejadas, por exemplo, através de consultas a proveniência de eventos considerados particularmente importantes (milestones) e rastro dos dados relativos às tarefas que contribuíram para o seu alcance.

18 Introdução 18 Um modelo é uma representação do que existe no intelecto humano como solução para um determinado problema. Como cada ser humano tem uma forma diferente de interpretar o mundo, existem diferentes modelos para o mesmo tipo de problema (Sowa, 1999). Dois modelos diferentes que propõem soluções para a representação de proveniência são sugeridos pelos projetos PASOA (Moreau & Ibbotson, 2006) e Data Provenance (Ram, 2007). Há ainda diversos outros projetos, avaliados em (Simmhan et al., 2005) e (Bose & Frew, 2005), que também estudam soluções para o problema de proveniência e propõem modelos distintos daqueles dois. Conforme discutido em (Simmhan et al., 2005), a maioria dos projetos pesquisados possui protocolos proprietários para gerenciar a proveniência e não fundamentam a sua coleta, representação, armazenamento e consulta em padrões abertos, o que, por sua vez, dificulta a interoperabilidade.[alam4] É justamente essa realidade que se apresenta como pano de fundo para a construção de novos modelos. A necessidade de interoperabilidade entre sistemas é um desafio para muitas áreas, mas é a comunidade de banco de dados, a partir da adoção de uma maior disciplina, que pode oferecer uma solução a priori. Adiantando um pouco os objetivos apresentados mais adiante (seção 1.4) descrevemos que, um resumo da solução para esse problema, deve partir de um estudo de padrões para construir um modelo de proveniência genérico. Acrescentamos que a utilização de padrões é uma das formas de promover a interoperabilidade dos sistemas de informação porque torna o problema de alinhamento de esquemas (schema matching) um problema tratável (Casanova et al., 2007). Inicialmente aprofundaremos a compreensão do conceito de proveniência e a identificação de outros conceitos que auxiliam a sua representação. Adaptamos a metodologia para a construção de padrões de projeto conceitual de ontologias para projetar um modelo genérico de proveniência, criado com base no alinhamento de recortes de ontologias de alto nível, padrões internacionais, projetos e propostas de padrões que tratam direta ou indiretamente de conceitos relacionados à proveniência. A partir da identificação de um conjunto de termos que capturam o conceito de proveniência faremos uma análise de cobertura e uso desses termos nas fontes selecionadas. O resultado obtido apresenta-se como um conjunto de conceitos unificadores que capturam a noção de proveniência.

19 Introdução 19 A solução proposta se atém à construção e representação do modelo de proveniência e a avaliação desse modelo para casos concretos (capítulo 4). Não faz parte deste trabalho, apresentar uma solução computacional para a coleta automática de proveniência. No entanto, uma sugestão para essa coleta é apresentada em aplicações para desktop semântico e em um estudo preliminar de um centro de informações (seção 4.4) Metodologia A metodologia adotada nesta pesquisa divide-se em três aspectos: metodologia de construção, de representação e de avaliação do modelo de proveniência. Cada uma delas utiliza uma mesma ferramenta cognitiva, baseada em perguntas, que (Al-Yahya, 2006) afirma que tem o objetivo de enriquecer o desenvolvimento de pensamentos críticos. As perguntas sugerem metaclasses, que convencionamos chamar de conceitos abstratos de proveniência ou simplesmente conceitos abstratos: What, How, Why, Who, Where, When e Which. A metodologia para construção do modelo de proveniência descrita aqui é adaptada da metodologia de construção de padrões conceituais (Gangemi, 2005) e (Blomqvist, 2005; Blomqvist & Sandkuhl, 2005), cujos passos em alto nível são: 1. Seleção de fontes de conhecimento: ontologias, normas, vocabulários, estruturas lingüísticas, teorias cognitivas, metodologias, melhores práticas entre outras; 2. Pesquisa transversal de invariâncias presentes nas fontes selecionadas; 3. Identificação de aproximações sintáticas e semânticas de conceitos, e fragmentos (grupo de conceitos relacionados) que cubram o conceito de proveniência, utilizando a ferramenta cognitiva; 4. Seleção e importação de fragmentos ou aproximações; 5. Anotações ao projeto do modelo, identificando a origem das importações; 6. Codificação e consolidação de conceitos; A metodologia de representação do modelo será reusar a nomenclatura da principal fonte de importação e preservar a nomenclatura das demais fontes.

20 Introdução 20 Para todas as classes e propriedades sem identificador único, um padrão similar ao da principal fonte deve ser definido. Para a representação final do modelo, os conceitos abstratos de proveniência devem ser eliminados, restando apenas os conceitos importados ou criados, temporariamente, associados aos conceitos abstratos. Após o descarte dos conceitos abstratos, é necessário identificar quais serão as classes primárias e quais movimentações de classes devem ser realizadas para satisfazer a disjunção de classes. Adicionalmente, a metodologia de representação também lança mão, ao longo da construção do modelo, de uma ontologia parcial de proveniência, utilizada meramente para facilitar a evolução do raciocínio, e não tem nenhum outro propósito além deste único. A metodologia de avaliação será a de especialização do modelo. Para a avaliação de casos concretos, devem ser utilizados dados reais. Na ausência total ou parcial deles, devem ser produzidos dados sintéticos de forma a permitir a representação do domínio em análise. Para as avaliações deve ser apresentado o mapeamento dos principais conceitos, e preferencialmente exemplos de instâncias. Nesse processo, a ferramenta cognitiva e conceitos não unânimes podem ser novamente utilizados para a construção da analogia. A Figura 2 contém a ontologia parcial para proveniência que utilizaremos para acumular os resultados parciais ao longo do caminho e que enfatiza apenas os conceitos abstratos de nossa ferramenta cognitiva. Ao longo do texto faremos três prévias (seções 2.1.6, e 2.4.4), utilizando a ontologia parcial, listando apenas as classes mais relevantes encontradas durante a pesquisa. Figura 2: Ontologia parcial para proveniência

21 Introdução Objetivo Planejado O foco de trabalho está em criar um modelo genérico para proveniência baseado em classes e relacionamentos já existentes em outros modelos conceituais. Os princípios adotados - proveniência, completude e reuso exigem que: A solução para o modelo de proveniência registre sua origem; Leve em conta um amplo contexto de proveniência para que sirva como generalização para diferentes domínios; Seja construída a partir de conceitos e idéias de fontes que são referências mundiais. Somando-se esses três pontos, o desafio do modelo é ser capaz de prover uma solução global que facilite a interoperabilidade entre sistemas que o adotam. Descrevemos os objetivos alinhados com tais princípios, como uma lista ordenada que será referenciada em nossas conclusões (capítulo 5): O1. Identificar caminhos que alavanquem o reuso e aumentem as possibilidades de integração. O2. Construir um modelo a partir do uso e da avaliação de ontologias de alto nível entre outras fontes para seleção de invariantes, fragmentos e identificação de conceitos não unânimes que cubram a noção de proveniência. O3. Identificar um padrão internacional que possa ser utilizado como referência principal para modelagem de proveniência e que tenha influenciado direta ou indiretamente outros projetos. O4. Explorar os modelos propostos em outros projetos e seus respectivos alinhamentos com o padrão internacional identificado, como forma de compreendê-los a partir de seus relacionamentos uns com os outros. De forma complementar, é preciso que os modelos ofereçam uma cobertura estrutural para proveniência. O5. Concentrar esforços nos estudos de diferentes modelos conceituais[alam5] para a construção[alam6] e avaliação do modelo conceitual genérico para proveniência.

22 Introdução 22 A partir da compreensão desses objetivos, definiremos quais reusos são possíveis e quais caminhos precisam ser explicitados, consolidando a visão[alam7] como um modelo conceitual genérico para proveniência. Não é alvo deste trabalho o desenvolvimento de uma interface para a entrada de dados manual, tampouco para coleta automática da proveniência Realizado Optamos pela apresentação (antecipada) na Figura 3 do modelo conceitual genérico para proveniência, um dos objetivos propostos para esta dissertação. Nela, o leitor encontra as metaclasses, indicadas por elipses, que são parte da ferramenta cognitiva utilizada para a construção, representação e avaliação do modelo. Os detalhes de como esse modelo foi alcançado estarão distribuídos ao longo do texto desta dissertação (Capítulos 2, 3, 4 e 5). Sugerimos ao leitor que consulte a Figura 3 sempre que necessário, como forma de ancorar a compreensão do texto. Optamos[ALAM8] por deixar a Figura 3 em uma página dedicada, apresentada a seguir, para oferecer ao leitor uma figura mais visível.

23 Introdução 23 Figura 3: Modelo conceitual genérico para proveniência (seção 3.6)

24 Introdução Organização do Texto Este texto está organizado da seguinte forma. No Capítulo 2 descrevemos inicialmente o conceito de proveniência (seção 2.1), em seguida, discutimos aspectos de projetos de proveniência (seção 2.2) e apresentamos uma análise de cobertura da noção de proveniência utilizando ontologias de alto nível (seção 2.3). Por fim, elucidamos os resultados obtidos com a avaliação análoga de projetos e padrões (seção 2.4). No Capítulo 3 apresentamos as preliminares à construção do modelo (seção 3.1), seguidas da motivação de necessidade global de recuperação de informação (seção 3.2). Então, discutimos a estratégia (seção 3.3) e a tática (seção 3.4) do projeto do modelo de proveniência. Destacamos a proveniência do modelo de proveniência (seção 3.5) e por fim descrevemos o modelo de proveniência (seção 3.6). No Capítulo 4 avaliamos o modelo de proveniência a partir de quatro diferentes domínios de aplicação. Inicialmente, as preliminares destacam a importância de uma API de serviços para proveniência e como consultas à proveniência poderiam ser estruturadas (seção 4.1). Em seguida, utilizamos dois domínios como motivação: o primeiro domínio analisa a aplicação do modelo sob a perspectiva de aplicações semânticas para desktops (seção 4.2) e o segundo domínio propõe a discussão do modelo como uma possível generalização a ser considerada para Design Rationale (seção 4.3). Em seguida, no terceiro domínio realizamos um estudo preliminar (seção 4.4) que sugere a adoção do modelo conceitual de proveniência para o desenvolvimento de um centro de informações que tem atribuições de registrar a história de um empreendimento. Por fim, concluímos nossa avaliação com o quarto domínio (seção 4.5), que utiliza dados reais de um projeto de catálogo, a partir do mapeamento da ferramenta adotada pela equipe de desenvolvimento para o gerenciamento de configuração de software. No Capítulo 5 apresentamos nossas conclusões (capítulo 5), destacamos as principais contribuições deste trabalho de dissertação e apontamos possíveis direções para trabalhos futuros.

25 2 Contexto para Proveniência O contexto para proveniência proporciona um olhar além das especificidades de domínios e sugere a adoção da modelagem disciplinada. A partir de análises de ontologias de alto nível, projetos e padrões é possível estabelecer uma base para identificação de padrões de modelagem. As análises transversais desses conteúdos heterogêneos permitem a extração de conceitos comuns para a construção de um modelo de proveniência de valor superior a uma terminologia, que pode evoluir para uma ontologia. O estudo do contexto também não tem apenas o objetivo de fornecer um conjunto de classes genéricas que atenda a diferentes domínios de aplicação, que Rocha & Edelweiss (2001) definem como framework conceitual. Os resultados esperados deste capítulo são, de fato, a identificação e análise de invariantes que capturam os conceitos de proveniência, permitindo a representação do conhecimento acerca desse tema, e a construção de uma base conceitual para sugerir um padrão de projeto que seja uma abstração para problemas que envolvam proveniência. Neste capítulo, descrevemos inicialmente o conceito de proveniência (seção 2.1). Em seguida, discutimos aspectos de projetos de proveniência (seção 2.2) e apresentamos uma análise de cobertura de proveniência utilizando ontologias de alto nível (seção 2.3). Por fim, elucidamos os resultados obtidos com a análise análoga de projetos e padrões (seção 2.4) O Conceito de Proveniência Até o momento utilizamos a definição intuitiva de que proveniência referese à origem. Mas a modelagem do conceito de proveniência está exposta a uma diversidade semântica. Moreau (2006) apresenta mais de uma centena de formas diferentes de utilização do termo proveniência. Faz-se necessária uma clara, correta e ampla definição do conceito de proveniência. Exploramos definições de dicionários (seção 2.1.1), seguida de uma apresentação do termo proveniência em alguns padrões de metadados (seção 2.1.2). Mapeamos os conceitos de H[ALAM9]istória em conceitos de proveniência (seção 2.1.3) e analisamos a proveniência e o ciclo de vida da informação

26 Contexto para Proveniência 26 (seção 2.1.4). Por fim, destacamos a sétima pergunta de proveniência (seção 2.1.5) e concluímos com uma ontologia parcial para proveniência (seção 2.1.6) Definição de Dicionário Inicialmente introduzimos a definição intuitiva de proveniência. Sua epistemologia tem a raiz no verbo Francês provenir. O Moderno Dicionário da Língua Portuguesa Michaelis apresenta a seguinte definição para proveniência: Definição : (i) lugar de onde alguma coisa provém. (ii) fonte, origem, procedência. O novo dicionário Aurélio da Língua Portuguesa define proveniência como procedência: Definição : (i) ato ou efeito de proceder. (ii) lugar donde alguém ou algo procede. (iii) origem. (iv) proveniência. O dicionário Infopédia 1 da Língua Portuguesa define proveniência como: Definição : (i) lugar donde uma coisa provém. (ii) procedência. (iii) origem. (iv) fonte. (do lat. provenientìa, part. pres. neut. pl. subst. de proveníre, «provir») Faz-se necessário um esclarecimento mais específico porque há uma sobreposição dos conceitos de proveniência e procedência. Dessas três primeiras definições, inicialmente podemos dizer que proveniência seria: fonte, origem, exatamente como se fez intuitivamente (seção 2.1). O Arquivo Nacional (2005) apresenta a noção de procedência de forma diferente da noção de proveniência. 1

27 Contexto para Proveniência 27 Definição Procedência: termo geral empregado para designar a origem mais imediata de um conjunto de documentos, quando se trata de entrada de documentos à instituição ou serviço com finalidade de custódia, efetuada por entidade diversa daquela que o gerou. Conceito distinto do de proveniência. Definição Proveniência: termo que serve para indicar a entidade que age de maneira organizada e é identificada por um nome específico, produtora de um conjunto de documentos. O intuito de destacar as duas últimas definições ( e ) é única e exclusivamente o de chamar atenção para o fato de que a noção de procedência é diferente da noção de proveniência. Os dicionários de língua portuguesa consultados definem que proveniência é procedência. Como a grande maioria das fontes pesquisadas encontra-se em língua inglesa e também como forma de esclarecer a definição de proveniência apresentada pelos dicionários de língua portuguesa optamos por complementar a seção com duas definições adicionais em inglês, mantendo sua transcrição em formato original. O dicionário inglês Oxford fornece a seguinte definição para o termo proveniência (provenance): Definição : (i) the fact of coming from some particular source or quarter; origin, derivation. (ii) the history or pedigree of a work of art, manuscript, rare book etc.; concr., a record of the ultimate derivation and passage of an item through its various owners. O dicionário americano online Merriam-Webster 2 define proveniência da seguinte forma: Definição : (i) the origin, source; (ii) the history of ownership of a valued object or work of art or literature.

28 Contexto para Proveniência 28 Todas as definições são compatíveis porque apresentam uma descrição sobre a origem, mas consideramos que as definições ainda apresentam certa especialização. Em busca de uma abstração mais adequada, exploramos o termo proveniência como descrição de um dado e, portanto, um metadado (seção 2.1.2). Nas definições também aparece a noção de história[mac10] agregando uma semântica importante ao conceito de proveniência, por isso, exploramos um mapeamento de conceitos de história nos conceitos de proveniência (seção 2.1.3). De agora até o final desta dissertação adotaremos o critério de apresentar todas as figuras em língua inglesa, preservando o conceito definido na fonte referenciada, para evitar a introdução de novos termos em português Proveniência como Metadado Buneman et al. (2000) argumenta que o termo proveniência de dados (data provenance) é usado para se referir a fontes de consultas ou a serviços baseados no processamento de resultados. Em determinadas áreas de conhecimento, é comum encontrarmos o termo linhagem de dados (data lineage, ou apenas lineage) (Melton et al., 1995), aplicado no lugar de proveniência de dados como seu sinônimo. Nesses casos, se refere à história de processamento de um conjunto dados. Bose & Frew (2005) identificam outros termos que aparecem na literatura que poderiam ser interpretados como data provenance ou data lineage: filiation, data genealogy, data set dependence, data archeology, audit trail e derivation history. Descrevemos a definição do termo que se refere à proveniência, conforme apresentado, respectivamente, nos padrões de metadados Dublin Core ( ), Warwick Framework ( ) e ISO 19115:2003 ( ). 2

29 Contexto para Proveniência Dublin Core O[ALAM11] primeiro Workshop de Metadados (Metadata Workshop) ou DC-1 (Dublin Core 1) aconteceu em março de 1995 na cidade de Dublin, Ohio, EUA. O seu resultado foi um conjunto enxuto, por limitação de escopo, de apenas quinze elementos julgados em consenso e definidos como descritores de recursos eletrônicos que passou a ser chamado de Dublin Core. Durante outros eventos com o propósito de aprofundar o estudo desse conjunto inicial ficou evidente que seria necessário acomodar outros descritores mais específicos porque os elementos originais não eram suficientes para descrever os recursos eletrônicos em todos seus aspectos. O termo proveniência (provenance) é parte dessa acomodação. Inicialmente declarado como uma propriedade do DC (Dublin Core) em 20 de setembro de , o termo provenance foi atualizado mais recentemente em 14 de janeiro de A definição oficial mais atual do termo provenance é: uma declaração de qualquer mudança de propriedade ou custódia de um recurso, desde sua criação, que seja significante para resguardar autenticidade, integridade e interpretação. [MAC12] Esse termo foi declarado como necessário porque descreve informações sobre essas mudanças e pode ajudar a selecionar um recurso ou a interpretá-lo Warwick Framework Um ano após o Workshop em Dublin (seção ), o segundo Workshop de Metadados acontecia na cidade de Warwick, UK. O Warwick Framework é resultante desse novo encontro e descreve uma arquitetura de containers para agregar logicamente, ou até fisicamente, pacotes distintos de metadados. A limitação de escopo do DC (Dublin Core) impõe naturalmente também uma limitação na cobertura do seu conjunto de descritores. Isso estimulou a identificação de outros metadados necessários a definir infra-estruturas de dados. 3 acessado em 15/01/2008.

30 Contexto para Proveniência 30 Entre esses metadados, está o de proveniência, destacado no Workshop em Warwick como um conjunto de dados que define a fonte da origem de algum objeto de conteúdo, por exemplo, a localização de algum artefato físico que teve seu conteúdo digitalizado. Opcionalmente, inclui um resumo de todas as transformações que foram aplicadas ao objeto referido. (Lagoze, 2006) ISO 19115:2003 A ISO 19115:2003 propõe um padrão de metadados para dados e serviços geográficos digitais. A norma define elementos de metadados, entre eles, o conceito de linhagem (lineage). A classe lineage é definida em ISO (2003) como informações sobre eventos ou dados de origem usados na construção do dado Linhagem Widom (2005) destaca que cada banco de dados tem uma relação (lógica) de linhagem (Lineage Relation). Acrescenta que linhagem pode ser representada como uma tupla (tupleid, derivation-type, time, how-derived, lineage-data). Nessa tupla, tupleid é a chave primária, derivationt-type corresponde ao tipo de derivação, time é tempo, how-derived representa como o dado foi derivado e lineage-data é o dado propriamente dito. Bose & Frew (2005) argumentam que o termo linhagem pode ser aplicado a itens que sejam a evolução de um produto de dados. Acrescentam ainda que há duas formas de navegação que implicam em: mover-se para a trás (backward) para descobrir produtos ou transformações ancestrais, ou mover-se para frente (forward) para descobrir descendentes. No início desta dissertação (seção 1.1) utilizamos como motivação a idéia de rastro para origem e rastro para o destino. De forma análoga temos respectivamente backward e forward lineage (linhagem para trás e para frente) (Bose & Frew, 2005) Anotação Proveniência é informação sobre a origem de um item de dado (digital). Braun et al. (2006) argumenta que nos casos onde a proveniência[alam13] é adicionada após a criação do dado, ela pode ser considerada como uma

31 Contexto para Proveniência 31 anotação. Diz-se então que o dado foi enriquecido com uma anotação. A anotação é, portanto, uma das formas de representação de proveniência. Esse e outros aspectos de proveniência são destacados mais adiante (seção 2.2) l Mapeamento de Conceitos de História Nos padrões de metadados estudados (seção 2.1.2) também se encontra o conceito de evento associado ao conceito de proveniência. Somando-se as definições de dicionários (seção 2.1.1), a essas colocações, exploramos a partir de agora, o conceito de proveniência associado ao conceito de história. De acordo com Bunge (1977), uma investigação sobre um episódio ou período histórico baseia-se em evidências, ou documentos, de eventos (Groth et al., 2006b)[ALAM14] que aconteceram no passado. Para elucidar o conceito de proveniência, investigamos as noções de história. Quando traduzidas para o contexto de dado (digital), essas noções podem ser mapeadas em perguntas simples que induzem conceitos abstratos de proveniência, semelhantes aos utilizados no modelo de proveniência proposto por (Ram, 2006a). A Tabela 1 ilustra esse mapeamento. A assim chamada matriz de perguntas (Wiederhold, 1993) tem o objetivo de ajudar a construção de questionários elucidando a proveniência dos dados. Yang et. al. (2003) [MAC15]destaca que essas são perguntas essenciais na construção de sistemas de respostas baseados em eventos. Tabela 1: Mapeamento entre conceitos de História e Proveniência (Ram, 2006a) Noção Evento (Event) Espaço (Space) Tempo (Time) Ação (Action) Agente (Agent) Pergunta O que (What) Onde (Where) Quando (When) Como (How) Quem (Who), Qual (Which) As perguntas de proveniência sobre o dado (usado no singular no seguinte sentido): Quem (Who) são os criadores, publicadores ou colaboradores? Quem tem permissões de acesso, quais são elas? Seria essa entidade confiável?

32 Contexto para Proveniência 32 Quando (When) o dado foi criado, acessado, modificado? Essa pergunta está ligada a quem acessou ou modificou o dado. Onde (Where) o dado foi reportado, ou onde está armazenado? Quais são as localizações físicas (no caso de mais de uma cópia)? Como (How) o dado foi derivado ou transformado? Essa pergunta relaciona-se à qual computação foi aplicada para transformá-lo. Quais (Which) aplicações, configurações de software ou de ferramentas foram usadas para a criação do dado. Essa questão está ligada às condições do ambiente. Qual é o dado? Qual é o evento? A Figura 4 identifica o fato gerador (evento) que desencadeia as evidências sobre o episódio ou período (creation até destruction)[alam16] a serem registrados. A elipse ilustra o conjunto de todas as situações possíveis (state of affairs 4 ) no mundo. Figura 4: Visão de História de Mario Bunge (Ram, 2006a) Para ilustrar como essas perguntas nos ajudam na captura do que aconteceu, considere o desenvolvimento de uma biblioteca de software para prover análise de navios com a proposta de simular o comportamento de embarcações ao serem submetidas a ondas, ventos e correntes marítimas. Do ponto de vista de projeto a avaliação de características e respectiva atribuição de valores e pesos são fundamentais para a seleção do pacote a ser 4 define state of affairs como: the general state of things; the combination of circumstances at a given time.

33 Contexto para Proveniência 33 utilizado por um protótipo. O registro dos dados de proveniência de cada pacote avaliado é parte dos dados que ajudam a qualificar os fabricantes. A equipe de desenvolvimento preparou um protótipo a partir do pacote selecionado de simulação de oceanos de diferentes fabricantes. O fabricante americano foi descartado porque o pacote não havia sido adotado por nenhum concorrente de mercado. Outro fabricante também foi eliminado porque seu pacote tinha menos de um ano de vida. Nesses casos, as perguntas Quem (What), Onde (Where) e Quando (When) foram fundamentais na qualificação de potenciais fornecedores. Agora, suponha que a equipe de modelagem tenha descoberto um novo padrão utilizado para construção de navios. Como o padrão foi recentemente lançado, não havia exemplos de como ele poderia ser aplicado. Em um determinado momento a equipe se deu conta que outro grupo de desenvolvedores havia utilizado o padrão em um projeto similar (com requisitos semelhantes). A equipe consultou a proveniência desses projetos para descobrir quais eventos teriam o registro de como e porque o padrão foi utilizado, para avaliar a experiência disponível anterior. Aqui é claro que perguntas de Quem, Como e Por que (Who, How e Why, respectivamente) facilitam o reuso e o compartilhamento de lições aprendidas. A partir de então, considere que dois engenheiros de testes sênior fossem responsáveis por homologar o uso da API. Ambos realizaram o mesmo teste para diferentes casos de uso. O primeiro engenheiro explorou a API para simular ondas de nível médio por um período de tempo extenso, enquanto que o segundo computou os testes registrando os resultados aplicando ondas gigantes durante um curto espaço de tempo. Esse cenário coloca em evidência a necessidade de registrar cada caminho. Usando a pergunta Como (How) para capturar os diferentes procedimentos[alam17], seria então possível compará-los. Finalmente, imagine que um analista de banco de dados tenha detectado um sério problema de desempenho relacionado a uma classe do módulo de persistência. Suponha que o erro existisse desde outubro de Ele ou algum outro recurso do projeto poderia então desejar localizar todos os artefatos que utilizaram tal classe desde então. Se fosse possível responder a perguntas Quais e Quando, haveria a possibilidade de identificar os artefatos que necessitassem ser avaliados e eventualmente corrigidos. A ilustração descrita até aqui reforça que o registro histórico dos eventos de um projeto é essencial para capturar a proveniência dos dados. Neste exemplo, identificamos várias formas de uso para proveniência: qualidade dos

34 Contexto para Proveniência 34 dados, auditoria, replicação, atribuição e descoberta de dados de caráter geral. Os dados de proveniência podem ser utilizados não apenas para uma boa gestão de um projeto, mas também para apoiar a conformidade com processos e normas. Em seguida, exploraremos proveniência do ponto de vista de ciclo de vida (seção 2.1.4) Proveniência e Ciclo de Vida Considere que proveniência é informação. Mills (2006) destaca que o ciclo de vida da informação usualmente se inicia com a captura e registro automáticos de eventos a partir de interações entre usuários e programas, seguido de um monitoramento e análise da informação por diferentes fontes e em diferentes formatos. A Figura 5 adaptada de (Ram, 2006a) ilustra tipos (taxonomias) de eventos que podem ocorrer em um ciclo de informações no contexto de projeto[mac18] e desenvolvimento de produtos. Optamos por manter os tipos em inglês (figura original) propositalmente para evitar a introdução de novos conceitos a partir das respectivas traduções para o português. Figura 5: Ciclo de vida da informação (Ram, 2006a)

35 Contexto para Proveniência 35 Boeuf (2006) define um evento como algo (What) que acontece no espaço e no tempo e provoca alguma mudança no mundo. Um evento pode envolver: pessoas, grupos, entre outros, que potencialmente desempenham um papel ativo ou passivo, por exemplo, provocando o evento, testemunhando-o ou submetendo-se a ele. Esse papel pode se referir a uma participação mais abstrata se estiver associado a criações do intelecto[mac19]. Adicionalmente, um evento ocorre no espaço e no tempo e, portanto, possui duração (Boeuf, 2006). Ancoramos o ciclo de vida de proveniência na noção de evento. Groth et al. (2006a) argumenta que o ciclo de vida de proveniência pode ser modelado como um processo com quatro fases: criação (creation), registro (record), consulta (query) e gerenciamento (manage). A primeira fase é a responsável pela descoberta de significado e criação da proveniência. A segunda fase foca no armazenamento dos metadados de proveniência para uso futuro. A estratégia de armazenamento de longo prazo para guardar os metadados de proveniência demanda um componente chamado armazenador de proveniência (provenance store) (Groth et al., 2006a). Esse componente provê persistência e gerenciamento de acesso aos metadados de proveniência. A terceira fase compreende a consulta ao armazenador de proveniência por usuários ou aplicações que desejam obter os metadados de proveniência. Em sua forma básica, o resultado da consulta seria o conjunto de metadados de proveniência. Uma consulta avançada poderia retornar dados mais elaborados derivados com a ajuda dos dados de proveniência. Finalmente, a quarta fase trata do gerenciamento do armazenador de proveniência. A principal característica dessa fase é manter os metadados de proveniência sincronizado com os respectivos dados. Esse gerenciamento cobriria o arquivamento, exclusão e descarte da proveniência. Um modelo de proveniência deve levar em conta todas essas questões (Groth et al., 2006a) A Sétima Pergunta de Proveniência Ao longo do mapeamento de conceitos de história (seção 2.1.3), uma pergunta que ainda não havia aparecido no mapeamento das noções de história que faz toda a diferença saber respondê-la é: por que (Why) o evento ocorreu? Por que um dado sofreu uma suposta transformação? Essa pergunta está intuitivamente ligada à capacidade de rastrear a sequência de idéias relacionadas.

36 Contexto para Proveniência 36 É essencial que o conceito de proveniência capture o conceito de razão (Reason), que inclui motivações como crença, desejo e intenção. Todos estes três últimos são fatores significativos e podem ser representados através do modelo Belief-Desire-Intention (Georgeff, 1999), onde crença representa o conhecimento sobre o mundo, desejo é o objetivo associado a um agente e intenção é o comprometimento de um agente com um determinado objetivo. De fato, é crucial rastrear as razões para capturar respostas para o porquê (Why) e registrar a proveniência que explica[alam20] o motivo[alam21] de uma dada criação ou transformação. Para eleger quais classes fariam parte de nosso modelo conceitual de proveniência, mais adiante (seção 2.3), aprofundaremos o estudo das perguntas de proveniência consultando ontologias de alto nível. Por hora apresentaremos a primeira prévia da ontologia parcial para proveniência (seção 2.1) que consideramos como conclusão dos assuntos explorados até aqui Ontologia Parcial para Proveniência (prévia 1) A Figura 6 apresenta um modelo conceitual parcial que utiliza a ferramenta cognitiva adotada. Figura 6: Ontologia parcial para proveniência (prévia 1) O modelo W7 (Ram et al., 2006b) também utiliza as classes abstratas que estão presentes em nossa ferramenta cognitiva. Contrapomos que as classes abstratas no modelo que estamos construindo são apenas metaclasses, enquanto que no modelo W7 (Ram et al., 2006b) as classes abstratas são

37 Contexto para Proveniência 37 classes primárias. Representamos inicialmente na Figura 6, a primeira prévia da ontologia parcial para proveniência que é parte de nossa metodologia de representação. As classes são ovais e as propriedades de objetos são arcos unidirecionais. As classes estão estratificadas em três níveis: O nível de topo, ou 1º nível, contém apenas a classe Proveniência (Provenance); O nível intermediário, ou 2º nível, contém as classes que capturam as Wh-Questions (Cheng, 1997) que representam conceitos abstratos de proveniência e são parte de nossa ferramenta cognitiva inspirada em (Wiederhold, 1993); O 3º nível contém as classes que capturam os detalhes da proveniência. Fundamentados nas seções anteriores, inicialmente assumimos que o conceito Event (uma especialização da pergunta o que ou em inglês What) é uma classe central do 3º nível, juntamente com Agent e Action e demais classes ainda não discutidas, representadas por círculos e identificadas com a marca de interrogação? na Figura 6. As classes do 3º nível deveriam idealmente ser importadas de padrões conhecidos. Os conceitos abstratos de proveniência fazem parte da ferramenta cognitiva definida para apoiar a construção do modelo de proveniência. Analogamente, apresentaremos outras prévias da ontologia parcial para proveniência (seções 2.3 e 2.4). A seguir, descrevemos aspectos de projetos de proveniência (seção 2.2). No capítulo 3, revisaremos os conceitos associados aos conceitos abstratos de nossa ferramenta cognitiva, para organizar as classes importadas para 3º nível da ontologia Aspectos de Projetos baseados em Proveniência A taxonomia de técnicas para a proveniência, Figura 7, sugere uma classificação para os esforços de pesquisa de proveniência para a área de e- Science. Destacamos que essa taxonomia oferece uma visão dos aspectos de projeto de sistemas de proveniência: porquê registram a proveniência, o que descrevem, como representam e armazenam, quais formas de disseminação de proveniência são exploradas, quais formas de uso, entre outros. Simmhan et al.

38 Contexto para Proveniência 38 (2005) afirma que a síntese resultante da pesquisa pode ajudar projetistas de sistemas de gerenciamento de metadados a compreender os projetos estudados. Destacamos aqui os aspectos que consideramos relevantes para o trabalho desenvolvido nesta dissertação. Optamos por manter os tipos em inglês na Figura 7 (figura original) propositalmente para evitar a introdução de novos conceitos a partir das respectivas traduções para o português. Ao longo do texto desta seção nos referenciamos a essa figura utilizando os termos em inglês da taxonomia apresentada. Destacamos também que as setas dessa figura indicam a direção da especialização. Os dois pequenos círculos são recursos visuais para simbolizar o nível da hierarquia das classes que estão ligadas abaixo deles e, nada mais além disso. Figura 7: Taxonomia de Aspectos de Proveniência de Dados (Simmhan et al., 2005) A pesquisa sobre proveniência (Simmhan et al., 2005) contempla projetos da área de e-science e cobre cinco diferentes domínios (ciências): geografia, astronomia, biologia, química e meteorologia. Com exceção do domínio de biologia, que teve dois projetos estudados, todas as demais ciências tiveram apenas um projeto representante. Adicionalmente, a pesquisa classifica ainda, dois projetos como genéricos da área de e-science. Iniciamos resumindo a distribuição dos tipos de arquitetura de banco de dados adotados pelos projetos (Simmhan et al., 2005), onde: quatro projetos

39 Contexto para Proveniência 39 apresentam arquitetura orientada a serviço 5, três são relacionais, um é baseado em script e outro é baseado em processamento de comandos. [ALAM22]Simmhan et al. (2005) destaca diferentes usos de dados de proveniência, como: qualidade de dados (data quality), auditoria (audit trail), replicação de experimentos (replication), atribuição de autoridade (attribution) e descoberta de dados (data discovery). A qualidade de dados pode ser estimada baseada em sua origem e nas transformações que sofre. Auditoria permite a identificação do uso de recursos e a detecção de erros. Replicação permite a repetição das derivações de dados. Atribuição estabelece propriedade, custódia, direitos e deveres. Por fim, descoberta de dados apóia a análise de contexto, que ajuda a interpretação do dado. Nos nove projetos avaliados (Simmhan et al., 2005), há duas estratégias: orientação a dado (data oriented) ou orientação a processo (process oriented). Contabilizamos cinco projetos para a primeira, três para a segunda e um que mescla ambas. Outro ponto destacado por (Simmhan et al., 2005) refere-se à granularidade de coleta da proveniência, onde apontamos que está relacionada essencialmente ao foco selecionado no intervalo definido por eventos complexos ou atômicos. Outro aspecto tratado é a representação da proveniência como anotação (annotation) ou como consulta invertida (inverse query). Na primeira, a história da derivação é representada como uma anotação associada ao dado. Por outro lado, na segunda as derivações são resultados de consultas invertidas, onde conhecendo-se o resultado, procura-se o dado de entrada que o produziu. Simmhan et al. (2005) afirma que a representação da proveniência como anotação permite um conteúdo mais rico e previamente processado, e contrapõe que a representação por consulta invertida é mais compacta, mas é processada dinamicamente. Por fim, acrescenta que a representação sintática pode adotar diferentes linguagens, por exemplo, XML ou OWL. Como praticamente metade dos projetos avaliados tem arquitetura de banco de dados orientada a serviço, nesses casos, o formato XML é uma escolha natural para a troca de dados. Mas a codificação do conhecimento semântico possibilita um uso mais elaborado da 5 Adicionalmente às operações típicas de um banco de dados relacional, em um banco de dados orientado a serviços, pode-se invocar funções definidas pelos usuários que implementam chamadas a procedimentos armazenados (stored procedures)

40 Contexto para Proveniência 40 proveniência, sendo uma base para inferências e processos de prova. (Simmhan et al., 2005) Simmhan et al. (2005) chama a atenção para o fato da proveniência poder crescer a ponto de ficar maior do que o dado que ela descreve. Por isso, apresenta questões sobre escalabilidade e overhead, que devem ser analisadas quando o volume de dados é grande, especialmente quando a coleta da proveniência respectiva é granular. A disseminação da proveniência é classificada por (Simmhan et al., 2005) de três formas: consultas (queries), grafo visual (visual graph) e API de serviços. A distribuição dos projetos nessa classificação é respectivamente quatro, quatro e um. Simmhan et al. (2005) conclui que o projeto PASOA (Moreau & Ibbotson, 2006) está na direção certa ao buscar a definição de uma API de serviços para proveniência, mas ressalta que precisa de maiores refinamentos para elucidar como a proveniência é representada e recuperada. Acrescenta ainda que qualquer padrão proposto para proveniência deve satisfazer às necessidades de múltiplos domínios, cujos requisitos necessitam ser identificados. Conclui apontando que um deles é seguramente a padronização da semântica dos termos. Simmhan et al. (2005) apresenta algumas questões ainda em aberto relativas à proveniência e os desafios que precisam ser superados para que o tema proveniência se torne permeável a diferentes comunidades. O compartilhamento de dados entre organizações é crescente, por isso Simmhan et al. (2005) destaca que é essencial que a proveniência também o seja. Acrescenta que a maioria dos projetos pesquisados possui protocolos proprietários para gerenciar a proveniência e que não fundamentam a sua coleta, representação, armazenamento e consulta em padrões abertos, o que dificulta a interoperabilidade. Com o objetivo de alcançar essa padronização, buscamos identificar fragmentos de ontologias de alto nível (seção 2.3) e apoiar a construção deste trabalho de dissertação em normas internacionais e projetos de boa reputação (seção 2.4) que permitam a representação da proveniência. As contabilizações realizadas nesta seção serão uma base para o direcionamento da pesquisa.

41 Contexto para Proveniência Ontologias de Alto Nível Preliminares Entendemos as ontologias de alto nível (do inglês Upper Level Ontologies) como fontes interessantes de padrões de modelagem porque a construção da hierarquia de classes e as propriedades de cada classe presentes nessas ontologias estão muito bem definidas. Esse rigor nos conceitos seria uma das principais vantagens do uso de ontologias de alto nível como fontes de consulta e referência para construção das classes de novos modelos conceituais. Essas consultas e referências oferecem a possibilidade de uma integração a priori (Bellatreche et al., 2006). De fato, o esforço de realizar uma boa modelagem minimiza a necessidade de uma integração a posteriori que, em geral, é sempre mais custosa e fortemente dependente do alinhamento de conceitos entre esquemas a partir do processamento e análise de suas respectivas instâncias (Brauner et al., 2006). Se as fontes de dados fossem em sua grande maioria modeladas a partir de padrões não ambíguos, estaríamos muito provavelmente minimizando o custo de integração quando uma determinada aplicação necessitasse realizar uma consulta a essas fontes, uma vez que esses conceitos teriam uma definição precisa. Mas, ainda assim, há inúmeras ontologias de alto nível e não é foco deste trabalho a análise de todas as existentes. Portanto, o primeiro passo foi selecionar três fontes que satisfizessem os critérios: Licenciamento de código aberto; Conter em suas definições os conceitos: evento, agente e ação; Existência de estudos que apresentem a avaliação em conjunto ou individual das ontologias selecionadas; Disponibilidade de consulta a arquivos em formato OWL ou qualquer outro compatível com visualizadores de código aberto. As ontologias que atenderam de forma mais adequada a esses critérios foram: a DOLCE (do inglês Descriptive Ontology for Linguistic and Cognitive Engineering) (Masolo et al., 2003), produzida a partir da metodologia (Guarino & Welty, 2002); a SUMO (do inglês Suggested Upper Merged Ontology) (Niles & Pease, 2001) modelada pelo IEEE[ALAM23] Standard Upper Ontology Working

42 Contexto para Proveniência 42 Group; e a OpenCyc 6, que é considerada a maior e mais antiga ontologia de alto nível disponível. Essas três ontologias de alto nível foram objeto de análise preliminar em (Semy et al., 2004), que qualificou a ontologia DOLCE como padrão candidato a atender ao domínio de governo americano. Semy et al. (2004) cita também outras ontologias de alto nível: BFO (Basic Formal Ontology), BWW (Bunge-Wand-Weber), GFO/GOL 7 (General Formalized Ontology/General Ontology Language), OCHRE (Object-Centered High Level Reference Ontology), e a ontologia de topo (Top Level Ontology) proposta por John F. Sowa. Adicionalmente, mencionamos também, a ontologia PUO (Proposed Upper Ontology) (Cassidy, 2003) e observamos que as ontologias BFO e OCHRE são resultantes do projeto WonderWeb 8, assim como a ontologia DOLCE. Mapear um domínio específico em uma ontologia de alto nível ou mesmo estendê-la para atendê-lo não é uma tarefa simples. Não há um padrão reconhecido amplamente e também há raras implementações que possam ser provadas (Semy et al., 2004). Essencialmente essa dificuldade é inerente a abordagens teóricas diferentes para a estrutura de construção das ontologias de alto nível. Além disso, há ausência de consenso para eleger uma referência que pudesse ser considerada a absoluta ontologia de alto nível. De todo modo, ainda é válido considerar as ontologias de alto nível porque seus conceitos são fruto de um estudo aprofundado e não ambíguo. Isto confere alguma garantia que um determinado conceito ancorado em uma ontologia de alto nível pode ser um bom começo para uma definição comprometida com o senso comum. As ontologias de alto nível oferecem uma fundamentação teórica e são boas fontes de consulta para definições de conceitos. Durante a concepção de novos modelos, essas ontologias devem ser avaliadas mesmo que um mapeamento direto, ideal, não seja adotado. No mínimo, essa avaliação reduzirá o potencial de definição de uma semântica nova para termos com a mesma sintaxe. O resultado natural desse comprometimento é uma semântica mais rica

43 Contexto para Proveniência 43 para o modelo, pelo simples fato de referenciar o senso comum que está lastreado por definições precisas pré-existentes em ontologias de alto nível. Mas existe um complicador adicional para aplicar e difundir essa prática, que é a tradução de conceitos e descrições para a língua nativa do país no qual se aplica esse exercício. Por exemplo, não há uma versão em português das ontologias de alto nível estudadas para esta pesquisa. A opção deste texto foi traduzir o mínimo necessário para garantir a sua qualidade e compreensão. Com isso, ao longo deste texto, ocorrerão termos em inglês sempre quando optamos por não traduzí-los, evitando assim a introdução de outros termos em português. Limitamo-nos apenas a descrever o termo em inglês com um texto em português para garantir a fluidez da leitura. Há ainda termos que foram deixados em seu formato original (inglês) propositalmente. A consulta às ontologias de alto nível foi feita utilizando os conceitos evento, agente e ação, a partir do mapeamento da noção de história (seção 2.1.3). Usamos ainda aproximações dos três primeiros com o propósito de realizar a identificação de invariantes (seções 2.3.2, e 2.3.4). Para exemplificar como a estrutura conceitual varia de uma ontologia de alto nível para outra, ilustraremos uma parte da hierarquia de especialização que inclui apenas a classe que representa a noção de evento. Por fim, apresentamos o alinhamento dos conceitos de proveniência entre as três diferentes ontologias selecionadas (seção 2.3.5) DOLCE A versão estudada é a 3.9 da DOLCE-Lite, acrescida de algumas extensões básicas, chamada de DOLCE-Lite-Plus ou DLP, de 28 de março de A DOLCE-Lite incorpora o resultado do relatório final D18 do projeto WonderWeb, que corresponde à documentação final e completa da DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering). A DOLCE baseia-se nos princípios da metodologia OntoClean (Guarino & Welty, 2002). A principal divisão da taxonomia é entre Perdurant (Perdurável) e Endurant (Contínuo). Os primeiros são entidades que se estendem no tempo enquanto que os segundos são entidades presentes continua e independentemente do tempo. A Figura 8 ilustra essa divisão e destaca quais instâncias da classe Endurant podem ter a propriedade espaço-temporal (PhysicalEndurant) ou não

44 Contexto para Proveniência 44 (NonphysicalEndurant). Por outro lado, especializações da classe Perdurant são instâncias da classe Event ou da classe Stative, dependendo de suas características temporais (Masolo et al., 2003). Na DOLCE, a classe Evento (Event) está no mesmo nível da classe DeEstado (Stative). A definição da classe Evento afirma que, em geral, eventos diferem de situações porque não tem uma descrição da qual dependam, ou seja, não tem um estado. Eventos podem ter uma relação sequencial dada por algum fluxo, mas não requerem uma descrição como critério de unificação. Por outro lado, é possível que se crie uma descrição que determina valores para as restrições que caracterizam um tipo de evento e, nesse caso específico, o evento seria na verdade uma situação. Outra noção de evento também investigada pela DOLCE está relacionada à idéia de mudança. Com isso, eventos poderiam ser considerados como aspectos ou partes de processos (Masolo et al., 2003). Por exemplo, o processo recuperação da mata ciliar do rio Macacú pode ser conceituado como: uma realização (o processo de recuperação como o resultado de ações prévias), um estado (se colapsarmos o intervalo de recuperação em um único ponto, contabilizando o número de árvores de mata nativa replantadas e totalizadas nesse ponto) ou como um evento (quais mudanças ocorreram que provocaram alterações em um trecho do rio levando-o de um estado para outro).[mac24] Figura 8: Hierarquia de especialização parcial da ontologia DOLCE (Semy et al., 2004) Esses diferentes aspectos podem ser mais ou menos adequados dependendo dos objetivos de representação do conceito evento: foco na causa,

45 Contexto para Proveniência 45 foco no efeito, sumarização, identificação de transições entre outros. (Masolo et al., 2003) Nem sempre é tão fácil compreender as descrições utilizadas em uma ontologia de alto nível para todos os conceitos apresentados. A compreensão de definições consome um tempo considerável da busca e análise de padrões. A classe Agente (Agent) é uma dessas classes que muitas vezes confundem ao contrário de esclarecer. Um agente identifica que algo atuou com certa ação, ou há um executor inicial ou ainda um papel foi desempenhado em uma ação. Agentes podem representar internamente descrições, planos, objetivos ou possíveis ações, mas que não necessariamente atuam. (Masolo et al., 2003) Instâncias da classe Ação (Action) exemplificam a intenção de um agente. Ações podem ser interrompidas, incompletas, abortadas e ainda assim permanecerem como uma (potencial) realização. Ter um resultado depende de um método, então uma ação ainda é uma ação mesmo se o resultado produzido é incompleto. (Masolo et al., 2003) SUMO A SUMO (Suggested Upper Merged Ontology) foi criada pela empresa Teknowledge com contribuições diretas da lista de distribuição SUO (Suggested Upper Ontology). Sua primeira versão data de 2001 e foi proposta pelo SUO Working Group para criar uma única, abrangente e concisa estrutura a partir da consolidação de outras ontologias e conteúdos de domínio público, entre eles: servidor Ontolingua 9, a ontologia de topo proposta por John F. Sowa 10, ontologias desenvolvidas pelo ITBM-CNR 11 (National Research Council, Institute. of Biomedical Technologies) e teorias mereológicas 12 (Niles & Pease, 2001). A versão 1.73 é a mais atual, mas optamos por estudar nesta seção, a versão que é considerada oficial: SUMO starter document que corresponde à versão 1.52 de 25 de Abril de Mereologia é o estudo lógico-matemático das relações entre as partes e o todo. Fonte: Tradução da definição do Webster Online.

46 Contexto para Proveniência 46 Não há a classe Evento (Event) na ontologia SUMO. Destacamos então a classe Process que é a classe de fenômenos que acontecem e tem partes ou estágios temporais. A Figura 9 apresenta a hierarquia parcial de especialização da ontologia SUMO, onde podemos identificar que há uma divisão dual entre Concreto (Physical) e Abstrato (Abstract). Repare que a classe Process está no ramo de entidades concretas. Originalmente na ontologia de topo de John F. Sowa, utilizada para a construção da SUMO, a classe Evento é uma especialização da classe Processo Discreto (DiscreteProcess) que por sua vez é subclasse de Process, esta sim, presente da Figura 9. Alguns exemplos de instâncias de Process são: eventos estendidos como uma partida de futebol ou corrida de carros, ações como ler ou escrever ou processos biológicos. A definição formal é algo que dura um período de tempo, mas não é um objeto. Vale notar que um processo pode ter participantes[alam25] que são objetos, como os jogadores da partida de futebol ou os pilotos da corrida. (Niles & Pease, 2001) Instâncias da classe Agente (Agent) são algo ou alguém que podem atuar por conta própria e produzir mudanças no mundo. Agentes têm direitos, mas podem ou não ter responsabilidades e racionalidade. Se o agente tem habilidade de racionalizar então a instância é também atribuída à classe AgenteCognitivo (CognitiveAgent). Animais são exemplos de instâncias da classe SentientAgent que é disjunta da classe CognitiveAgent. (Niles & Pease, 2001) Figura 9: Hierarquia de especialização parcial da ontologia SUMO (Semy et al., 2004) Não existe a classe Ação (Action) nessa ontologia. A classe mais próxima em nossa avaliação é IntentionalProcess, que pode ser definido como um

47 Contexto para Proveniência 47 processo que tem um propósito específico para um agente cognitivo (instância da classe CognitiveAgent) que o executa. (Niles & Pease, 2001) OPENCYC A ontologia de alto nível OpenCyc é a versão de licenciamento aberto da ontologia de alto nível Cyc comercial. A Cyc foi inicialmente desenvolvida na MCC (Microelectronics and Computer Technology Corporation) no início de 1984, construída como uma base de conhecimento do senso comum para o processamento de linguagem natural. Essa ontologia possui centenas de milhares de termos atômicos, milhares de conceitos e uma quantidade de axiomas pelo menos uma ordem grandeza maior que a quantidade de conceitos. A versão estudada é a de 14 de julho de O manuseio da ontologia, pelo seu tamanho e quantidade de classes, não é muito prático. Portanto, todas as definições desta seção são traduções dos respectivos conceitos, provenientes de consultas estruturadas realizadas à fonte Nesse imenso universo de termos e conceitos, estudamos apenas as definições para os três principais conceitos que elegemos como fragmento que captura parcialmente a noção de proveniência: Evento, Agente e Ação. A Figura 10 apresenta a hierarquia de especialização parcial da ontologia OpenCyc. A classe Evento (Event) é uma especialização da classe Situation que é por sua vez, uma especialização da classe IntangibleIndividual. Cada instância da classe Evento é algo que alguém diz que acontece. Eventos são intangíveis porque são mudanças por si só. Portanto, não são objetos tangíveis que sofrem mudanças. Alguns exemplos de especializações da classe Evento incluem: LocalizedEvent, PhysicalEvent, Action e Transfer. Eventos não devem ser confundidos com intervalos de tempo (classe TimeIntervals). A delimitação temporal de eventos, esta sim, é dada por um intervalo de tempo. Não há uma classe com o nome Agente, mas sim Agente-Genérico (Agent- Generic) que é uma especialização de algo que existe de forma estável no tempo. Cada instância da classe Agente-Genérico é um ser que tem desejos ou intenções e habilidade de agir a partir deles. Essas instâncias podem ser indivíduos ou podem consistir de vários agentes genéricos operando em conjunto como um grupo.

48 Contexto para Proveniência 48 Figura 10: Hierarquia de especialização parcial da ontologia OpenCyc (Semy et al., 2004) A classe Ação (Action) é uma coleção de eventos que são executados por uma instância da classe Executor (Doer) que descreve atores que executam eventos. Instâncias da classe Action incluem qualquer evento no qual um ou mais atores produzem uma mudança no estado do mundo, tipicamente ao despender um esforço ou energia. Não é necessário que nenhum objeto tangível seja movido, modificado, produzido ou destruído para que uma ação ocorra. Os efeitos de uma ação podem ser intangíveis (por exemplo, a intimidação de um subordinado). O executor de uma ação, tipicamente uma instância de alguma classe que é uma especialização da classe Agent-Generic não necessariamente é um ser vivo. Dependendo do contexto um executor de uma ação pode também ser um animal ou um objeto inanimado (por exemplo, uma jaca que ameaça o teto de um carro estacionado em frente ao RDC) COSMO e o Alinhamento entre Ontologias de Alto Nível A ontologia de alto nível COSMO 13 (Common Semantic Model) é uma pesquisa em desenvolvimento, conduzida pelo grupo de trabalho COSMO-WG 13

49 Contexto para Proveniência 49 (COSMO Working Group). Esse grupo é uma ramificação do grupo de trabalho ONTACWG (Ontology and Taxonomy Coordinating Working Group) que teve seu início em 05 de outubro de As definições e demais informações resumidas nesta seção são um resumo das consultas realizadas ao Wiki colab.cim3.net/cgibin/wiki.pl?cosmowg. A COSMO propõe consolidar diferentes ontologias de alto nível como OpenCyc, SUMO, DOLCE entre outras, com o objetivo de acomodar em uma única ontologia diversos conceitos muitas vezes logicamente incompatíveis. Atualmente o COSMO-WG disponibiliza o que é chamado de Hierarquia de Topo (Top Level Hierarchy) onde é possível identificar um alinhamento parcial de conceitos elementares, entre eles, aqueles que capturam parcialmente o conceito de proveniência. Este não é um alinhamento trivial porque existem diferenças estruturais por características intrínsecas a construção de cada ontologia de alto nível, como exemplificado sucintamente pelas Figura 8, Figura 9 e Figura 10. A Tabela 2 ilustra as consultas as classes Evento (Event), Agente- Genérico (Agent) e Ação (Action) da ontologia COSMO mapeadas nos conceitos abstratos de proveniência. Essas classes são definidas pelo alinhamento entre os conceitos das ontologias de alto nível (seções 2.3.2, e 2.3.4). Iniciamos neste momento o mapeamento de conceitos de proveniência nos conceitos de ontologias de alto nível. Tabela 2: Alinhamento parcial de Ontologias de Alto Nível Conceito abstrato COSMO DOLCE SUMO OpenCyc What Event Event Process Event Who Agent-Generic Agent Agent Agent-Generic How Action Action Intentional Process Action Enriqueceremos (seção 2.4) o estudo desenvolvido até aqui com os resultados obtidos a partir da análise de padrões internacionais e, também, de projetos das áreas de museologia, biblioteconomia e comércio eletrônico que possuem classes que capturam o conceito de proveniência. Por hora, exibimos uma segunda prévia (seção 2.3.6) de nossa ontologia parcial para proveniência que inclui os resultados apurados até aqui.

50 Contexto para Proveniência Ontologia Parcial para Proveniência (prévia 2) A ferramenta cognitiva (seção 1.3) utilizada para o alinhamento (seção 2.3.5) é adotada também na representação da ontologia parcial para proveniência apresentada na Figura 11. Figura 11: Ontologia parcial para Proveniência (prévia 2) A partir do alinhamento entre ontologias, associamos o conceito Agent ao conceito abstrato Who, uma vez que todas as fontes consultadas apresentaram essa invariante de alguma forma. Manteremos o conceito Evento associado à What, mas ressalvamos que a noção de processo aparece como relevante nas ontologias de alto nível, como algo que tem uma duração e tem partes (eventos). Por hora, o conceito Event apareceu quase unanimemente, mas deixamos indicado que Process poderia estar também associado à noção abstrata What. A Figura 11 apresenta então os resultados acumulados. Há dúvidas ainda quanto ao conceito de processo intencional (IntentionalProcess), mas temporariamente o associamos ao conceito abstrato How, assim como o fazemos para Action. Lembramos que a ontologia parcial apresentada nesta prévia ou em qualquer outra tem o único e somente objetivo didático e nenhum outro além deste.

51 Contexto para Proveniência Padrões e Projetos cobrindo o conceito de proveniência Preliminares O conceito de evento está diretamente relacionado ao conceito de proveniência porque é o ponto de partida para capturar evidências para registro de episódios ou períodos históricos, conforme ilustrado na Figura 4. Estudamos esse conceito, e classes relacionadas, em dois padrões e três projetos de diferentes áreas com o objetivo de identificar possíveis padrões de modelagem que poderiam nos ajudar a representar o conceito de proveniência e reforçar a direção de integração a priori. Optamos por dois padrões internacionais (seção 2.4.2) que possuem os conceitos que representam proveniência. Complementando nosso estudo descrevemos (seção 2.4.3) os projetos que apresentam estruturas e conceitos que capturam o conceito de proveniência, mas que não são declarados com o propósito de estudo da proveniência. Esses projetos guardam entre si uma relação de pesquisa interessante que potencializa a capacidade de integração a priori porque suas principais classes se alinham. Além disso, o conceito de evento em todos esses projetos assume um papel central em seus modelos. Há ainda vários outros projetos (Simmhan et al., 2005) e (Bose & Frew, 2005) relacionados ao estudo do tema proveniência, mas que não serão detalhados neste trabalho. Interessa-nos aqui apenas os projetos que adotam o conceito de evento como central porque consideramos essa característica como sendo representativa na construção da nossa solução Padrões Os padrões ISO 14 (International Organization for Standarization) são reconhecidos em dezenas de países, Brasil, Estados Unidos, Japão e outros, dentre os quais uma parte significativa optou por adotá-los como normas nacionais. Na prática são os órgãos governamentais e empresas desses países que passam a exigir a conformidade com os padrões. O conteúdo desses

52 Contexto para Proveniência 52 padrões não está disponível gratuitamente, mas podem ser adquiridos e utilizados para fins comerciais. Ainda não existe um padrão ISO publicado, especifico e dedicado a proveniência. Há apenas um único com status em desenvolvimento. O padrão ISO/NP (Data quality - Part 120: Master data: Provenance) alcançou o estágio (novo projeto aprovado) em 14 de novembro de Porém, durante o curso desta pesquisa, sua documentação ainda estava indisponível para comercialização. Esse padrão é parte da ISO 8000 em desenvolvimento, como norma de qualidade da informação. A pressão competitiva no mercado mundial - tal qual existe na área de rastreabilidade de alimentos (Bechini et al., 2005)[ALAM26] e (Dorp, 2004) - é o principal catalisador para que um padrão dedicado a proveniência seja homologado e amplamente adotado nos próximos anos. Descrevemos as classes dedicadas à proveniência contidas no padrão ISO 14721:2003 (seção ), sendo essa característica a principal razão de sua seleção na ausência de um padrão dedicado ao tema proveniência. Apresentamos as classes que capturam o conceito de proveniência (seção ) presentes no padrão ISO 21127:2006 que foi selecionado por simbolizar uma área fundamental na representação de conhecimento histórico (museologia) que tem a preocupação com o contexto da herança cultural. Finalmente, alinhamos conceitos-chave (seção ) entre esses padrões e as ontologias de alto nível estudadas (seção 2.3) ISO 14721:2003 (OAIS) Este padrão internacional, também conhecido como padrão OAIS (Open Archival Information System), foi recentemente traduzido e homologado, em 20 de abril de 2007, como a norma brasileira NBR Adotaremos nesta seção os termos traduzidos da norma brasileira para sistemas espaciais de dados e informações. A norma apresenta um modelo de referência para sistemas abertos de arquivamento de informação (SAAI). 14

53 Contexto para Proveniência 53 Os sistemas de arquivamento têm como principal objetivo preservar os documentos em seus componentes individuais (conteúdo, estrutura e contexto), bem como sua relação dentro de uma série histórica de eventos. Assim é possível reconstruir fatos, eventos ou transições com a confiança necessária. Essas são características importantes para a preservação da proveniência e do valor de prova (Thomaz, 2004). Garrett & Waters (1996) explicam que proveniência se tornou um dos conceitos de organização central da ciência moderna de arquivamento. Acrescentam que a integridade de um objeto de informação é parcialmente garantida ao rastrear de onde ele vem. Para preservar a integridade de um objeto informacional, arquivos digitais devem obrigatoriamente preservar o registro de suas origens e a sua respectiva cadeia de custódia. Atualmente, no Brasil, o Arquivo Nacional caminha na direção de adotar a NBR 15472:2007 para o desenvolvimento de seus sistemas, que têm, entre outros objetivos, preservar documentos confiáveis, autênticos e acessíveis. A CTDE (Câmara Técnica de Documentos Eletrônicos) do Conarq (Conselho Nacional de Arquivos) é um órgão nacional, que conta com colaboradores do Arquivo Nacional e define diretrizes para arquivos públicos e privados. A Carta para a Preservação do Patrimônio Arquivístico Digital 15, que alerta para a perda de patrimônio nacional e mundial, é um exemplo. A proveniência é parte importante dessa realidade e tem, na norma brasileira, descrições específicas que podem apoiar o desenvolvimento de políticas e procedimentos nessa direção. Para compreendermos a orientação da NBR 15472:2007 em relação à proveniência é necessária uma breve menção a alguns conceitos antes de focarmos nos detalhes de interesse desta pesquisa. Destacamos alguns conceitos da norma que aparentemente utiliza o conceito de informação como dado. Com isso, sugerimos ao leitor que interprete informação como dado ao longo desta seção. Por exemplo, informação de proveniência propomos que seja interpretado como dado de proveniência. De acordo com a ABNT (NBR 15472)[ALAM27], informação[mac28] de proveniência (provenance information) documenta o histórico de um conteúdo. Essa informação[mac29] relata a origem ou a fonte da informação de conteúdo,

54 Contexto para Proveniência 54 sua custódia e mudanças desde a sua produção. Por exemplo, o pesquisador principal que registrou os dados e a informação sobre seu arquivamento, manuseio e migração. Segundo a ABNT (NBR 15472), a informação de conteúdo é o conjunto de informações-alvo original da preservação. É um objeto de informação composto por seu objeto de dados de conteúdo e sua informação de representação. Por exemplo, uma simples planilha de previsão de vendas, representada, e entendida como, cotas de vendas, mas que não inclua a documentação que explica seu histórico e origem, seus relacionamentos com outros objetos (a informação de descrição de preservação). A ABNT (NBR 15472) acrescenta que a informação de descrição de preservação é composta por informação de referência, de proveniência, de contexto e de fixidez explicados mais adiante. A Tabela 3 exemplifica essas classificações, considerando um pacote de software como a respectiva informação de conteúdo. Tabela 3: Exemplo de um pacote de informação (informação de conteúdo + informação de descrição de preservação) (NBR 15472:2007) Referência é a identificação da informação de conteúdo que inclui uma forma unívoca, não ambígua de identificação, por exemplo, o número de série. Fixidez - traduzida na NBR 15472:2007 para português do termo Fixidity da ISO 14721: pode ser entendida como um mecanismo de identificação para que o objeto de informação de conteúdo não seja alterado de forma não documentada. Em maior detalhe, destacamos nas Figura 12 e Figura 13 os conceitos relacionados às duas informações de descrição de preservação 15 Publicada pelo Conarq e UNESCO em 2005

55 Contexto para Proveniência 55 restantes, contexto e proveniência. Apresentamos também as associações com os conceitos abstratos de proveniência. Why Which Figura 12: Detalhamento de informação de contexto (Lavoie et al., 2002) Note que Evento é um conceito central e que a representação do conceito abstrato Where, apesar de não estar presente na figura, poderia estar associado ao conceito Nota (note) relacionado a um Evento.[ALAM30] What Figura 13: Detalhamento de informação de proveniência (Lavoie et al., 2002) Lavoie et al. (2002) destaca que Origin, Pré-Ingest, Ingest, Archival Retention e Rights Management são tipos de eventos. Portanto, o evento é um elemento central para a captura da informação de proveniência. Destacamos que entre outros atributos de um evento estão Procedure, Responsible Agency, Date e Note, que respectivamente poderiam ser mapeados para os conceitos abstratos How, Who, When e Where. A informação de proveniência tem um aspecto temporal (When) intrínseco compatível com a necessidade de registrar todos os eventos relacionados a um objeto de informação de conteúdo, desde sua criação, se estendendo até o seu estado corrente. Então, a informação de proveniência descreve a informação de conteúdo como uma entidade dinâmica. Garrett & Waters (1996) afirmam que o objeto de conteúdo pode ser visto como

56 Contexto para Proveniência 56 resultante de um processo evolutivo, onde o período que se refere à fase de arquivamento pode corresponder apenas a uma pequena parte de seu histórico. Acrescentam ainda que a informação de proveniência pode ser considerada um metadado baseado em eventos (What), que deve registrar particularidades dos eventos, bem como respectivos impactos no objeto de informação de conteúdo. No contexto de preservação digital, a motivação para registrar a informação de proveniência está na necessidade ou requisito de documentar os procedimentos e resultados de processos arquivísticos, ou seja, registrar as ações (How). Posicionar tais processos no contexto do ciclo de vida do objeto de informação significa idealmente considerar a história prévia desse objeto, registrando a informação de proveniência correspondente ao período anterior à submissão à entidade arquivística. Portanto, qualquer entidade, de um modo geral, deve se preocupar com o registro da proveniência para a preservação da integridade da informação. Documentar o que acontece com o objeto de informação está intimamente relacionado a documentar o contexto (Garrett & Waters, 1996) como forma de integridade. O contexto inclui as dimensões: técnica (software, hardware, métodos, normas etc), relacional (relacionamentos com outros objetos) (Which), espacial (Where), racional (Why) entre outras. Garrett & Waters (1996) ressaltam que a história prévia à admissão do objeto de informação pela entidade arquivística pode ser contada sob três perspectivas: pessoal, corporativa e acadêmica. Considere que uma mensagem de correio eletrônico sob essas três perspectivas. No contexto estritamente pessoal, pode conter uma piada ou anexo humorístico. Um indivíduo produz e relaciona objetos de informação que dizem respeito à sua vida privada, a deveres e responsabilidades assumidos, ou mesmo ao seu modo de vida. A responsabilidade da entidade arquivística centra-se na capacidade de estabelecer a proveniência de forma concisa, que identifique univocamente o indivíduo como a fonte dos objetos (Who) e que rastreie a cadeia de custódia até ao momento prévio à admissão do objeto (Garrett & Waters, 1996). Por outro lado, uma mensagem eletrônica pode ser o veículo para o contexto da comunicação formal e expressa, por exemplo, na troca de documentos entre chefe e subordinado, e vice-versa. O desafio nesse caso é estabelecer a proveniência dos objetos de informação de forma a preservar a interpretação de políticas e processos, bem como de responsabilidades

57 Contexto para Proveniência 57 representadas pelos sistemas de informação, produtos e serviços comercializados. Por fim, na perspectiva acadêmica, o conteúdo pode representar o resultado de um fluxo de trabalho de um experimento em desenvolvimento. Rastrear os objetos de informação científicos significa identificar os elementos que instrumentalizaram sua produção e descrever as características de projeto das ferramentas utilizadas. Garrett & Waters (1996) destacam que para representar o contexto, diferentes eventos devem ser descritos e que múltiplas ocorrências do mesmo evento seriam aquelas que apresentam as mesmas entradas e saídas. A extensão de um evento poderia incluir as informações de equipamentos, software e especificações, entre outras, que são utilizadas durante sua ocorrência. Acrescentam ainda que o resultado de um evento pode ser a geração de um novo objeto de informação, que deve ser igualmente preservado pela entidade arquivística. Uma forma de preservar é pensar os metadados de proveniência como transcendentes a representações para manifestações físicas de um objeto de informação, aplicando a idéia de obra, que é um conceito abstrato para representar uma coleção de objetos que guardam entre si algo em comum. Conceitos abstratos que poderiam ser considerados adequados para estender a norma são os conceitos de Conceptual Object ou Work apresentados mais adiante (respectivamente nas seções e ) e harmonizados logo em seguida (seção ) ISO 21127:2006 (CIDOC CRM) Ainda não há uma iniciativa nacional voltada à tradução do padrão ISO 21127:2006 como uma norma brasileira, analogamente a ISO 14721:2003 (seção ). A ISO foi homologada em setembro de 2006, mas sua origem data de Em 1996, nascia o projeto de um modelo orientado a objeto, desenvolvido como Modelo de Referência Conceitual (CRM - Conceptual Reference Model) pelo Grupo de Padrões de Documentação (Documentation Standards Group) do Comitê Internacional de Documentação (CIDOC - International Committee of Documentation) do Conselho Internacional de Museus (ICOM - International

58 Contexto para Proveniência 58 Council of Museums). Esse modelo passou a ser conhecido abreviadamente como CIDOC CRM. A motivação do CIDOC CRM (atualmente na versão 4.2.2) - e principal papel do padrão equivalente ISO 21127: é servir de base para mediação de informações de herança cultural. O modelo essencialmente provê uma semântica comum, necessária para que as inúmeras fontes locais e distribuídas de registro cultural documentem seu acervo de forma adequada, preservando-o como um valioso bem global. A ISO 21127:2006 pode ser interpretada como uma ontologia onde os conceitos e relacionamentos são aqueles relevantes para a documentação de heranças culturais. É um modelo extenso, com dezenas de classes e centenas de relacionamentos. (Doerr et al., 2006) A Figura 14 representa uma visão muito simplificada de algumas classes desse padrão. Os retângulos representam classes e as setas representam relacionamentos. As interseções entre os retângulos e algumas elipses - conceitos abstratos de proveniência - identificam os possíveis alinhamentos. Figura 14: Algumas classes do CIDOC CRM e destaque para o evento no centro Na Figura 14 destacam-se quatro tipos diferentes de nomeação: Time Appellation, Actor Appellation, Place Appellation e Appellation. As três primeiras são especializações da última. Qualquer classe do modelo pode estar relacionada a uma instância da classe Appellation ou de sua especialização, e podem ser nomes próprios, frases ou códigos, significativos ou não.

59 Contexto para Proveniência 59 O conceito de proveniência Como (How) está inicialmente associado à classe Atividade (Activity), que é uma especialização da classe Event (Evento) presente na Figura 14. Crofts et al. (2007) adota o critério de letras maiúsculas seguidas imediatamente de números para representar os identificadores únicos de classes e propriedades. A Figura 15 ilustra a taxonomia para a classe E2 Temporal Entity da qual fazem parte a classe E5 Event e a classe E7 Activity, apresentando sempre ao lado do nome da classe o seu identificador global exatamente como o fizemos neste parágrafo. As setas indicam a direção de especialização. A Tabela 4 destaca as propriedades de classes Event, Actor e Activity do modelo CIDOC CRM respectivamente relacionadas aos conceitos de proveniência Evento, Agente e Ação. A cobertura das propriedades dessas classes equivale a 21% do total de propriedades existentes no modelo. Optamos[ALAM31] por deixar a Figura 15 em uma página dedicada, apresentada a seguir, para oferecer ao leitor uma figura mais visível.

60 Contexto para Proveniência 60 Figura 15: Taxonomia para E2 Temporal Entity (Doerr, 2005)

61 Contexto para Proveniência 61 Tabela 4: Propriedades que apresentam as classes Evento, Agente e Ação como classedomínio ou classe-imagem (ISO ). Id Nome da Propriedade Classe-Domínio Classe-Imagem P12 occurred in the presence of (was present at) E5 Event E77 Persistent Item P16 - used specific object (was used for) E7 Activity E70 Thing P11 - had participant (participated in) E5 Event E39 Actor P carried out by (performed) E7 Activity E39 Actor P transferred title to (acquired title through) E8 Acquisition E39 Actor P transferred title from (surrendered title through) E8 Acquisition E39 Actor P custody surrendered by (surrendered custody through) E10 Transfer of Custody E39 Actor P custody received by (received custody through) E10 Transfer of Custody E39 Actor P1 is identified by (identifies) E1 CRM Entity E41 Appellation P131 - is identified by (identifies) E39 Actor E82 Actor Appellation P49 has former or current keeper (is former or current keeper of) E18 Physical Thing E39 Actor P50 - has current keeper (is current keeper of) E18 Physical Thing E39 Actor P51 has former or current owner (is former or current owner of) E18 Physical Thing E39 Actor P52 - has current owner (is current owner of) E18 Physical Thing E39 Actor P74 has current or former residence (is current or former residence of) E39 Actor E53 Place P75 possesses (is possessed by) E39 Actor E30 Right P76 has contact point (provides access to) E39 Actor E51 Contact Point P105 right held by (has right on) E72 Legal Object E39 Actor P107 has current or former member (is current or former member of) E74 Group E39 Actor P109 has current or former curator (is current or former curator of) E78 Collection E39 Actor P15 was influenced by (influenced) E7 Activity E1 CRM Entity P16 - used specific object (was used for) E7 Activity E70 Thing P17 - was motivated by (motivated) E7 Activity E1 CRM Entity P134 - continued (was continued by) E7 Activity E7 Activity P19 Was intended use of (was made for) E7 Activity E71 Man-Made Thing P20 Had specific purpose (was purpose of) E7 Activity E7 Activity P21 had general purpose (was purpose of) E7 Activity E55 Type P125 used object of type (was type of object used in) E7 Activity E55 Type

62 Contexto para Proveniência 62 Não identificamos nenhuma classe específica que pudéssemos destacar como representante do conceito abstrato Por que (Why). Entretanto há algumas propriedades que poderiam representar esse conceito, com seu identificador marcado em negrito na Tabela 4. A classe E2 Temporal Entity é disjunta da classe E77 Persistent Item. Instâncias da classe E77 Persistent Item têm uma existência limitada no tempo, mas preservam sua identidade entre eventos, como são as intâncias da classe E39 Actor que é uma especialização da classe E77 Persistent Item. A classe Atividade (E7 Activity) compreende ações intencionais executadas por instâncias da classe Ator (E39 Actor) que resultam em mudanças de estado documental de sistemas culturais, sociais ou físicos. A noção inclui ações complexas, compostas, de curta ou de longa duração que vão do simples fechamento de uma porta a toda uma guerra. (Crofts et al., 2007) Alguns exemplos de instâncias da classe E7 Activity são: a Batalha de Estalingrado, a Conferência de Yalta de 1945; a celebração do meu aniversário 12 de junho; a conclusão da escrita (E65) da dissertação Modelos Conceituais para Proveniência ; a formação (E66) do grupo de pesquisa do projeto de um Centro de Informações. Destacamos na Figura 16 um exemplo de classes do padrão ISO 21127:2006 expressas com termos do Dublin Core (seção ). Figura 16: Algumas classes da ISO 21127:2006 expressas com elementos do Dublin Core baseado em (Doerr, 2005)

63 Contexto para Proveniência 63 A representação gráfica da Figura 16 utiliza dois retângulos, um acima do outro. O retângulo de cima contém o identificador único e o nome da classe no padrão ISO 21127:2006. O retângulo debaixo destaca em negrito os nomes dos elementos do Dublin Core e atribui valores de exemplo a cada elemento, logo após o caracter : (que é apenas um separador). As setas unidirecionais com ou sem descrições representam relacionamentos do modelo ISO 21127:2006. A ISO[ALAM32] (2006) e Doerr et al. (2007).contém todas as propriedades do modelo CIDOC CRM distribuídas nas seguintes colunas: Identificador Único da propriedade (Property id), Nome da Propriedade (Property Name), Entidade - Domínio (Entity Domain) e Entidade - Imagem (Entity Range). O conjunto básico de elementos do Dublin Core é limitado (Martin, 1998). Quando o objetivo é representar, de forma mais precisa, a noção de evento e seus relacionamentos, o Dublin Core não oferece uma estrutura de termos suficiente para capturar relacionamentos mais sofisticados e descrever resenhas de fatos históricos. Por outro lado, a ISO 21127:2006 (CIDOC CRM) exige um grande esforço para representação por conter uma grande quantidade de classes e relacionamentos. Entre esses dois extremos existe um subconjunto da ISO 21127:2006, conhecido como CIDOC CRM Core, ou apenas CRM Core. Sinclair et al. (2006b) argumenta que o CRM Core é um subconjunto condensado de elementos de metadados da ISO :2006 que captura os relacionamentos fundamentais que conectam fenômenos (things), conceitos (concepts), pessoas (people), tempo (time) e lugar (place), e modela precisamente informações (herança cultural) baseadas em eventos. Por ser condensado, o CRM Core é mais fácil de ser aplicado do que a ISO :2006, preservando a compatibilidade com essa norma. CRM Core não é apenas um formato para elementos de metadados para descoberta de recursos, mas também um esquema simples de resenha de fatos históricos (Sinclair et al., 2006b). Assim como expressamos algumas classes da ISO 21127:2006 como termos do Dublin Core, é possível fazer o mesmo para todo o conjunto de classes do CRM Core, pois é um subconjunto d[alam33]e classes bem mais conciso. Sinclair (2006) e Doerr (2005) destacam que o CRM Core permite explorar o fato de que os metadados sobre a criação, uso ou descoberta constituem fatos históricos comparáveis às informações encontradas nos respectivos documentos propriamente ditos. A Figura 17 é uma representação gráfica para o CIDOC

64 Contexto para Proveniência 64 CRM Core, onde se identificam as classes que representam os principais relacionamentos: Identificação (Identification, Description): permite estabelecer a relação entre identificadores únicos e um ou mais nomes (appellations) ou títulos para esses identificadores; Classificação (Classification e todas as classes terminadas em _Type): classifica os recursos em tipos a partir de tesauros ou vocabulários controlados. Por exemplo, o tesauro Getty Art and Architecture Thesaurus 16 (AAT); Participação (Participation, Event, Role_in_Event, Date, Place): identifica a participação de pessoas e objetos em eventos. Relaciona itens persistentes a entidades temporais e cria uma noção de História; Decomposição de partes (has_part, part_of): permite a representação de relacionamentos do tipo todo-parte (whole-part). Por exemplo, representar uma coleção que consista de um número de objetos, ou um evento que é parte de um evento maior; Referências (Event_Related, refers_to, is_referred_to_by, Relation_To): são referências entre objetos de informação e qualquer item do mundo real. Por exemplo, um evento referencia outro evento com uma ordem específica que não estritamente a cronológica; Similaridade (show_features_of): permite representar similaridade ou influências entre objetos e, atividades (activities) ou produtos (products) e vice-versa. Por exemplo, uma porcelana Coreana contemporânea de uma porcelana Chinesa, pode mostrar traços e formas similares à Chinesa. Optamos[ALAM34] por deixar a Figura 17 em uma página dedicada, apresentada a seguir, para oferecer ao leitor uma figura mais visível. 16

65 Contexto para Proveniência 65 [ALAM35] Figura 17: Representação Gráfica do CIDOC CRM Core DTD 17 (Sinclair et al., 2006a) Optamos[ALAM36] por deixar a Figura 18 em uma página dedicada, apresentada a seguir, para oferecer ao leitor uma figura mais visível. 17 Document Type Definition

66 Contexto para Proveniência 66 Figura 18: Exemplo utilizando o CRM Core (Sinclair et al., 2006a)

67 Contexto para Proveniência 67 A Figura 18 é um exemplo de representação, utilizando o CIDOC CRM Core, de documentos históricos que tem a si e entre si eventos relacionados. Sem o relacionamento entre os eventos, não seria possível compreender completamente a história apenas com os documentos. Portanto, associados os documentos tem mais valor que meramente agrupados isoladamente. Nessa figura, há seis fotos e um documento texto, totalizando sete objetos de informação representados com classes e relacionamentos do CRM Core. N[ALAM37]esse exemplo, cada objeto se refere a um documento (imagem ou texto) e contém uma lista de classes, cada uma com um valor de instanciação. A foto mais à esquerda refere-se ao evento Crimea Conference, que representa a produção de uma conferência. O documento texto, identificado por seu conteúdo parcial, mais ao topo e centralizado, se refere a outro evento, Agreement, que representa a criação do documento texto. O primeiro evento tem uma relação (composto por) com o segundo e permite interpretar que o documento texto foi criado como resultado da conferência identificada na foto. Há ainda, na Figura 18 três participantes-chave, nos eventos, que estão destacados como as fotos de líderes de estado dos respectivos países organizadores e associados a ambos os eventos. Há também duas fotos de dois locais, Yalta e Crimea, respectivamente a cidade e a república da Ucrânia. A cidade está associada a ambos os eventos e representada como parte da república. Observamos neste ponto que um conjunto de objetos e relacionamentos, modelado segundo o padrão ISO 21127:2006, pode ser representado em XML. A Figura 19 exemplifica a descrição do objeto informacional mais à esquerda da Figura 18. A representação da Figura 19 corresponde ao modelo CIDOC CRM Core e descreve a foto 18 da Figura 18, que registra o evento da conferência. Note que vários dos relacionamentos possíveis do CIDOC CRM Core estão presentes na Figura 19. Por exemplo, um evento possui participantes, data e local, que podem ser identificados pelo aninhamento dos respectivos elementos XML <Participant>, <Date> e <Place> dentro do elemento <Event>. 18

68 Contexto para Proveniência 68 Figura 19: Exemplo XML do CIDOC CRM Core (Sinclair et al., 2006a) As classes da ISO 21127:2006, ou seu subconjunto[alam38] CIDOC CRM Core, permitem a criação de uma rede global e interligada de conhecimento, a partir da representação de fatos históricos, tendo como elementos fundamentais eventos e relacionamentos. Algumas dessas classes estão associadas com os conceitos abstratos de proveniência. Apresentamos o alinhamento dos conceitos (seção ) de proveniência Evento, Agente e Ação entre ontologias de alto nível (seção 2.3) e os padrões internacionais (seção 2.4.2) Alinhamento entre Padrões e Ontologias de Alto Nível Casanova et at. (2007) propõe que a modelagem de um banco de dados federado pode utilizar a estratégia a priori de alinhamento de esquemas e sugere o registro da passagem das obras de arte por seus proprietários. Destaca que o projeto do modelo pode começar pela análise de diferentes ontologias de alto nível (seções 2.3.2, 2.3.3, e 2.3.5), que incluem conceitos de proveniência como evento, agente e ação. De fato, a proveniência de obras de arte pode ser modelada como uma sequência de eventos resultante de ações de compra e venda em leilões, executadas por agentes como artistas, colecionadores ou museus. A partir desses conceitos, um esquema comum pode

69 Contexto para Proveniência 69 ser adotado pelos bancos de dados da federação para publicar dados que descrevam a proveniência das obras de arte. (Casanova et at., 2007) Outra alternativa para a modelagem do esquema é a simples adoção de um fragmento de um padrão internacional como a ISO 14721:2003 (seção ), que oferece classes específicas para o conceito de proveniência, ou como a ISO 21127:2006 (seção ), adequada para representação de fatos históricos. Tabela 5: Alinhamento parcial sugerido entre ontologias de alto nível e padrões ISO adaptado de (Casanova et al., 2007[ALAM39]) Conceito abstrato ISO (2006) ISO (2003) COSMO DOLCE SUMO OpenCyc What Event Event Event Event Process Event Who Actor Responsible Agency Agent- Generic Agent Agent Agent- Generic How Activity Procedure Action Action Intentional Process Action Projetos Os projetos estudados e apresentados nesta seção possuem duas propriedades: O conceito Evento assume um papel de destaque em relação às demais classes; Há referências cruzadas entre os projetos ou alguma influência direta ou indireta da ISO 21127:2006; Para cada projeto apresentado, iniciamos sua respectiva seção com uma descrição como introdução, seguida de destaques com visões gráficas ou tabelas dos conceitos mais representativos. Identificamos e analisamos também quais são os conceitos abstratos de proveniência presentes e como estão associados às classes em evidência. O modelo do projeto CIDOC CRM (seção ) serviu como base para pesquisas em diferentes domínios. A Figura 20 sinaliza a influência direta ou indireta da ISO 21127:2006 (seção ) nos projetos estudados (seções , e ).

70 Contexto para Proveniência 70 CIDOC CRM ( ISO 21127) Museum IFLA FRBR (ER x OO 2003-presente) Library DC/INDECS ( ) - E-commerce Harmony Project (ABC Model) ( ) Generic Figura 20: Relação entre projetos estudados e a ISO 21127: FRBRoo O grupo de pesquisa de requisitos funcionais para registros bibliográficos (FRBR - Functional Requirements for Bibliographic Records) da IFLA (International Federation of Library Associations and Institutions) atuou em duas fases durante o desenvolvimento do projeto do modelo de referência. A primeira ocorreu entre 1991 e 1995 com o objetivo de pesquisar possíveis codificações para conceitos que capturassem uma visão generalizada do universo de catalogação e pesquisa para bibliotecas (locais públicos ou particulares onde se instalam grandes coleções de livros e outros objetos bibliográficos, para uso público ou particular). Entre 1996 e 1998, o projeto, em sua segunda fase, dedicou-se à produção de um modelo ER 19 (Entidade e Relacionamento). Desenvolvido com objetivo de se tornar um modelo de referência, é abreviadamente conhecido como FRBR. (FRBR Review Group, 1998). Carlyle (2006) destaca que o modelo FRBR é uma continuação e uma extensão natural dos modelos usados na catalogação bibliográfica. A Figura 21 apresenta uma visão geral do FRBR com seus três grupos de entidades e 19 CHEN, Peter P. The Entity-Relationship Model:Toward a unified of data. ACM transactions on Database Systems, n. 1, p. 9-36, 1976.

71 Contexto para Proveniência 71 principais relacionamentos. As interseções entre os retângulos e algumas elipses identificam os alinhamentos entre os conceitos abstratos de proveniência e as entidades do modelo FRBR (ER). Figura 21: Visão Geral do Modelo FRBR baseado em (FRBR Review Group, 1998) Silveira (2007) descreve os 3 grupos da Figura 21: Grupo 1: são entidades bibliográficas como produtos de trabalho intelectual ou artístico: Obra (Work), Expressão (Expression), Manifestação (Manifestation) e Item (Item). Grupo 2: são entidades responsáveis pelo conteúdo, produção, disseminação e guarda das entidades do primeiro grupo: Pessoa (Person) e Entidade Coletiva (Corporate Group). Grupo 3: servem como assuntos (Subject) de uma obra: Conceito (Concept), Objeto (Object), Evento (Event) e Lugar (Place). Um assunto por ser também qualquer entidade do Grupo 1 ou do Grupo 2. A Figura 22 traduzida de (Tillett, 2003) - ilustra um exemplo para instâncias do Grupo 1 que captura o núcleo de representação de um objeto bibliográfico e que se divide em imaterial (Work/Expression) e material

72 Contexto para Proveniência 72 (Manifestation/Item). Uma Obra (Work) é uma entidade abstrata e não se refere a nenhum material físico propriamente dito, tampouco a uma linguagem de representação. A realização de uma Obra é representada por uma Expressão, que é na verdade a forma artística ou intelectual, a linguagem adotada para expressar a obra. Quando uma Expressão é fisicamente materializada existe uma Manifestação em algum meio: áudio, vídeo, papel, tela, ambiente etc. Por fim, um Item é definido como uma entidade concreta e se refere a uma ou mais cópias de um mesmo objeto físico. Figura 22: Instanciações para o Grupo 1 baseado em (Tillett, 2003) O conceito de proveniência Quando (When) está presente apenas como o atributo data (date) em algumas entidades do modelo, como Work, Expression, Manifestation, Person e Corporate Group. Do Grupo 2 a entidade Person possui os atributos nomes, datas e títulos e, a entidade Corporate Group possui nome, número, lugar e data. As entidades do Grupo 3 possuem cada uma apenas um único atributo chamado termo. Um termo é uma palavra, frase ou grupo de caracteres usado para designar a entidade. Uma entidade do Grupo 3 pode ser designada por mais de um termo, por exemplo, o termo de um evento pode ser Conferência de Yalta ou 2ª Guerra Mundial. Por outro lado, é possível identificar atributos, em algumas entidades, que estão diretamente ligados à idéia de proveniência. A entidade Obra (Work), por exemplo, possui o atributo Contexto da Obra que representa o contexto histórico, social, intelectual ou qualquer outro no qual a obra foi concebida e que pode ajudar a responder o porquê (Why) de sua produção. Já à entidade Item

73 Contexto para Proveniência 73 (Item) pertence o atributo Proveniência do Item, que corresponde ao seu registro histórico de propriedade ou custódia. Doerr et al. (2007) afirma que a representação temporal oferecida pelo modelo FRBR ER é insuficiente. De fato, não há atributos ou relacionamentos suficientes para capturar o contexto bibliográfico dentro de uma visão histórica mais representativa. Além disso, o modelo é centrado no item (Item) bibliográfico, entidade do Grupo 1, e não no evento (Event) (entidade do Grupo 3 que pode ser definida apenas como o assunto de uma Obra). Entidade temporal, ou perdurant em ontologias de alto nível (seção 2.3.2), é um conceito central para o modelo CIDOC CRM (seção ) porque é através de instâncias de classes do tipo dessa entidade que o modelo permite relacionar (Tabela 4) objetos físicos ou não, eventos, intervalos de tempo, ações e agentes. Em 2003, um grupo para conduzir a harmonização dos modelos FRBR e CIDOC CRM (International Working Group on FRBR/CIDOC CRM Harmonization) foi constituído com representantes de ambas as comunidades com os objetivos (Doerr et al., 2007): Expressar o modelo FRBR com conceitos, ferramentas, mecanismos e convenções oferecidos pelo modelo CIDOC CRM; Alinhar ou mesclar os modelos para construir uma solução para a interoperabilidade semântica entre as estruturas de representação para bibliotecas e museus; Se satisfeitos os dois objetivos, toda informação sobre herança cultural que tenha alguma equivalência deve poder ser recuperada a partir de noções comuns, de forma independente de sua distribuição por distintas fontes de dados. Em 2006 foi publicada então a primeira versão, v.0.6.7, do modelo FRBR orientado a objeto, abreviadamente FRBRoo, como resultado de uma rígida interpretação lógica das entidades, atributos e relacionamentos expressos no modelo FRBR original. (Doerr et al., 2007). As entidades temporais (Temporal Entities) foram introduzidas no modelo FRBRoo (Doerr et al., 2007) através da declaração de algumas de suas classes como subclasses das seguintes classes do modelo CIDOC CRM: E65 Creation, E12 Production e E13 Attribute Assignment. Com isso, o modelo FRBRoo passa a ter uma representatividade para a pergunta Quando (When) antes existente apenas como atributos que não capturavam intervalos de tempo.

74 Contexto para Proveniência 74 Apresentaremos os principais conceitos do projeto DC/INDECS (seção ) e destacaremos como o projeto FRBR o influenciou INDECS O projeto INDECS (Interoperability of Data in E-Commerce Systems) (Rust & Bide, 2000) durou 17 meses, entre 1998 e 2000, e teve como objetivo integrar várias iniciativas de diferentes setores da economia. Bearman et al. (1999) destaca que algumas das iniciativas pesquisadas incluem projetos da indústria fonográfica IFPI 20 (International Federation of the Phonographic Industry), como o ISRC 21 (International Standard Recording Code), iniciativas da área audiovisual, como o ISAN 22 (International Standard Audiovisual Number), e da área de produção textual, como ISBN 23 e ISSN 24, trabalhos da Organização Internacional de Propriedade Intectual WIPO 25 (World Intellectual Property Organization) e, por fim, o projeto DOI 26 (Digital Object Identifier). Foram pesquisados nessas iniciativas, diversos padrões e ferramentas comuns que habilitassem a interoperabilidade de identificadores e metadados. Como resultado final, foi proposto um framework de metadados que representasse a propriedade intelectual no contexto de comércio eletrônico. Esse framework está fundamentado na dicotomia conceito/percepção. Divisões do mundo em dois grandes grupos datam da época de Platão que propunha a divisão entre essência e matéria. As ontologias de alto nível (seção 2.3) mais recentemente formalizam tais dualidades, criando diferentes divisões: material/imaterial, concreto/abstrato, durável/perdurável, entre outras possíveis, e que podem considerar a representatividade do tempo, adotando uma representação no espaço 4D, ou não, adotando uma representação no espaço 3D International Standard Serial Number disponível em

75 Contexto para Proveniência 75 O modelo INDECS possui três entidades elementares: Conceito (Concept), Percepção (Percept) e Relação (Relation). Conceito é algo concebido no cérebro. Percepção é algo captado por pelo menos um dos cinco sentidos (Rust, 2005). A classe Relation é responsável por estabelecer uma ligação entre quaisquer duas ou mais entidades. [MAC40]Esse exemplo nos parece um erro de modelagem porque sugere que todos os relacionamentos binários estariam abaixo de uma única classe do modelo. A documentação disponível para consulta não fornece detalhes suficientes para que essa decisão de projeto seja compreendida, portanto, discutida mais aprofundadamente. [ALAM41] A[ALAM42] Figura 23 destaca elementos Being, Thing, Time e Place - do modelo INDECS que se relacionam a partir do Evento. Seres (instâncias da classe Being) e fenômenos (instâncias da classe Thing) são percebíveis. Time é a noção de tempo e Place, a de lugar. As elipses identificam os conceitos abstratos de proveniência e não fazem parte da figura original. Os eventos são como uma cola entre todas as demais entidades, por isso, desempenham um papel central. Ou seja, aparentemente[alam43], eventos são modelados como relacionamentos quaternários, reificados para instâncias de uma classe.[alam44] Figura 23: Principais classes e relacionamentos INDECS adaptado de (Bearman et al., 1999) 27 Rust (2005) chama atenção para a influência representação de entidades bibliográficas e seus respectivos relacionamentos - do modelo FRBR (seção ) no modelo INDECS. Acrescenta que manifestações artísticas ou 27 As imagens desta fonte estão protegidas por Copyright. As utilizamos aqui amparados por

76 Contexto para Proveniência 76 intelectuais e seus respectivos objetos físicos (itens) podem ser generalizados através de abstrações. No modelo INDECS, o conceito Manifestation representa algo percebível, que pode ser transiente (Performance) ou persistente (Fixation). Rust (2005) destaca que essa interpretação é uma atualização para a versão apresentada na conclusão do projeto INDECS em 2000, onde o termo manifestation era originalmente usado apenas para referenciar manifestações fixas. Os conceitos Performance e Fixation foram adotados no padrão MPEG-21 RDD (Rights Data Dictonary), DOI e Mi3P (Music Industry Integrated Identifiers Project). Por isso, o modelo INDECS foi atualizado para incluir esses conceitos. A nova leitura permite alinhar, na Tabela 6, os respectivos conceitos presentes no modelo FRBR. Originalmente, no modelo FRBR (seção ), uma manifestação é tida como algo material. Entretanto, estudos mais recentes (Doerr et al., 2003) esclarecem que a interpretação mais adequada é que uma manifestação deve ser algo abstrato. Tabela 6: Alinhamento parcial entre modelo INDECS e FRBR baseado em (Rust, 2005) Interpretação Criações Conceituais (classes) Criações Percebíveis (indivíduos) Conceito do modelo INDECS Abstraction Performance Fixation Conceito do modelo FRBR Work Expression Manifestaion Item As criações conceituais e percebíveis são instâncias da classe Thing (Figura 23). A compreensão dos conceitos Abstraction, Performance e Fixation pode ser alcançada pelo exemplo destacado na Tabela 7, que ilustra em suas últimas 2 linhas uma cadeia de manifestações que levam ao registro de respectivas abstrações.

77 Contexto para Proveniência 77 Tabela 7: Detalhamento da interpretação de abstrações e manifestações do modelo INDECS baseado em (Rust, 2005) Abstração (Abstraction) Manifestação (Manifestation) Performance Fixation Entidade Conceito Percepção Percepção Temporalidade Atemporal Transiente Persistente Estrutura Pensamentos Eu concebi Ações Eu executei Átomos/Bits Eu produzi Exemplo de Performance, Abstração e Re- Performance (3) O nome temporário da canção (4) O título oficial (1) Anotar as cifras de uma canção (5) Executar a canção. Gravar a canção. (2) O papel com as anotações (6) O CD com a canção gravada Os números (1) a (6) nas últimas linhas da Tabela 7 ilustram a sequência cronológica típica de como uma performance, que se desdobra em uma abstração, pode por sua vez desencadear outras performances. A Figura 24 é um detalhamento da Figura 23, apresentando de forma consolidada as três visões do framework INDECS. Essas visões não estão detalhadas nesta seção porque essencialmente representam as entidades (conceito, percepção e relação) sob três aspectos diferentes (visão geral, comercial e de propriedade intelectual) (Rust & Bide, 2000). A Figura 24 realça a importância dos eventos e identifica os conceitos abstratos de proveniência. Ressaltamos que a Figura 24 é de 2000, portanto, anterior a discussão que apresentamos nesta seção. Na definição original, o conceito manifestation era usado apenas para referenciar manifestações fixas. Fazendo uma leitura mais atual (Rust, 2005) da Figura 21 interprete expression como performance, manifestation troque por fixation. Com a ajuda da Tabela 7 é possível identificar outros conceitos de proveniência que não estavam evidentes (How e Why). De forma implícita, Performance é uma subclasse de Event, assim como acontece no modelo CIDOC CRM, e guarda a estrutura de ações (How). Já as abstrações, por representarem pensamentos, poderiam ser uma boa fonte para explicar (Why) as manifestações transientes e persistentes do modelo INDECS.

78 Contexto para Proveniência 78 Figura 24: Visão centralizada da classe Evento no modelo INDECS adaptada de (Rust & Bide, 2000) 28 Tabela 8: Conceitos de proveniência do modelo INDECS Conceito abstrato What Who How When Where Which Why Conceito do modelo INDECS Event Party Performance Time Place Abstraction A Tabela 8 propõe o alinhamento entre conceitos abstratos e conceitos que capturam a proveniência do modelo INDECS.[ALAM45] 28 As imagens desta fonte estão protegidas por Copyright. As utilizamos aqui amparados por

79 Contexto para Proveniência Harmony O projeto Harmony é fruto de uma parceria internacional entre a Universidade de Cornell, o DSTC (Australian Distributed Systems Technology Centre) e o ILRT (Institute for Learning and Research Technology) da Universidade de Bristol. O projeto durou 3 anos, entre meados de 1999 e 2002, com um propósito genérico e, foi influenciado pela norma[alam46] ISO 21127:2006 (seção ), pelo projeto FRBR (seção ) e pelo projeto INDECS (seção ). Wiseman et al. (1999) destaca que o objetivo do projeto Harmony foi investigar os aspectos relevantes para descrever recursos multimídia complexos, armazenados em bibliotecas digitais, através da colaboração entre comunidades que estudam padrões de metadados e da pesquisa de um modelo conceitual para representar estruturas complexas e seus respectivos relacionamentos. O modelo conceitual de uma biblioteca digital deve ser projetado para armazenar e recuperar recursos multimídia complexos, que combinam componentes de texto, imagem, áudio e vídeo. Investigar princípios e conceitos comuns a diferentes projetos é a base para compreender e analisar vocabulários e modelos de metadados. Lagoze & Hunter (2001) afirmam que os resultados dessas investigações, são entre outros, a construção de um guia conceitual para comunidades que projetam novos modelos e de uma metodologia para mapeamento entre diferentes esquemas de banco de dados. Lagoze & Hunter (2001) elucidam que os projetistas de metadados frequentemente necessitam oferecer consultas que incluam atributos de múltiplas entidades e que cubram perguntas sobre quem é responsável pelo que, quando e onde. Com isso, um modelo de metadados deve prover uma fundamentação lógica para raciocínio temporal e relacionar consistentemente agentes, ações e transições de objetos ao longo do tempo. A recuperação desse tipo de informação envolve noções que capturam a proveniência. A Figura 25 apresenta a taxonomia do modelo conceitual ABC, criado a partir do projeto Harmony, lado-a-lado com os conceitos abstratos de proveniência, representados com elipses.

80 Contexto para Proveniência 80 Figura 25: Taxonomia[ALAM47] para Modelo ABC baseado em (Doerr et al., 2003) Observando a Figura 25 note que o modelo ABC também representa os conceitos Work, Manifestation e Item. Esses conceitos são importados do modelo FRBR, que os amadureceu e consolidou ao longo de vários anos de pesquisa (seção ). Um item pode representar alguma ferramenta ou objeto que foi utilizado durante um evento. Na Figura 25 a classe Manifestation está representada como subclasse de Artifact e a classe Work como uma subclasse de Abstraction. Lagoze & Hunter (2001) destacam que tempo e transições não são frequentemente representadas em modelos centrados em recursos, como são os modelos da área de biblioteconomia tradicional (seção ). Lagoze (2000) aponta que a modelagem centrada em recursos (resource-centric) é inadequada em muitos contextos: Em museologia, transições temporais de um objeto (descoberta, classificação, história) são essenciais; Em arquivologia, onde proveniência de um objeto é crucial para estabelecer integridade; Em propriedade intelectual, onde perguntas como quem fez o que, onde e quando são essenciais para registro de propriedade.

81 Contexto para Proveniência 81 Lagoze & Hunter (2001) ressaltam que os diversos modelos centrados em recursos são inadequados para expressar entidades como pessoas, lugares, idéias e especialmente transições temporais. O modelo ABC inclui as noções de Evento (Event) e Situação (Situation)[ALAM48], que capturam respectivamente transições e propriedades existenciais. Lagoze & Hunter (2001) acrescentam que ambas foram adicionadas ao modelo porque estão fundamentadas em modelagem de processos (Petri Nets) e extensões temporais para lógica de primeira ordem (Situational Calculus). Os conceitos abstratos de proveniência What, Who, How estão associados (Figura 25) respectivamente às classes Event, Actuality (superclasse de Agent) e Action. No modelo ABC, eventos marcam a transição de uma situação para outra e sempre possuem a propriedade temporal. Já as instâncias da classe Situation têm sua duração definida implicitamente pelos eventos que a precede e sucede. Agentes são instâncias da classe Agent que estão presentes durante um evento ou são executores de alguma ação, podendo ser pessoas, instrumentos, organizações etc. Por fim, ações permitem modelar o conhecimento de envolvimento e responsabilidade de agentes em eventos e denotam um verbo no contexto de um evento. A propriedade hasaction tem classe-domínio Event e classe-imagem Action.[ALAM49] O modelo ABC então é capaz de representar períodos de tempo onde essas e outras entidades se relacionam. As entidades podem apresentar algumas propriedades estáticas e os eventos são transições que alteram propriedades de algumas entidades. Há duas facetas para entidades do modelo ABC, a universal e a existencial, que equivalem respectivamente aos conjuntos de propriedades globais e transientes. A Figura 26 é uma ilustração gráfica da representação do evento (EV0) correspondente ao nascimento de uma pessoa, onde estão envolvidos três agentes (pai, mãe e o obstetra). O evento precede o fato universal que a criança é do sexo feminino e ao existencial que identifica seu peso. Imagine ainda outros eventos, por exemplo, um evento (EV1) que sucederia a situação (ST0) e que representaria a saída dos pais e da criança do local onde a mãe deu a luz. Ressaltamos que a influência do projeto INDECS no modelo ABC pode ser evidenciada em sua capacidade de extensão. Hunter (2002) avaliou a importação de classes dos padrões MPEG-7 (descrição de conteúdo multimídia) e MPEG-21 (INDECS/RDD, veja seção ) para estender o modelo ABC e

82 Contexto para Proveniência 82 torná-lo capaz de representar e recuperar objetos multimídia e respectivos dados sobre propriedade (direito autoral e intelectual). Figura 26: Exemplo de Instanciação do modelo ABC (Lagoze & Hunter, 2001) A preocupação com interoperabilidade também é uma característica do modelo ABC, pois durante seu desenvolvimento foram exploradas técnicas para alavancar o alinhamento e a representação de seus metadados, a partir de metadados de outros modelos. Tabela 9: Alinhamento parcial entre os modelos ABC e Dublin Core adaptado de (Hunter, 2000) Conceitos do ABC Event.Title Event.Description Event.Type Event.Identifier Time Place Action/Agent Situation Artifact/Situation Elementos do Dublin Core Title Description Type Identifier Date Coverage Creator Publisher Contributor Source Relation

83 Contexto para Proveniência 83 A tradução direta de um esquema de banco de dados em outro quase nunca é trivial e esbarra em desafios sintáticos e semânticos, bem como de expressividade. A Tabela 9 é um exemplo de um possível alinhamento parcial entre o modelo ABC e quase todos os conceitos elementares do Dublin Core. Para este exemplo, considere que a classe Event tenha os seguintes atributos: Title, Description, Type e Identifier. Em seguida, destacamos o alinhamento (seção ) entre os modelos do projeto FRBRoo (seção ) e da ISO 21127:2006 (seção ). Por fim apresentamos alguns resultados do esforço de colaboração que se estabeleceu entre o projeto Harmony e a ISO 21127:2006 (seção ), destacando o alinhamento de suas classes e propriedades (seção ) Alinhamento entre Projetos e o Padrão ISO O modelo orientado a objeto FRBR reutiliza muitas classes da ISO 21127:2006 (CIDOC CRM), bem como nomenclaturas dessa norma. Por exemplo, suas classes E4 Period e F11 Event alinham-se diretamente. No projeto INDECS 29 (INteroperability of Data in E-Commerce Systems), as cinco principais classes se relacionam umas com as outras a partir da classe Evento, que é central ao modelo. Todos esses três projetos analisam o processo de como os fenômenos (things) se transformam e não se limitam à sua interpretação e representação. Acima de tudo, desejam expressar as transformações ao longo do tempo. Por isso, todos definem prioritariamente a descrição de relacionamentos como a base para seus metadados. O projeto Harmony 30 - modelo ABC - é influenciado por todos esses três projetos. O modelo ABC é motivado por bibliotecas digitais, mas propõe-se a ser genérico. Destacamos os alinhamentos dos conceitos (seções e ) oriundos dos projetos que foram influenciados diretamente pela ISO 21127:2006, não nos limitando ao conceito Evento, mas incluindo também outros conceitos associados aos conceitos abstratos de proveniência. 29

84 Contexto para Proveniência FRBRoo / CIDOC CRM Doerr et al. (2007) argumenta que os modelo FRBR ER e OO continuam a coexistir: o primeiro com propósitos pedagógicos, enquanto que o segundo está voltado ao desenvolvimento de aplicações governadas por ontologias. O modelo FRBRoo está em desenvolvimento e, atualmente, está disponível na versão 0.8.1c. Doerr et al. (2007) apresenta 41 classes (pág. 17) e 56 propriedades (pág. 20 e 21), que mapeiam o modelo de entidaderelacionamento original. Além dessas, o modelo orientado a objeto re-usa 44 classes (pág. 87) e 45 propriedades (pág. 88) do modelo CIDOC CRM (Doerr et al., 2007). O padrão de identificação das classes do modelo FRBRoo é semelhante ao adotado no modelo CIDOC CRM. As classes definidas têm seu identificador começado pela letra F e as propriedades têm sua identificação iniciada com a letra R. Essas letras correspondem respectivamente às letras E e P da convenção adotada pelo CIDOC CRM. (Doerr et al., 2007) O modelo FRBRoo é um pouco menor que o modelo CIDOC CRM, mas ainda assim exige um grande esforço cognitivo pois apresenta um quantidade de classes e propriedades da ordem de centenas. A Figura 27 apresenta o alinhamento entre as principais classes dos modelos FRBRoo e CIDOC CRM. Destacamos ao lado de cada classe os conceitos de proveniência associados (Bouef & Doerr, 2007). A Tabela 10 destaca as classes do modelo FRBRoo alinhadas diretamente com as classes do modelo CIDOC CRM. As classes F1 Work, F2 Expression, F4 Manifestation Singleton e F5 Item do modelo FRBRoo (Figura 27) - correspondentes às entidades do Grupo 1 no modelo FRBR ER (seção ) - não têm alinhamento direto com classes do modelo CIDOC CRM, mas são respectivamente especializações das classes importadas E28 Conceptual Object, E73 Information Object, E24 Physical Man-Made thing e E84 Information Carrier. 30

85 Contexto para Proveniência 85 Figura 27: Alinhamento de classes dos modelos FRBRoo e CIDOC CRM (ISO 21127:2006) baseado em (Bouef & Doerr, 2007) Tabela 10: Alinhamento parcial de classes entre modelos FRBRoo e CIDOC CRM (Doerr et al., 2007) FRBRoo F11 Event F8 Person F9 Concept F7 Corporate Body F13 Name F12 Place F10 Object CIDOC CRM E4 Period E21 Person E28 Conceptual Object E74 Group E41 Appellation E53 Place E18 Physical Thing A Tabela 11 apresenta a hierarquia de especialização do modelo FRBRoo para a classe F11 Event (E4 Period). As classes em negrito são classes nativas do modelo FRBRoo e as demais foram importadas parcialmente do modelo CIDOC CRM. Parcialmente aqui quer dizer que foram mantidas apenas as

86 Contexto para Proveniência 86 propriedades estritamentes essenciais ao domínio de bibliotecas, eliminando as demais. Tabela 11: Hierarquia de especialização do modelo FRBRoo para a classe F11 Event E4 E5 E7 F52 E11 E12 F31 F40 F44 E13 F33 F36 F37 E65 F30 F31 F55 F45 Period = F11 Event Event Activity Performance Modification Production Expression Creation Carrier Production Event Reproduction Event Attribute Assignment Identifier Assignment Representative Manifestation Assignment Representative Expression Assignment Creation Work Conception Expression Creation Recording Event Publication Event A partir das classes identificadas em negrito na Tabela 11, destacamos nas Tabela 12 e Tabela 13 as propriedades relacionadas, criadas no modelo FRBRoo, ratificando a importância do conceito de evento. As propriedades das Tabela 12 e Tabela 13 correspondem a 50% das propriedades novas criadas para o modelo FRBRoo.

87 Contexto para Proveniência 87 Tabela 12: Propriedades que representam a importância da classe Evento no modelo FRBRoo Id Nome da Propriedade Classe-Domínio Classe-Imagem R64 performed (was performed in) F52 Performance F50 Performance Plan R45 created (was created by) F31 Expression Creation F4 Manifestation Singleton R49 created a realisation of (was realised through) F31 Expression Creation F46 Individual Work R38 produced things of type (was produced by) F40 Carrier Production Event F3 Manifestation Product Type R39 followed (was followed by) F40 Carrier Production Event F39 Production Plan R40 used as source material (was used by) F40 Carrier Production Event F41 Publication Expression R41 produced (was produced by) F40 Carrier Production Event F5 Item R59 reproduced (was reproduced by) F44 Reproduction Event E84 Information Carrier R60 produced (was produced by) F44 Reproduction Event E84 Information Carrier R24 assigned to (was assigned by) F33 Identifier Assignment E1 CRM Entity R25 assigned (was assigned by) F33 Identifier Assignment F14 Identifier R26 used constituent (was used in) F33 Identifier Assignment F13 Name

88 Contexto para Proveniência 88 Tabela 13: Propriedades que representam a importância da classe Evento no modelo FRBRoo (continuação da Tabela 12) Id Nome da Propriedade Classe-Domínio Classe-Imagem R52 used rule (was the rule used in) F33 Identifier Assignment F16 Identifier Rule R53 assigned (was assigned by) F36 Representative Manifestation Assignment F4 Manifestation Singleton R31 assigned to (was assigned by) F36 Representative Manifestation Assignment F2 Expression R32 assigned (was assigned by) F36 Representative Manifestation Assignment F3 Manifestation R33 assigned to (was assigned by) F37 Representative Expression Assignment F21 Complex Work R34 assigned (was assigned by) R16 carried out by (performed) R17 carried out by (performed) R21 initiated (was initiated by) F37 Representative Expression Assignment F36 Representative Manifestation Assignment F37 Representative Expression Assignment F30 Work Conception F1 Work F2 Expression F28 Bibliographic Agency F28 Bibliographic Agency R22 created (was created by) F31 Expression Creation F2 Expression R45 created (was created by) F31 Expression Creation F4 Manifestation Singleton R created a realisation of (was realised through) F31 Expression Creation F46 Individual Work recorded (was recorded through) F55 Recording Event E7 Activity created (was created through) F55 Recording Event F56 Recording realised (was realised through) F55 Recording Event F53 Recording Work created production plan (was created by) F45 Publication Event F39 Production Plan

89 Contexto para Proveniência 89 Um evento deixa de ser apenas um assunto que descreve, através de um termo, uma obra bibliográfica para ser representado pela classe F11 Event, que é uma especialização da classe E2 Temporal Entity do modelo CIDOC CRM, relacionando conceitos de Agente (E49 Actor) e Ação (E7 Activity) (seção ). Estas últimas duas classes são classes importadas também para o modelo FRBRoo Harmony / CIDOC CRM O modelo ABC do projeto Harmony pode ser entendido como uma extensão compatível com o modelo CIDOC CRM (seção ), onde todos os estados devem ser explicitados. Doerr et al. (2003) comenta que o resultado das sete reuniões ao longo de um ano de trabalho entre membros de ambos os projetos é fruto de um processo conciso e comprometido ontologicamente com a harmonização dos conceitos. Ambos os modelos se propõem a oferecer uma representação de mudanças ao longo do tempo. Entretanto, a natureza dessa mudança é entendida de forma distinta por cada um deles. O modelo ABC foca a atenção em como os objetos mudam ao longo de um período, enquanto que o modelo CIDOC CRM pretende representar as mudanças de contexto e atribuições, sem necessariamente focar atenção a mudança do objeto propriamente dita. Outra diferença importante é que a classe E39 Actor do modelo CIDOC CRM descreve que a noção está associada a uma pessoa ou grupo durante sua existência. Já o modelo ABC define que agentes - instâncias da classe Agent - são fases (phaseof) de uma pessoa ou máquina atuando durante um evento. As definições não são iguais, mas cada uma isoladamente parece lógica. A pergunta é: qual é a definição mais apropriada e em qual contexto? O esforço de harmonização ou apenas de alinhamento é possível, mas árduo. Doerr et al. (2003) identifica aproximações entre os principais conceitos desses modelos e propõe equivalência entre algumas de suas classes (Tabela 14) e propriedades (Tabela 15). Dentre os resultados do projeto Harmony que influenciaram alterações no projeto CIDOC CRM (seção ), Doerr et al. (2003) salienta que as classes Abstraction e Actuality correspondem à classe Persistent Item (ou endurants) no modelo CIDOC CRM.

90 Contexto para Proveniência 90 Tabela 14: Alinhamento parcial de classes entre modelos ABC e CIDOC CRM (Doerr et al., 2003) ABC Entity Temporality Event Action Artifact Place Time CIDOC CRM Entity Temporal Entity Event Activity Man-Made Object Place Time-Span Além dos alinhamentos (classes consideradas equivalentes), existem outros resultados interessantes da harmonização entre esses modelos, como a ratificação da interpretação da classe Manifestation como conceito abstrato (conforme já destacado na seção ). Figura 28: Alinhamento parcial das classes dos modelos ABC e CIDOC CRM (ISO 21127:2006) baseado em (Doerr et al., 2003) A Figura 28 apresenta a taxonomia harmonizada e inclui as classes que não tem alinhamento direto, complementando os alinhamentos identificados pela

91 Contexto para Proveniência 91 Tabela 14. As classes são representadas como retângulos e os arcos simbolizam a direção da generalização[alam50]. Os nomes das classes da Figura 28 são apresentados iniciados pelo seu respectivo identificador. Para o modelo ABC o identificador é fixo e igual a ABC:. Por exemplo, ABC: Entity é a classe mais geral do projeto Harmony. Para o modelo CIDOC CRM (ISO 21127:2006) o identificador começa com a letra E seguida imediatamente de um número único. Por exemplo, E1 CRM Entity é a classe mais geral desse modelo. Quando ambos os nomes estão dentro do mesmo retângulo significa que estão alinhados diretamente. Quando estão em retângulos diferentes ligados por uma seta significa a sugestão de harmonização proposta. Por fim, a classe E77 P. I. é a abreviação da classe E77 Persistent Item. Tabela 15: Alinhamento parcial de propriedades entre modelos ABC e CIDOC CRM (Doerr et al., 2003) ABC hasparticipant haspresence destroys creates usestool CIDOC CRM hadparticipant occurred in the presence of took out of existence brought into existence used specific object A[ALAM51] Figura 29 apresenta a harmonização das propriedades e inclui as propriedades que não tem alinhamento direto, mas que complementam as apresentadas na visão destacada pela Tabela 15. As classes são representadas como retângulos e as propriedades como ovais. Se as classes estão alinhadas diretamente, então estão dentro do mesmo retângulo. As classes adotam a mesma nomenclatura descrita para a Figura 28. Analogamente, os nomes das propriedades na Figura 29 são apresentados iniciados pelo seu respectivo identificador. Para o modelo ABC o identificador é fixo e igual a ABC: e as propriedades começam com letra minúscula. Por exemplo, ABC: involves é uma propriedade do modelo. Para o modelo CIDOC CRM (ISO 21127:2006) o identificador da propriedade começa com a letra P seguida imediatamente de um número único. Por exemplo, P12 ocurred in the presence of (was present at) é uma propriedade do modelo CIDOC CRM que na harmonização é sugerida como propriedade mãe da propriedade ABC: involves. As setas que ligam duas classes ou duas propriedades identificam a direção de generalização. As setas

92 Contexto para Proveniência 92 que ligam uma classe a uma propriedade ou uma propriedade a uma classe respectivamente identificam a origem da classe-domínio e o destino da classeimagem onde opera a propriedade. Figura 29: Alinhamento parcial de propriedades entre modelos ABC e CIDOC CRM (ISO 21127:2006) baseado em (Doerr et al., 2003) O modelo ABC - ao contrário do modelo CIDOC CRM - inclui a possibilidade de representar períodos de tempo durante os quais alguns objetos mantêm estáticas suas propriedades. O primeiro também define que há estados e situações entre eventos, enquanto que o modelo CIDOC CRM representa apenas eventos e descreve transições. Mas o modelo CIDOC CRM oferece algo similar à descrição de um estado a partir da noção de Conditon State, que descreve a duração de uma fase, onde é seguro assumir que as propriedades de um objeto são estáveis. Ambos os modelos apresentam vantagens e desvantagens (Doerr et al., 2003): Eventos em geral são conhecimentos primários, mas o testemunho absoluto de um estado é raro. Estados normalmente são resultantes de inferências;

93 Contexto para Proveniência 93 Representar[MAC52] estados apenas através de transições podem ocasionar o descarte de conhecimento, como a não identificação de outras transições intermediárias; Transições podem ser inferidas a partir de dois estados observados (por exemplo, construído em 1944 e destruído em 1945 ). Estados são subjetivos e relativos ao contexto. Se alguma propriedade é alterada, mas o novo valor não é representativo, possivelmente será considerada estática; O conhecimento sobre um estado, ainda que inferido ou subjetivo pode ser relevante. Por fim, exibimos a terceira e última prévia (seção 2.4.4) de nossa ontologia parcial para proveniência que inclui os resultados mais relevantes segundo nossa visão - apurados até aqui Ontologia Parcial para Proveniência (prévia 3) A ontologia parcial da Figura 30 é o resultado acumulado, dos conceitos que consideramos mais relevantes, dos diferentes modelos estudados. Figura 30: Ontologia parcial para Proveniência (prévia 3)

94 Contexto para Proveniência 94 O propósito deste resultado é meramente didático para ajudar o leitor a manter uma referência dos principais conceitos explorados. As propriedades não são apresentadas na Figura 30 para evitar a sobrecarga de informação, mas lembramos que são fundamentais para a análise de fragmentos. A partir do contexto para proveniência acumulado (capítulo 2), esclareceremos as decisões de projeto e apresentaremos o modelo conceitual genérico de proveniência em detalhes a seguir (capítulo 3).

95 3 Modelo de Proveniência Neste capítulo, apresentamos as preliminares à construção do modelo conceitual genérico para proveniência (seção 3.1), seguidas da motivação de necessidade global de recuperação de informação (seção 3.2). Então, discutimos a estratégia (seção 3.3) e tática (seção 3.4) do projeto do modelo de proveniência. Apresentamos a proveniência da proveniência do modelo (seção 3.5) e por fim descrevemos o modelo de proveniência (seção 3.6) Preliminares A cada novo dia, governo, indústria e a academia contribuem com a introdução de novos modelos que se somam a uma infinidade de outros já construídos. Alguns deles são promovidos a padrões, que se listados aqui tornariam esta introdução longa e difícil. O interessante sobre padrões é que há inúmeros para serem escolhidos, mas poucas vezes cogitamos escolher algum porque acabamos por criar os nossos próprios. Com cuidado, se percebidos com maior profundidade, dentre os padrões existentes, é possível notar que há de fato fragmentos semelhantes, padrões de conteúdo (content-patterns), por vezes sintáticos, por outras, semânticos. Ainda assim, com disciplina, é possível destacar fragmentos, identificar e classificar invariantes e, por fim, interromper o ciclo vicioso da criação de padrões a partir de novos conceitos. A despeito dos esforços de inúmeros grupos (seção 2.1.2) que estudam elementos comuns para representar metadados, é quase certo que, ao longo dos próximos anos, muitas, senão a maioria das comunidades, com suas distintas necessidades, inventarão modelos de metadados incompatíveis. Na busca por soluções, que fundamentalmente apresentam sobreposições de objetivos, se existe alguma metodologia geral que oriente o projetista de metadados, essa no mínimo não é adequadamente difundida nem reconhecida amplamente nos diversos domínios de conhecimento existentes. Bearman et al. (1999) alerta que é de suma importância que modelos conceituais comuns para a troca de informação sejam identificados e adotados. Reconhecer a convergência de requisitos ajuda a minimizar as diferenças muitas vezes conflitantes das demandas em domínios distintos. Acrescenta que

96 Modelo de Proveniência 96 educadores já propuseram modelos para objetivos semelhantes aos da comunidade de comércio eletrônico. Uma abordagem mais disciplinada durante o projeto de metadados poderia ser conquistada considerando o custo-benefício da introdução de novos conceitos. Uma metodologia para construção de modelos ampara-se na avaliação cuidadosa de propriedades, classes-domínio e classes-imagens onde operam, com o objetivo de identificar semelhanças de como os metadados estão relacionados e não apenas uma comparação entre tipologias diferentes. Este caminho não apenas habilita a equivalência semântica, mas também a integração de informações complementares. Doerr et al. (2003) elucida que os esforços de harmonização entre diferentes modelos focam na análise de classes, propriedades e relacionamentos. Conclui que em alguns casos o nível de abstração de determinados conceitos é tão alto que não há como avaliar sua corretude. Também admite que conceitos como evento e agente podem apresentar semânticas distintas e, mesmo assim, apropriadas em cada contexto onde são adotados. A conclusão em geral que se pode obter a partir do estudo de ontologias de alto nível (seção 2.3) é que o mundo é dual. Há possibilidades de interpretá-lo às vezes centralizado no recurso, e outras no evento ou processo (seção 2.4.3). Yang et al. (2003) argumenta que as pessoas interpretam (questionam) o mundo a partir da formulação de perguntas sobre essa dualidade. Tais perguntas podem ser respondidas na medida em que dados que descrevem as entidades questionadas, de alguma forma, foram preservados (seção ) ao longo da história. É nosso objetivo, ressaltar que há caminhos que alavancam o reuso e aumentam as possibilidades de integração (seção 3.4). Ao longo deste capítulo, apresentaremos o nosso modelo de proveniência como uma abstração, não para um domínio especifico, mas que procura ser intercambiável, ou seja, o modelo conceitual genérico para proveniência deve ser capaz de oferecer um conjunto de metadados de uso comum a diferentes domínios para normalizar o intercâmbio dos dados entre aplicações. Bearman et al. (1999) afirma que, para que os metadados sejam intercambiáveis, os relacionamentos implícitos devem ser explicitados. Também apresentamos a proveniência do modelo, que pode ser entendida como metaproveniência (seção 3.5), que captura a origem dos conceitos adotados, justificando-os de forma consistente, completa e não ambígua. Por fim, descrevemos o modelo propriamente dito (seção 3.6).

97 Modelo de Proveniência Motivação Considere as diferentes interfaces de recuperação de informação que estão presentes em nosso dia a dia no ambiente pessoal, corporativo ou acadêmico, através do uso de sistemas Web ou não. Cada uma delas oferece um nível de detalhe diferente apresentando maior ou menor variedade e qualidade de metadados disponíveis para a busca. Ainda assim, as respostas retornadas expõem apenas um pequeno grupo de todos os metadados de fato existentes. Muitas vezes, é através de algum conhecimento já adquirido que estabelecemos as relações que poderiam estar explicitas pelos metadados. Então, quando localizamos os objetos de interesse, manualmente criamos os metadados implícitos, relacionado os objetos entre si. Esses metadados representam a proveniência como anotação (seção 3.3) realizada após a criação do objeto. Sinclair (2006c) argumenta que há vezes em que as relações entre os objetos já existem, mas não há registro de quando, onde, como ou porque se estabeleceram. Assim, somos forçados a criar hipóteses para visualizar o contexto histórico da relação a partir apenas de valores dos objetos retornados em uma busca. Acrescenta ainda que, varrendo os resultados da busca, conjecturamos relacionamentos mais profundos entre os itens retornados. Por isso, enfatiza que os mecanismos de consulta e visualização deveriam ser capazes de representar os relacionamentos entre os itens retornados. Por fim, sugere que o caminho para essa representação seria alcançado através do uso de modelos de metadados mais ricos que pudessem capturar o histórico completo dos objetos representados. Mas alerta que esse modelo deve superar as diversidades das representações de materiais e mídias, bem como sua heterogeneidade. De fato, virtualmente nada pode ser compreendido ou interpretado sem sua relação com o contexto. Portanto, é necessário relacionar as entidades, sejam elas eventos, documentos digitais ou físicos, ou abstrações. Para compreender como os relacionamentos serão estruturados, apresentamos as estratégias de projeto possíveis (seção 3.3), destacando a adotada em nossa modelagem.

98 Modelo de Proveniência Estratégia de Projeto (Proveniência no Centro) As estratégias de projeto de modelagem, intrínsecas ao estudo de proveniência, podem ser compreendidas por duas formas (Globe, 2003): Derivação: é um caminho dentro de um fluxo (workflow), um script ou consulta; são as ligações (links) entre objetos que usualmente estão representadas pelas arestas de um grafo direcionado. A derivação é uma explicação de onde, quem, ou como alguma coisa foi produzida ou derivada. Anotações: são dados representadas como anotações dos objetos de informação, de forma estruturada, semi-estruturada ou em forma de texto livre. Os relacionamentos entre itens também podem se estabelecer a partir das anotações. Podem ser explicações relativas ao item, do porquê, quando, onde, quem, qual ou como. A derivação então dá origem à estratégia centrada em evento (eventcentric) ou processo (process-centric) onde as mudanças estão no centro. Por outro lado, a anotação está vinculada à estratégia centrada no dado (datacentric), algumas vezes também chamada de centrada no documento ou centrada no recurso (document-centric ou resource-centric). Os projetos Dublin Core, OAIS e FRBR, que cobrem conceitos de proveniência (seções , e respectivamente), são exemplos de estratégia centrada no recurso. Lagoze (2001) explica que, das perspectivas técnicas e econômicas, por exemplo, o conjunto elementar do DC permite que valores sejam associados a um conjunto finito de propriedades. Nesta estratégia o documento ou recurso é promovido à classe principal (first-class) enquanto que entidades como agente, evento, ação entre outras são apenas complementares. Por outro lado, Lagoze (2001) esclarece que a necessidade de representações mais ricas, sugere uma abordagem mais expressiva dos modelos e vocabulários, onde deve ser possível definir e delimitar múltiplas entidades. Essa necessidade é atendida pela estratégia centrada no evento, como adotam os projetos CIDOC CRM, FRBRoo, INDECS, HARMONY, (respectivamente seções , , e ). Hunter (2001) ressalta, por exemplo, que a adoção de uma visão centrada em eventos permite a modelagem de relacionamentos entre várias manifestações de uma criação.

99 Modelo de Proveniência 99 Adiciona que a estratégia habilita também a associação de propriedades entre eventos e agentes envolvidos no ciclo de vida de um recurso. Comenta ainda que essa estratégia de modelagem de metadados permite múltiplas visões para a recuperação dos dados. Em nosso projeto, adotamos uma estratégia composta, que definimos como centrada na proveniência (event-centric + event-relations + related resources) porque permite a representação de agentes, ações, recursos, contexto entre outros, transformando conhecimentos implícitos em explícitos, favorecendo a interoperabilidade semântica (Yanosy, 2006). Exploramos a tática (seção 3.4) que complementa a estratégia adotada, a partir da discussão de padrões de projeto de ontologia conceitual Tática de Projeto (PPCO) Há problemas de modelagem que se repetem com freqüência nos projetos de diferentes aplicações. Quando isto ocorre, a solução adotada deve preferencialmente ser descrita de forma genérica, adequada para cobrir várias classes de aplicações. Essa tática é conhecida como Padrão de Projeto (Design Pattern). Na área de informática, o termo apropriado é Padrão de Projeto de Software (Software Design Pattern), mas seu uso abreviado ao termo original também é bastante comum. Gamma et al. (1995) destaca que os padrões de projeto são um método geral e abstrato de solucionar questões de modelagem, que tem se mostrado consistentemente eficaz na resolução de problemas da engenharia de software. Aranguren (2005) apresenta os padrões de projeto de ontologia ODP (Ontology Design Pattern) como soluções de modelagens abstratas para problemas conhecidos da engenharia de ontologias. Alguns padrões de projeto de ontologia são propostos pelo Grupo de Engenharia e Padrões de Ontologia do W3C, abreviadamente conhecido como OEP 31 (Ontology Engineering and Patterns Task Force). 31

100 Modelo de Proveniência 100 Os padrões de projeto conceitual de ontologias PPCO (tradução da respectiva abreviação em inglês CODeP: Conceptual Ontology Design Patterns) tem uma aplicação análoga aos padrões de projeto de software (Gangemi, 2006). Entretanto, Aranguren et al. (2007) chama atenção para a diferença entre CODePs e ODPs: o conceito de CODeP (Gangemi, 2005) parece próximo ao conceito ODP, porém difere em nível de expressividade. CODePs representam padrões conceituais e abstratos em linguagens que não necessariamente permitem inferência, enquanto que ODPs são representados através de linguagens (por exemplo, OWL) sustentadas por um formalismo (com Lógica de Descrição). Esta dissertação adotou uma tática de projeto inspirada na metodologia de construção de padrões de projeto conceitual de ontologias para o desenvolvimento do modelo conceitual genérico para proveniência (seção 3.6). Adicionalmente a construção do CODeP, Gangemi (2005) sugere sua publicação (codificação e anotações) em repositórios e a disponibilização de um serviço de consulta, por exemplo, uma biblioteca ou um catálogo acessível via Web. Identificamos apenas um catálogo 32 on line que permite pesquisas estruturadas nos padrões disponibilizados, enquanto que os demais repositórios 33 de padrões disponibilizam acesso, mas não consultas estruturadas. Por hora, interessa-nos destacar um padrão que exemplifica a reificação 34 de relacionamentos indexados pelo tempo. Algumas classes de um padrão de ontologia representam reificações semelhantes à destacada pelo CODeP da Figura 31. Esse padrão apresenta os principais elementos de nossa estratégia de projeto: evento (ou processo), a evidência de relacionamentos e objeto (ou recurso). O CODeP Time-Index-Participation da Figura 31 apresenta a reificação do padrão Participation (Masolo et al., 2003). Essa reificação representa uma configuração para: um evento, as entidades que participam desse evento e o intervalo de tempo no qual o evento ocorre define reificação como: to regard or treat (an abstraction) as if it had concrete or material existence

101 Modelo de Proveniência 101 Apresentaremos a proveniência da proveniência (seção 3.5), explicando a origem do modelo proposto. Em seguida, descrevemos o modelo de proveniência (seção 3.6). [ALAM53] Figura 31: CODeP Participation reificado (Gangemi, 2005) 3.5. Metaproveniência[ALAM54] O esboço de um modelo de proveniência se manifestou a partir das noções abstratas de proveniência e do estudo de perguntas elementares ao estilo 5W1H 35. O segundo ponto importante da modelagem foi o foco na noção de evento, mas que inicialmente não havia se mostrado evidente pelas definições de dicionários. Na verdade, o conceito de evento estava implícito nas noções de história (state of affairs). A noção de evento foi então ratificada pela análise das definições de grupos tradicionais de pesquisa de metadados. Então, o estudo da proveniência baseada em eventos amadureceu com a seleção e identificação de normas e projetos que tinham como elemento central o conceito evento, e que ao mesmo tempo apresentavam uma cobertura para os conceitos abstratos de proveniência. Por fim, com o desafio de tornar o alinhamento de esquemas um problema tratável, projetamos um modelo de proveniência como um padrão conceitual através da busca de invariantes em todo o contexto estudado. 35 5W1H origina-se das seis palavras em inglês: What, When, Who, Why, Where e How. É um mnemograma que se popularizou na linguagem empresarial porque ajuda a lembrar dos seis pontos principais de um plano de ação.

102 Modelo de Proveniência 102 Após esse breve histórico da criação do nosso modelo de proveniência, ao longo desta seção destacaremos as partes do contexto de proveniência mais relevantes e que influenciaram mais significativamente a construção do modelo. Identificaremos os reusos possíveis e selecionados, assegurando que as classes importadas sejam apenas as necessárias e suficientes para a representação do modelo conceitual genérico de proveniência que nos referenciaremos também, abreviadamente, como modelo mínimo. O foco no modelo mínimo é um dos caminhos para assegurar a consistência da utilidade do modelo. As classes importadas estarão associadas inicialmente a conceitos abstratos, que são parte de nossa ferramenta cognitiva, mas que serão descartadas tão logo o modelo mínimo seja alcançado. Lembramos também que, neste capítulo, modelo de proveniência e modelo conceitual de proveniência são sinônimos para modelo conceitual genérico de proveniência. Criamos uma generalização para conceito de proveniência a partir do termo proveniência do padrão Dublin Core (seção ). A proveniência a que se refere nosso modelo (seção 3.6) é a de um conjunto de descrições de qualquer mudança de um objeto de informação, que registre sua história e que seja significante para resguardar autenticidade, integridade e interpretação. Esse contexto inicial para proveniência é a justificativa principal para considerarmos o conceito de Evento associado à metaclasse What. Dos aspectos de projetos de proveniência (seção 2.2) adotamos a estratégia centrada em eventos como derivação da estratégia orientada a processos. Com isso, ratificamos que o conceito abstrato What e a noção de evento são centrais ao modelo de proveniência. Não obstante, argumentamos que a proveniência em forma de anotação chamou atenção para a importância dos objetos de informação propriamente ditos, levando-nos a avaliar a modelagem de proveniência orientada ao dado. Descartamos esta última porque a centrada em eventos é mais expressiva, mas consideramos que de forma prática, o objeto de informação como produto é mais tangível. Dentre as ontologias de alto nível (seção 2.3) estudadas, a ontologia que melhor representa o comprometimento com a integração a priori é a DOLCE (Masolo et al., 2003) porque foi a única que definiu um padrão de projeto de

103 Modelo de Proveniência 103 ontologia: D&S 36 (Description & Situation). Esse padrão é referência para outros reusos, por exemplo, as decomposições, Participation, Role<->Task, entre outras, propostas na forma de CODePs por (Gangemi, 2005) e (Gangemi, 2006). A Figura 32 exemplifica o padrão D&S, onde Region, Endurant, Perdurant e Situation são entidades primárias ( first-class ), portanto classes disjuntas. As classes Parameter, Funtional Role, e Course of Event são do tipo Description e agregadas pela classe S-Description (contexto), também do tipo Description. Figura 32: Padrão de Ontologia D&S proposto em (Masolo et al., 2003) Uma forma mais simples de compreender o padrão D&S é sugerida por (Gangemi, 2006). A Figura 33 apresenta as principais classes e relacionamentos do padrão, e por simplificação didática, não representa todos os relacionamentos propostos pelo padrão D&S. Um contexto (instância de S-Description) define as classes reificadas, que por sua vez classificam as entidades primárias que são então uma configuração para uma situação (instância de Situation) que satisfaz o contexto. [ALAM55] 36

104 Modelo de Proveniência 104 Figura 33: CODeP DnS 37 simplificado em (Gangemi, 2006) Gangemi (2006) esclarece que esse padrão pode ser especializado para diferentes domínios de aplicação. Esse, como outros CODePs foram aplicados por mais de dois anos em projetos de sistemas de informação para a indústria pesqueira, seguradoras, integração de ontologias da biomedicina, controle de lavagem de dinheiro em instituições financeiras, acordos de níveis de serviço, aprendizado de ontologia biomolecular e contratos. Por fim, acrescenta ainda que CODePs também foram aplicados para gerenciamento de conteúdo digital.[alam56] Do D&S, não importamos a classe Functional Role, que estaria inicialmente, mapeada para o conceito abstrato Which porque a propriedade P14.1 in the role of importada da ISO 21127:2006 já representa esse conceito. Nesse padrão, outra classe nos chamou atenção: Course of Events. Essa classe foi uma candidata ponderada por nós em determinado momento da pesquisa para assumir o mapeamento para o conceito How porque suas instâncias são ordens esperadas. Optamos por não importar a classe Course of Events do padrão D&S, porque consideramos que ela restringe a possibilidade da representação para a pergunta Como (How). O conceito adotado é Means 38, importado da Matriz de Perguntas (The Question Matrix) de Weiderhold[ALAM57] 39 (1993[ALAM58]) para o modelo de proveniência. Buscando ancorar nosso modelo de proveniência em padrões internacionais (seção 2.4.2), mencionamos o padrão ISO/NP (Data Como (How) um resultado é obtido. 39 Referimo-nos aqui a Chuck Wiederhold e não a Gio Wiederhold.

105 Modelo de Proveniência 105 quality - Part 120: Master data: Provenance), ainda não homologado, que ratifica a importância da proveniência para a qualidade dos dados, uma vez que esse padrão é parte da ISO 8000 em desenvolvimento com esse propósito. Em seguida, descrevemos da ISO 14721:2003 (seção ), equivalente a tradução brasileira da norma NBR 15472:2007 (seção ), a parte dedicada à proveniência, apresentando os conceitos relacionados ao componente da informação de descrição de preservação. Essa norma ratifica a importância da modelagem de eventos, mas restringisse ao domínio arquivístico, limitando, portanto, as definições relacionadas à proveniência. Embora não tenhamos importado da norma brasileira nenhuma classe ou relacionamento, a sua homologação recente demonstra a importância deste padrão para a indústria nacional, bem como os esforços em adotá-lo para desenvolvimento de sistema arquivístico de caráter aberto, em diferentes instituições governamentais, como por exemplo, no Arquivo Nacional. Concluindo o estudo de padrões internacionais, exploramos a ISO 21127:2006 (seção ). A escolha desse padrão foi motivada por três razões. Primeiro, o padrão é a consolidação de dez anos de pesquisa na área de museologia (herança cultural) através do projeto CIDOC CRM. Segundo, porque o modelo desenvolvido é fortemente centrado em eventos e amplamente reconhecido pela comunidade internacional. E por fim, o modelo influenciou outras pesquisas (seção 2.4.3) que apresentam também coberturas para conceitos de proveniência e exploradas nesta dissertação. De fato, a possibilidade do reuso e da extensão de uma ontologia reconhecida mundialmente, agrega ao modelo de proveniência maiores chances de interoperabilidade. Adicionalmente o sintoniza com uma infra-estrutura emergente que é a Web Semântica. O estudo aprofundado desse padrão ISO demonstra que o seu projeto de modelagem é adequado para a organização e descrição da proveniência porque modela eventos históricos e inerentemente dependentes do tempo, bem como objetos de informação relacionados por eles. I[ALAM59]nicialmente desse modelo importaríamos as classes Actor e Physical Thing. Entretanto, estabelecemos como critério de seleção de classes a disjunção entre classes associadas à mesma metaclasse (conceito abstrato). De fato, não importamos as classes Actor e Physical Thing porque não são disjuntas. Para que o sejam, seria necessário resolver a interseção de instâncias: a classe Biological Thing - especialização indireta de Physical Thing é a generalização para Person, da mesma forma que Actor também o pode ser. O projetista deve ter atenção redobrada ao importar classes da ISO 21127

106 Modelo de Proveniência 106 quando o modelo alvo tem como objetivo a disjunção. Com isso, optamos, portanto, pela importação da classe Participant da ontologia de topo proposta por (Sowa 1999) que é referência para a ontologia de alto nível SUMO (seção 2.3.3), como o conceito associado a Who. Essa decisão é interessante por duas razões: Sowa (1999) define subárvores abaixo do conceito Participant que chama de Thematic Roles e, foi ratificada pela presença do conceito Participant no modelo CIDOC CRM Core (seção ). Descreveremos nos próximos parágrafos as metaproveniências relacionadas aos projetos estudados: FRBRoo, INDECS e Harmony. Iniciamos pelo projeto FRBRoo (seção ) que surgiu pela aproximação das comunidades de biblioteconomia e museologia que juntaram esforços para harmonizar ambos os modelos de forma a possibilitar uma integração mais efetiva entre essas áreas de conhecimento. O modelo de proveniência, enquanto proposta genérica, não deve atender exclusivamente ao domínio de biblioteconomia. Por isso, não iremos contemplar em nosso modelo mínimo os conceitos abstratos que são específicos para apenas alguns domínios. Entretanto ressaltamos que as classes Work, Expression, Manifestation Product Type e Item são consideradas elementares para o domínio de biblioteconomia e também importantes em outros domínios, por exemplo, e- commerce projeto INDECS (seção ). A representação concreta dos conceitos abstratos (Work, Expression e Manifestation Product Type) é Item. Todos esses últimos estão presentes no modelo FRBRoo. Sugerimos que o modelo mínimo pode ser expandido a partir da importação das classes Work, Expression, Manifestation Product Type e Item respectivamente como especializações de Conceptual Object, Information Object, Type e Information Carrier. Todas estas quatro últimas são classes da ISO 21127:2006 modelo CIDOC CRM (seção ), mas apenas Conceptual Object e Type (especialização de Conceptual Object) foram importadas para o modelo mínimo porque representam respectivamente a noção de abstrações que são concebidas por participantes que têm intenção - em diferentes ontologias de alto nível (seção 2.3) são chamados de agentes e, a noção de classificação. Com isso, a interoperabilidade com os modelos CIDOC CRM e FRBRoo seria assegurada, uma vez que a harmonização desses dois últimos modelos é a origem de nossa sugestão. A classe Information Carrier, que não faz parte do modelo mínimo, pode ser importada como especialização indireta de Physical Thing sempre que algum domínio necessitar da noção de veículo que

107 Modelo de Proveniência 107 corresponde ao objeto físico propriamente dito. Podemos citar como exemplo de uma de suas instâncias (Information Carrier) a Rosetta[ALAM60] Stone 40 [MAC61]. Com a noção de Conceptual Object, recuperamos os argumentos de (Sinclair et al., 2006b), que explicam que o CIDOC CRM Core é um subconjunto condensado de elementos de metadados da ISO :2006 que captura os relacionamentos fundamentais que relacionam fenômenos (things), conceitos (concepts), pessoas (people), tempo (time) e lugar (place). Para essa captura, o CIDOC CRM Core oferece duas classes: Relation e RelatedEvent. A primeira representa instâncias de relacionamentos entre eventos e instâncias de CRM Core (entidade topo desse modelo). A segunda representa uma instância que é um auto-relacionamento entre eventos. Como a primeira é mais geral que a segunda, seria candidata a importação. Ressaltamos que a avaliação feita durante o projeto do modelo, para reificar o conceito abstrato Why, foi ponderar[alam62] as propriedades (relacionamentos) marcadas em negrito (Tabela 4 seção ) repetidas (Tabela 16). As noções de Belief e Desire seriam cobertas respectivamente por was Influenced by e was motivated by. Analogamente, Intention cobriria was intended use of. Assim, o mapeamento para o conceito abstrato Why foi cogitado em determinado momento da pesquisa para ser dado não a partir de uma classe importada, mas sim através de propriedades importadas. D[ALAM63]e fato, não faria sentido um conceito abstrato apresentar propriedades. A existência de propriedades (relacionamentos) qualificados que capturam a noção de razão conceito abstrato Why permitiu identificar a importância da representação de algumas relações, como uma classe reificada, nas expansões do modelo[alam64], analogamente ao modelo CIDOC CRM Core. Entretanto, esclarecemos que consideramos a noção de relação (Relation) também abstrata. Como alternativa, propomos o conceito importado da Matriz de Perguntas (The Matrix Question) de Weiderhold (1993) como a classe reificada adequada para o conceito abstrato Why. Conforme a estratégia adotada (seção 3.3), a explicitação da noção de relacionamento é fundamental. No modelo conceitual de proveniência esta noção é capturada pela classe Reason. 40 A pedra Rosetta (Rosetta Stone) é o mais remoto software de linguagem de aprendizado do mundo, e tem seu original (Information Carrier) exposto no British Museum em Londres.

108 Modelo de Proveniência 108 Tabela 16: Propriedades que capturariam parcialmente a noção de razão (Reason[ALAM65]) Id Nome da Propriedade Classe- Domínio Classe-Imagem P15 was influenced by (influenced) E7 Activity E1 CRM Entity P17 - was motivated by (motivated) E7 Activity E1 CRM Entity P19 was intended use of (was made for) E7 Activity E71 Man-Made Thing Continuamos a descrever a metaproveniência, destacando que o projeto INDECS (seção ) contribuiu para retificar os conceitos abstratos do projeto FRBR, apontando que a noção Manifestation é abstrata e não concreta como definida originalmente no modelo ER do FRBR. Adicionalmente, o projeto INDECS ratificou a importância da representação de relacionamentos, também definindo a classe Relation como a reificação da conexão (com atributos) entre duas ou mais entidades, conforme apresentado na Figura 34. No projeto INDECS a classe Relation é responsável por estabelecer relações entre concepções e percepções do mundo. Figura 34: Entidades do modelo INDECS (Rust & Bide, 2000) 41 [ALAM66] 41 As imagens desta fonte estão protegidas por Copyright. As utilizamos aqui amparados por

109 Modelo de Proveniência 109 Rust & Bide (2000) reconhecem que percepções (percepts) são seres inanimados (things) ou animados (beings), e relações (relations) como dinâmicas (events) ou estáticas (situations). Acrescentam que a classe evento desempenha um papel fundamental como cola do modelo: todos os metadados de relacionamentos são eventos por si, ou dependem de eventos para se estabelecer. Concluem que este mecanismo em transformar metadados em representações de eventos provê uma poderosa abordagem para a interoperabilidade. Concluindo os projetos estudados, esclarecemos que do projeto Harmony também não importamos nenhuma classe para nosso modelo, mas frisamos que é um modelo significativo, ao ser, por si próprio, mais um exemplo de harmonização com a ISO 21127:2006, analogamente ao FRBRoo. O modelo ABC, produto do projeto Harmony, também importou classes do modelo FRBR. Mas a principal contribuição do estudo do projeto Harmony, já mencionada anteriormente, é expressa por (Lagoze & Hunter, 2001): os diversos modelos centrados em recursos são inadequados para expressar entidades como pessoas, lugares, idéias e especialmente transições temporais. O modelo ABC inclui as noções de Evento (Event) e Situação (Situation), que respectivamente capturam transições e propriedades existenciais, e ressalta ainda que são fundamentadas em modelagem de processos e extensões temporais para lógica de primeira ordem. O projeto Harmony possui uma peculiaridade interessante: uma classe primária chamada Abstraction, noção não considerada como first-class pelo CIDOC CRM. Pelo contrário, Persistent Item tem como subclasse Conceptual Object, o que confunde um pouco os conceitos do que é Concreto ou Abstrato. As representações abstratas seriam então um item persistente, mas concretamente, apenas, através de uma instância da classe Information Carrier. U[ALAM67]ma possível analogia entre as classes primárias Actuality na ontologia de topo de Sowa (1999) e Temporal Entity no modelo da ISO 21127:2006 com Endurant e Perdurant do padrão D&S permite presumir que nosso modelo também contempla a estrutura núcleo definida nesse padrão. Assim como no padrão D&S, as classes Functional Role e Course of Events classificam respectivamente Endurant e Perdurant, o relacionamento qualificado P14.1 in the role of e a classe Means classificam Participant e Event que têm como classes raízes de seus respectivos ramos taxonômicos, as classes Actuality (Sowa, 1999) e Temporal Entity (ISO ).

110 Modelo de Proveniência 110 A Tabela 17 mapeia cada conceito abstrato de proveniência de interesse para as respectivas classes e especializações e identifica a origem da importação dos conceitos apresentados. Para concluirmos o processo de construção do modelo, precisamos nos desfazer dos conceitos abstratos de proveniência que até o momento serviram ao papel de metaclasses (de classes primárias) para a realização dos mapeamentos. Considere, a partir de agora, que tenhamos chegado a um conjunto de classes importadas que seja satisfatoriamente genérico e interoperável, e que então podemos descartar as metaclasses (Wh-questions), utilizadas meramente como ferramenta cognitiva, sem prejuízo ao modelo e de forma transparente para o projetista. [MAC68] Tabela 17: Mapeamento de conceitos abstratos de proveniência [ALAM69] Conceito Origem do Conceito Conceitos e Especializações Abstrato Importado What Event CIDOC CRM - Activity CIDOC CRM - Begin of Existence CIDOC CRM - End of Existence CIDOC CRM Who Participant Sowa (1999) Where Place CIDOC CRM When Time-Span CIDOC CRM Conceptual Object CIDOC CRM Why Reason Matriz de Perguntas de Wiederhold (1993) How Means Matriz de Perguntas de Wiederhold (1993) Agora[ALAM70], é necessário identificar quais serão as nossas classes primárias e quais movimentações de classes devemos realizar para criar classes primárias de fato disjuntas. Primeiro, definimos a classe Conceptual Object como a generalização adequada para Reason e Means. Movemos as classes Reason e Means imediatamente para baixo de Conceptual Object, passando todos movidos, a serem especializações. O resultado obtido é apresentado na Tabela 18 que exibe um detalhamento parcial da hierarquia de especialização, apenas com o propósito de manter o foco da discussão nas classes que nos interessam.

111 Modelo de Proveniência 111 O conceito abstrato Which - choice segundo Wiederhold (1993) não está presente associado a uma classe na Tabela 17, mas faz parte do modelo mínimo porque está representado pela prorpiedade qualificada P14.1 in the role of importada da ISO 21127:2006. Tabela 18: Hierarquia parcial de especialização após descarte dos conceitos abstratos Proveniência Hierarquia ID ISO 21127:2006 ISO 21127:2006 ISO 21127:2006 ISO 21127:2006 Event - Activity - Begin of Existence - End of Existence E5 E7 E63 E64 Sowa (1999) Participant CID2 ISO 21127:2006 Place E53 ISO 21127:2006 Time-Span E52 ISO 21127:2006 Wiederhold (1993) Wiederhold (1993) Conceptual Object - Reason - Means E28 CID4 CID5 [MAC71] Não apresentamos a classe E55 Type (ISO 21127:2006) na Tabela 18, para mantermos o foco da discussão nas classes mais relevantes, mas ratificamos que essa classe faz parte do modelo mínimo. Da mesma forma, não identificamos na hierarquia, porém importamos a classe E41 Appellation do modelo CIDOC CRM, como especialização de CID1 Provenance Entity, mantendo a coerência do corte feito na ontologia CIDOC CRM (ISO 21127:2006). As instâncias da classe E41 Appellation não são como instâncias de um banco de dados que são surrogates ou referências a entidades do mundo real. Cada instância dessa classe é apenas um appellation propriamente dito: o appellation André é nada mais que a palavra André, e não uma referência a uma pessoa, por isso, não carrega nenhuma semântica, o que explica a decisão de não colocá-lo como subclasse de E28 Conceptual Object. A Tabela 18 inclui também uma coluna adicional que representa o identificador único da cada classe e utiliza a nomenclatura também importada da respectiva fonte. No caso das classes Participant (CID2), Reason (CID4) e Means (CID5), cujas fontes não oferecem um identificador único, optamos pela criação da seguinte nomenclatura para representá-lo: CID (Class ID) seguido imediatamente de um campo numérico incremental automático (CID1, CID2 e assim por diante). O identificador CID3 foi reservado para ser utilizado em

112 Modelo de Proveniência 112 expansões ao modelo mínimo. Sugerimos ao projetista que avalie a reificação da propriedade P14.1 in the role of como classe CID3 Functional Role, o que compatibilizaria este conceito com a classe Functional Role do padrão D&S da DOLCE. O resultado apresentado na Tabela 18 se não estivesse lastreado em padrões, fundamentando o comprometimento com a interoperabilidade e integração a priori, nem explicitasse quais são as respectivas origens dos conceitos, poderia ser visto então como um novo modelo. Da forma como está, seu verdadeiro propósito é o de uma visão que interrompe o ciclo vicioso de criação de novos modelos, ou ao menos restringe sua frequência. Em resumo, até aqui descrevemos a origem do modelo de proveniência (mínimo) que reusa parcialmente as classes: da ontologia de topo de Sowa (1999), da Matriz de Perguntas de Wiederhold (1993) e da ISO 21127:2006. A hierarquia de especialização da Tabela 18 é a ponte (metaproveniência) para a consolidação das classes e relacionamentos do modelo conceitual genérico para proveniência (seção 3.6) Modelo Conceitual[ALAM72] O modelo conceitual genérico para proveniência pode ser aplicado a diferentes domínios porque se baseia em classes que representam conceitos unificadores, de uso comum, idealmente não ambíguos, extraídos de padrões amplamente reconhecidos. A metaproveniência do modelo fundamentada pelo contexto para proveniência (capítulo 2) potencializa a sua interoperabilidade porque assegura a escolha de invariantes presentes ou alinhadas diretamente a classes de outros modelos. Com o objetivo de registrar o que aconteceu, o modelo habilita, através de suas expansões, a capacidade de rastreabilidade dos dados através dos relacionamentos entre evento e oferece, em sua versão minimal, a representação da proveniência. Adicionalmente, serve de base para um entendimento comum de como criar: uma visão para proveniência a partir de modelos de referência ou de outras fontes não ambíguas e uma metodologia de construção de modelos conceituais. Apresentamos na sequência a seguir os preliminares ao modelo conceitual genérico para proveniência (seção 3.6.1), as classes e propriedades do modelo mínimo (seção 3.6.2) e por fim, duas expansões do modelo (seção 3.6.3).

113 Modelo de Proveniência Preliminares Com exceção das classes Reason e Means importadas da Matriz de Perguntas de Wiederhold (1993) e, da classe Participant da ontologia de topo de Sowa (1999), as demais classes do modelo de proveniência (mínimo) são importadas da ISO 21127:2006 (seção ). Para as classes do modelo mínimo e suas expansões adotamos a nomenclatura padrão para identificação das classes das fontes de construção do modelo e, para as classes sem um identificador único além do seu nome, adotamos uma identificação própria do modelo de proveniência: As classes do modelo CIDOC CRM são identificadas pela letra E seguida de um número para o id da classe. As classes que não tem id na fonte de importação são identificadas por CID (Class ID) seguido de um número (CID1, CID2 e assim por diante). Analogamente, as propriedades são identificadas da seguinte forma: As propriedades do modelo CIDOC CRM são identificadas pela letra P, seguida de um número. As outras propriedades são identificadas por PID seguido de um número. Esta dissertação apresenta os termos em inglês em formato itálico. A partir de agora, como uma exceção a esta regra, ao referenciarmos uma classe, precederemos seu nome em formato regular não itálico sempre com seu respectivo identificador único. Com isso, ratificamos o formato das fontes de importação. As referências ISO (2006) e Doerr et. al. (2007) contém a descrição detalhada das classes e especializações não explicitadas no modelo mínimo e na expansão FRBR; estas referências de fato apresentam de forma completa as classes da ISO 21127:2006 e do modelo FRBRoo. Definimos a classe topo da hierarquia de especialização do modelo de proveniência como Provenance Entity e identificador CID1. Assim, todas as classes do modelo são especializações diretas ou indiretas desta classe. Ela possui as seguintes propriedades: Identificação por nome ou appellation (E41 Appellation), ou identificador único; Classificação por tipo (E55 Type); Descrição por texto livre.

114 Modelo de Proveniência 114 A classe E52 Time-Span é um intervalo temporal que não se referencia a nenhum contexto geográfico ou cultural, diferentemente de instâncias de E5 Event que ocorrem (take place at) em instâncias de E53 Place ou, (take place on or within) em instâncias de E18 Physical Thing. Os eventos (E5 Event) têm duração definida por E52 Time-Span. As instâncias de E52 Time-Span algumas vezes são identificadas por instâncias de E49 Time Appellation, usualmente na forma de sua especialização de E50 Date. Outras vezes, as instâncias de E52 Time-Span podem ser discretas no tempo quando P81 ongoing throughout opera, ou incertas quando P82 at some time within opera. A classe-imagem dessas propriedades é a classe E61 Time Primitive que compreende instâncias de E59 Primitive Value. Esta última representa tempo que deve ser implementado com a apropriada validação, precisão e intervalo lógico para expressar variações de datas relevantes para o domínio de aplicação que adota o modelo. Figura 35: A classe E52 Time-Span, outras classes e relacionamentos da ISO 21127:2006 Acrescentamos que, para manter a compatibilidade com a ISO 21127:2006, importamos também a classe E59 Primitive Value, que é superclasse de E60 Number, E61 Time Primitive e E62 String, que representam respectivamente valores primitivos. Por isso, suas instâncias não são consideradas como elementos do domínio de discurso. A Figura 35 original do

115 Modelo de Proveniência 115 modelo CIDOC CRM ilustra algumas dessas classes e relacionamentos (as linhas duplas significam tipo de, e as linhas simples são outros relacionamentos que têm[alam73] seu significado descrito pelo nome da propriedade). O modelo CIDOC CRM não se limita apenas a representação de eventos discretos, uma vez que, no domínio de museologia, podem existir objetos que tenham ou não o respectivo dado de quando foram criados que pode ser preciso ou aproximado. De forma análoga, por exemplo, um incêndio ou um furto respectivamente poderiam determinar a sua destruição ou mera incerteza sobre sua existência. No modelo conceitual de proveniência nos interessam apenas os eventos discretos, portanto, os que têm duração ou são identificados por uma determinada data. Deixamos como nota que a opção de construção do modelo de proveniência quebrou a hierarquia original proposta pela ISO 21127:2006 para acomodar a noção de Abstrato como sendo disjunta da noção de Concreto, diferentemente da proposta na ISO 21127:2006 que acomoda ambas como um item persistente. Em nossa interpretação, as classes E28 Conceptual Object e CID2 Participant são disjuntas e, por isso, são classes primárias. Em cada uma das próximas subseções descreveremos as classes primárias e suas respectivas especializações, adotando a nomenclatura da ISO 21127:2006. Apenas as classes presentes na Tabela 18 serão detalhadas. Para cada propriedade de cada classe, apresentamos seu identificador único, sua descrição, propriedade inversa entre parêntesis e a sua classe-imagem. A maioria dos exemplos é inspirada em exemplos da ISO 21127:2006. Para informações adicionais sobre outras especializações e propriedades veja ISO[ALAM74] (2006) e Doerr et al. (2007). Por fim, apresentamos na Figura 36 o diagrama UML referente ao modelo mínimo (seção 3.6.2) com objetivo de mantermos o foco nas principais classes e relacionamentos. Identificamos também o mapeamento para os conceitos abstratos que foram utilizados durante a construção do modelo, para facilitar a compreensão do texto daqui em diante. A Figura 3 apresentada, antecipadamente como resultado realizado (1.4.2) é uma cópia da Figura 36.

116 Modelo de Proveniência 116 Figura 36: Diagrama UML com principais classes e relacionamentos do modelo conceitual e ilustrado com conceitos abstratos (Wh-questions)

117 Modelo de Proveniência Modelo Mínimo (3P) Nesta seção, descrevemos o modelo conceitual genérico para proveniência, ou simplesmente o modelo mínimo, que esperamos poder evoluir para um padrão de projeto para proveniência modelo conceitual 3p se aplicado e validado para diversos outros domínios diferentes daqueles que avaliaremos como nossos casos concretos (capítulo 4) Classes Classe importada da ISO 21127: E5 Event (What) Id e nome da classe primária: E5 Event Subclasse de: CID1 Provenance Entity Superclasse de: E7 Activity, E63 Begin of Existence e E64 End of Existence Nota de Escopo: esta classe compreende mudanças de estados independentemente de escala promovidos por arranjos de fenômenos culturais, físicos, legais ou tecnológicos. Tais mudanças afetam instâncias de CID2 Participant ou suas especializações. Um evento visto seu nível mais granular é uma mudança instantânea de estado. E5 Event pode ser analisado através de seus fenômenos componentes com espaço e intervalo de tempo. Exemplos: a 2ª Guerra Mundial ou A Conferência de Yalta em Propriedades importadas: P4 has time-span (is time-span of): E52 Time-Span P7 took place at (witnessed): E53 Place P11 has participant (participates in) 42 : CID2 Participant P[ALAM75]ID1 has reason: CID4 Reason P[ALAM76]ID2 has arrangement: CID5 Means Propriedades não importadas: P8 took place on or within (witnessed): E19 Physical Object P12 occurred in the presence of (was present at): CID2 Participant

118 Modelo de Proveniência 118 P114 is equal in time to: E5 Event P115 finishes (is finished by): E5 Event P116 starts (is started by): E5 Event P117 occurs during (includes): E5 Event P118 overlaps in time with (is overlapped in time by): E5 Event Descrevemos os detalhes das especializações diretas importadas da ISO 21127:2006 da classe E5 Event. Porém, as subclasses destas classes não serão detalhadas aqui. Para maiores informações veja ISO[ALAM77] (2006) e Doerr et al. (2007). Id e nome: E7 Activity Nota de Escopo: define ações intencionais desempenhadas por participantes (instâncias) CID2 Participant, que ocasionam mudanças de estado. Esta noção inclui ações complexas ou de longa duração[mac78]. Exemplos: a criação da parte 1 da tragédia Fausto por Goethe em 1806 ou a formação da Escola Bauhaus em Propriedades importadas: P14 carried out by (performed): CID2 Participant o P14.1 in the role of: E55 Type Propriedades não importadas: P15 was influenced by (influenced): E1 Provenance Entity P17 was motivated by (motivated): E1 Provenance Entity P19 was intended use of (was made for): E1 Provenance Entity P20 had specific purpose (was purpose of): E7 Activity P21 had general purpose (was purpose of): E55 Type P32 used general technique (was technique of): E55 Type P125 used object of type (was type of object used in): E55 Type Destacamos duas especializações de E5 Event que simbolizam eventos marcantes de uma história (state of affairs). 42 A propriedade P14.1 original é had participant (participates in)

119 Modelo de Proveniência 119 Id e nome: E63 Begin of Existence Nota de Escopo: representa eventos que simbolizam o início da existência de qualquer instância de CID2 Participant nascimento, criação, formação entre outros. Exemplo: a criação da Torre Eiffel para a exposição universal em 1889 ou a re-criação do Panteão de Agripa (Roma) em 125 d.c. Propriedades: P92 brought into existence (was brought into existence by): CID2 Participant Id e nome: E64 End of Existence Nota de Escopo: representa eventos que definem o fim da existência de qualquer instância de CID2 Participant morte, destruição, dissolução entre outros. Exemplo: a destruição do Panteão de Agripa (Roma) por um incêndio em 80 d.c. ou a morte de Alexandre O Grande na Babilônia em 323 a.c. Propriedades: P93 took out of existence (was taken out of existence by): CID2 Participant Classe importada de Sowa (1999) - CID2 Participant (Who) Id e nome da classe primária: CID2 Participant Subclasse de: CID1 Provenance Entity Superclasse de: nenhuma Escopo: identifica um participante do evento. O participante pode determinar ou não o que acontece, pode estar presente apenas no início ou no fim sem exercer nenhum tipo de controle no respectivo evento do qual participa. Exemplos: uma jaca que amassa o teto de um carro ou uma pessoa que a observa cair, de outra forma: um ladrão que quebra o vidro de um carro ou uma câmera que o filma. Propriedades: nenhuma Descrevemos os detalhes das especializações diretas da classe E5 Event. Porém, as subclasses destas classes não serão detalhadas aqui. A classe E51 Contact Point não foi importada para o modelo de proveniência mínimo, mas pode ser alvo de futuras expansões. Para maiores informações veja ISO[ALAM79] (2006) e Doerr et al. (2007).

120 Modelo de Proveniência 120 As classes E39 Actor e E18 Physical Thing da ISO 21127:2006 não foram importadas para o modelo mínimo porque consideramos que estão cobertas pela generalização proposta CID2 Participant. Sugerimos ao projetista considerá-las como possíveis especializações diretas ou indiretas de CID2 Participant para o domínio de aplicação que esteja em construção. Destacamos que a classe E39 Actor possui uma propriedade importada de (Pasin et al., 2007) que permite a representação de conceitos (E28 Conceptual Object) concebidos. Id e nome: E39 Actor Nota de Escopo: compreende pessoas, indivíduos ou grupos, que tem o potencial de atuar intencionalmente em ou observar ações, nas quais podem assumir responsabilidades. Exemplo: Marco Antonio Casanova (person) ou Representante de Alunos de Pós-Graduação (legal body) ou Comissão de Pós-Graduação (group) Propriedades: P74 has current or former residence (is current or former residence of): E53 Place P75 possesses (is possessed by): E30 Right P76 has contact point (provides access to): E51 Contact Point P131 is identified by (identifies): E82 Actor Appellation PID5 conceives (is conceived by): E28 Conceptual Object[ALAM80] Sugerimos que a expansão permita também representar que um participante intencional (E39 Actor) tenha concebido um conceito através da propriedade PID5 conceives (is conveived by). Id e nome: E18 Physical Thing Nota de Escopo: inclui todos os itens físicos, com relativa forma estável, naturais ou artificiais. Exemplo: A Mona Lisa ou Meu Notebook Propriedades: P45 consists of (is incorporated in): E57 Material P46 is composed of (forms part of): E18 Physical Thing P49 has former or current keeper (is former or current keeper of): E39 Actor P50 has current keeper (is current keeper of): E39 Actor

121 Modelo de Proveniência 121 P51 has former or current owner (is former or current owner of): E39 Actor P52 has current owner (is current owner of): E39 Actor P53 has former or current location (is former or current location of): E53 Place P58 has section definition (defines section): E46 Section Definition P59 has section (is located on or within): E53 Place Classe importada da ISO 21127: E53 Place (Where) Id e nome da classe primária: E53 Place Subclasse de: CID1 Provenance Entity Superclasse de: nenhuma outra classe Nota de Escopo: define a extensão no espaço no sentido físico: independente de fenômeno temporal (temporal phenomena) ou matéria (matter). Instâncias de E53 Place são usualmente determinadas pela referência a uma posição imóvel (prédio, cidade, montanha, rios, marcos geográficos). Um lugar (Place) pode ser determinado pela posição relativa a uma estrutura (frame) através da noção de seção (section), que pode assumir uma instância de E19 Physical Object como válida para determinação de E53 Place. Pode ainda ser identificada por uma ou mais instâncias da classe E44 Place Appellation, subclasse de E41 Appellation. Por fim, as instâncias de E53 Place podem ser também identificadas por coordenadas globais ou referências absolutas. Exemplos: Coordenada geográfica do meridiano de Greenwich ou endereço do Observatório de Greenwich em Londres. Propriedades importada e exibida 43 nas representações gráficas do modelo mínimo: P88 consists of (forms part of): E53 Place Propriedades importadas e não detalhadas 44 nas representações do modelo mínimo: P87 is identified by (identifies): E44 Place Appellation P89 falls within (contains): E53 Place 43 Com o objetivo de exemplificar uma propriedade que é um auto-relacionamento não qualificado. 44 Com o propósito de manter o foco da discussão sobre as propriedades mais relevantes.

122 Modelo de Proveniência 122 P121 overlaps with: E53 Place P122 borders with: E53 Place Classe importada da ISO 21127: E52 Time-Span (When) Id e nome da classe primária: E52 Time-Span Subclasse de: CID1 Provenance Entity Superclasse de: nenhuma outra classe Nota de Escopo: compreende extensões temporais abstratas que tenham início, fim e duração. Instâncias da classe E52 Time-Span não tem nenhuma outra conotação semântica a não ser a de definir uma extensão temporal para instâncias de E5 Event válidas durante certo intervalo. Um E52 Time-Span pode ser identificado com uma ou mais instâncias de E49 Time Appellation. Uma instância de E52 Time-Span durante a qual uma biblioteca foi construída pode recair em outro intervalo que corresponda ao mandato de um político, embora, muito provavelmente, não exista uma relação contextual ou causal entre ambas. Exemplos: A data da fixação ao teto do Panthéon e da demonstração do pêndulo de Foucault em Paris no ano de 1851, ou o intervalo que caracteriza a física de Galileu. Propriedades importada e exibida 45 nas representações gráficas do modelo mínimo: P86 falls within (contains): E52 Time-Span Propriedades importadas e não detalhadas 46 nas representações do modelo mínimo: P78 is identified by (identifies): E49 Time Appellation P79 beginning is qualified by: E62 String P80 end is qualified by: E62 String P81 ongoing throughout: E61 Time Primitive P82 at some time within: E61 Time Primitive Classe importada da ISO 21127: E28 Conceptual Object (Which, How e Why) 45 Com o objetivo de exemplificar uma propriedade que é um auto-relacionamento não qualificado. 46 Com o propósito de manter o foco da discussão sobre as propriedades mais relevantes.

123 Modelo de Proveniência 123 Id e nome da classe primária: E28 Conceptual Object Subclasse de: CID1 Provenance Entity Superclasse de: CID4 Reason, CID5 Means e E55 Type Nota de Escopo: compreende produtos não materiais do intelecto e informações produzidas por seres humanos com ou sem uso de aparatos tecnológicos que são objetos de discurso sobre identidade, circunstâncias de criação e implicações históricas. Caracteristicamente, instâncias desta classe são criadas, inventadas ou pensadas por algum E39 Actor ou classes que representem objetos de discurso que possuam racionalidade. Exemplos: a definição de World Wide Web de Tim Berners-Lee ou a obra de Michelangelo. Propriedades: nenhuma Agora, descrevemos os detalhes para as especializações diretas da classe E28 Conceptual Object. Id e nome: CID4 Reason (Why) Nota de Escopo: é qualquer motivação que descreva o Porquê (Why). Esta classe deve ser refinada pelo projetista de acordo com o domínio de aplicação. Exemplo: a rede da informática parou por mais de 24h porque houve uma catástrofe na sala dos equipamentos de rede. Propriedades: nenhuma Id e nome: CID5 Means (How) Nota de Escopo: é qualquer explicação que descreva o Como (How). Esta classe deve ser refinada pelo projetista de acordo com o domínio de aplicação. É necessária atenção para não confundir esta classe com suas variações, por exemplo, how come tem o mesmo significado que why. Exemplo: uma sequência de eventos, um arranjo de objetos no espaço, um encadeamento de idéias, um workflow ou um processo. Propriedades: nenhuma A classe E55 Type não é apresentada nas representações gráficas (Figura 3 e Figura 36) do modelo mínimo nem nas hierarquias de especializações (Tabela 17 e Tabela 18), propositalmente, com o único objetivo de focarmos a discussão nas classes mais relevantes.

124 Modelo de Proveniência 124 Id e nome: E55 Type (Which) Nota de Escopo: compreende conceitos arbitrários (universais) e prove um mecanismo para organizá-los em uma hierarquia. Exemplo: terremoto, maremoto e furacão são tipos de catástrofe natural. Propriedades: P127 has broader term (has narrower term): E55 Type P137 is exemplified by (exemplifies): CID1 Provenance Entity Propriedades[ALAM81] Tabela 19: Descrição das Propriedades do Modelo de Proveniência Id Descrição da propriedade Classedomínio Classe- Imagem Mult. P7 took place at (witnessed) E5 Event E53 Place P11 has participant (participates in) E5 Event CID2 Participant P4 has time-span (is time-span of) E5 Event E52 Time- Span PID1 has reason E5 Event CID4 Reason P14 carried out by (performed) E7 Activity CID2 Participant 0,n (1,n) 0,n (0,n) 1,n (1) 0,n 1,n (0,n) PID2 has arrangement E5 Event CID5 Means 0,n P92 brought into existence (was E63 Begin of CID2 brought into existence by) Existence Participant P93 took out of existence (was E64 End of CID2 taken out of existence by) Existence Participant P88 consists of (forms part of) E53 Place E53 Place P86 falls within (contains) E52 Time-Span E52 Time- Span 1,n (1) (1,n) 0,1 0,n (0,n) 0,n (0,n) Apresentamos na Tabela 19 para cada classe descrita (seção ), o identificador da propriedade, a descrição da propriedade e sua inversa entre

125 Modelo de Proveniência 125 parêntesis, a classe-domínio, a classe-imagem e a multiplicidade da propriedade (coluna Card.) e de sua inversa para as principais propriedades do modelo de proveniência. Para a lista completa de propriedades veja ISO[ALAM82] (2006) e Doerr et al. (2007) Expansões O projetista que expande o modelo mínimo deve se certificar de que a disjunção é preservada. Adicionalmente, recomendamos ao projetista que sempre consulte as fontes de importação a ontologia de topo de Sowa (1999), a Matriz de Perguntas de Wiederhold (1993), a ontologia DOLCE, o modelo FRBRoo e a ISO 21127:2006 durante o planejamento de expansões. Com isso, há maiores chances de potencializar a interoperabilidade do modelo estendido. Sugerimos três expansões para o modelo mínimo. A primeira é a expansão de ordem parcial (PO) (seção ). A segunda incorpora ao modelo mínimo a capacidade de rastreabilidade dos dados (seção ). Por fim, sugerimos a expansão para herança cultural (seção ) para domínios que precisem representar a noção de obra F1 Work e conceitos relacionados (seção ) presentes no modelo FRBR PO (Partial Order) Sugerimos[ALAM83] a noção matemática[alam84] de ordem parcial (partial order), abreviadamente PO, como uma extensão ao modelo mínimo. Uma ordem (total) é um caso particular de uma ordem parcial. Para os casos concretos (capítulo 4) expandiremos o modelo mínimo com a noção de ordem parcial. No modelo conceitual genérico de proveniência estamos interessados em ordens parciais de entidades temporais (E5 Event) porque nosso foco é a proveniência como um conjunto de descrições de qualquer mudança de um objeto de informação que registre sua história (eventos) e que seja significante para resguardar autenticidade, integridade e interpretação. Com isso, especializamos CID5 Means com a classe CID6 PO Event que descreve ordens parciais de eventos. Id e nome: CID6 PO Event

126 Modelo de Proveniência 126 Subclasse de: CID5 Means Nota de Escopo: representa uma ordem parcial de eventos entendida como uma explicação, ou seja, a representação sugerida por esta expansão, como resposta a pergunta Como (How). Exemplo: uma sequência de eventos ou um projeto Propriedades: PID4 arranges: E5 Event A expansão PO permite também propor outras evoluçõescomo a representação de ordens parciais de participantes (CID2 Participant) ou objetos conceituais (E28 Conceptual Object), respectivamente, por exemplo, um layout dos móveis em uma sala e uma ontologia de domínio. Neste caso, especializaríamos CID5 Means em CID8 PO Participant e CID9 PO Conceptual Object. Acrescentamos ainda, que a classe Course of Events padrão D&S da DOLCE poderia ser uma especialização (natural) futura da classe CID6 PO Event. Analogamente, sugerimos que a classe E29 Design or Procedure do modelo CIDOC CRM poderia ser uma especialização de CID5 Means. Consultando a Figura 37 (cópia da Figura 1 da seção 1.1), identificamos ao topo: Fornecedor, Produtor, Transformador e Distribuidor que representam etapas da produção arranjos de atividades e lotes - que podemos considerar como ordens parciais que descrevem o Como (How) da respectiva[alam85] etapa[mac86]. Figura 37: R[ALAM87]astreabilidade na Cadeia Produtiva baseado em (Bechini et al., 2005)

127 Modelo de Proveniência 127 Acrescentamos que a noção de projeto pode ser representada como uma ordem parcial de eventos (E5 Event) ou uma ordem parcial de atividades (E7 Acitivity) com duração e relacionamentos causais (CID4 Reason) entre si. A noção ordem parcial de atividades com apenas um relacionamento dedutível - ordem cronológica dos eventos a partir de respectivos timestamps - pode ser encontrada no Projeto DrProject 47 inspirado na ferramenta[alam88] Trac (seção 4.5.3). Também é possível encontrar a noção de ordem parcial em cronogramas construídos a partir da ferramenta Microsoft Project 48. Um projeto pode ser interpretado como um DAG de atividades (E7 Activity). Sowa (2001a) argumenta que os processos governados por leis (lawgoverned process) estão em algum ponto intermediário entre o caos e o determinismo absoluto. Por exemplo, a lei da gravidade impõe restrições suficientes para sabermos onde a água cai da ducha do banheiro, logo onde devemos ficar em pé para tomarmos banho, mas não é suficiente para prever a trajetória exata de cada gota de água (Sowa, 2001a). Com base nessa realidade, Sowa define que: Um evento é uma especialização de um processo discreto (tem início e fim conhecidos); Um processo discreto é um grafo acíclico direcionado cujos nós podem ser eventos ou estados. Portanto, um processo discreto consiste em instâncias de eventos ou estados; Um procedimento (procedure) é uma família tipos de eventos ou tipos de estados de processos discretos que podem ter ciclos. Apesar de permitidos, estes ciclos não promovem um retorno no tempo, mas apenas a alguma instância do mesmo tipo de evento ou tipo de estado. A Figura 38 (Sowa, 2001a) ilustra três exemplos de notações gráficas diferentes para a representação de procedimentos: um fluxo (Flow Chart), onde os eventos são simbolizados pelos quadrados e as decisões por diamantes; uma máquina de estados finita (Finite-State Machine), onde os círculos simbolizam os estados e os arcos as transições entre estados; uma Rede Petri (Petri Net) considerada uma fusão dos dois últimos procedimentos onde os círculos são

128 Modelo de Proveniência 128 estados (places) e as barras entre arcos são eventos (transitions). (Sowa, 2001a) Figura 38: Três notações gráficas para especificação de procedimentos (Sowa, 2001a) Com isso, podemos concluir que a noção de ordem parcial que adotamos para a classe CID6 PO Event contempla a representação de processos discretos onde os nós são eventos. Analogamente, o modelo mínimo com a expansão PO cobre a noção de projeto, uma vez que uma atividade (E7 Activity) é uma especialização de um evento (E5 Event) TR (TRaceability TRace and TRack) Rastreabilidade como a capacidade de realizar consultas para rastrear a origem (trace) e rastrear o destino (track) (Dorp, 2004). Rastrear dados é realizar consultas a proveniência (seção 1.1). O modelo mínimo não restringe como o projetista deve planejar a rastreabilidade e oferece apenas a propriedade, e não oferece sua inversa, que liga um evento (E5 Event) a uma motivação (CID4 Reason) ou analogamente, um evento a uma explicação (CID5 Means) RQR (Reification of Qualified Relations) O primeiro relacionamento (propriedade) que nos interessa explorar é o auto-relacionamento qualificado entre eventos. Para criar essa noção nesta expansão, especializamos a classe CID4 Reason em CID7 Event Reason, que representa a reificação do relacionamento e que tem a função de atribuir uma justificativa, intenção, motivo ou causa à ligação entre eventos. Por isso,

129 Modelo de Proveniência 129 possibilita a captura de relacionamentos que não podem ser deduzidos, bem como a representação de eventos complexos. Comentamos que um relacionamento dedutível seria, por exemplo, uma linha do tempo a partir dos timestamps dos eventos. Id e nome: CID7 Event Reason Subclasse de: CID4 Reason Nota de Escopo: o auto-relacionamento entre eventos é explicitado através de atributos ou propriedades que representam respostas a pergunta Por que (Why), portanto, atribuindo mais significado ao dado (E5 Event). A propriedade PID3 is reason to é a inversa, não representada no modelo mínimo, à propriedade PID1 has reason que tem classe-domínio E5 Event e classe-imagem CID4 Reason. Exemplo: a pintura do Juízo Final na Capela Sistina sobrepôs (CID7) a pintura de uma imagem da Virgem da Assunção de Perugin; o evento de assinatura do acordo de Crimea é parte do (CID7) evento da Conferência de Yalta. Propriedades: PID3 is reason to: E5 Event A expansão do modelo mínimo a partir da adição de outros autorelacionamentos entre instâncias de CID2 Participant ou entre instâncias de E28 Conceptual Object possibilitaria a representação de instâncias complexas. Por exemplo, no primeiro caso, poderíamos capturar a noção de que o filé mignon é parte de um boi, ou cada um de três diferentes quadros é parte de um tríptico. No segundo caso, seria possível imaginar que um campo de estudo é comum a uma área de pesquisa ou uma teoria e uma escola de pensamentos são partes de uma ciência. Optamos por não representar no modelo mínimo tais autorelacionamentos, delegando tal decisão para o projetista do domínio. Com isso, o modelo conceitual genérico para proveniência ratifica sua resiliência, podendo oferecer uma opção de recuperação do dado flexível à demanda do domínio que instancia o modelo. Concluímos, retomando o exemplo do boi, que seria possível então a partir de uma consulta ao evento de abate do boi se chegar através do autorelacionamento entre CID2 Participant até o filé mignon. Adicionalmente, uma consulta a eventos que se referem ao mesmo boi permitiria validar se o filé mignon é proveniente de um boi que foi vacinado contra a doença da vaca-louca.

130 Modelo de Proveniência 130 Este seria um dado que não está representado no banco de dados, porém pode ser obtido através de uma consulta, fixando uma das facetas da proveniência: CID2 Participant (Who) DISP (Determinant, Immanent, Source Product) Adicionalmente ao auto-relacionamento, o rastro para origem ou para o destino de cada atividade (E7 Activity) especializações de eventos (E5 Event) pode interessar ao projetista que tem como objetivo a identificação de quais são as respectivas entradas (Sources) e saídas (Products). Além disso, o domínio onde será aplicada a expansão do modelo mínimo pode necessitar a representação distinta de participantes: os que controlam o curso de um evento (Determinant) e os que são expectadores meramente aderentes (Immanent) a ele. A expansão DISP pode ser facilmente alcançada a partir da importação das classes Determinant, Immanent, Source e Product da ontologia de topo de Sowa (2001b). Estes conceitos dão origem a outras classes especializadas que Sowa (2001b) define como papéis temáticos (Thematic Roles). É interessante destacar aqui que na ontologia de topo de Sowa a classe Role está a muitos níveis acima da classe Participant, portanto, um participante é então uma especialização indireta de um papel. Acrescentamos ainda que o conceito de agente também aparece na hierarquia de especialização proposta por Sowa e pode ser generalizado para o conceito de participante. Id e nome: CID10 Determinant Subclasse de: CID2 Participant Nota de Escopo: um determinante participa da direção de um processo, seja para iniciá-lo, alterar o seu fluxo ou encerrá-lo. (Sowa, 2001b) Exemplo: um programador Java que codifica um componente Propriedades: nenhuma Id e nome: CID11 Immanent Subclasse de: CID2 Participant Nota de Escopo: um imanente (aderente) é um participante que está presente durante todo o processo, mas não controla ativamente o que acontece.(sowa, 2001b)

131 Modelo de Proveniência 131 Exemplo: a IDE (Integrated Development Environment) MyEclipse 49 Propriedades: nenhuma Id e nome: CID12 Source Subclasse de: CID2 Participant Nota de Escopo: uma fonte (Source) deve estar presente no início do processo, mas não precisa estar presente durante o processo (Sowa, 2001b) Exemplo: um documento de especificação de requisitos funcionais Propriedades: nenhuma Id e nome: CID13 Product Subclasse de: CID2 Participant Nota de Escopo: um produto (Product) deve estar presente ao final do processo, mas não precisa estar presente durante o processo (Sowa, 2001b) Exemplo: a versão release candidate de um componente de software Propriedades: nenhuma Por fim, sugerimos a seguir a classe CID3 Functional Role como uma possível opção para a representação de papéis. Essa classe seria a reificação da propriedade P14.1 in the role of da ISO 21127:2006 que tem classe-imagem E55 Type. Id e nome: CID3 Functional Role (Which) Subclasse de: E28 Conceptual Object Nota de Escopo: compreende responsabilidade causal ou legal quando definido para instâncias de CID2 Participant e restrições de papéis a serem desempenhados em atividades E7 Activity. Exemplo: o papel de incendiário voador é desempenhado por um dragão (CID2), ou apenas um incendiário voador pode desempenhar a atividade de cuspir fogo (E7). Propriedades: PID6 performs (carried out by): E7 Activity PID7 played by (plays): CID2 Participant 49

132 Modelo de Proveniência 132 Neste caso, a classe tem dois pares de relacionamentos (com inversa) que a ligariam à classe CID2 Participant (ou alguma de suas especializações) e à classe E7 Acitivity. O papel poderia ser descrito de forma geral por instâncias de E55 Type ou mais restrita a partir de uma enumeração CH (Cultural Heritage) Para as classes desta expansão adotamos a nomenclatura padrão para identificação das classes das fontes de construção, analogamente como fizemos na descrição do modelo mínimo. Acrescentamos que as classes do modelo FRBRoo, se importadas em expansões do modelo, devem ser identificadas pela letra F seguida de um número para o id da classe. Da mesma forma, as propriedades do modelo FRBRoo são identificadas pela letra R seguida de um número. Descrevemos então as classes desta expansão: Id e nome: F1 Work Subclasse de: E28 Conceptual Object Nota de Escopo: inclui a soma de conceitos que afloram no curso de evolução de uma idéia original. Pode ser encontrado através de uma ou mais expressões que são dominadas pela mesma idéia. Uma obra (Work) pode ser produzida por mais de um E39 Actor simultaneamente ou através do tempo. Uma obra pode ter componentes que constituem o conceito geral. Um volume de uma trilogia representa apenas uma parte do conceito geral. Exemplo: Hamlet de William Shakespeare ou David de Gian Lorenzo Bernini ou o padrão D&S da DOLCE. Propriedades: R1 has constraining supertype (is constraining supertype of): E55 Type R2 has representative expression (is representative expression for): F2 Expression R57 is logical successor of (has successor): F1 Work R58 is derivative of (has derivative): F1 Work R65 is realised in (realises): F2 Expression Id e nome: E73 Information Object Subclasse de: E28 Conceptual Object

133 Modelo de Proveniência 133 Superclasse de: F3 Expression Nota de Escopo: inclui itens imateriais identificáveis como poemas, piadas, imagens, algoritmo, entre outros, que tenha uma estrutura reconhecível objetivamente. As instâncias de E73 Information Object não dependem de uma instância de E84 Information Carrier. Instâncias conceituais como tipos ou classes não são instâncias de E73 Information Object, bem como idéias sem uma forma de expressão reproduzível. Exemplo: imagem do Pão de Açúcar ou o filme[mac89] A Cidade Perdida de Andy Garcia. Propriedades: P67 refers to (is referred to by): CID1 Provenance Entity P106 is composed of (forms part of): E73 Information Object P129 is about (is subject of): CID1 Provenance Entity Id e nome: F3 Manifestation Product Type Subclasse de: E55 Type Nota de Escopo: inclui as definições de produtos de publicações. Uma instância de F3 Manifestation Product Type é a espécie da publicação (jornal, revista etc) Exemplo: o formato ASCII ou binário do padrão D&S da DOLCE codificado na linguagem Java ou jornal, periódico, revista. Propriedades: P2 should have type (should be type of): E55 Type P46 should be composed of (may form part of): F3 Manifestation Product Type P57 should have number of parts: E60 Number P104 subject to (applies to): E30 Right P105 right held by (right on): E39 Actor Agora, descreveremos os detalhes para as especializações diretas da classe E73 Information Object. Essa classe possui outras especializações que não detalharemos aqui, porque estamos focando a atenção nas classes que são relevantes para nossa discussão. Para maiores informações veja ISO[ALAM90] (2006) e Doerr et al. (2007). Id e nome: F2 Expression

134 Modelo de Proveniência 134 Subclasse de: E73 Information Object Nota de Escopo: compreende a realização de trabalhos artísticos ou intelectuais de uma obra, na forma de itens imateriais identificáveis. Expressão é a linguagem na qual a obra (F1 Work) se expressa. Expressões não existem sem sua respectiva instância de E84 Information Carrier. Exemplo: o padrão D&S da DOLCE na linguagem Java ou Prolog Propriedades: R3 has representative manifestation product type (is representative manifestation product type for): F3 Manifestation Product Type R11 is composed of (forms part of): F2 Expression As classes a seguir seriam as especializações indiretas de CID2 Participant que poderiam ser importadas para expansões do modelo de forma a mapear conceitos de domínios de biblioteconomia, e-commerce ou outro que demande a representação da noção de veículo de persistência. Sugerimos que ambos os conceitos estejam presentes nesta expansão na hierarquia de especialização descrita porque está alinhada ao resultado da harmonização do modelo FRBRoo com a ISO 21127:2006. Id e nome: E84 Information Carrier Subclasse de: E22 Man-Made Object Superclasse de: F5 Item Nota de Escopo: inclui todas as instâncias de E22 Man-Made Object que são explicitamente projetadas para atuar como veículo de persistência física para instâncias da classe E73 Information Object. Isto permite que relacionamentos sejam estabelecidos entre E19 Physical Object e um respectivo conteúdo imaterial. Um E84 Information Carrier pode ou não conter informação. Algumas classes não descritas aqui, porém podem ser encontradas no ISO[ALAM91] (2006) e Doerr et al. (2007). Exemplo: A pedra Rosetta (Rosetta Stone) Propriedades: nenhuma Id e nome: F5 Item Subclasse de: E84 Information Carrier Nota de Escopo: compreende objetos físicos que carregam uma expressão de publicação produzida por algum processo industrial que envolve uma instância de F3 Manifestation Product Type.

135 Modelo de Proveniência 135 Exemplo: o item impresso desta dissertação ou um DVD com todo o material pesquisado. Propriedades: R10 is example of (has example): F3 Manifestation Product Type Apresentamos nas Tabela 20 e Tabela 21 algumas propriedades das classes desta expansão. Para maiores informações veja ISO[ALAM92] (2006) e Doerr et al. (2007).

136 Modelo de Proveniência 136 Tabela 20: Descrição das Propriedades do Modelo de Proveniência (parte 1 de 2) Id Descrição da propriedade Classe- (Descrição da propriedade Classe-domínio Imagem inversa) R1 has constraining supertype (is constraining supertype of) F1 Work E55 Type R2 has representative expression (is representative expression for) F1 Work F2 Expression R57 is logical successor of (has successor) F1 Work F1 Work R58 is derivative of (has derivative) F1 Work F1 Work R65 is realised in (realises) F1 Work F2 Expression P2 should have type (should be type of) F3 Manifestation Product Type E55 Type P46 should be composed of (may form part of) F3 Manifestation Product Type F3 Manifestatio n Product Type P57 should have number of parts F3 Manifestation Product Type E60 Number P104 subject to (applies to) F3 Manifestation Product Type E30 Right P105 right held by (right on) F3 Manifestation Product Type E39 Actor P67 refers to (is referred to by) E73 Information Object CID1 Provenance Entity P106 is composed of (forms part of) E73 Information Object E73 Information Object

137 Modelo de Proveniência 137 Tabela 21: Descrição das propriedades da expansão (parte 2 de 2) Id Descrição da propriedade (Descrição da propriedade inversa) Classe-domínio E73 Information P129 is about (is subject of) Object has representative manifestation product type (is representative manifestation R3 product type for) F2 Expression R11 is composed of (forms part of) F2 Expression Classe- Imagem CID1 Provenance Entity F3 Manifestatio n Product Type F2 Expression Exploraremos (capítulo 4) os casos concretos do modelo conceitual genérico para proveniência aplicando o modelo mínimo com a expansão PO.

138 4 Aplicações do Modelo de Proveniência Para a análise do modelo conceitual de proveniência, também referenciado como modelo de proveniência, avaliamos quatro diferentes domínios de aplicação. Inicialmente, as preliminares apresentam a importância de uma API de serviços para proveniência e como consultas a proveniência poderiam ser estruturadas (seção 4.1). Em seguida, utilizamos dois domínios como motivação: o primeiro domínio analisa a aplicação do modelo sob a perspectiva de aplicações semânticas para desktops (seção 4.2) e o segundo domínio propõe a discussão do modelo como uma possível generalização a ser considerada para Design Rationale (seção 4.3). Em seguida, no terceiro domínio realizamos um estudo preliminar (seção 4.4) que sugere a adoção do modelo conceitual de proveniência para o desenvolvimento de um centro de informações que tem atribuições de registrar a história de um empreendimento. Por fim, concluímos nossa avaliação com o quarto domínio (seção 4.5), que utiliza dados reais de um projeto de catálogo, a partir do mapeamento da ferramenta adotada pela equipe de desenvolvimento para o gerenciamento de configuração de software Preliminares Relembramos aqui que Simmhan et al. (2005) conclui que o projeto PASOA (Moreau & Ibbotson, 2006) está na direção certa ao buscar a definição de uma API para proveniência, mas ressalta que precisa de maiores refinamentos para elucidar como a proveniência é representada e recuperada. Acrescenta ainda que qualquer padrão proposto para proveniência deve satisfazer as necessidades de múltiplos domínios, e tais requisitos necessitam ser identificados. Conclui, apontando que um deles é seguramente a padronização da semântica de termos. Bose & Frew (2005) esclarecem algumas questões gerais que podem servir de guias para métodos de recuperação de linhagem (lineage) utilizados para sistemas protótipos: como alguém pode navegar pela linhagem de um item em um sistema? Quais métodos são utilizados para a recuperação da linhagem? Quais consultas relativas à linhagem podem ser feitas a um sistema? Como são os resultados dessas consultas? Bose & Frew (2005) respondem que qualquer

139 Aplicações do Modelo de Proveniência 139 navegador deveria poder acessar um objeto de linhagem, onde o usuário fornece um identificador de um item de interesse e especifica a quantidade de níveis de linhagem para trás ou para frente a serem recuperadas. Descreve ainda que, no caso do sistema ESSW (Bose & Frew, 2005), a aplicação utiliza consultas recursivas em SQL retorna os resultados como um grafo no formato GraphViz 50 de objetos científicos. Conclui que, clicando em qualquer objeto do grafo, o respectivo metadado pode ser visualizado Aplicações de Desktop Semântico A modelagem de proveniência pode ser explorada para apoiar a recuperação e análise de dados baseados em contexto, por exemplo, para a construção de aplicações para desktop semântico (Marins et al., 2007). Com o atual volume de informação disponível para consulta através da Web, validade e propriedade intelectual tornam-se, mais do que nunca, essenciais. Ambos estão listados entre os problemas a serem atacados pela comunidade Científica de Computação, ao final da seção 2 do documento (Carvalho et al., 2006). Permitem questionamentos relacionados à proveniência: "É possível confiar na validade de uma dada informação? De onde veio?. Ou simplesmente, qual a sua origem? Em setembro de 2006, o mecanismo de indexação do Google processou 850 TB de dados brutos coletados da Web. Considerando que o crawler tem uma capacidade de compressão de 11%, estamos falando de 8.5 Peta Bytes de dados disponível on line (Chang et al., 2006). Sem contar com transmissões de rádio e TV, que ainda não estão totalmente digitalizadas ainda, uma pessoa pode encontrar (e comprar) praticamente qualquer informação em formato digital. As listas de divulgação comercial escalaram com a venda de listas de usuários de cartões de crédito (acima de três bilhões de números), arquivos criminais (100 milhões), o nome e o endereço de cada cidadão Mexicano, identidade e telefone de cada Argentino, como anunciado pelas companhias LexisNexis e Choice Point (Gaspari, 2005). 50

140 Aplicações do Modelo de Proveniência 140 Em virtude do crescimento exponencial dos dados digitais, é virtualmente impossível para seres humanos, gerenciar a complexidade e volume de informações disponíveis. O perigo é a criação de banco de dados somente de leitura ( write only databases), nos quais a informação é constantemente armazenada, mas impossível de ser minerada para propósitos significativos. Este fenômeno levanta uma ameaça à usabilidade da Web atualmente. Novas abstrações são necessárias para ajudar a modelagem e sumário de volumes massivos de dados para uma dimensão processável pelas pessoas. Pesquisadores da indústria, governo e academia estão agora explorando a possibilidade de criar uma Web com mais significado (semântica) na qual o conhecimento é colocado de forma mais explícita, permitindo que máquinas, em oposição a humanos, processem e integrem recursos de forma inteligente. (Breitman et al., 2007). As aplicações para desktop semântico exploram tecnologias inovadoras da Web Semântica para oferecer uma solução computacional para o que é conhecido como problema da sobrecarga de informação (information overload problem). Em particular, o uso de metadados de proveniência pode ser aplicado para melhorar a recuperação e análise de dados baseado em contexto no ambiente da computação pessoal. Aplicações para desktop semântico, em geral, se beneficiariam de um modelo de proveniência, tornando-se então, aplicações aptas a recuperar proveniência (provenance-ready applications). A metáfora de área de trabalho e interface de trabalho (desktop interface) ajudam indivíduos a gerenciar dados armazenados em seus computadores pessoais e representam um ponto de entrada único para as aplicações disponíveis para produzir, armazenar, acessar e gerenciar objetos digitais pessoais ou corporativos. O conjunto de métodos, estrutura de dados e ferramentas que estendem a área de trabalho e atribuem um significado bem definido representa o que se convencionou chamar de área de trabalho semântica (semantic desktop). Se a palavra social (Chernov et al., 2006) é adicionada como sufixo, então significa que a área de trabalho está habilitada a trocar dados além das fronteiras individuais e com isso melhorar a colaboração on line e ajudar na organização dos dados criados por um grupo de usuários. Rastrear a origem do dado, através da utilização de metadados de proveniência, é uma forma interessante em atribuir mais significado ao dado. [MAC93]Metadados de proveniência incluem relacionamentos relevantes entre fatos, pessoas, publicações e qualquer outro objeto digital, bem como a resenha histórica entre essas entidades.

141 Aplicações do Modelo de Proveniência 141 Aplicações de desktop oferecem inúmeras oportunidades de captura de metadados de proveniência. Por exemplo, quando um anexo de uma mensagem de correio eletrônico é salvo no disco rígido, as informações sobre a conexão deste arquivo e quem o enviou podem ser armazenadas com metadados de proveniência. Quando se abre o navegador a partir de um link no corpo de uma mensagem e se faz o download de um arquivo daquela página Web, também oferece um rico conjunto de metadados de proveniência para este arquivo. Estes dois exemplos ilustram porque aplicações de desktop devem ser instrumentalizadas para salvar e armazenar metadados de proveniência, que serão utilizados mais tarde para a recuperação dos dados. Idealmente, os metadados de proveniência devem ser coletados de todas as aplicações de desktop para permitir que mais significado seja armazenado e não apenas o conteúdo. A ferramenta de indexação e recuperação de conteúdo no desktop é uma tecnologia base para explorar diferentes tipos e formatos de conteúdos locais. A Figura 39 apresenta um framework simplificado para aplicações de desktop semântico, adaptado de (Sauermann, 2005). Várias soluções de buscadores para desktop (desktop search), como o Google Desktop, Microsoft Desktop, Copérnico Desktop e Beagle, recentemente surgiram para suprir a dificuldade de recuperação de informações armazenadas nos computadores pessoais. Boa parte delas ainda não é compatível com proveniência. [ALAM94] Figura 39: Arquitetura Simplificada para Desktop Semântico O gerenciador semântico (Semantic Manager) interfaceia entre empacotadores (provenance wrappers) de proveniência, contexto do usuário e

142 Aplicações do Modelo de Proveniência 142 ontologias de domínio disponíveis, para coletar os dados de proveniência. Na camada final da arquitetura, no meio da Figura 39, temos o componente de busca do desktop que idealmente deve estar disponível e integrado a todos os aplicativos. Esse componente de busca no desktop (desktop search) indexa, armazena e consolida localmente as informações pessoais. Também habilita a consulta ao conteúdo, ordenando e classificando os resultados a partir dos metadados de proveniência. Aplicações semânticas seriam, entre outras, aplicações de desktop enriquecidas com a capacidade de capturar e recuperar a proveniência. Assim, essa instanciação sugere que o armazenador de metadados tradicional deve ser repensado como um componente dedicado a armazenar os metadados de proveniência (provenance storage). Um possível caminho para construção desse componente apresentado na Figura 40, é a aplicação direta do modelo de proveniência (seção 3.6). Nessa figura, os índices de conteúdo e de metadados de proveniência estão fisicamente separados. Os metadados têm demandas de gerenciamento distintas das de conteúdo. Por exemplo, requer políticas e procedimentos de arquivamento e descarte específicos. O lado esquerdo da Figura 40, ilustra que sempre que um evento ocorre no sistema operacional, por exemplo, o salvamento de um anexo de uma mensagem eletrônica, os empacotadores de conteúdo e proveniência são acionados e responsáveis por suas respectivas indexações criando um fluxo unidirecional do evento até os índices. Figura 40: Arquitetura de Busca em Desktop Semântico baseada no Beagle ++ Por outro lado, à direita o fluxo bi-direcional representa a consulta a esses índices. A ordenação e classificação do resultado são dadas por palavras-chave

143 Aplicações do Modelo de Proveniência 143 que estejam no conteúdo (filtros de conteúdo) ou pelos metadados de proveniência (filtros de proveniência). Questões relacionadas à granularidade, escalabilidade e segurança colocadas por (Braun et al, 2006) influenciam a modelagem do armazenador dos metadados de proveniência. Na verdade, o item segurança, é crucial para identificar entidades confiáveis, estabelecer propriedade, controlar acesso, registrar dados de auditoria e rastrear mudanças. Recuperar a informação de proveniência é uma consulta ao modelo de proveniência a procura de um ou mais objetos. Uma consulta a proveniência tipicamente possui dois tipos de filtros (Miles, 2006): Manipulador do dado (query data handle), que identifica objetos de interesse; Filtro para relacionamentos (relationship target filter), que define o escopo da consulta, restringindo o resultado a um volume processável; A Figura 41 ilustra um exemplo, baseado no Beagle++, com o resultado de uma consulta apresentando três itens que foram retornados a partir de uma pesquisa pelos termos semantic desktop. O item retornado corresponde a um que contém um artigo anexado. O destaque da elipse identifica a ligação desse anexo com o seu contexto. Figura 41: Resultado de uma consulta semântica A Figura 42 é o detalhamento da elipse destacada na Figura 41, identificando com retângulos os conceitos abstratos de proveniência associados a cada parte do contexto, neste caso, referente à publicação do artigo que está em anexo ao , e corresponde respectivamente ao item retornado, apresentado na Figura 41.

144 Aplicações do Modelo de Proveniência 144 Nesse mesmo exemplo, poderíamos identificar outro evento que seria o evento relacionado ao envio da mensagem propriamente dita. Seria então, importante, identificar quem enviou a mensagem e a data de recebimento, o que respectivamente já associaria dois conceitos abstratos de proveniência. Figura 42: Conceitos de Proveniência ajudam a organizar e classificar o resultado de uma consulta semântica Generalização para Design Rationale[ALAM95] Outra aplicação do modelo de proveniência é referente à generalização de design rationale, usualmente adotado para representar esquemas baseados em argumentação porque oferece uma infra-estrutura para identificar quais decisões foram tomadas e quais os motivos relacionados. O modelo de proveniência adota o conceito de um conjunto de descrições de qualquer mudança de um objeto de informação, que registre sua história e que seja significante para resguardar autenticidade, integridade e interpretação, e pode ser visto como uma generalização para design rationale. Medeiros (2006) descreve o modelo Kuaba, apresentado na Figura 43, como um conjunto de elementos (classes, propriedades, relações e restrições) que expressam o domínio de design rationale. Acrescenta que permite a representação explícita das decisões tomadas durante o projeto de software e

145 Aplicações do Modelo de Proveniência 145 suas justificativas. Além disso, captura as relações entre os elementos de argumentação e os artefatos gerados, e inclui também, a integração da estrutura de argumentação com as descrições dos artefatos produzidos e com informações sobre a história de projeto do artefato: quando as decisões foram tomadas, quem tomou as decisões, que método de design foi utilizado etc. Essas são perguntas que podemos interpretar como consultas a proveniência das decisões. Há claramente a preocupação com a rastreabilidade do raciocínio utilizado ao longo do ciclo de desenvolvimento de um software, ratificado pela necessidade de registro da história. Figura 43: Modelo Kuaba e conceitos abstratos adaptado de (Medeiros, 2006) Focaremos nossa análise no mapeamento entre elementos do modelo Kuaba e classes do modelo de proveniência. Breitman et al. (2007) argumenta que mapas de analogia facilitam a modelagem conceitual permitindo que o projetista reinterprete fragmentos de modelos conceituais conhecidos em outros contextos. Analogamente à construção do modelo, iniciamos identificando qual classe representa o conceito de evento no modelo Kuaba. O principal propósito do modelo é identificar quais decisões foram tomadas e quais os motivos relacionados.. As decisões são então os eventos que estamos interessados. A Tabela 22 propõe um mapeamento entre elementos do modelo Kuaba e conceitos do modelo de proveniência.

146 Aplicações do Modelo de Proveniência 146 Tabela 22: Analogia entre Design Rationale e Proveniência Elemento Kuaba Conceito de Proveniência Conceito Abstrato Decisão E5 Event What Duração Prevista E52 Time-Span When Atividade E7 Activity - Método CID5 Means How Pessoa CID2 Participant Who Justificativa CID4 Reason Why Papel CID3 Functional Role Which Artefato Artefato Atômico CID2 Participant Who Artefato Complexo Tipo da Relação E55 Type? Elemento de Raciocínio Modelo Formal Questão Idéia Argumento E28 Conceptual Object?? E53 Place Where Os pontos de interrogação? da Tabela 22 representam questionamentos não resolvidos neste exercício e demandam maior aprofundamento que não exploraremos nesta dissertação. Todas as propriedades existentes no modelo Kuaba devem ser analisadas com maior profundidade para avaliar quais propriedades do modelo de proveniência podem ser reusadas e quais precisam ser especializadas ou compostas. Uma possibilidade seria utilizar a expansão DISP (seção ) a partir da importação das classes Determinant, Immanent, Source e Product da ontologia de topo de Sowa (2001b). Os artefatos atômicos e complexos poderiam ser então instâncias de Source ou Product, ou de suas especializações. No modelo Kuaba há um relacionamento ternário entre Atividade, Papel e Pessoa. Com isso, outra importação seria necessária: a classe Functional Role da DOLCE, por exemplo, seria importada para o modelo como a classe CID3 Functional Role, para possibilitar a reificação da propriedade P14.1 in the role of presente no modelo conceitual. Neste caso, também seriam necessários a criação de dois pares de relacionamentos (com inversa) que ligariam: a classe CID3 Functional Role à classe CID2 Participant (ou alguma de suas especializações) e à classe E7 Acitivity. Por hora, esta dissertação não avançará a análise, deixando-a como proposta para ser estudada como alternativa para o projetista do domínio de Design Rationale.

147 Aplicações do Modelo de Proveniência 147 Avançaremos agora para um exemplo mais abrangente, acrescentando um estudo preliminar de um centro de informações que adota o modelo de proveniência para a preservação digital (seção 4.4) Centro de Informações Ao longo desta seção realizaremos um estudo preliminar da aplicação do modelo de proveniência para um centro de informações (CI) de um empreendimento. Um CI envolve uma grande variedade de elementos - textos, planilhas, apresentações, dados geográficos (mapas), mídia contínua (áudio e vídeo), imagens (fotos), entre outros - que referenciaremos aqui como documentos. A principal atribuição de um centro de informações é a organização destes documentos com o objetivo de atender a preservação digital e registrar a história do empreendimento. Um centro de informações consolida o conteúdo indicado por entidades produtoras, garante sua preservação e fornece acesso para que consumidores o consultem. A Figura 44 representa o modelo funcional adaptado da ISO 14721:2003 (seção ), para sistemas abertos de arquivamento de informação, que pode ser adotado também como ilustração para as macro funções de um centro de informações. Descrevemos agora sucintamente as macro funções da Figura 44. A Admissão: oferece serviços e processos necessários para aceitar os conteúdos indicados pelos produtores. O Arquivamento (archival) é responsável por arquivar, manter e recuperar os conteúdos que passaram pela Admissão. O Gerenciamento de dados (storage) suporta a inclusão, manutenção e acesso de informações descritivas, que identificam e documentam os conteúdos, bem como os dados propriamente ditos. A Administração do sistema opera o sistema como um todo. O Planejamento da preservação gerencia e monitora o ambiente, registrando as mudanças, com objetivo de assegurar que a história seja preservada no longo prazo. Por fim, a função de Acesso apóia os consumidores na determinação da existência, descrição e localização dos dados armazenados.

148 Aplicações do Modelo de Proveniência 148 Figura 44: Modelo Funcional de um Centro de Informações adaptado da ISO 14721:2003 O foco de nosso estudo está na função de preservação mais especificamente, na proveniência, que a ISO 14721:2003 (seção ) considera como parte da informação de descrição de preservação. A informação de descrição de preservação é composta por informação de referência, de proveniência, de contexto e de fixidez (fixidity) (veja detalhes na seção ). A proveniência definida pela informação de descrição de preservação da ISO 14721:2003 é a informação que documenta o histórico de uma informação de conteúdo: relato da origem ou da fonte da informação de conteúdo e mudanças de custódia desde a sua produção. Lembramos que a ISO 14721:2003, em muitos casos, utiliza o termo informação de proveniência quando o termo que consideramos correto seria dado de proveniência. A proveniência a que se refere o modelo conceitual de proveniência (seção 3.6) é a de um conjunto de descrições de qualquer mudança de um objeto de informação que registre sua história e que seja significante para resguardar autenticidade, integridade e interpretação. A definição de proveniência do modelo de proveniência é mais ampla porque não se restringe apenas à custódia. Todos os fatos geradores que representam a história como um conjunto de mudanças e suas respectivas descrições são potenciais eventos a serem representados por um CI. Assim, prosseguimos como nas outras aplicações do modelo conceitual de proveniência descritas ao longo deste capítulo e, identificamos os eventos de interesse de um centro de informações. O centro de informações de um empreendimento é construído em paralelo a diversos eventos que devem ser registrados. Elegemos como exemplo, os

149 Aplicações do Modelo de Proveniência 149 eventos que simbolizam a história da construção civil do próprio centro de informações. Considere também que, a cada evento descrito, há diferentes documentos associados e que a produção de cada documento associado ao evento pode ser interpretada como uma atividade. No exemplo que descreveremos a seguir, não estamos preocupados em definir como será o acesso a estes metadados. Começamos pelo mapeamento de conceitos para descrever eventos e documentos. As instâncias da classe E5 Event seriam os eventos e as instâncias da classe E7 Activity as atividades que produziram algum documento. Imagine que no dia 14 de junho de 2007 (E52 Time-Span), os moradores da região (CID2 Participant) como expectadores (P14.1 in the role of) participaram juntamente com o Sr. Fulano de Tal (CID2 Participant) presidente do centro de informações (P14.1 in the role of) do Lançamento da Pedra Fundamental do CI (E5 Event). Continuando a construção de nosso exemplo, o projetista deste domínio poderia julgar necessária a representação da herança cultural. Neste caso, sugerimos a expansão CH (Cultural Heritage) que oferece classes que capturam conceitos importantes para representar a história de uma obra, expressão, manifestação e veículos de persistência. Considere agora três atividades (E7 Activity) que produziram cada uma um documento (E84 Information Carrier) diferente: foto.jpg, recibo de entrega da lápide.doc e nota de divulgação para imprensa.pdf. Essas três atividades, em um arranjo (CID5 Means), poderiam ser uma descrição, preliminar, de como o evento Lançamento da Pedra Fundamental (E5 Event) ocorreu, complementar às informações sobre data, local e participantes. A lápide (F5 Item) de polipropileno (F3 Manifestation Product Type) poderia conter um trecho em português (F2 Expression) da obra (F1 Work) de Guimarães Rosa. Cada atividade, da mesma forma que o evento Lançamento da Pedra Fundamental, poderia ter um detalhamento, indicando entre outros, onde, quando e quem. Por exemplo, a foto foi tirada pelo satélite brasileiro ABC 51 (CID2 Participant), nas coordenadas geográficas XYZ (E53 Place) às 13h em 01/01/2007 (E52 Time-Span). 51 ABC é uma instância por exemplo, de E41 Appellation.

150 Aplicações do Modelo de Proveniência 150 Por fim, imagine outros dois documentos (E84 Information Carrier), o vídeo de lançamento do empreendimento e a mapa do terreno adquirido, que poderiam ser respectivamente a motivação (P17 was motivated by) e influência (P15 was influenced by) para o evento de Lançamento da Pedra Fundamental. Considere agora que tenhamos também descrições semelhantes para o evento Início da Construção do Centro de Informações. Entre este último e o evento de Lançamento da Pedra Fundamental ocorreram outros eventos que, se devidamente registrados e relacionados, formariam uma rede de conhecimento que descreve o empreendimento que poderia ser representada a partir do modelo conceitual de proveniência. Para isso, recomendamos ao projetista que avalie se as expansões PO (seção ) ou RQR (seção ) atendem completamente a representação de uma rede de conhecimento. A capacidade de realizar consultas a essa rede e recuperar a proveniência dos eventos nos permitiria avaliar sua história. Podemos imaginar que a interface de um centro de informações com os consumidores seja uma ferramenta de portal, por exemplo, o Liferay 52. O serviço de proveniência do portal poderia ser dividido entre dois portlets 53 : portlet de coleta e portlet de consulta, que desempenhariam respectivamente funções análogas ao provenance wrapper e provenance filter da Figura 40 (seção 4.2). A partir da especificação JSR que define, entre outras regras, as de comunicação entre portlets e está disponível como minuta, desde 13/12/2007. Qualquer portlet desenvolvido de acordo com essa especificação poderia então se registrar junto aos portlets de proveniência para a troca de dados (coleta e consulta de proveniência). Por exemplo, um portlet de upload de documentos poderia repassar os valores manualmente coletados no formulário, para que o portlet de proveniência registrasse esses dados como respectivas instâncias das classes do modelo, sendo o evento de criação de documento no portal uma instância da classe E7 Activity. Por outro lado, um portlet de consulta poderia utilizar a API Lucene 55 para recuperar dados dos índices de conteúdo e metadados e apresentar os resultados consolidados no portlet de consulta Um Portlet pode ser entendido como um Servlet Visual independente que pode ser utilizado para disponibilizar informações dentro de uma página Web

151 Aplicações do Modelo de Proveniência 151 Concluímos ressaltando então que, do ponto de vista de preservação digital, um centro de informações poderia adotar o padrão ISO 14721:2003 como especificação de serviços e processos cobrindo as suas principais funcionalidades. De forma complementar, do ponto de vista de metadados, poderia adotar o padrão de projeto para proveniência que está essencialmente fundamentado pela ISO 21127:2006. Conceitualmente, a adoção de um modelo de proveniência permite que o centro de informação seja estruturado para oferecer uma navegação multifacetada: eventos, agentes, conceitos etc. Imagine um centro de informações que possui uma galeria, onde os quadros são monitores de alta definição. Considere também que a definição da história a ser contada para os visitantes dessa galeria fosse guiada, não necessariamente associada a uma ordem cronológica, e visualizada através destes quadros. A história poderia ser contada de diferentes formas, dependendo do arranjo (partial order) estipulado previamente ao início do tour. Os eventos estariam associados de forma a satisfazer as expectativas do público visitante. Por fim, sugerimos o modelo conceitual de proveniência como a base para esta visão porque está centrado em eventos e relacionamentos e tem recursos associados a eventos. Avançaremos adiante e faremos um estudo mais amplo do modelo de proveniência, utilizando uma ferramenta do domínio de gerenciamento de configuração de software (seca 4.5) Serviço de Proveniência na Web para ferramenta de Gerenciamento de Configuração de Software[ALAM96] Descrevemos aqui a aplicação do padrão de projeto de proveniência, utilizando como motivação um serviço de proveniência na Web (Web Provenance Service ou abreviadamente WPS). O objetivo deste serviço é disponibilizar via Web os dados de proveniência de um banco de dados modelado a partir do padrão de projeto para proveniência para o domínio de gerenciamento de configuração de software. Iniciamos, descrevendo a especificação (seção 4.5.1), em seguida, detalhamos o ambiente (seção 4.5.2) utilizado para o desenvolvimento do protótipo, e por fim apresentamos o estudo da ferramenta Trac (seção 4.5.3) que inclui a instanciação do modelo de proveniência.

152 Aplicações do Modelo de Proveniência Especificação do Serviço Por limitações de tempo, o serviço de proveniência na Web contempla apenas a recuperação da proveniência, não tratando de sua coleta automática ou manual. O objetivo de um WPS (Web Provenance Service) é fornecer aos usuários a possibilidade de disponibilizar acesso aos dados de proveniência armazenadas em um determinado servidor de banco de dados relacional através de requisições HTTP a um servidor de aplicações. Através deste serviço os dados de uma determinada aplicação são disponibilizados através da Web sem a necessidade do cliente conhecer os detalhes de armazenamento do banco de dados acessado. Os usuários de um serviço WPS são seres humanos, sistemas, agentes de software e outros clientes que acessem o serviço utilizando requisições HTTP. O WPS faz interação com os sistemas clientes (usuários) do serviço de proveniência Requisitos Um WPS possui os requisitos: 1. Atender requisições HTTP. 2. Acessar o banco de dados através dos parâmetros em um arquivo de configuração. 3. A tela inicial com as operações do WPS corresponde ao resultado da consulta a capacidade do serviço WPS e deve estar em formato XML. 4. Permitir a iteração com usuário através da URL. 5. Ler as consultas realizadas as fontes de dados a partir de arquivos de consultas. Cada tipo de consulta tem seu respectivo arquivo ou conjunto de arquivos. 6. Converter resultados para XML utilizando extensão da linguagem SQL, minimizar o acoplamento entre o código de conversão do resultset e o código do sistema. 7. Disponibilizar o Serviço de Proveniência na Web em um servidor de aplicações. 8. Listar e descrever quais operações e respectivos parâmetros o serviço disponibiliza, apresentando o resultado em formato XML.

153 Aplicações do Modelo de Proveniência Retornar os dados de proveniência em formato XML a partir da identificação global de uma entidade. A identificação global deve ser única. 10. Servir uma requisição retornando as entidades correspondentes de acordo com o tipo da entidade, tipo de relacionamento e palavra de referência requisitada, limitando o resultado formatado em XML a um número máximo de objetos, identificado também como parte da requisição Descrição das Operações Um WPS oferece três operações básicas para atender aos requisitos (seção ). As operações de um WPS são um subconjunto das operações disponíveis em um Web Object Service (WOS) (Vretanos, 2003). Neste projeto não estaremos oferecendo operações para transação. As operações são consultas Web que o serviço WPS é capaz de responder. Uma consulta Web (requisição) utiliza o protocolo HTTP para atender as requisições. O WPS aceita requisições através dos métodos GET e POST. O prefixo da requisição é definido como uma string incluindo o protocolo, nome do servidor, número da porta, caminho, um ponto de interrogação?, e, opcionalmente, um ou mais parâmetros específicos do serviço concatenados com o símbolo &. A sintaxe da consulta Web é uma URL genérica que representa uma requisição HTTP. Neste projeto essa requisição é feita ao WPS O cliente adiciona os parâmetros de requisição necessários, respeitando a multiplicidade, e para cada novo parâmetro que deseja incluir na consulta utiliza a sintaxe nome=valor&, onde nome representa o nome do parâmetro e valor o seu valor propriamente dito. 56 colchetes [ ] denotam zero ou um ocorrência e chaves { } denotam zero ou mais ocorrências.

154 Aplicações do Modelo de Proveniência 154 O WPS aceita requisições com parâmetros específicos a cada operação. O único parâmetro comum a todas as operações é o parâmetro REQUEST que pode assumir um dos seguintes valores: getcapabilities, getobjectbyid ou getobject[mac97] que equivalem exatamente às operações que a OGC 57 (Open Geospatial Consortium) implementa para vários dos seus serviços. Este parâmetro é case sensitive (maiúsculas e minúsculas são interpretadas de forma diferente). O serviço WPS retorna as respostas às requisições HTTP com o tipo MIME (Multipurpose Internet Mail Extensions) definido como text/xml. As descrições de cada operação de REQUEST são: getcapabilities: descrever as suas capacidades. Especificamente, ele deve ser capaz de indicar os tipos de objetos que pode servir e quais operações e respectivos parâmetros são suportados. Esta operação é responsável por servir uma requisição HTTP retornando as capacidades do serviço e apresentando o resultado no formato XML; getobjectbyid: retornar uma única instância de um objeto da fonte dados a partir de um identificador global. Esta operação é responsável por servir uma requisição HTTP retornando a proveniência do objeto identificado, apresentando o resultado no formato XML; getobject: suportar consultas mais complicadas que envolvam o uso de parâmetros como typename, relationtotype e showreference. Esta operação é responsável por servir uma requisição HTTP retornando as instâncias correspondentes aos valores dos parâmetros requisitados, apresentando o resultado no formato XML Arquitetura A arquitetura do sistema está divida em três camadas horizontais identificadas pelas linhas tracejadas da Figura 45. A camada superior representa a Web, a camada intermediária o serviço propriamente dito e por fim a camada inferior simboliza a fonte de dados que desejamos compartilhar na Web. 57

155 Aplicações do Modelo de Proveniência 155 Figura 45 Arquitetura do Web Provenance Service (WPS) Entre as duas linhas sólidas verticais, temos a arquitetura propriamente dita onde as setas sólidas representam requisições (request) e as setas pontilhadas as respostas (response). Os ícones à esquerda da arquitetura são exemplos de instanciação de hardware e à direita listamos alguns exemplos de instanciação de software Ambiente de Desenvolvimento O ambiente de desenvolvimento está consolidado em uma única máquina virtual. Utilizamos o VMWare para a configuração de um servidor com sistema operacional Windows 2003 Server, interface de programação MyEclipse 5.5 e interface para abstração de consultas SQL Hummingbird BI v8.1. Para prototipar o serviço de proveniência, temos ainda as seguintes instanciações das tecnologias da arquitetura: Navegador Web - Internet Explorer 7.0, Servidor de Aplicações - Tomcat e Servidor de Banco de Dados - MS SQL Server Catálogo TDK Um catálogo é uma coleção de dados descritivos (metadados) a respeito dos dados (objetos) armazenados em um banco de dados. Os metadados atuam como propriedades que podem ser consultadas e requisitadas através do serviço

156 Aplicações do Modelo de Proveniência 156 de catálogo para avaliação dos recursos fornecidos por um banco de dados ou serviço. O Catálogo TDK oferece serviços de descoberta, acesso e gerenciamento que permitem ao cliente respectivamente: localizar os metadados que descrevem os dados, acessar métodos para requisição de serviços sobre os dados e acessar métodos para alterações dos metadados do catálogo. Elegemos o esquema do Catálogo TDK como base para a construção do modelo físico. A escolha foi importante porque permitiu uma abstração ainda maior para o modelo de proveniência porque possibilita que o modelo de proveniência seja composto de diferentes views criadas a partir do modelo adaptado do Catálogo TDK. Como o esquema original do Catálogo TDK não possui em suas tabelas a possibilidade de representação de relacionamentos entre entidades, algumas adaptações foram realizadas (seção ). Além disso, há várias tabelas para controle de acesso e outras funções que não foram relevantes para este projeto e que não estão descritas neste documento. Selecionamos um conjunto reduzido de tabelas do esquema original, definindo-o como esquema mínimo do Catálogo TDK (seção ) Modelo Físico construído por Reuso e Adaptação Nomeamos[ALAM98] o modelo físico de proveniência de W6H2. (W6H correspondem aos conceitos abstratos utilizados para a construção do modelo conceitual e o número 2, lemos como to, simbolizando a importância dos relacionamentos entre eventos, entre recursos e entre ambos). Como em nosso modelo de proveniência (mínimo) (seção 3.6) só possuímos relacionamentos binários, é possível utilizar um esquema reduzido do Catálogo TDK desde que sejam criadas as respectivas tabelas para representar o auto-relacionamento entre as diferentes entidades do modelo. Este autorelacionamento permite a construção de entidades complexas e bem como a qualificação de outros relacionamentos. Assim, o esquema do banco de dados implementado neste projeto corresponde ao da Figura 46, que tem circulado com elipses as tabelas adicionais acrescentadas ao esquema do Catálogo TDK, de forma a comportar os relacionamentos entre entidades.

157 Aplicações do Modelo de Proveniência 157 As tabelas que de fato foram utilizadas para popular o banco de dados foram: TDK_CAT_ENTITY: armazena os atributos fixos de uma entidade. TDK_CAT_TYPE: armazena o tipo de uma entidade. Todas as classes do modelo de proveniência estão mapeadas na tabela TDK_CAT_ENTITY, sendo que seus respectivos tipos (E5 Event, E7 Activity, CID2 Participant etc) estão representados pela tabela TDK_CAT_TYPE. Por fim, a tabela TDK_CAT_FILE referencia os itens físicos propriamente ditos de uma instância de E84 Information Carrier (documentos digitais) que por sua vez estão relacionados diretamente a uma entidade de proveniência. Os relacionamentos existentes entre as classes do modelo conceitual de proveniência serão representados utilizando as tabelas que foram adicionadas ao esquema do Catálogo TDK: W6H2_TDK_CAT_RELATIONS: armazena os relacionamentos entre entidades. W6H2_TDK_CAT_RELATION_TYPE: armazena o tipo de relacionamento entre entidades. Essas tabelas estão identificadas com elipses na Figura 46 que foi gerada pelo diagrama de esquema do banco de dados TDKSimple, utilizando a ferramenta Enterprise Manager do Microsoft SQL Server Todas as propriedades das classes do modelo conceitual de proveniência foram completamente mapeadas nos atributos disponíveis nas classes descritas nesta seção. Em nossa instanciação, por simplificação, algumas das tabelas do esquema mínimo do Catálogo TDK não foram necessárias, por exemplo, a representação da autoridade criadora de cada entidade (tabelas TDK_CAT_ENTITY_AUTHOR). Existem ainda outras tabelas presentes no esquema original do banco de dados do Catálogo TDK que também não foram utilizadas, mas são essenciais ao modelo físico do TDK porque flexibilizam a extensão do modelo físico a partir da adição de novos atributos a qualquer entidade: TDK_CAT_ATTRIBUTES: armazena os atributos estendidos de uma entidade. TDK_CAT_ENTITY_ATTRIBUTES: associa entidades a atributos estendidos.

158 Aplicações do Modelo de Proveniência 158 TDK_CAT_ATTRIBUTE_TYPE: armazena o tipo de atributo TDK_CAT_ATTRIBUTE_CATEGORY: define categorias que têm como propósito agrupar os atributos de entidades. TDK_CAT_AUTHOR: armazena os autores da entidade TDK_CAT_ENTITY_AUTHOR: associa entidades a autores Figura 46: Principais Tabelas do Catálogo TDK Adaptado Há[ALAM99] apenas uma tabela existente originalmente no esquema mínimo do Catálogo TDK que optamos por utilizar em nossa aplicação, como forma de representar documentos (files) que podem estar associados a qualquer entidade do modelo. A tabela TDK_CAT_FILE armazena os documentos associados a uma determinada entidade. Poderíamos realizar uma engenharia reversa e, imaginar que esta tabela do modelo físico seria equivalente no modelo conceitual a uma expansão que importa a classe E84 Information Carrier da ISO 21127

159 Aplicações do Modelo de Proveniência 159 (2006) como especialização indireta de CID2 Participant. Por fim, esta tabela está associada à tabela TDK_CAT_ENTITY o que implicaria acrescentar a esta expansão uma propriedade a classe CID1 Provenance Entity que poderia ser PID14 has file reference (is file reference to) que tem classe-imagem E84 Information Carrier Abstração para o Modelo Físico - Ferramenta BI A ferramenta Hummingbird 58 BI (Business Intelligence) também foi utilizada para a construção e validação das consultas SQL. Incluímos na abstração da Figura 47 apenas as tabelas que serão utilizadas por este projeto. No projeto foi implantada a opção de consulta apenas em uma direção no relacionamento entre entidades, mas a representação da inversa está disponível no esquema adaptado para ser explorada em trabalhos futuros. No caso da recuperação também da inversa, são necessárias duas consultas a fonte de dados para recuperar o relacionamento em ambas as direções. O estudo da ferramenta Trac (seção 4.5.3) também fez uso da modelagem BI para a compreensão de seu banco de dados (seção ), a partir da análise de consultas SQL. 58

160 Aplicações do Modelo de Proveniência 160 Figura 47: Abstração BI para o modelo físico Estudo da Ferramenta Trac Preliminares A instanciação de nosso modelo conceitual foi feita para o domínio GCS (Gerenciamento de Configuração de Software). Escolhemos o domínio GCS ou do inglês SCM (Software Configuration Management) porque em nosso levantamento de oportunidades de acesso a dados reais, teríamos contato com a equipe do laboratório TecGraf da PUC-Rio responsável pelo Projeto TDK Catalog 59. Este projeto tem sua gestão baseada na ferramenta Trac 60, que é um Wiki estendido que oferece um sistema de controle de ocorrências e também provê uma interface de consulta ao Subversion 61. O Trac está integrado ao sistema de controle de versões, possibilitando a criação de links entre defeitos, tarefas, Changesets, anexos (attachments) e páginas Wiki

161 Aplicações do Modelo de Proveniência 161 Figura 48: Tela de Entrada do Trac O Trac possui a noção de Timeline (Figura 48) onde estão listados vários tipos de eventos em ordem cronológica facilitando uma visão geral do projeto. Para que o mapeamento do domínio dessa ferramenta fosse possível precisávamos entender quais dados estavam disponíveis, como estavam organizados, como acessá-los e de que forma utilizá-los. Aprofundando essa visão geral, estudamos o banco de dados original utilizado pelo Trac (SQLite 62 ). Neste projeto foi necessário realizar uma transformação dos dados originais (do inglês DTS - Data Transformation Task) para que todos os dados do banco original estivessem disponíveis em um servidor com banco de dados SQL Server Adicionalmente, adotamos a ferramenta BI Query da Hummingbird para aprendizado do conteúdo do banco de dados. A Figura 49 ilustra o modelo BI construído com essa ferramenta para o banco de dados do Trac já convertido para o servidor SQL. 62

162 Aplicações do Modelo de Proveniência 162 Figura 49: Abstração BI para o esquema do banco de dados do Trac As tabelas REVISION e NODE_CHANGE contêm dados que vêm diretamente do Subversion (por exemplo, artefatos alterados em um determinado ChangeSet), enquanto que as tabelas que tem relacionamento com a tabela TICKET e as tabelas WIKI, ATTACHMENT, REPORT e ENUM representam os dados relativos à ferramenta Trac propriamente dita. Após o estudo do banco, procuramos identificar características específicas que demonstram a necessidade de rastreabilidade dos dados atendida parcialmente pela ferramenta Trac. Destacamos que a ferramenta Trac oferece uma forma de relacionamentos entre ChangeSets que pode ser entendida através da Figura 50 que ilustra o plugin RevTree. Este plugin permite uma visualização gráfica dos relacionamentos. Nessa figura temos diferentes ramos de versionamento armazenados no Subversion que são identificados ao topo da figura. As setas ligam um ChangeSet a outro verticalmente indicando de onde foi originado, e horizontalmente indicando uma eventual mudança de ramo. Além dessas informações disponibilizadas pelo plugin RevTree e do Timeline, a ferramenta Trac oferece alguns relatórios que permitem a

163 Aplicações do Modelo de Proveniência 163 identificação de estado das ocorrências (tickets) e algumas outras consultas para acompanhamento do projeto, mas não uma visão gerencial consolidada do projeto. Durante o estudo do esquema do banco de dados do Trac, também foi consultado o projeto DrProject 63, que na verdade é uma extensão da ferramenta Trac habilitando a capacidade de multi-projetos e também oferecendo suporte a lista de discussões. Figura 50: Rastreabilidade de ChangeSets A Figura 51 é um exemplo de dados sintéticos acrescentados a base do Trac. Ao topo há o ticket #20 com status closed e ao final dessa figura há uma referência ao Changeset 1129 correspondente a sua conclusão. 63 Projeto da Universidade de Toronto:

164 Aplicações do Modelo de Proveniência 164 Figura 51: Referências cruzadas entre Ticket e ChangeSet apresentada no Ticket A Figura 52 destaca da lista de eventos registrados no Timeline, o evento que corresponde ao Changeset 1129 que foi responsável pela conclusão do ticket #20. A identificação que o ticket está concluído é representada pelos caracteres tachados #20. Figura 52: Referências cruzadas entre ChangeSet e Ticket apresentada no Timeline O ChangeSet é o identificador de um evento. A ligação entre ChangeSets simboliza o encadeamento de eventos. Interessa-nos validar este encadeamento para os milestones, que também são eventos, de forma que aos dados de proveniência dos milestones agreguem valor à gestão do projeto. Os dados do Trac utilizados para o Serviço de Proveniência na Web correspondem a um subconjunto dos dados reais do projeto TDK Catalog desenvolvido pelo laboratório Tecgraf. Algumas conversões e ajustes foram feitos inserindo alguns dados sintéticos de forma a completar os dados reais uma vez que não havia referências organizadas entre Changesets que concluíam tickets em aberto.

165 Aplicações do Modelo de Proveniência 165 Agora, apresentamos o mapeamento dos conceitos do Trac em conceitos do modelo de proveniência (seção ) Mapeamento para o Modelo de Proveniência Como o modelo de proveniência é centrado em eventos, era necessário identificá-los, bem como seus níveis de granularidade. Identificamos dois importantes tipos de eventos: Milestone e Commit, sendo o primeiro um tipo de evento do Trac e o segundo um tipo de evento do Subversion. O conceito de Milestone tipicamente representa um evento, de duração zero, importante em um projeto, como a conclusão de um componente, uma fase ou a criação de um protótipo entre outros. Já o conceito Commit é representado por um número: ChangeSet, e simboliza um ou mais artefatos criados, alterados ou excluídos. Como Trac e Subversion trabalham de forma integrada, inicialmente, analisamos o mapeamento desses dois conceitos de eventos, com o objetivo de explorar os conceitos relevantes para validar a cobertura do modelo de proveniência. Essa integração permite o desenvolvimento de hooks que podem ser ativados antes ou após a execução de um evento de Commit do Subversion. Um hook pode ser entendido como um script que poderia, entre outras ações de controle, por exemplo, concluir um ticket atualizando seu status para fixado. Complementando a direção inversa, um usuário, ao fechar um ticket pela interface do Trac, poderia referenciar o Changeset que o motivou a concluí-lo. Os comentários dos Commits, as descrições de tickets relacionadas à troca de status, por exemplo, de novo ticket para ticket concluído, ou até textos do Wiki do Trac referentes a algum ticket, poderiam definir a necessidade da criação de especializações para a classe E38 Conceptual Object, de forma que esses dados fossem representados estruturadamente. Aprofundando, um hook poderia ser definido para a captura manual da proveniência, a partir de propriedades obrigatórias a serem preenchidas durante um evento de Commit. Outra informação interessante que um hook deste tipo poderia capturar seria o nome do desktop do responsável pelo Commit, permitindo com isto a coleta automática da proveniência de onde (o nome do desktop que possui o espelhamento do respectivo ramo do Subversion) foi realizado o Commit, registrando o dado de proveniência como instância da classe E53 Place. Isto poderia ajudar no acompanhamento da distribuição dos artefatos fora do repositório central.

166 Aplicações do Modelo de Proveniência 166 Neste momento, interessa-nos explorar a aplicação do modelo de proveniência a partir de sua especialização. Com isso, utilizamos uma analogia com os principais conceitos do domínio do Trac produzindo o mapeamento da Tabela 23. Ressaltamos que o uso dos conceitos abstratos (Wh-questions), adotados pela metodologia de construção do modelo, é também adotado na especialização do modelo para este domínio. Nossa instanciação foca o conceito de Milestone como os eventos que nos interessam. No caso do Trac, um milestone 64 é um conjunto de tickets. Os milestones não estão relacionados uns com os outros explicitamente e tem apenas uma descrição e uma data de expiração (Due Date). No modelo mínimo, instâncias da classe CID4 Reason poderiam ter o significado de um projeto como sendo a motivação mais geral para o porquê (Why) dos respectivos milestones. O[ALAM100] Trac, a partir da adoção da expansão TR (Traceability) poderia oferecer a rastreabilidade de tickets. Outra alternativa possível seria a adaptação do banco de dados da ferramenta, incluindo outras tabelas relacionadas à tabela Ticket para a representação de auto-relacionamentos qualificados. Tabela 23: Mapeamento entre conceitos do Trac em classes do modelo de proveniência Conceito do Trac Classe do Modelo de Proveniência Conceito Abstrato Milestone E5 Event What - E53 Place Where Milestone Due Date E52 Time-Span When Ticket E7 Activity - Ticket Owner CID2 Participant Who Comentários de Commits do SVN ou justificativas de fechamento de tickets E28 Conceptual Object - A[ALAM101] ferramenta Trac poderia também representar de forma explícita, a noção de explicação (CID5 Means) como uma ordem parcial de tickets (E7 Activity) que permite compreender como o milestone (E5 Event) foi alcançado. 64 Um milestone é um evento que não tem duração e simboliza um marco importante no curso de um projeto.

167 Aplicações do Modelo de Proveniência 167 Essa representação poderia se capturada pela expansão PO (seção ) através da classe CID6 PO Event. Outra perspectiva é que, em sua configuração padrão, a ferramenta Trac não permite limitar o papel a ser executado dentro de um ticket. Essa funcionalidade é interessante do ponto de vista gerencial, para evitar que um recurso no papel de desenvolvedor, altere inadvertidamente um ticket de relatório gerencial onde apenas uma pessoa no papel de coordenador de projeto poderia realizar tal atividade. A ferramenta Trac não possui o conceito de papel (Role). Por isso, poderia ser aprimorada para oferecer a representação de papéis desempenhados por seus usuários (CID2 Participant). O conceito Role (papel) poderia ser tão simples quanto um papel estático que um participante rotineiramente desempenha (User Description) ou mais sofisticado se o mesmo participante desempenhar papéis dinâmicos dentro de um mesmo milestone. Por fim, acrescentamos que outros conceitos do Trac como Component, Priorities, Severities e Versions poderiam ser mapeados em instâncias ou especializações da classe E28 Conceptual Object. O conceito de tipos de tickets (Ticket Types) pode ser mapeado para a classe E55 Type. Realizamos então alguns exemplos motivados pelos mapeamentos indicados na Tabela 23. Cadastramos manualmente alguns valores, do projeto TDK, gerenciado pela ferramenta Trac, no banco de dados criado a partir do modelo conceitual de proveniência. Em seguida, capturamos e apresentamos as respostas às requisições de operações (seção ) do serviço de proveniência na Web Respostas do Serviço de Proveniência na Web Por limitações de tempo, não exploramos o serviço de proveniência na Web como um plugin para o Trac ou Subversion. Seria necessário primeiro desenvolver uma coleta automática da proveniência, que provavelmente também seria outro plugin para o Trac ou hook para o Subversion. O serviço de proveniência na Web foi alimentado manualmente com os dados do projeto TDK extraídos do Trac. O estudo desenvolvido teve como objetivo uma validação inicial do modelo aplicado ao domínio de gerenciamento de configuração de software. Apresentamos aqui apenas as respostas à operação getobject, que oferece as consultas mais complexas que o serviço disponibiliza. As demais operações getcapabilities e getobjectbyid fazem parte do serviço, mas seus

168 Aplicações do Modelo de Proveniência 168 respectivos resultados não serão apresentados aqui porque consideramos que as respostas das requisições a operação getobject são suficientes para a didática que necessitamos desenvolver durante nossa explanação. Os resultados apresentados são conversões diretas 65 das saídas de consultas (prepared queries) SQL, que correspondem às chamadas das operações do Serviço para Proveniência na Web, a partir da cláusula FOR XML AUTO, ELEMENTS. Inicialmente ilustramos três milestones que existem no projeto do Catálogo TDK na Figura 53 a partir do acesso a página Roadmap da ferramenta Trac deste projeto. Figura 53: Página de Roadmap da ferramenta Trac que apresenta os milestones existentes no projeto A requisição a operação getobject para recuperar os milestones é possível através do parâmetro que especifica o tipo do objeto que se deseja recuperar. A consulta é formada pela URL base XML. 65 Por limitações de tempo não disponibilizamos nesta versão do serviço o respectivo esquema

169 Aplicações do Modelo de Proveniência 169 acrescida de REQUEST=getObject&maxRows=20&typeName=E5 Event. Esta consulta produz a resposta apresentada na Figura 54 que é o resultado da operação getobject retornando todas as entidades que são do tipo E5 Event presentes no banco de dados de proveniência. O atributo entity_source representa a proveniência do conceito da ferramenta da respectiva instância do objeto retornado.

170 Aplicações do Modelo de Proveniência 170 Figura 54: Resultado com todos os eventos no banco de dados de proveniência. A[ALAM102] Tabela 24 contém a consulta SQL (prepared query) correspondente ao resultado da Figura 54. Esta consulta recebe apenas um parâmetro - representado pelo caracter de interrogação? da linha destacada em negrito itálico - que corresponde ao tipo do objeto que se deseja recuperar, por exemplo, os nomes (completos que incluem o respectivo identificador) das classes do modelo mínimo: E5 Event, E7 Activity, CID2 Participant etc.

171 Aplicações do Modelo de Proveniência 171 Tabela 24: Consulta SQL (prepared query) para a operação getobject que especifica o tipo do objeto que deve ser retornado use TDKSimple select entity.entity_id, entity.entity_name, entity.entity_description, entity.entity_source, relation_type.type_name, relation_type.type_description from w6h2_cat_relations_type AS relation_type, w6h2_cat_relations AS relation, tdk_cat_entity AS entity where entity.entity_id = relation.entity_id and relation.relat_type_id = relation_type.type_id and relation_type.type_name =? for XML AUTO, ELEMENTS A operação getobject pode filtrar outros resultados através dos parâmetros relationtotype e showreference. O primeiro permite especificar o tipo da propriedade de um objeto, por exemplo, P11 has participant. Lembramos que o Serviço de Proveniência na Web não implementa, na versão atual, a consulta automática à inversa[mac103] de P11 has participant. Porém, em versões futuras, poderia realizar duas consultas SQL e então apresentar a propriedade consultada e sua inversa (se existente) de forma transparente para o usuário do serviço. O segundo parâmetro permite especificar um nome parcial de qualquer artefato (E84 Information Carrier), por exemplo,.cpp ou Catalog. Neste caso, assumimos que o modelo mínimo foi expandido com esta classe. O artefato pode estar associado a uma instância de E5 Event que represente, por exemplo,

172 Aplicações do Modelo de Proveniência 172 o evento de Commit do Subversion que através de um hook concluiu tickets pendentes. A Figura 55 ilustra três destes eventos que correspondem aos ChangeSets 1127, 1128 e 1129 e as respectivas instâncias de E84 Information Carrier associadas. A Figura 55 corresponde a URL base acrescida de: REQUEST=getObject&maxRows=20&typeName=E5 Event&showReference. Figura 55: Eventos de Commit do Subversion que correspondem a ChangeSets

173 Aplicações do Modelo de Proveniência 173 A Figura 56 ilustra o conteúdo do terceiro ChangeSet (E5 Event) apresentado na Figura 55. Figura 56: ChangeSet 1129 que concluiu o ticket #20. A Figura 56 apresenta um único artefato modificado (modified): TdkCorbaCatalogueService.IDL. Abaixo e à direita, em relação ao título

174 Aplicações do Modelo de Proveniência 174 Changeset 1129, as linhas 7 e 8 da Revision identificam as alterações do artefato em relação ao ChangeSet imediatamente anterior (Revision 812) que também registrou alguma mudança (Commit) desse mesmo artefato. Por fim, a ferramenta Trac define um milestone como um simples agrupamento de tickets. Com a incorporação do modelo de proveniência, o Trac poderia ir além das explicações dedutíveis como a linha to tempo página Timeline - que simboliza a cronologia dos ChangeSets. Através do plugin RevTree (seção ) seria possível navegar entre ChangeSets, por exemplo, do ChangeSet 812 se chegar ao ChangeSet 1129, o que seria portanto, uma explicação dedutível análoga a linha do tempo que poderia ser construída com o evento de Commit (Revision 812) acontecendo antes do evento (Revision 1129). Através desses eventos até é possível se chegar aos tickets correspondentes, mas sem proveniência o dado fica sem qualidade. Os ChangeSets 1127, 1128 e 1129 correspondem respectivamente ao fechamento dos tickets 4, 9 e 20 que por sua vez estão agrupados na Figura 57 sob o milestone Branch 1.5 (Figura 53 e Figura 54) que possui ao todo nove tickets concluídos. Figura 57: Tickets do Milestone Branch 1.5 Argumentamos que através da aplicação do modelo de proveniência seria possível associar mais significado ao dado, permitindo a representação de relacionamentos (qualificados) não dedutíveis (CID7 Event Reason) que podem capturar por que (Why) causas, justificativas, motivos etc - um ticket está ligado a outro. Adicionalmente, um milestone estando associado a um arranjo - 66 Tem o mesmo significado que ChangeSet

175 Aplicações do Modelo de Proveniência 175 como uma ordem parcial - de tickets (CID6 PO Event), poder-se-ia dizer que esta ordem é uma explicação de como (How) o milestone foi alcançado. Figura 58: Tickets #4, #9 e #20 e respectivos IDs de participantes