Metadados do conteúdo

[ppKrauss]

Agora que temos um primeiro draft do conteúdo na base de dados, conforme src/step1.sql, podemos impor regras e processos para obtenção de metadados na carga dos conteúdos.

Os metadados principais são aqueles que estabelecem a origem do dado, ou seja,

• jurisdição (no sendo jurisdiction da URN LEX). Ex. br;rj;campinas.

• data de publicação do DO (data ISO ex. 2013-02-21).

• convenção nossa sobre "autoridade" do Diário Oficial: Governo/Poder viculado. Governos federal, estadual e municipal, conforme jurisdição. Poder judiciário, legislativo ou executivo. Exemplo: gov-exePS: também é prevista para uso futuro a autoridade não-governamental (ex. org-condominio;nome.condominio).

No caso da urn_do um ID de controle das matérias é suficiente, caso exista, senão deve ser destacado como id-lex.

Exemplo de URN: br;rj;rio.janeiro:gov-exe:2015-02-02:materia:100150 designa 100150.html.

[JaTvoiRabotnik]

Acho que isso fica sendo de responsabilidade do coletor. Deixa eu ver com o Andres se o TrazDia pode ser refatorado pra fazer essas coisas, de uma maneira abstrata.

[ppKrauss]

@JaTvoiRabotnik, "Coletor=trazDia"? Acho que cabe no TrazDia, justamente porque a API do trazDia precisa aceitar algum formato padrão de identificação transparente dos diários e suas matérias. O padrão LEX já prevê isso, e o site do LexML tem zilhões de exemplos.

... Bom, ao que tudo indica o TrazDia será um projeto independente (!), de modo que essa issue aqui já seria movida para lá... Ou optamos por desenvolver a API-TrazDia aqui (ou seja a "API a rigor" que é apenas a casca de um software), e depois fazer uso dela já como requisito do TrazDia.

Ah, ELI e ECLI (European Legislation Identifier e European Case Law Identifier) são muito similares à URN LEX, são IDs transparentes e baseados em metadados explícitos do conteúdo identificado... reforçam a necessidade de adotarmos um padrão de ID transparente.

[JaTvoiRabotnik]

@ppKrauss, isso.

Eu acho que é saudável a prática dos consumidores da API ditar o que precisa, e a API então prover. Então formular como a API deveria se comportar aqui no queriDO parece ser uma boa idéia. Aí, no TrazDia a gente pode tomar decisões arquitetônicas que violam ou não os requerimentos, mas com justificativa e compensação.