lexml / lexml-vocabulary

Vocabulários do Projeto LexML

     

Vocabulários LexML

O controle de vocabulários desempenha papel fundamental na organização da informação governamental e estruturação de conteúdos nos documentos oficiais.

Os vocabulários do projeto LexML Brasil, conforme apresentados na Parte 6 das normas LexML, são utilizados nas [URNs LEX](https://en.wikipedia.org/wiki/Lex_(URN) (Parte 2). Há também a previsão de utilização dos vocabulários LeXML como referência para os diários oficiais do governo brasileiro, no controle da terminologia espressa em títulos das matérias e seções dos diários.

Os vocabulários são aqueles elencados nas seções 2 e 3 da referida norma Parte 6:
"2.1 Natureza do Conteúdo" (tipoConteudo), "2.2 Língua" (lingua), "2.3 Evento" (evento), "3.1 Localidade" (localidade), "3.2 Autoridade" (autoridade) e "3.3 Tipo de Documento" (tipoDocumento), disponíveis nas pastas /data/RDF-v* do presente repositório, com proveniência e autenticidade descritos nesta documentação.

Na ausência de um comitê formal (seção 1.1 da Parte 6), os mantenedores do presente repositório git assumem parte das atribuições do "Comitê Central para a Atribuição de Nomes" do LexML.

Apesar do padrão RDF permitir o uso de diferentes formatos, foi adotado o RDF/XML como principal — que por sua vez, historicamente no LexML, foi inspirado pelo padrão RDA.

Versão corrente dos vocabulários

A tag de versão próprio git determina a versão corrente válida — a mais recente entre as versões lançadas, e em geral anterior ao último commit do repositório. As tags de versão seguem a sintaxe de Major.minNor.Patch (vM.N.P), sendo que os arquivos RDF são mantidos em sua versão mais na pasta correspondente vM.N.

A tag do repositório só é atribuída quando todos os RDFs da pasta mais atual forem homologados. Arquivos que não sofrem alteração permanecem na pasta onde receberam a última homologação. No repositório são previstos os seguintes tipos de arquivo:

• Documentos XML formato RDF: mantidos cada qual na sua pasta data/RDF-vM.N, quando um arquivo estiver ausente significa que ainda se encontra na versão anterior (portanto na pasta correspondente).

• Documentos CSV: mantidos na pasta de dados, data e descritos no arquivo datapackage.json, seguem a versão corrente do repositório, em sincronia (ou à frente) dos arquivos RDF. Versões específicas poderão ser encontradas navegandos-se pelas versões antigas do repositório.

Licenças

• Software: algoritmos e códigos-fonte de software, licença relativa à pasta /src, MIT.

• Dados: arquivos CSV, JSON, XML e demais arquivos de dados, ODbL-1.0

• Conteúdo: presente documentação e todos os aqrquivos da pasta /docs, CC-BY-4.

lexml-vocabulary's Issues

Normalização dos arquivos XML e CSV para evitar falsos-alertas de modificação

O controle de versões git e o esquema de autenticação, conforme lembrado na descrição do preparo, são ambos baseados em checksum, de modo que são sensíveis às minimas variações nos arquivos, inclusive modificações "inócuas" no espaçamento ou quebras de linha.

Convencionar algoritmos de normalização que garantam sempre a mesma produção de arquivos XML e CSV, independente do software ou tipo de edição realizada.

• XML: adotar normalização C14N da Libxml2, que está presente em todas as linguagens e plataformas.

• CSV: na falta de algo melhor, adotar o padrão PHP da função fputcsv(), baseado em pacote C, e que provavelmente tem seu correspondente em todas as demais linguagens abertas, tais como Python, Java, etc.

Trazendo da OKBR para o LexML

O presente repositório foi inspirado no okfn-brasil/lexml-vocabulary, de modo que algoritmos e metodologias estão sendo trazidos de lá.

Como eles descrevem todo o processo, já é possível no primeiro commit apresentar a versão 1.0.0 dos vocabulários LexML.

Por que manter a pré-coordenação de autoridades multiplas

Não seria melhor deixar para fazer a coordenação "a posteriore". Fazer uma pós-coordenação. Não se pode prever todas as possibilidade de coordenação entre os órgãos.
Vejam o exemplo que sugiro eliminar:
ministerio.fazenda;secretaria.receita.federal,tribunal.superior.eleitoral

prefLabel inglês, regras para sua adoção

A regra de validação "um só <skos:prefLabel> por <skos:Concept>" poderia ser aplicada em todos os vocabulários.
A exeção surgiu no Autoridades. Trata-se também do único item com atributo xml:lang="en" entre todos os vocabulários: pode ser removido.

  <skos:Concept rdf:about="lei" rdf:id="1">
    <skos:prefLabel lexml:faceta="Legislação::Lei" rdf:nodeID="label_1" xml:lang="pt-BR">Lei</skos:prefLabel>
    <skos:altLabel rdf:nodeID="label_2" xml:lang="pt-BR">Lei Ordinária</skos:altLabel>
    <skos:prefLabel lexml:traducaoDe="label_1" rdf:nodeID="label_30" xml:lang="en">Act</skos:prefLabel>
    <skos:inScheme rdf:resource="#tipoDocumento"/>
  </skos:Concept>

Oferecer CSV que reproduza as informações do RDF

Implantar software simples de conversão e manter arquivos CSV atualizados conforme os RDF. Já está previsto o uso do algoritmo src/vocLexMLRdf2csv.php.

A versão do CSV deve ser compatível com a versão do seu RDF correspondente no momento do release de cada versão.

---

Os arquivos também serão úteis como meio intermediário para modificações manuais: alterações manuais da equipe no CSV são levadas ao SQL, e do SQL se produz o XML final.

Versionamento 1.0.X e 1.1.0, discussões aqui

Planejamento das próximas versões, a partir da v1.0.1. Discutir aqui cada as propostas, associando issues consolidadas com as versões onde entrariam. Por exemplo o bug #7 entraria já na v1.0.2.

voc. lingua, nome oficial do Português do Brasil

A sigla pt-br designa Português do Brasil, não é apenas Português (genérico). Sugere-se corrigir o seu skos:prefLabel.

---

PS1: quanto ao uso do <skos:inScheme rdf:resource="#lingua"/> neste e em outros vocabulários, me parece redundante, visto que uma das regras fundamentais de qualquer XML é a herança: se nada é dito contrário, o elemento herda o atributo. A regra da herança também deveria ser usada para subintender o xml:lang (o idioma no qual são expressas as descrições e nomenclaturas).

PS2: quanto às regras discutidas em #6, convém limitar aos idiomas previamente definidos neste vocabulário, assim como explicitar o link entre eles.

Atributo lexml:urnAlt de Localidade precisa de separador

O valor do atributo urnAlt em <skos:altLabel lexml:urnAlt="brac" ...> precisa ser br;ac, com separador ";" antes de "br".

Exemplo extraído do vocabulário de Localidade:

  <skos:Concept rdf:about="br;acre" rdf:id="20">
    <skos:prefLabel lexml:faceta="Estados::Acre" lexml:facetaAcronimo="AC – Acre"
     rdf:nodeID="label_77"  xml:lang="pt-BR">Acre</skos:prefLabel>
    <skos:altLabel lexml:acronimoDe="label_77" lexml:urnAlt="brac" rdf:nodeID="label_78" 
     xml:lang="pt-BR">AC</skos:altLabel>
    <skos:inScheme rdf:resource="#localidade"/>
    <skos:broader rdf:resource="#br"/>
</skos:Concept>

identificador global duplicado no RDF TipoDocumento

Identificadores globais rdf:id (aparecem como <skos:Concept rdf:id="123">) não podem ser duplicados dentro de um mesmo arquivo .rdf.xml.

Já na versão v1.0.0 do vocabulário de TipoDocumento aparecia o rdf:id="461" duas vezes.

Solução: trocar a segunda ocorrência de 461 por 3000. Na v1.0.0 são o max(rdf:id) é 2381, então pode-se eleger do 3000 em diante como ID seguro para novos itens.

Incluir controle Goodtables no git

Usar https://goodtables.io para as planilhas CSV.

Por que a repetição das informações no facetaAcronimo?

As informações das outras colunas eu sei para que servem, mas não sei porque as informações das colunas prefLabel e altLabel estão repetidas na coluna facetaAcronimo. Essa concatenação poderia ser feito por sistema?