Metadados

Visão Geral e Guia de preenchimento

1. Visão Geral dos Metadados

Atualmente o Conector Local pode gerar documentos baseados em três tipos de metadados diferentes:

• Diploma Digital a partir dos metadados indicados em JSON;

• Documentação Acadêmica a partir dos metadados indicados em JSON;

• Inserir Representação Visual a partir dos metadados indicados em JSON.

A estrutura dos metadados é dividida em duas partes: a seção meta e seção data. A seção meta é comum para todos os tipos de metadados, diferenciando apenas os valores indicados para cada campo.

{
    "meta": {
        "clientId": "institution_id",
        "yourNumber": "",
        "dltId": "ethereum",
        "docType": "visual_rep_degree",
        "mimeType": "application/pdf",
        "clientSignature": "",
        "groupId": "1" 
  } 
} 

Os valores dos campos são preenchidos da seguinte forma:

• clientId: ID da instituição junto ao RAP. Também chamado de institution_id. É enviado para cada instituição no momento da adesão ao serviço.

• yourNumber: código que identifica unicamente cada documento internamente à instituição.

• dltId: identificador da blockchain que será utilizada para registro. Atualmente o id suportado é ethereum. Esse campo é opcional. Caso não seja enviado ou enviado vazio, o documento não será registrado na blockchain.

• docType: Tipo de documento que está sendo processado. Opções são:

  • visual_rep_degree: referente a um documento do tipo representação visual de um diploma digital;

  • academic_doc_mec_degree: referente a um documento do tipo XML que representa uma Documentação Acadêmica de um aluno;

  • digital_degree: Referente a um documento do tipo XML que representa um Diploma Digital de um aluno.

• mimeType: Tipo de documento que está sendo enviado. Exemplo: text/xml para documentos XML ou application/pdf para documentos PDF e PDF/A.

• clientSignature: Campo reservado para uso futuro que deve ser enviado como string vazia.

• isDocSigned: Informa se o documento que está sendo processado será assinado ou não. Esse campo é opcional e por padrão é verdadeiro. No caso da geração de representação visual esse campo deve ser indicado com valor falso (false)

• groupId: Esse campo representa o ID que associa unicamente uma tupla de documentos.

No caso do diploma digital um grupo (groupId) pode ser uma dupla que combina um XML de Documentação Acadêmica + XML de Diploma Digital ou um trio que combina XML de Documentação Acadêmica + XML de Diploma Digital + PDF da Representação Visual (nesse caso os três documentos serão agrupados pelo serviço RAP). O ID de grupo é uma string e pode ser gerado da forma que a instituição achar mais conveniente. TODOS OS DOCUMENTOS QUE COMPÕE UMA TUPLA DEVEM CONTER UM MESMO ID DE GRUPO. A correta geração de IDs únicos e sua indicação por tupla de documentos é condição essencial para correta gestão dos documentos e pode acarretar erros caso não estejam corretamente configurados.

Como exemplo de uso, caso desejássemos gerar um grupo de documentos relacionados ao diploma digital teríamos os seguintes campos meta nos metadados hipotéticos:

• XML da Documentação Acadêmica

{ 
    "meta": { 
        "clientId": "institution_id" , 
        "yourNumber": "AAA" , 
        "dltId": "ethereum" , 
        "docType": "academic_doc_mec_degree" , 
        "mimeType": "tex/xml" , 
        "clientSignature": "" , 
        "isDocSigned": true , 
        "groupId": "1" 
    } 
} 

• XML do Diploma Digital

{ 
    "meta": { 
        "clientId": "institution_id" , 
        "yourNumber": "BBB" , 
        "dltId": "ethereum" , 
        "docType": "digital_degree" , 
        "mimeType": "text/xml" , 
        "clientSignature": "" , 
        "groupId": "1" 
    } 
} 

• PDF da Representação Visual

{ 
    "meta": { 
        "clientId": "institution_id" , 
        "yourNumber": "CCC" , 
        "dltId": "ethereum" , 
        "docType": "visual_rep_degree" , 
        "mimeType": "application/pdf" , 
        "clientSignature": "" , 
        "isDocSigned": false , 
        "groupId": "1" 
    } 
} 

Na tupla de exemplo acima o id de grupo (groupId) é 1 . Percebam que o yourNumber é único para cada documento. Essa tupla de metadados representa o os documentos relacionados ao processamento do Diploma Digital de UM aluno.

O campo data dos metadados são preenchidos de acordo com cada documento/forma de geração.

Vide arquivos de exemplos de preenchimentos** desses campos.

Também foram disponibilizados esquemas JSON** que podem ser utilizados para validar os metadados JSON criado antes de enviar para o Conector local iniciar o processamento.

Algumas considerações sobre o preenchimento dos campos data dos tipos de metadados:

• Diploma Digital a partir dos metadados indicados em JSON;

  • Conjunto de campos solicitados na Nota Técnica No. 13/2019/DIFES/SESU/SESU/MEC, Seção 7.12 - Anulação do Diploma;

  • Campo Versão: versão do XSD utilizado para gerar o XML do Diploma Digital;

• Documentação Acadêmica a partir dos metadados indicados em JSON;

  • Conjunto de campos solicitados na Nota Técnica No. 13/2019/DIFES/SESU/SESU/MEC, Seção 7.12 - Anulação do Diploma;

  • Campo Versão : versão do XSD utilizado para gerar o XML da Documentação Acadêmica.

• Representação Visual a partir dos metadados indicados em JSON.

  • Campo ReferenciaDiploma: mesmo código VDip contido no atributo infoDiploma do XML do Diploma Digital.

1.1. Esquemas para validação dos dados montados no formato JSON

Junto com os exemplos de JSON montados para Documentação Acadêmica, Diploma Digital e Representação Visual, estão os Schemas que podem ser utilizados para validar se o documento correspondente montado está válido e deverá ser processado com sucesso pelo Conector local. É possível confrontar o JSON montado com o Schema utilizando validadores online como o https://www.jsonschemavalidator.net/ Para uma lista completa de validadores de esquema, consultar: https://json-schema.org/implementations.html#validators