1. Propósito
Este documento transforma o Dicionário de Dados e Metadados em uma regra prática de aplicação. Ele indica quais elementos devem ser preenchidos em cada situação, evitando tanto a ausência de metadados essenciais quanto o excesso de campos sem finalidade reconhecível.
Definição central: um perfil de aplicação é uma seleção governada
de elementos de metadados, restrições, cardinalidades, vocabulários controlados e
regras de uso adequada a um contexto específico.
2. Posicionamento na cadeia documental
Modelo Conceitual de Dados e Metadados → Dicionário de Dados e Metadados → Perfil de Aplicação → Esquemas lógicos e validação
O modelo conceitual define as entidades e relações. O dicionário descreve todos os campos disponíveis. O perfil de aplicação seleciona quais campos serão empregados em determinado tipo de registro. Os esquemas lógicos materializam essas decisões em JSON, banco relacional, grafo, formulário ou interface.
3. Autoridade e dependências
Derivações posteriores
- JSON Schema dos objetos de conhecimento.
- Modelo lógico relacional.
- Modelo lógico de grafo.
- Formulários de cadastro e validação.
- Rotinas de auditoria de metadados.
4. Escopo do perfil
Este perfil abrange os seguintes tipos de registro:
Objetos de conhecimento
Unidades conceituais com identidade própria.
Representações
HTML, imagem, knowgrama, JSON, grafo, banco de dados e outros suportes.
Jornadas
Percursos orientados por pergunta, objetivo, estados e entregas.
Fontes e evidências
Registros de origem, suporte e comprovação.
Versões e validações
Histórico de alteração, revisão, aceitação e qualidade.
Publicações e decisões
Registros de implantação, aprovação, governança e responsabilidade.
5. Níveis de obrigatoriedade
| Nível | Significado | Regra |
|---|---|---|
| Obrigatório | Elemento indispensável à identidade, compreensão, integridade ou governança. | O registro não deve ser considerado válido sem o preenchimento. |
| Recomendado | Elemento que amplia qualidade, recuperação, contexto ou interoperabilidade. | Pode ser omitido, mas a ausência deve ser reconhecida. |
| Opcional | Elemento útil somente em situações específicas. | Preencher quando houver valor claro para uso, gestão ou aprendizagem. |
| Condicional | Elemento obrigatório apenas quando determinada condição ocorre. | A condição deve estar declarada na regra do campo. |
6. Princípios de aplicação
- Finalidade: nenhum campo deve ser exigido sem finalidade de uso reconhecível.
- Proporcionalidade: a quantidade de metadados deve ser compatível com o valor, risco e maturidade do objeto.
- Identidade estável: objetos e representações devem possuir identificadores persistentes.
- Separação conceitual: objeto de conhecimento não se confunde com arquivo, página ou representação.
- Rastreabilidade: origem, autoria, versão, validação e publicação devem ser recuperáveis.
- Vocabulário controlado: estados, tipos, papéis e relações devem usar termos padronizados.
- Evolução progressiva: o perfil mínimo pode ser enriquecido conforme o objeto amadurece.
- Governança explícita: exceções devem ser registradas e justificadas.
7. Núcleo mínimo comum
Todo registro governado do LAC deve possuir um conjunto mínimo comum, independentemente do seu tipo específico.
| Elemento | Obrigatoriedade | Aplicação | Regra |
|---|---|---|---|
| identificador | Obrigatório | Todos os registros | Único, estável e não reutilizável. |
| tipo | Obrigatório | Todos os registros | Valor de vocabulário controlado. |
| título ou nome | Obrigatório | Todos os registros identificáveis | Forma legível para pessoas. |
| descrição | Recomendado | Todos os registros | Explicar natureza e finalidade. |
| estado | Obrigatório | Registros sujeitos a ciclo de vida | Usar estado controlado. |
| responsável | Obrigatório | Registros governados | Agente ou papel responsável. |
| data de criação | Obrigatório | Todos os registros persistidos | Formato ISO 8601. |
| data de atualização | Condicional | Registros alterados | Obrigatória após a primeira alteração. |
| versão | Recomendado | Objetos e representações | Controlar evolução significativa. |
| proveniência | Recomendado | Conteúdo derivado ou importado | Indicar origem e transformação. |
8. Perfil para Objeto de Conhecimento
| Campo | Nível | Finalidade | Condição ou regra |
|---|---|---|---|
| oc_id | Obrigatório | Identidade conceitual. | Persistente e independente do arquivo. |
| titulo | Obrigatório | Identificação humana. | Claro, específico e não ambíguo no contexto. |
| descricao | Obrigatório | Delimitação do objeto. | Expressar o que é e para que serve. |
| tipo_objeto | Obrigatório | Classificação. | Usar vocabulário controlado. |
| dominio | Recomendado | Contextualização temática. | Pode haver mais de um domínio. |
| conceitos_associados | Recomendado | Recuperação semântica. | Referenciar conceitos controlados. |
| estado_ciclo_vida | Obrigatório | Governança da maturidade. | Rascunho, em revisão, validado, publicado, obsoleto ou legado. |
| responsavel | Obrigatório | Responsabilização. | Agente ou papel reconhecido. |
| jornada_origem | Recomendado | Rastreabilidade. | Obrigatório quando produzido por jornada formal. |
| fontes | Condicional | Proveniência e evidência. | Obrigatório para conteúdo factual derivado de fontes. |
| data_criacao | Obrigatório | Histórico. | ISO 8601. |
| data_atualizacao | Condicional | Histórico. | Obrigatório após alteração. |
| versao_atual | Recomendado | Controle evolutivo. | Referenciar registro de versão. |
| representacoes | Obrigatório | Acesso ao objeto. | Ao menos uma representação deve existir. |
9. Perfil para Representação
| Campo | Nível | Finalidade | Condição ou regra |
|---|---|---|---|
| rep_id | Obrigatório | Identidade da representação. | Único e persistente. |
| oc_id | Obrigatório | Vínculo com o objeto. | Não pode existir representação órfã. |
| tipo_representacao | Obrigatório | Classificação técnica e cognitiva. | HTML, imagem, knowgrama, JSON, grafo, PDF, banco de dados etc. |
| formato | Obrigatório | Interoperabilidade. | MIME type ou formato controlado. |
| localizacao | Obrigatório | Acesso físico ou lógico. | URI, caminho ou identificador de armazenamento. |
| idioma | Recomendado | Acesso e busca. | BCP 47, como pt-BR. |
| titulo | Recomendado | Identificação. | Pode herdar do objeto quando apropriado. |
| versao | Obrigatório | Controle de alteração. | Independente da versão conceitual quando necessário. |
| checksum | Recomendado | Integridade técnica. | Especialmente em produção. |
| acessibilidade | Recomendado | Inclusão e qualidade. | Registrar recursos ou limitações. |
| ambiente | Obrigatório | Implantação. | Desenvolvimento, validação ou produção. |
| estado_publicacao | Obrigatório | Governança. | Não publicado, em validação, publicado, substituído ou retirado. |
10. Perfil para Jornada
| Campo | Nível | Finalidade | Condição ou regra |
|---|---|---|---|
| jor_id | Obrigatório | Identidade da jornada. | Formato estável e controlado. |
| titulo | Obrigatório | Reconhecimento. | Expressar o resultado ou transformação principal. |
| pergunta_ativadora | Obrigatório | Origem cognitiva. | Deve ser explícita ou derivada de uma demanda formal. |
| objetivo | Obrigatório | Finalidade. | Resultado verificável. |
| escopo | Obrigatório | Delimitação. | Incluir limites e exclusões relevantes. |
| papel_responsavel | Obrigatório | Responsabilidade. | Autor, gestor, curador, agente etc. |
| estado | Obrigatório | Acompanhamento. | Planejada, ativa, suspensa, concluída ou cancelada. |
| entradas | Obrigatório | Material inicial. | Referenciar objetos, documentos, perguntas ou demandas. |
| entregas | Obrigatório | Saídas esperadas. | Referenciar objetos ou representações produzidas. |
| criterios_aceitacao | Obrigatório | Validação. | Devem ser verificáveis. |
| transacoes | Recomendado | Estrutura operacional. | Obrigatório em jornadas complexas. |
| decisoes | Recomendado | Governança. | Registrar decisões relevantes. |
11. Perfil para Fonte e Evidência
Fonte
Obrigatórios: identificador, título ou descrição, tipo, origem, data de acesso ou obtenção e responsável pelo registro.
Recomendados: autor, data de publicação, URI, editora ou instituição, idioma, direitos e nota de confiabilidade.
Evidência
Obrigatórios: identificador, afirmação ou decisão suportada, fonte associada, trecho ou localização e responsável pela associação.
Recomendados: força da evidência, contexto, data de verificação, limitações e estado de validade.
Regra: uma evidência não deve ser registrada apenas como link.
Deve indicar o que ela sustenta, onde o suporte se encontra e em qual contexto foi utilizado.
12. Perfil para Versão e Validação
| Registro | Campos obrigatórios | Campos recomendados |
|---|---|---|
| Versão | versao_id, objeto ou representação, número ou rótulo, data, responsável, descrição da mudança. | motivo, jornada, decisão associada, versão anterior, impacto e compatibilidade. |
| Validação | validacao_id, objeto validado, critério, resultado, responsável e data. | evidências, observações, não conformidades, recomendação e prazo de correção. |
13. Perfil para Publicação e Decisão
Publicação
Obrigatórios: publicação_id, representação, ambiente, data, responsável, estado e localização publicada.
Recomendados: validação anterior, versão, checksum, registro de implantação e possibilidade de reversão.
Decisão
Obrigatórios: decisão_id, questão decidida, decisão, responsável, data e objetos afetados.
Recomendados: alternativas, critérios, justificativa, evidências, riscos e consequências.
14. Perfis por tipo de objeto do LAC
| Tipo | Elementos adicionais obrigatórios | Elementos recomendados |
|---|---|---|
| Página conceitual | propósito, definição central, relações, estado e responsável. | fontes, evidências, documentos relacionados e próximas derivações. |
| Knowgrama | objeto representado, título, versão, autoria, data e descrição textual. | legenda, elementos visuais, acessibilidade e página de contexto. |
| Índice ou portal | escopo, área atendida, itens relacionados e critério de organização. | público, jornadas de entrada e data de revisão. |
| Modelo | objeto modelado, finalidade, elementos, relações, restrições e versão. | hipóteses, exemplos, critérios de validação e derivações. |
| Política ou regra | escopo, autoridade, regra, vigência, responsável e exceções. | justificativa, riscos, evidências e histórico de decisões. |
| Experimento de P&D | hipótese, método, entradas, execução, resultados e responsável. | dados, evidências, limitações, reprodutibilidade e decisão resultante. |
15. Metadados por etapa do ciclo de vida
| Etapa | Metadados mínimos | Controle principal |
|---|---|---|
| Proposto | identificador provisório, título, tipo, autor da proposta, data e necessidade. | Evitar duplicidade. |
| Em elaboração | responsável, escopo, versão de trabalho, fontes iniciais e jornada. | Rastrear autoria e evolução. |
| Em revisão | critérios, revisores, versão submetida, data e não conformidades. | Controlar qualidade. |
| Validado | resultado da validação, responsável, data e evidências. | Confirmar aceitação. |
| Publicado | ambiente, localização, versão, data, responsável e checksum recomendado. | Assegurar integridade. |
| Substituído ou obsoleto | motivo, sucessor, data, decisão e impacto. | Preservar continuidade. |
| Legado | origem, período de validade, motivo de preservação e relação com o vigente. | Preservar memória histórica. |
16. Perfis por ambiente
Desenvolvimento
Exige identidade, tipo, responsável, estado, data e vínculo com demanda ou jornada. Campos de publicação podem permanecer incompletos.
Validação
Exige versão identificável, critérios de aceitação, responsáveis pela revisão, evidências e registro de não conformidades.
Produção
Exige perfil completo de identidade, proveniência, versão, validação, publicação, ambiente, localização e responsabilidade.
A promoção de desenvolvimento para validação ou produção é uma mudança de estado
governada, e não apenas uma cópia física de arquivos.
17. Herança e reaproveitamento de metadados
Metadados podem ser herdados do objeto de conhecimento para suas representações, desde que a origem seja explícita e que o valor continue válido.
| Metadado | Pode ser herdado? | Observação |
|---|---|---|
| Título | Sim | A representação pode possuir título específico. |
| Descrição | Sim | Pode exigir adaptação ao formato. |
| Domínio | Sim | Herdado do objeto salvo especialização. |
| Responsável | Parcialmente | Responsável conceitual pode diferir do responsável técnico. |
| Versão | Não automaticamente | Versão do objeto e versão da representação são distintas. |
| Estado | Não automaticamente | Objeto validado pode ter representação ainda não publicada. |
| Direitos | Sim, com verificação | Representações podem incorporar materiais com direitos próprios. |
18. Regras condicionais principais
- Se o conteúdo contém afirmações factuais derivadas, então fonte e evidência tornam-se obrigatórias.
- Se uma representação é publicada em produção, então versão, ambiente, data, responsável e localização tornam-se obrigatórios.
- Se um objeto foi alterado após validação, então deve existir nova versão e nova avaliação de impacto.
- Se um objeto substitui outro, então a relação de sucessão e a decisão correspondente tornam-se obrigatórias.
- Se houver agente de IA participante, então papel, ação executada e responsável humano pela validação devem ser registrados.
- Se houver dado pessoal, restrito ou sensível, então classificação de acesso e fundamento de tratamento tornam-se obrigatórios.
19. Critérios de qualidade dos metadados
Completude
Campos obrigatórios preenchidos e campos condicionais avaliados.
Exatidão
Valores correspondem ao objeto, à representação e ao estado real.
Consistência
Valores não se contradizem entre registros relacionados.
Atualidade
Datas, estados, localizações e responsáveis permanecem vigentes.
Rastreabilidade
Origem, autoria, decisão, versão e transformação podem ser recuperadas.
Interoperabilidade
Tipos, formatos e vocabulários permitem uso em diferentes representações.
20. Validação do perfil
Um registro atende ao perfil quando:
- possui todos os campos obrigatórios aplicáveis;
- teve todas as condições avaliadas;
- usa identificadores e vocabulários controlados válidos;
- não apresenta relações órfãs ou contraditórias;
- possui responsabilidade e estado explícitos;
- mantém coerência entre objeto, representação, versão e publicação.
Conformidade = obrigatórios completos + condicionais avaliados + domínios válidos + relações íntegras
21. Exemplo aplicado
Exemplo simplificado para a página modelo_da_maquina_de_conhecimento_lac.html:
| Campo | Valor exemplificativo | Nível |
|---|---|---|
| oc_id | OC-MC-MOD-001 | Obrigatório |
| titulo | Modelo da Máquina de Conhecimento do LAC | Obrigatório |
| tipo_objeto | modelo_conceitual | Obrigatório |
| estado_ciclo_vida | publicado | Obrigatório |
| responsavel | Walter Dominguez | Obrigatório |
| rep_id | REP-MC-MOD-001-HTML | Obrigatório |
| tipo_representacao | pagina_html | Obrigatório |
| localizacao | fundacao/modelo_da_maquina_de_conhecimento_lac.html | Obrigatório |
| versao | 1.0 | Obrigatório |
| jornada_origem | Jornada de formalização da Máquina de Conhecimento | Recomendado |
22. Orientação para implementação
Formulários
Os campos obrigatórios devem ser visíveis e validados; os condicionais devem aparecer quando a condição for ativada.
JSON Schema
Os níveis de obrigatoriedade devem ser traduzidos em required, enumerações, formatos e dependências.
Banco relacional
Obrigatoriedade deve orientar nulabilidade, chaves, restrições e tabelas de domínio.
Grafo
Relações obrigatórias devem ser verificadas para evitar nós órfãos e trajetórias sem proveniência.
23. Governança do perfil
Alterações neste perfil devem ser controladas por versão e decisão registrada. A inclusão de um campo obrigatório deve apresentar finalidade, impacto, fonte de autoridade e plano de migração para registros existentes.
Regra de mudança: um campo não deve passar de opcional para obrigatório
sem análise do impacto sobre páginas, registros, formulários, bancos, grafos e rotinas já existentes.
24. Próximas derivações
- Produzir o JSON Schema do Objeto de Conhecimento.
- Produzir o JSON Schema da Representação.
- Produzir o modelo lógico relacional.
- Produzir o modelo lógico de grafo para Memgraph.
- Criar formulário HTML para cadastro e validação de metadados.
- Criar rotina de auditoria de conformidade do perfil.
- Atualizar o índice da Fundação.
25. Síntese
O Perfil de Aplicação de Metadados do LAC transforma o dicionário geral em um conjunto aplicável de obrigações, recomendações e condições para diferentes objetos, etapas e ambientes.
Conclusão: o dicionário diz quais metadados existem; o perfil de
aplicação determina quais devem ser utilizados em cada contexto; os esquemas e
sistemas de persistência executam essas decisões.
26. Estado do documento
Versão inicial consolidada
Fundação
Documento apto a orientar esquemas JSON, modelos lógicos, formulários, auditorias de metadados e processos de publicação do LAC.