Este repositório contém a proposta de arquitetura para um sistema de informações dedicado à preservação, curadoria e compartilhamento de conhecimento tradicional associado à biodiversidade. O sistema foi projetado com respeito aos princípios C.A.R.E. (Collective Benefit, Authority to Control, Responsibility, Ethics) e em conformidade com a legislação pertinente.

O Brasil possui múltiplas iniciativas de qualidade mundial para sistematizar conhecimento tradicional associado à biodiversidade, porém operam de forma isolada sem arquitetura comum que permita integração e sinergia. Por exemplo, algumas das iniciativas em 2025:

Projeto de grande porte (US$ 7 milhões) coordenado pelo MCTI para fortalecer capacidade de Povos Indígenas e Comunidades Locais (PIPCTAFs) gerenciarem dados sobre sociobiodiversidade em Amazônia e Cerrado, usando padrões DarwinCore/PlinianCore via SiBBr.

Iniciativa do ICMBio (CNPT) em parceria com UFSC que busca integrar bases de dados dispersas em plataforma única, com ênfase em protocolos comunitários e Consentimento Livre, Prévio e Informado (CLPI).

Projeto de 13 meses para modernizar o Sistema Nacional de Gestão do Patrimônio Genético e CTA, implementando interoperabilidade via IPT (Integrated Publishing Toolkit) com padrões FAIR e CARE.

Sistema com registros etnobotânicos validados, implementando inovador "Registro Comunitário" onde comunidades definem níveis de acesso a seus conhecimentos.

Apesar de perseguirem objetivos convergentes, essas iniciativas geram:

• Dispersão de dados: mesmo conhecimento armazenado em múltiplos sistemas sem sincronização
• Padrões inconsistentes: Useflora (41 campos relacional), GEF (DarwinCore), SISGEN (patrimônio genético), RCS (agregador flexível)
• Replicação de esforços: múltiplos "registros comunitários" em desenvolvimento paralelo
• Soberania fragmentada: comunidades interagem com sistemas desconectados
• Pesquisa limitada: impossível fazer queries que atravessem iniciativas
• Sustentabilidade em risco: cada um com seu ciclo de financiamento e dependências

Uma arquitetura integrada possibilitaria:

✅ Interoperabilidade sem perda de autonomia: camada comum permite compartilhamento mantendo independência
✅ Registro comunitário unificado: comunidade faz login uma única vez, direitos propagam para todas plataformas
✅ Governança consistente: FAIR + CARE implementados uniformemente
✅ Busca e análise integrada: pesquisadores com visão completa da biodiversidade
✅ Repartição de benefícios rastreável: Lei 13.123/2015 cumprida efetivamente

A fragmentação coloca em risco o cumprimento de:

• Lei 13.123/2015: comunidades precisam ser informadas sobre usos de conhecimento (impossível se disperso)
• Protocolo de Nagoya: exige rastreabilidade internacional (integração técnica essencial)
• CDB Art. 8j: participação ativa de detentores (integração facilitaria essa participação)

Todas compartilham:

• Objetivo de sistematizar CTA
• Desafio de proteção do conhecimento tradicional
• Mesma base legal (Lei 13.123/2015)
• Compatibilidade técnica (SiBBr, infraestrutura de dados aberta, padrões interoperáveis)
• Cobertura geográfica complementar (juntas cobrem praticamente toda biodiversidade brasileira)

Esta proposta de arquitetura não busca substituir as iniciativas existentes, mas criar camada de integração que possibilite interoperabilidade, estabeleça padrões mínimos sem sacrificar autonomia, e implemente governança compartilhada com protagonismo comunitário.

• Preservar o conhecimento tradicional de comunidades sobre o uso de plantas e biodiversidade
• Validar e qualificar dados através de processos curatoriais rigorosos
• Compartilhar informações de forma ética e responsável com pesquisadores e público geral
• Integrar múltiplas fontes de dados, desde artigos científicos até registros primários
• Automatizar a captura de informações relevantes de fontes confiáveis

O sistema é organizado em quatro contextos principais que trabalham de forma integrada. O diagrama abaixo apresenta a visão de mais alto nível da arquitetura; diagramas C4 detalhados estão disponíveis na documentação técnica.

graph TB
    FS["Fontes Secundárias<br/>(Artigos, PDFs, Livros)"]
    FP["Fontes Primárias<br/>(Comunidades Tradicionais)"]

    EP["✓ etnopapers<br/>Extração com IA<br/>(entrada opcional)"]

    MONGO[("MongoDB<br/>coleções: etnoDB · etnoTermos · etnoRelatos")]


    subgraph "✓ etnoDB — Fontes Secundárias"
        ED_ACQ["Aquisição"]
        ED_CUR["Curadoria"]
        ED_PUB["Apresentação<br/>etnoChat · Painel Analítico"]
    end

    subgraph "etnoRelatos — Fontes Primárias"
        ER_ACQ["Aquisição + CLPI"]
        ER_CUR["Curadoria Comunitária"]
        ER_PUB["Apresentação"]
    end

    subgraph "✓ etnoTermos — Vocabulários SKOS-XL"
	    TERM_CUR["✓ Curadoria"]
	    TERM_ACQ["✓ Aquisição"]
		TERM_PUB["✓ Apresentação"]
    end

    PUB["Público · Pesquisadores · Comunidades Tradicionais"]

    FS -.->|via IA, opcional| EP
    EP --> ED_ACQ
    FS --> ED_ACQ

    FP --> ER_ACQ

    ED_ACQ --> MONGO
    MONGO <--> ED_CUR
    MONGO --> ED_PUB

    ER_ACQ --> MONGO
    MONGO <--> ER_CUR
    MONGO --> ER_PUB

	MONGO --Aquisição Direta--> TERM_ACQ
	TERM_PUB --> PUB
    ED_PUB --> PUB
    ER_PUB --> PUB

    style EP fill:#28a745,stroke:#1e7e34,color:#ffffff
    style TERM_CUR fill:#28a745,stroke:#1e7e34,color:#ffffff
	style TERM_ACQ fill:#28a745,stroke:#1e7e34,color:#ffffff
	style TERM_PUB fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ED_ACQ fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ED_CUR fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ED_PUB fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ER_ACQ fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ER_CUR fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ER_PUB fill:#28a745,stroke:#1e7e34,color:#ffffff
    style MONGO fill:#1168bd,stroke:#0b4884,color:#ffffff

Legenda:

• Verde: containers implementados e disponíveis nos repositórios GitHub
• Laranja: etnoRelatos — em desenvolvimento
• Azul: MongoDB compartilhado com coleções separadas por projeto
• Linha pontilhada: entrada opcional (fontes secundárias podem ir direto ao etnoDB sem passar pelo etnopapers)

Esta arquitetura possui implementações concretas que materializam os conceitos propostos:

Interface web para gerenciamento de conhecimento tradicional secundário extraído de artigos científicos. Implementa os três contextos arquiteturais principais:

Características:

• Três Interfaces Especializadas:
  • Aquisição (porta 3001): Entrada de dados por pesquisadores
  • Curadoria (porta 3002): Validação e aprovação de registros
  • Apresentação (porta 3003): Consulta pública com busca avançada
• Stack Tecnológico: Node.js, Express, MongoDB, HTMX, Alpine.js, Tailwind CSS
• Estrutura de Dados: Hierárquica (Referência → Comunidade → Planta → Uso)
• Workflow C.A.R.E.: Implementação de status (pendente/aprovado/rejeitado)
• 29 Classificações de Comunidades: Conforme Decreto nº 8.750, de 9 de maio 2016

Componente da camada de Apresentação que permite interação com o banco de dados através de linguagem natural.

Funcionalidades:

• Formulação de perguntas em linguagem natural sobre comunidades e plantas
• Sugestões automáticas de buscas e relacionamentos entre dados
• Explicações contextualizadas sobre registros etnobotânicos
• Integração com MCP (Model Context Protocol) para comunicação com modelos de IA

Acesso: Rota /etnochat na porta 3003

Componente da camada de Apresentação para exploração e análise visual dos dados etnobotânicos.

Funcionalidades:

• Cartões Resumidos: Total de comunidades, referências aprovadas, plantas únicas e autores
• Visualizações Geográficas: Mapas de calor com distribuição por estado
• Gráficos Interativos:
  • Evolução temporal de publicações (gráfico de área)
  • Top 10 plantas mais citadas (gráfico de barras)
• Tabelas Analíticas:
  • Autores mais produtivos
  • Comunidades com maior diversidade botânica
  • Referências mais abrangentes
• Filtros Avançados: Estado, tipo de comunidade e período de publicação

Stack: Google Charts, HTMX, Alpine.js, Tailwind CSS

Acesso: Rota /painel na porta 3003

Aplicativo desktop Windows para extração automatizada de metadados de artigos científicos em PDF usando inteligência artificial.

Características:

• Plataforma: Windows (.NET 8, WPF, MVVM)
• Extração com IA:
  • Google Gemini (15 req/min, gratuito)
  • OpenAI GPT-4o-mini
  • Anthropic Claude 3.5 Haiku
• Integração Nativa: MongoDB (Atlas ou local)
• Dados Extraídos:
  • Obrigatórios: Título, autores, ano, abstract
  • Opcionais: Espécies (nomes vernaculares e científicos), usos, comunidades, localização
• Performance: Melhoria de 50% em relação a soluções locais

Plataforma digital para preservação e organização do conhecimento etnobotânico através de um sistema estruturado de glossários, vocabulários controlados e tesauros, seguindo o padrão SKOS-XL (W3C Simple Knowledge Organization System eXtension for Labels). Totalmente integrado ao etnoDB, atuando como infraestrutura terminológica transversal em todos os seus contextos (Aquisição, Curadoria e Apresentação).

Propósito:

Documentar termos e conhecimentos de comunidades tradicionais brasileiras sobre plantas e animais, garantindo reconhecimento cultural, padronização terminológica e justiça na distribuição de benefícios. O padrão SKOS-XL viabiliza interoperabilidade com padrões de dados abertos (Linked Data, RDF) e integração com iniciativas como GBIF, SiBBr e Wikidata.

Características:

• Gestão de Conceitos (SKOS-XL):

  • Criação com identificadores únicos (URIs) e suporte multilíngue
  • Rótulos preferenciais e alternativos (skosxl:prefLabel / skosxl:altLabel)
  • Relações hierárquicas (skos:broader / skos:narrower)
  • Relações associativas (skos:related)
  • Desambiguação de termos idênticos
  • Polihierarquia (múltiplos conceitos mais amplos)

• Sistema de Notas (SKOS):

  • Notas de escopo (skos:scopeNote) e definições (skos:definition)
  • Notas históricas (skos:historyNote) e editoriais (skos:editorialNote)
  • Exemplos de uso (skos:example)

• Gestão de Fontes:

  • Rastreabilidade de origens (bibliográficas, conhecimento tradicional)
  • Conformidade com princípios CARE para governança de dados indígenas

• Recursos Técnicos:

  • Busca: Meilisearch para busca inteligente
  • Autenticação: OAuth Google
  • Exportação: SKOS-XL/RDF, JSON-LD, Dublin Core, CSV
  • APIs: REST para integração com etnoDB e sistemas externos
  • Containerização: Docker com GitHub Actions

Integração na Arquitetura:

O etnoTermos funciona como infraestrutura terminológica transversal totalmente integrada ao etnoDB, conectando os três contextos:

1. Aquisição: Fornece vocabulários controlados (SKOS-XL) para padronização na entrada de dados, autocomplete de termos validados para etnoDB e etnoRelatos
2. Curadoria: Oferece base para validação semântica, normalização de nomenclatura vernacular e desambiguação de termos
3. Apresentação: Permite navegação por tesauros estruturados e busca expandida por sinônimos e termos relacionados

Plataforma para aquisição, registro e gestão de dados de conhecimento tradicional associado à biodiversidade provenientes de fontes primárias — registrado diretamente junto às comunidades tradicionais. Complementa o etnoDB, que é dedicado a fontes secundárias (artigos científicos, livros).

Diferença fundamental em relação ao etnoDB:

Propósito:

Registrar diretamente o conhecimento tradicional sobre biodiversidade das comunidades tradicionais brasileiras, com todos os protocolos éticos e legais requeridos (Consentimento Livre, Prévio e Informado — CLPI, conforme Lei 13.123/2015). Este projeto está em fase inicial de desenvolvimento.

Integração na Arquitetura:

O etnoRelatos atua no Contexto de Aquisição da EtnoArquitetura como canal para dados primários, alimentando o mesmo MongoDB compartilhado com o etnoDB. Os dados registrados seguem o mesmo workflow de curadoria, mas com validação comunitária adicional. O etnoTermos fornece suporte terminológico também para o etnoRelatos.

graph TB
    PDF["PDFs de Artigos"] --> EP["etnopapers<br/>Extração com IA"]
    PDF --> ED_ACQ["etnoDB<br/>Aquisição<br/>Entrada Manual"]
    CAMPO["Registros de Campo<br/>Comunidades Tradicionais"] --> ERELA["etnoRelatos<br/>Aquisição Primária"]

    EP --> MONGO[("MongoDB")]
    ED_ACQ --> MONGO
    ERELA --> MONGO

    ET["etnoTermos<br/>Vocabulários · SKOS-XL"] --> ED_ACQ
    ET --> ED_CUR
    ET --> ED_PUB
    ET --> ERELA

    MONGO <--> ED_CUR["etnoDB<br/>Curadoria"]
    MONGO --> ED_PUB["etnoDB<br/>Apresentação"]
    MONGO --> CHAT["etnoChat<br/>Interface Conversacional"]
    MONGO --> DASH["Painel Analítico<br/>Dashboard"]

    ED_PUB --> PUB["Público"]
    CHAT --> PUB
    DASH --> PUB

    style ED_ACQ fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ED_CUR fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ED_PUB fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ET fill:#28a745,stroke:#1e7e34,color:#ffffff
    style EP fill:#28a745,stroke:#1e7e34,color:#ffffff
    style CHAT fill:#28a745,stroke:#1e7e34,color:#ffffff
    style DASH fill:#28a745,stroke:#1e7e34,color:#ffffff
    style ERELA fill:#28a745,stroke:#1e7e34,color:#ffffff

O fluxo integrado permite que:

1. etnopapers processa PDFs e extrai metadados usando IA, salvando diretamente no MongoDB
2. etnoDB (Aquisição) permite entrada manual de dados secundários por pesquisadores, também salvando no MongoDB
3. etnoRelatos registra conhecimento tradicional diretamente de comunidades tradicionais (fontes primárias), com protocolo CLPI, salvando no mesmo MongoDB
4. etnoTermos fornece vocabulários controlados (SKOS-XL) para padronização terminológica em todos os contextos, com integração total ao etnoDB e suporte ao etnoRelatos
5. As três fontes alimentam a mesma base de dados de forma paralela
6. etnoDB (Curadoria) valida e aprova os registros (de todas as fontes), com suporte de validação semântica do etnoTermos
7. etnoDB (Apresentação) disponibiliza dados validados publicamente, com navegação por tesauros do etnoTermos
8. etnoChat permite consultas em linguagem natural via integração com IA (MCP)
9. Painel Analítico oferece visualizações interativas e análises estatísticas dos dados

A arquitetura deste sistema é documentada utilizando o C4 Model, um framework de visualização que descreve arquiteturas de software através de 4 níveis de diagrama progressivamente mais detalhados (criado por Simon Brown):

1. Context (Contexto): Visão de alto nível mostrando o sistema como uma caixa preta e suas interações com usuários e sistemas externos
2. Container (Contêiner): Decomposição do sistema em contêineres tecnológicos (aplicações, bancos de dados, serviços) e como se comunicam
3. Component (Componente): Detalhamento interno de cada contêiner, mostrando os componentes principais e suas responsabilidades
4. Code (Código): Nível de detalhe de classes, interfaces e relações (opcional, utilizamos quando necessário)

Essa abordagem oferece clareza progressiva: iniciantes entendem o contexto geral, arquitetos visualizam containers e decisões técnicas, e desenvolvedores acessam detalhes de componentes. Os diagramas neste repositório seguem este padrão, permitindo navegação intuitiva da visão geral até a implementação.

Responsável pela entrada de dados no sistema de múltiplas fontes:

• Dados Secundários: Extração de informações de artigos científicos, livros e publicações
• Dados Primários: Registro direto com todos os cuidados éticos e legais necessários
• Coleta Automatizada: Robôs que monitoram periódicos científicos (ex: etnobotânica)
• Integrações: APIs para consumo de dados de sistemas externos

sequenceDiagram
    participant Fonte as Fonte de Dados
    participant API as API de Ingestão
    participant Validador as Validador
    participant DB as Base de Dados

    Fonte->>API: Envia dados (padrão definido)
    API->>Validador: Valida estrutura
    Validador->>API: Confirma validação
    API->>DB: Armazena com status "pendente"
    DB-->>API: Confirmação

Características principais:

• Padrão de dados unificado para todas as fontes
• APIs RESTful para ingestão
• Sistema de fila para processamento assíncrono
• Validação automática de dados taxonômicos via GBIF e Global Names

Interface dedicada para qualificação e validação dos dados:

• Acesso restrito a pesquisadores e representantes de comunidades
• Workflow de aprovação e enriquecimento de dados
• Integração com APIs de validação taxonômica
• Controle de versões e auditoria de alterações

stateDiagram-v2
    [*] --> Pendente
    Pendente --> EmRevisão: Curador inicia revisão
    EmRevisão --> Rejeitado: Dados insuficientes
    EmRevisão --> EmValidação: Revisão completa
    EmValidação --> Aprovado: Validação taxonômica OK
    EmValidação --> EmRevisão: Requer correção
    Aprovado --> Publicado: Curador publica
    Publicado --> [*]
    Rejeitado --> [*]

Portal público para acesso e consulta das informações validadas:

• Interface web responsiva
• APIs públicas de consulta
• Visualizações interativas
• Sistema de busca avançada
• Exportação de dados em formatos abertos

Devido à complexidade e flexibilidade necessárias para armazenar conhecimento tradicional, três abordagens são consideradas:

1. Bancos de Dados SQL - Modelo relacional

   • Estrutura rigorosa com esquema bem definido
   • Integridade referencial garantida
   • Consultas poderosas em dados estruturados
   • Ideal para relacionamentos complexos

2. Bancos Orientados a Documentos (JSON)

   • Flexibilidade no esquema
   • Escalabilidade horizontal
   • Consultas ricas em documentos estruturados como JSON
   • Armazenamento natural de dados semi-estruturados

3. Bancos Multi-Modais

   • Suportam múltiplos modelos de dados (documentos, grafos, relações)
   • Permitem modelar relações complexas entre entidades
   • Query language moderna e versátil
   • Flexibilidade arquitetural para evolução futura

• Flora e Funga do Brasil API (https://floradobrasil.jbrj.gov.br/consulta/) - Verificação primária de nomenclatura científica e validação de dados taxonômicos para plantas, algas e fungos brasileiros
• Fauna do Brasil API (https://fauna.jbrj.gov.br/) - Verificação primária de nomenclatura científica e validação de dados taxonômicos para fauna brasileira
• GBIF API (https://www.gbif.org/) - Validação de dados taxonômicos como fallback quando não encontrado nas bases brasileiras

• Plataforma de Territórios Tradicionais (MPF) (https://territoriostradicionais.mpf.mp.br/) - Sincronização de polígonos territoriais de povos indígenas e comunidades tradicionais, validação de proveniência geográfica e cruzamento espacial de registros com seus territórios de origem

• Outras Fontes Autoritativas - Padrão extensível para integração com sistemas especializados (SISGEN, SiBBr, registros comunitários) que complementam validação e enriquecimento de dados

• Periódicos científicos via APIs ou scraping ético, com extração de dados com auxílio de IA

• Collective Benefit: Os dados devem beneficiar as comunidades que os originaram
• Authority to Control: Comunidades mantêm autoridade sobre seus conhecimentos
• Responsibility: Responsabilidade ética no manejo dos dados
• Ethics: Respeito às práticas éticas e culturais

O sistema respeita:

• Lei da Biodiversidade (Lei 13.123/2015)
• Protocolo de Nagoya
• Legislações locais sobre conhecimento tradicional

Este repositório está organizado da seguinte forma:

etnoArquitetura/
├── README.md (este arquivo)
├── docs/
│   ├── c4-model/
│   │   ├── 01-context-diagram.md
│   │   ├── 02-container-diagram.md
│   │   └── 03-component-diagram.md
│   ├── architecture-decisions/
│   │   ├── ADR-001-database-selection.md
│   │   ├── ADR-002-api-standards.md
│   │   └── ADR-003-data-model.md
│   └── diagrams/
│       ├── data-flow.md
│       └── integration-patterns.md

1. Diagrama de Contexto - Visão de alto nível do sistema e seus usuários
2. Diagrama de Containers - Componentes principais e suas tecnologias
3. Diagrama de Componentes - Detalhamento interno de cada contexto
4. Decisões Arquiteturais - ADRs documentando escolhas técnicas

1. Definição detalhada do modelo de dados
   • Considerando a diferença entre dados primários e secundários
2. Prototipação das APIs de ingestão
3. Desenvolvimento do sistema de autenticação e autorização
4. Implementação do workflow de curadoria
5. Desenvolvimento da interface pública

A proposta de arquitetura incorpora lições aprendidas do projeto NIKMAS (National Indigenous Knowledge Management System) da África do Sul, especialmente:

• Modelo de Dados Dual: Preservação simultânea de artefatos originais (gravações audiovisuais, fotos) e estruturas de metadados formais para proteção legal
• Arquitetura Distribuída: Nó central com Pontos de Presença (PoPs) regionais para captura descentralizada e sincronização seletiva respeitando confidencialidade
• Segurança Multi-Camadas: Controle de acesso baseado em políticas (XACML) para proteção de conhecimento sensível
• Catálogo de Detentores: Base de dados de indivíduos e comunidades detentores de conhecimento com rastreamento de proveniência
• Curadoria Estruturada: Interface dedicada para especialistas validarem e anotarem dados

Reconhecendo que muitas comunidades tradicionais em áreas remotas têm acesso móvel limitado mas penetrante, a arquitetura prevê:

• Aplicações Mobile Offline-First: Captura de dados sem necessidade de conexão permanente
• Integração SMS/USSD: Acesso a informações via mensagens de texto para regiões com infraestrutura móvel limitada
• WhatsApp Integration: Suporte a plataforma popular para comunicação e consultas
• Apps Comunitárias: Desenvolvimento de aplicativos customizados para diferentes contextos culturais

Esta abordagem segue exemplos bem-sucedidos como CyberTracker e MAPEO, que demonstram o potencial de tecnologias móveis para empoderamento comunitário em monitoramento participativo.

O sistema implementa um workflow robusto de validação em múltiplas etapas:

1. Validação Estrutural: Verificação automática de conformidade com padrões de dados
2. Validação Taxonômica: Integração com bases brasileiras (Flora e Funga para flora/fungos, Fauna para fauna) com fallback para GBIF API quando não encontrado nas bases brasileiras
3. Validação Semântica: Integração com vocabulários existentes
4. Curadoria Especializada: Revisão por especialistas de domínio (botânicos, etnobólogos, farmacêuticos tradicionais)
5. Validação Comunitária: Participação de detentores de conhecimento na certificação de dados antes de publicação
6. Rastreabilidade Completa: Logs de auditoria de todas as mudanças e validações

Para coleta ética e consentida de dados diretamente das comunidades:

• Processo CLPI (Consentimento Livre, Prévio e Informado): Implementação de protocolo completo baseado em Lei 13.123/2015
• Registro Comunitário: Interface para comunidades registrarem autonomamente seu próprio conhecimento
• Acordos Eletrônicos: Armazenamento e rastreamento de acordos de compartilhamento de benefícios
• Infopreneurs Locais: Capacitação de membros da comunidade como coletores de dados com oportunidades de geração de renda
• Documentação Audiovisual: Suporte a preservação de conhecimento em múltiplas formas (áudio, vídeo, foto, texto)

A arquitetura está projetada para integração bidirecional com a Plataforma de Territórios Tradicionais do Ministério Público Federal:

• Sincronização de Polígonos Territoriais: Importação automática de limites geográficos de territórios indígenas e tradicionais
• Cruzamento Espacial: Associação de registros de conhecimento com territórios de origem
• Rastreabilidade Geográfica: Visualização interativa de onde conhecimentos são praticados
• Dados Públicos do MPF: Acesso a informações sobre status de demarcação, conflitos e historicamente de ocupação
• API de Integração: Endpoints REST para consulta e sincronização de dados territoriais

Esta integração fortalece:

• Rastreabilidade de conhecimento até sua origem territorial
• Suporte a processos de demarcação e regularização
• Monitoramento de ameaças a territórios que guardam conhecimento tradicional
• Conformidade com Lei 13.123/2015 sobre proveniência geográfica

A arquitetura adota e contribui para padrões de dados abertos reconhecidos:

• Darwin Core: Para ocorrências de espécies e dados de biodiversidade
• Plinian Core: Para descrições de espécies e informações sobre usos
• Dublin Core Estendido: Para metadados ricos e flexíveis
• SocioBio Standard: Padrão específico para dados de sociobiodiversidade brasileira (ver projeto SocioBio no GitHub)

Integração planejada com principais sistemas brasileiros:

• SiBBr (Sistema de Informação sobre Biodiversidade Brasileira): Nó brasileiro do GBIF
• SisGen (Sistema Nacional de Gestão do Patrimônio Genético): Rastreamento de acesso e repartição de benefícios
• CNPq: Integração com dados de pesquisadores e grupos de pesquisa
• GBIF Global: Contribuição de dados brasileiros para rede global de biodiversidade

Esta arquitetura integra projetos implementados e dialoga com iniciativas em desenvolvimento:

• etnoDB - Interface web com três contextos (Aquisição, Curadoria, Apresentação) para conhecimento tradicional secundário
• etnopapers - Aplicativo desktop com extração automatizada de metadados via IA (Gemini, GPT-4, Claude)
• etnoTermos - Infraestrutura terminológica com glossários, vocabulários e tesauros no padrão SKOS-XL, com integração total ao etnoDB

• etnoRelatos - Plataforma para aquisição de dados primários de conhecimento tradicional diretamente de comunidades tradicionais

• Useflora - Banco de dados etnobotânicos com registro comunitário onde comunidades definem níveis de acesso

• SocioBio - Padrão de dados para sociobiodiversidade brasileira, desenvolvido pelo SiBBr
• CESP SiBBr 2024 - Iniciativa de ciência aberta e interoperabilidade do Sistema de Informação sobre Biodiversidade Brasileira

• EtnoVocab - Vocabulário controlado para termos etnobotânicos e etnobiológicos
• EtnoVector - Vetorização e representação semântica de conceitos etnobotânicos

• Estrutura de Dados Etnobotânicos - Modelos e esquemas para armazenamento de informações etnobotânicas

Estes projetos complementares fornecem:

• Implementações concretas da arquitetura (etnoDB e etnopapers)
• Padrões de dados interoperáveis
• Vocabulários controlados para melhorar a qualidade dos dados
• Exemplos práticos de implementação
• Recursos para curadoria e validação de informações etnobotânicas

Para a lista completa de referências bibliográficas organizadas segundo a norma ABNT NBR 6023:2018 (padrão brasileiro), consulte Referencias.md.

Essa documentação incorpora referências a:

• Legislação brasileira e internacional relevante (Lei 13.123/2015, Protocolo de Nagoia, Convenção 169 OIT)
• Padrões de dados abertos (Darwin Core, Plinian Core, Dublin Core, SocioBio)
• Arquitetura de sistemas (NIKMAS, Fedora, OAIS)
• Governança de dados (FAIR, CARE)
• Tecnologias móveis (CyberTracker, MAPEO)
• Etnobiologia e conhecimento tradicional
• Iniciativas brasileiras práticas (GEF Entre-Ciências, SISGEN, Useflor@, RCS)
• Data sovereignty e consentimento livre, prévio e informado (CLPI)

Para acompanhar a evolução completa desta arquitetura, consulte o CHANGELOG.md que documenta todas as versões e mudanças significativas desde a versão 1.0.0 inicial até a atual versão 2.0.0.

Se você usar esta proposta de arquitetura em seu trabalho, por favor cite como:

APA:

Dalcin, E. (2026). Arquitetura para um Sistema de Informações sobre Conhecimento Tradicional Associado à Biodiversidade - Versão 2.0 (Version v2.0) [Software documentation]. Zenodo. https://doi.org/10.5281/zenodo.18075074

BibTeX:

@software{dalcin2026,
  author = {Dalcin, Eduardo},
  title = {Arquitetura para um Sistema de Informações sobre Conhecimento Tradicional Associado à Biodiversidade - Versão 2.0},
  version = {v2.0},
  year = {2026},
  publisher = {Zenodo},
  doi = {10.5281/zenodo.18075074},
  url = {https://doi.org/10.5281/zenodo.18075074}
}

DOI: 10.5281/zenodo.18075074

Este é um projeto em fase de proposta. Contribuições e sugestões são bem-vindas através de issues e pull requests.

A definir - considerando licenças que respeitem os princípios C.A.R.E. e protejam adequadamente o conhecimento tradicional.

Para mais informações sobre este projeto, entre em contato através das issues deste repositório.