Trocar 461 por 3000. Na v1.0.0 são o max(id) é 2381, então pode-se eleger do 3000 em diante como ID seguro para novos itens.

Atualmente o projeto apelidado de SQL-datasets Unifier permite carregar automaticamente todos os datasets no SQL, facilitando sua gestão.

Podemos usar o Try-SQL-Datasets como framework de referência para expressar operações SQL de proveniência e manutenção, bem como apoio na geração de relatórios, etc.

Isso eliminaria a necessidade de manter códigos-fonte mais gerais no presente projeto.

Usar o seguinte conf.json para reunir todos os datasets relevantes ao projeto:

{
   "github.com":{
        "okfn-brasil/lexml-vocabulary":null,
        "datasets-br/state-codes":"br-state-codes",
        "datasets-br/city-codes":null
   },
   "useBig":true, "useIDX":false, "useRename":true
}

Foi convencionada como interface de manutenção de arquivos CSV deste projeto o Google-spreadsheets.

Dessa forma é importante NUNCA copiar CSV direto de outro aplicativo, sempre subir para o Google-spreadsheets antes. As principais diferenças de um aplicativo para o outro são terminadores de linha e aspas... Apesar de não afetarem a interoperabilidade, o diff do Github acusa alteração indevidamente.

O vocabulário de autoridades (CSV) possui itens duplicados (no atributo about), tais como: procuradoria.geral.republica, imprensa.oficial, tribunal.regional.trabalho;turma.1 e outros.

Tem seus motivos, na procuradoria.geral.republica por exemplo são as facetas "Federal::Ministério Público da União::Procuradoria Geral da República" e "Federal::Procuradoria Geral da República"
que justificam a duplicação.

Mas a boa prática sugere que não hajam duplicações, e que se opte por uma só faceta — relativa ao termo corrente, canônico ou mais utilizado no acervo LexML.

As demais facetas podem ser tratadas mais objetivamente como instâncias, fazendo uso da proposta da issue #3, onde a informação relativa às variantes de conotação do mesmo nome ficaria registada num arquivo separado, o instancia.rdf.xml.

Mesmo no caso de TipoDocumento, quando existirem significados distintos, podemos resolver indicando diferentes instâncias semânticas como instâncias onde o nome (fragmento de URN) se torna válido.

Procedimento

1. Detectar duplicações via base SQL;
2. Expressar duplicados do passo anterior em instancia.rdf.xml (issue #3) ou sinonimos.rdf.xml (issue #4);
3. Eliminar duplicados dos vocabulários RDF.
4. Atualizar as bases de dados, para refletir as correções em todos os arquivos.

Dando continuidade à iniciativa da issue #2, pode-se também expressar a associação com item semântico da Wikidata através de prefixos de URN. Exemplos típicos são as autoridades, que uma vez contextualizadas (instanciadas) pela jurisdição, ganham nova roupagem semântica.

Retomando o exemplo da Câmara Municipal (camara.municipal), cujo conceito genérico Q10262936 pode se especializar conforme a jurisdição:

• br;sao.paulo;campinas:camara.municipal é Q10262900;
• br;sao.paulo:assembleia é Q4808730.

Proposta de arquivo complementar

Conforme nota abaixo, pode não se tratar apenas de prefixos simples, mas de uma notação geral de prefixos ou fragmentos de URNs LEX, para designar "instâncias semânticas". A sugestão portanto é de que o nome de arquivo seja instancia.rdf.xml, com representação direta em planilha CSV.

NOTA: a conotação de TipoDocumento pode também, em casos particulares, ficar especificada pela jurisdição, e de forma independente da autoridade. Por exemplo para se distinguir decreto.lei brasileiro dos demais países de língua portuguesa, pode-se usar a notação br:*:decreto.lei para o prefixo. Cabe todavia avaliar se, para o escopo do projeto LexML Brasil já não estará implícita essa contextualização (BR).

Sinônimos canônicos: resolução por data

Nomes oficiais vigentes são automaticamente canônicos. Por exemplo dos nomes oficiais de municípios, fixados pelo IBGE, obtêm-se os lexLabels canônicos dos municípios (jurisdições que comporão URNs LEX).

Mas o que é vigente hoje pode não ter sido o mesmo ontem... Um bom exemplo é o município de Serra Caiada (RN), nome oficial vigente associado ao item semântico Q2298053. O item Q2298053 já teve outros nomes em outras datas:

• br;rn;serra.caiada::[1953-11-24..1962-11-30,2013-01-14..]
• br;rn;presidente.juscelino::[1963..1963]
• br;rn;presidente.kubitschek::[1964-01-23..2013-01-13]

Isso pode ser confirmado pela legislação da nomenclatura do município:

• "Serra Caiada", município criado pela Lei nº 908 de 24 de novembro de 1953
• "Presidente Juscelino" em dezembro de 1963
• "Presidente Kubitschek", Lei Estadual, nº 3.077, de 23/01/1964.
• "Serra Caiada" de volta, Lei Estadual, nº 9.691, de 14/01/2013.

Sugere-se portanto a inclusão dos intervalos de tempo da vigência das instâncias de nomes no arquivo instancia.rdf.xml.

Faz mais sentido por ser o repositório oficia, e desejarmos uma participação mais oficial. Tudo preparado por lá:
https://github.com/lexml/lexml-vocabulary

Foi convencionado na norma técnica LexML Parte 2, na sua seção 4.3.3, "Substituição de Espaços, Conectivos e Pontuação", que preposições são eliminadas quando da conversão de nome oficial para URN LEX. Por exemplo "Rio de Janeiro" é convertido para rio.janeiro, sem o de.

Por estensão lógica, o "de" contraído de nomes oficiais, tais como "Espigão D'Oeste" ou "Olho d'Água", também deveria ser removido na conversão para URN LEX. Sem isso, nomes usualmente praticados como "Espigão do Oeste" terão sua grafia URN LEX incompatível com a versão canônica.

Como por hora, do que se pôde levantar dos vocabulários LexML vigentes, não há risco de se criar ambiguidade, sugere-se impor a regra da exclusão do .d. das URNs LEX.

Nomes de jurisdições (municípios) com preposição "da", "de" ou "do" contraída, e que apresentam particular .d. na sua respectiva URN LEX:

Alta Floresta D'Oeste
Alvorada D'Oeste
Aparecida d'Oeste
Barra D'Alcântara
Conquista D'Oeste
Diamante D'Oeste
Dias d'Ávila
Espigão D'Oeste
Estrela d'Oeste
Figueirópolis D'Oeste
Glória D'Oeste
Guarani d'Oeste
Herval d'Oeste
Itapejara d'Oeste
Itaporanga d'Ajuda
Lagoa d'Anta
Lambari D'Oeste
Machadinho D'Oeste
Mãe d'Água
Mirassol d'Oeste
Nova Brasilândia D'Oeste
Olho d'Água
Olho-d'Água do Borges
Olho d'Água do Casado
Olho d'Água das Cunhãs
Olho d'Água das Flores
Olho d'Água Grande
Olho D'Água do Piauí
Olhos-d'Água
Palmeira d'Oeste
Pau D'Arco
Pau D'Arco
Pau D'Arco do Piauí
Pérola d'Oeste
Pingo-d'Água
Rancho Alegre D'Oeste
Santa Bárbara d'Oeste
Santa Clara d'Oeste
Santa Luzia D'Oeste
Espigão D'Oeste
Estrela d'Oeste
Figueirópolis D'Oeste
Glória D'Oeste
Guarani d'Oeste
Herval d'Oeste
Itapejara d'Oeste
Itaporanga d'Ajuda
Lagoa d'Anta
Lambari D'Oeste
Machadinho D'Oeste
Mãe d'Água
Mirassol d'Oeste
Nova Brasilândia D'Oeste
Olho d'Água
Olho-d'Água do Borges
Olho d'Água do Casado
Olho d'Água das Cunhãs
Olho d'Água das Flores
Olho d'Água Grande
Olho D'Água do Piauí
Olhos-d'Água
Palmeira d'Oeste
Pau D'Arco
Pau D'Arco
Pau D'Arco do Piauí
Pérola d'Oeste
Pingo-d'Água
Rancho Alegre D'Oeste
Santa Bárbara d'Oeste
Santa Clara d'Oeste
Santa Luzia D'Oeste
Santa Rita d'Oeste
São Felipe D'Oeste
São João d'Aliança
São João do Pau d'Alho
São Jorge d'Oeste
Sítio d'Abadia
Tanque d'Arca

• licença de software: não é o foco do projeto, seria relativa à pasta /src. Sugiro MIT (semelhante a CC-BY) para não restringir, alguns preferem GNU, Apache2, etc. que se assemelham a um CC-BY-SA.

• licença de dados (incluindo RDF): sugiro CC0 (como as leis do Brasil) ou CC-BY-SA-4 (como o SchemaOrg).
  ... O certo seria herdar o que está previsto com os RDFs v1.0, mas não foi explicitada no repositório de origem.

Ver listagem dos comitês estaduais em cbh-codes/cbh.csv. São instâncias para a formulação das normas que regulam a gestão da água no Brasil.

• CBHs inter-municipais: são jurisdições internas aos limites de um estado. Exemplos: br;mg;cbh;rio.piranga (CBH MG5), br;mg;cbh;entorno.lago.furnas (CBH MG15), br;sp;cbh;alto.tiete (CBH SP15), br;sp;cbh;paraiba.sul (CBH SP14).
  Exemplo de norma: Deliberação CBH-PS 009/2017.

• CBHs inter-estaduais: exemplo São Francisco, br;cbh;sao.francisco. Ver http://cbhSaoFrancisco.org.br

Correções para a v1.0 do vocabulário de Localidades. Originais em RDF-v1.
PS: as correções podem ser realizadas manualmente na planilha de revisão colaborativa.

Itens ausentes, para inserir

3 itens.

Itens para satisfazer padrão IBGE vigente

9 itens, três mudanças de nome e 6 de grafia.

Scripts e análise

Revisar src/prepV1_step1.sql conforme scripts abaixo, baseados no schema dataset.

Usando a proposta da issue #1 pode-se obter as VIEWS SQL de ambos datasets, localidade e br_city_codes, e então conferir o join entre eles:

CREATE VIEW dataset.vw_br_state_codes_lex AS 
   SELECT 'br;'||lexlabel as urn_jur, subdivision FROM dataset.vw_br_state_codes;

CREATE VIEW dataset.vw_br_city_codes_full AS
  SELECT c.*, x.urn_jur||';'||c.lexlabel as urn_jur
  FROM dataset.vw_br_city_codes c  INNER JOIN dataset.vw_br_state_codes_lex x
       ON  x.subdivision=c.state;

CREATE VIEW dataset.vw_br_city_synonyms_full AS
  SELECT c.*, x.urn_jur as state_lexlabel, 
                 x.urn_jur ||';'|| lib.name2lex(synonym) as urn_jur
  FROM dataset.vw_br_city_synonyms c  INNER JOIN dataset.vw_br_state_codes_lex x
       ON  x.subdivision=c.state;

CREATE VIEW vwtest_geral_urnlex AS
  SELECT 'br' as urn_jur
  UNION  (SELECT 'br;df')
  UNION (SELECT urn_jur FROM dataset.vw_br_state_codes_lex)
  UNION (SELECT urn_jur FROM  dataset.vw_br_city_codes_full)
  UNION (SELECT urn_jur FROM  dataset.vw_br_city_synonyms_full)
;
-- --
CREATE or replace FUNCTION dataset.br_city_canonic(text) RETURNS text AS $f$
  SELECT COALESCE((
    SELECT state_lexlabel||';'||lexlabel 
    FROM dataset.vw_br_city_synonyms_full 
    WHERE urn_jur=$1),
    $1
  );
$f$ LANGUAGE SQL IMMUTABLE;

---  Gera listagem de nomes ausentes da base IBGE e dos sinônimos:
SELECT about, faceta
FROM dataset.vw_localidade 
WHERE about NOT IN (SELECT urn_jur FROM vwtest_geral_urnlex)
ORDER BY 1
; -- se tudo ok vai retornar apenas justica, etc. nada de cidades

SELECT urn_jur as ausente, concat(name,' (',state,')') as name, idibge
FROM dataset.vw_br_city_codes_full
WHERE urn_jur NOT IN (
    SELECT dataset.br_city_canonic(about) FROM dataset.vw_localidade
)
; -- se tudo ok retorna vazio, senão a lista é de itens a serem inclusos em Localidade.

SELECT about as about_errado, canonic as about_correto  
FROM (
    SELECT about, dataset.br_city_canonic(about) as canonic FROM dataset.vw_localidade
) t 
WHERE canonic!=about;
-- se tudo ok retorna vazio, senão é são itens a serem corrigidos conforme canônico.

As versões estão sendo rotuladas formalmente no git com os rótulos dos lançamentos (releases). A sugestão é de se adotar o padrão "Semantic Versioning" corrente, http://semver.org/

Ainda assim, por ser uma ontologia e não um software, alguns cuidados precisam ser tomados na interpretação do MAJOR.MINOR.PATCH:

• PATCH: "correção de falhas" que aqui podem ser também entendidas como "manutenção" (por exemplo atualização com novos nomes de cidade fornecidos pela atualização dos padrões IBGE).

• MINOR: "adicionar funcionalidades mantendo compatibilidade", o que aqui podemos interpretar como adição de atributos (por exemplo adição do Wikidata-ID no RDF), ou de arquivos RDF complementares que não comprometem a compatibilidade (ex. lista de todos "sinônimos e abreviações oficiais" num arquivo CSV).

• MAJOR: quebra de compatibilidade com versões anteriores, ou grande modificação, afetando forma de uso, escopos, etc.

É um esboço: importante que seja claro e haja consenso em torno do que ficar definido. É interessante também fixar convenções quanto a versões de pré-lançamento (pre-release), ex. 1.0.0-alpha, o que mudaria ligeiramente a dinâmica dos lançamentos.

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

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>

Trata-se do único item com atributo xml:lang="en" nos 3 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>

No RDF do vocabulário fazem sentido, além do nome oficial, a abreviação ou sigla oficiais. Também faz sentido incluir instâncias com nomes diferentes em datas diferentes, conforme segunda parte da issue #3...

... Todas as outras variantes de grafia um mesmo nome canônico podem ser expressas como sinônimos. Com os diferentes acordos ortográficos, ou mesmo casos de "tradição de uso", alguns nomes não-oficiais acabam sendo aceitos em documentos oficiais.

O critério para se registrar um sinônimo é a existência de pelo menos um documento oficial (portanto existe URN LEX desse documento) com a variante ortográfica.

Proposta: criar sinonimos.rdf.xml como complemento aos vocabulários.

Diversos termos empregados nos vocabulários, principalmente TipoDocumento e Localidade, são semanticamente completos, ou seja, sozinhos são suficientes, não apresentam ambiguidade. Para indicar com precisão o item semântico associado pode-se referenciar o identificador Wikidata (wdId) correspondente.

Exemplos de termos genéricos sem ambiguidade na língua portuguesa:

• Autoridade Câmara Municipal (about camara.municipal) corresponde exatamente ao conceito genérico de "câmara dos vereadoes de um município qualquer do Brasil", fixado pelo Wikidata-ID Q10262936.

• Autoridade Ministério Público (about ministerio.publico) corresponde exatamente ao item semântico Q11775750, que não está atrelado à jurisdição, portanto é genérico.

• Autoridade Ministério Público Federal (about ministerio.publico.federal) corresponde exatamente ao item semântico Q10330355, dispensando vínculo com jurisdição, pois já o faz implicitamente (palavra "Federal") associação à jurisdição.

• Todas as jurisdições (vocabulário de Localidade), por serem "raiz" da URN LEX, devem ser definidas sem ambiguidade. De fato, todas elas possuem entradas na Wikidata, podendo ser referenciadas sem ambiguidade.
  Exemplos: br é Q155, br;sao.paulo é Q175, br;sao.paulo.campinas é Q171617, etc.

• TipoDocumento Projeto de Lei (about projeto.lei) corresponde exatamente ao item semântico Q686822, podendo depois ser instanciado para um significado mais específico (federal ou da respectiva jurisdição estadual ou municipal).

Implantação

A relação entre o item semântico do vocabulário Wikidata e do vocabulário LexML, no contexto acima (de equivalência) pode ser expressa como propriedade SKOS exactMatch, ou qualquer outra equivalente:
http://schema.org/sameAs = https://www.w3.org/2009/08/skos-reference/skos.html#exactMatch ~= http://www.w3.org/2004/02/skos/core#closeMatch

NOTAS

O Ministério Público (geral) no Brasil é um todo composto de partes:

1. Ministério Público da União (subdivido em Ministério Público Federal, Ministério Público do Trabalho, Ministério Público Militar e Ministério Público do Distrito Federal e Territórios);
2. Ministérios Públicos dos Estados.

Esse tipo de relacionamento já vem sendo expresso nos vocabulários LexML, através da propriedade skos:broader. Convém todavia revisar demais oportunidades de expressão do relacionamento. Em alguns casos, como no ilustrado, estabelecer com mais precisão, através do uso do skos:broaderTransitive.