radar
radar copied to clipboard
radar-parlamentar
Interoperabilidade com LexML
Sugestão de se incluir no SQL função de conversão de ID da norma (ex. Lei) ou proposição (ex. PL) em URN LEX.
Para quem não conhece, o LexML é muito mais do que um "site de busca",
o Projeto LexML, http://projeto.lexml.gov.br/ , definiu uma série de padrões para interoperabilidade
sendo talvez o padrão mais importante, aquele que define a URN LEX para todas as normas e proposições normativas (projetos de Lei) do Brasil.
- Toda Lei, e seu Projeto de Lei, tem um identificador universal, transparente e único. Por exemplo o Marco Civil da Intenet, tem um identificador único,
urn:lex:br:federal:lei:2014-04-23;12965, assim como o Projeto de Lei que lhe deu origem, ourn:lex:br:senado.federal:projeto.lei;pls:2000-05-24;151
PS: na maioria dos casos é possível omitir o mês e dia: ex.urn:lex:br:federal:lei:2014;12965também funcional (é uma "URN de referência" enquanto a data completa caracteriza a "URN canônica"). - Toda URN LEX-BR pode ser resolvida no http://www.lexml.gov.br/urn , e esse URN Resolver tem garantia de estabilidade (não falha nem sai do ar) e de persistência (em 2020 ainda vai estar resolvendo as URNs) ... Análogo do http://dx.doi.org.
A proposições legislativas da base de dados do Radar Parlamentar poderiam ter já na base de dados uma expressão parcial das URNs, permitindo com isso:
- oferecer trivialmente (não precisa de um template para cada autoridade) para os usuários links confiáveis para os documentos e metadados dos documentos
- conferir consistência (e/ou corrigir automaticamente datas ou IDs) dos dados (com a lista de URNs válidas)
- "falar a mesma língua" com outros sistemas e com iniciativas de Dados Abertos, através das URNs (são padrão e-PING).
- garantir rastreabilidade do projeto de Lei que foi aprovado (código da lei correspondente)
- ...
+1 para a iniciativa, achei muito legal a proposta do Peter ! E acho que dialoga muito com a proposta de termos um webservice!
@diraol Estou pensando numa "arquitetura de microservices" bem ao estilo dx.doi.org para apoiar as URNs e tendo o LexML como resolução federada (não precisamos esperar o governo de São Paulo se organizar para fazer uso das suas URNs visto que são transparentes)... Se quizerem discutir podemos unir esforços. Tem também a possibilidade de interoperar com o pessoal do Diário Aberto (ah e o EuVoto, o Legislando, e outros)... convidemos o @andresmrm para conversar sobre potencial de interoperabilidade com o Radar.
Opa! Parece interessante sim. A ideia seria fazer um micro serviço que, a partir do URN, retornasse dados sobre a lei em São Paulo?
@andresmrm os serviços de "ficha catalográfica do documento" ou "ficha da revista" já existem no universo biblioteconômico, com diferentes comportamentos mas todos eles podendo ser descritos como "me passa o ID do documento que eu te passo a URL dele ou umas infos sobre ele".
Como todo "ID público" pode ser considerado uma URN, podemos usar o antigo jargão das URNs (RFC2169) para expressar o comportamento desses microserviços típicos de "resolução de nomes":
- "URN to URL" (N2L): serviço de redirecionamento de DOI como o realizado pelo
dx.doi.org(concatenado ao /DOI). - "URN to URLs" (N2Ls) e "info": serviço de redirecionamento (ou entrega de dados em JSON, etc.) para uma página de metadados, uma "ficha catalográfica" do documento. A API do DOI faz isso. O serviço de resolução do LexML (concatenando a URN LEX ao
www.lex.gov.br/urn/) também é desse tipo. - ... outros: menos comuns.
Dentro desse modelo podemos entender que diversos outros serviços por aí já realizam "resolução de URN" para diversas URNs... Listei algumas nessa proposta embrionária (veja por exemplo que o Worldcat é um resolvedor de fato para os códigos de revista, os ISSNs). Poderiamos incluir aí a resolução de CEP do Correio, a resolução de CPF da Fazenda, e por aí vai... "Tem ID público? precisa ter URN-resolver associado para se dizer aberto ao público".
Essa arquitetura simples de resolvedores permite que sistemas bem diversos se conversem, se tornem interoperáveis, e façam uso de fato dos padrões já bem estabelecidos de identificação pública das coisas.
Me parece uma solução bem boa. =)
Quoting Peter (2015-04-23 08:52:43)
@andresmrm os serviços de "ficha catalográfica do documento" ou "ficha da revista" já existem no universo biblioteconômico, com diferentes comportamentos mas todos eles podendo ser descritos como "me passa o ID do documento que eu te passo a URL dele ou umas infos sobre ele".
Como todo "ID público" pode ser considerado uma URN, podemos usar o antigo jargão das URNs (RFC2169) para expressar o comportamento desses microserviços típicos de "resolução de nomes":
• "URN to URL" (N2L): serviço de redirecionamento de DOI como o realizado pelo dx.doi.org (concatenado ao /DOI).
• "URN to URLs" (N2Ls) e "info": serviço de redirecionamento (ou entrega de dados em JSON, etc.) para uma página de metadados, uma "ficha catalográfica" do documento. A API do DOI faz isso. O serviço de resolução do LexML (concatenando a URN LEX ao www.lex.gov.br/urn/) também é desse tipo.
• ... outros: menos comuns.
Dentro desse modelo podemos entender que diversos outros serviços por aí já realizam "resolução de URN" para diversas URNs... Listei algumas nessa proposta embrionária (veja por exemplo que o Worldcat é um resolvedor de fato para os códigos de revista, os ISSNs). Poderiamos incluir aí a resolução de CEP do Correio, a resolução de CPF da Fazenda, e por aí vai... "Tem ID público? precisa ter URN-resolver associado para se dizer aberto ao público".
Essa arquitetura simples de resolvedores permite que sistemas bem diversos se conversem, se tornem interoperáveis, e façam uso de fato dos padrões já bem estabelecidos de identificação pública das coisas.
— Reply to this email directly or view it on GitHub.*
Olá! Por conhecidência acabamos de dar o passo-1: https://github.com/okfn-brasil/getlex agora é repo OKBr, está disponível para todos colaborarmos... ;-)
Passo 2: criar uma SQL VIEW que gere a URN LEX. coisa que posso ajudar... Preciso só estudar aqui o seu modelo de dados...
Alguém tem alguma outra ideia de onde por isso? Talvez na view do sql seja um tanto quanto escondido... Mas tb não sei em q outro lugar ficaria legal... @ppKrauss pode passar, plz, a regra de formação da URN?
A regra está descrita didaticamente aqui na intro do portal LexML (ver "nomes persistentes")
e no projeto getlex posso já deixar os prefixos prontos para facilitar ... Bom, hora de estudar os modelos e adaptar projetos...
MELHOR SOLUCAO: @leonardofl que tal você conseguir algumas amostras de normas da sua base, buscando a correspondência com o link dado pela busca LexML?
Exemplo: select * from modelagem_normalex where id_radar=9 retorna 9;"PLS";"2008";"00104";"Senado";"sen";"FEDERAL";"";"foo" o que corresponde a http://www.lexml.gov.br/urn/urn:lex:br:senado.federal:projeto.lei;pls:2008-03-27;104 e tambem vai funcionar se fizer urn:lex:br:senado.federal:projeto.lei;pls:2008;104.
Quanto os casos da prefeitura eu me preparo aqui para voces, o importante agora é confirmar que as federais estão batendo...
... pelo que percebo vamos precisar de uma tabela auxiliar para mapear por exemplo seu "FEDERAL"+"Senado"+"PLS" em br:senado.federal:projeto.lei;pls.
"br:senado.federal:projeto.lei;pls:2008:00104"
Feito (exemplo): select * from modelagem_proposicao_lex where id=9
CREATE VIEW modelagem_proposicao_lex AS
SELECT
modelagem_radar2lex(c.esfera,c.nome,sigla) || ':' || p.ano || ';'|| p.numero as urnlex,
p.*,
c.nome, c.nome_curto, -- autoridade
c.esfera, c.local -- jurisdição
FROM
modelagem_casalegislativa c INNER JOIN modelagem_proposicao p
ON p.casa_legislativa_id = c.id;
CREATE TABLE modelagem_prefixoLexml (
chave_radar text,
prefixolex text,
UNIQUE (chave_radar),
UNIQUE (prefixolex)
);
INSERT INTO modelagem_prefixoLexml (chave_radar,prefixolex) VALUES
('FEDERAL:Senado:PLS','br:senado.federal:projeto.lei;pls')
('...','...');
CREATE FUNCTION modelagem_radar2lex(text,text,text)
--
-- Converte campos radar em prefixo URN LEX:BR.
-- SELECT modelagem_radar2lex(esfera,nome,sigla)
--
RETURNS text AS
$func$
SELECT prefixolex FROM modelagem_prefixoLexml WHERE chave_radar=$1||':'||$2||':'||$3;
$func$ LANGUAGE sql IMMUTABLE;
@leonardofl , tá resolvido (!)... Você acha que completar artesanalmente a tabela modelagem_prefixoLexml? Só são 25 registros,
SELECT DISTINCT esfera,nome,sigla
FROM
modelagem_casalegislativa c INNER JOIN modelagem_proposicao p
ON p.casa_legislativa_id = c.id
ORDER BY 1,2,3;
A resolução municipal tambem nao tem mistério,
- "MUNICIPAL";"Câmara Municipal de São Paulo";"PDL" = "br;sao.paulo;sao.paulo:camara.municipal:projeto.lei;pl"
- "MUNICIPAL";"Câmara Municipal de São Paulo";"PL" = ...
- "MUNICIPAL";"Câmara Municipal de São Paulo";"PLO" = ...
(esses aí não existem ainda no LexML, precisa deduzir pelo bom senso)
... se preferir usar a abrev. de nome também ok.
Eu pedi para "completar artesanalmente a tabela": joguei de volta para vocês uns 80% do abacaxi... Colaboração é isso, cada um faz um pouco dentro do tempo que tem ;-)
Estou formalizando melhor a minha colaboração lá pela Wiki, assim fica mais didático e menos perdida a explicação.
(ops desculpe apertei botões close/open no celular... )
Eu diria que é o ritmo ou arritmia normal da vida, que funciona a base de pulsos e espasmos esporádicos ;-)
A grande vantagem de se registrar aqui na issues, é que com isso dispensamos a necessidade de sincronia nos nossos "pulsos"... Enquanto estivermos pulsando, não importa se arrítmica e assincronamente, projetos legais como o Radar também manifestarão seus sinais de vida!
PS: o Radar tem planos de captar fundos (e aproveitar as issues discutidas) para um "Radar2"?
Não sei oq vc chama de radar2, mas o radar em si tem infinitas possibilidades de evolução. Mas não temos planos no momento de captar fundos, mas não que não fosse uma possibilidade.
Voltando à issue... o banco é gerado automaticamente pelo Django. E desse banco gerado automaticamente é que fazemos o dump. Então o código SQL é resultado, não insumo. Temos que pensar como esse código SQL q vc tá fazendo aí se encaixaria... daríamos um append no SQL obtido pelo dump? Algum outro caminho menos gambiarra?
O termo "um Radar2" foi para isso mesmo, designar um segundo aporte ao projeto ;-) Talvez o potencial de integração/interoperabilidade seja mais um atrativo para esse "radar2": acho que podemos pensar por hora em "provar o conceito" mais do que implementar uma coisa super-bacana... Daí a ideia de gambiarra que você colocou é bem válida.
"Menos gambiarra"? É meio subjetivo, mas talvez isolando a parte do LexML num SQL schema, seja suficiente:
CREATE SCHEMA lexml;
CREATE TABLE lexml.prefixo (...);
CREATE FUNCTION lexml.radar2lex(text,text,text) ...;
CREATE VIEW modelagem_proposicao_lex AS SELECT
lexml.radar2lex(c.esfera,c.nome,sigla) .... ;
Esse SCHEMA lexml pode ficar a cargo de um projeto paralelo, que se responsabiliza pela atualização: o okfn-brasil/getlex. A única peça nova no sistema (a substituir peças antigas) seria então a VIEW... Que acha, fica mais elegante?
Peter, o que o Léo quis dizer com "Menos gambiarra" é que nós não escrevemos SQL no Radar, nós não escrevemos códigos que acessam o banco de dados diretamente, tudo é feito via Django (pelo ORM) [ http://turing.com.br/material/acpython/mod3/django/orm1.html]
Se for preciso, caso se queira, é possível manter tabelas "não gerenciadas" pelo django no banco de dados, e aí fazer alguma coisa com SQL.
Em 12 de maio de 2015 22:18, Diego Rabatone Oliveira < [email protected]> escreveu:
Peter, o que o Léo quis dizer com "Menos gambiarra" é que nós não escrevemos SQL no Radar, nós não escrevemos códigos que acessam o banco de dados diretamente, tudo é feito via Django (pelo ORM) [ http://turing.com.br/material/acpython/mod3/django/orm1.html]
— Reply to this email directly or view it on GitHub https://github.com/radar-parlamentar/radar/issues/273#issuecomment-101475152 .
ps. não deixa de ser um pouco gambiarra também, na minha opinião, mas só estou dizendo que é mais ou menos previsto pelo django :)
Em 12 de maio de 2015 22:26, Saulo Trento [email protected] escreveu:
Se for preciso, caso se queira, é possível manter tabelas "não gerenciadas" pelo django no banco de dados, e aí fazer alguma coisa com SQL.
Em 12 de maio de 2015 22:18, Diego Rabatone Oliveira < [email protected]> escreveu:
Peter, o que o Léo quis dizer com "Menos gambiarra" é que nós não escrevemos SQL no Radar, nós não escrevemos códigos que acessam o banco de dados diretamente, tudo é feito via Django (pelo ORM) [ http://turing.com.br/material/acpython/mod3/django/orm1.html]
— Reply to this email directly or view it on GitHub https://github.com/radar-parlamentar/radar/issues/273#issuecomment-101475152 .
Hum... puro Django, agora caiu a ficha(!)... ;-)
Já usei CakePHP que é similar (framework MVC com scaffolding, etc.)... Nesses frameworks sempre tem como incluir mais MVC-Models, de modo que a sql-view seria um novo model... Mas, como imagino, se a tabela envolve apenas leitura, sem gravação de dados (só Django get's), podemos "enganar" o framework oferecendo uma sql-view com o nome da sql-table (e mudando o nome da tabela original).
Uma segunda abordagem, daquelas que dão menos trabalho, seria gerar o código básico das interfaces dessa nova sql-view com o tal django-admin... São chutes...
Sem chutar, a sugestão seria compor por exemplo um webservice (sem DJango!), de uma interface AJAX de modal dialog abrindo com a listagem de leis associadas à votação, seria o caso típico: que tal começar por algo assim?
Outra opção, Peter, sendo bem ousado, será desenvolvermos um "app gérico (e independente)" para o django que faça esse serviço e que futuramente possa ser reutilizado em outros projetos desenvolvidos com django.... Ai quem quiser usar é só "adicionar o app" e utilizá-lo.....
Essa é uma solução muito mais "pensando na comunidade" do que "pensando em resolver o nosso problema da forma mais rápida e fácil possível"....
ok, parece otimo (!)... manda um post aqui depois, a título didático, do que vier a implementar de app.
(reabrindo só para divulgar novidade na imprensa e nas discussões OKBr)
Oi gente, reparei que a iniciativa privada está fazendo uso de nossas iniciativas... Em parte por nossa falta de alinhamento em torno de uma infra-estrutura comum dos projetos (grupos do terceiro setor poderiam cooperar e dividir custos), e nossa falta de alinhamento com padrões interoperabilidade...
O Votenaweb, http://www.votenaweb.com.br/ em parte (a outra parte é expressa pelos jornais) se aproveitou disso e já usou a sugestão de fazer um EuVoto Federal... Enquanto entre nós fechamos portas.
Existe alguém aqui interessado em levar mais adiante essa ideia de interoperabilidade de projetos e integração entre as ONGs?
Peter,
algumas considerações:
-
O pessoal do VoteNaWeb, que eu saiba, não utiliza nossas tecnologias ou qualquer outro Software Livre.
-
Se existe algum grupo e/ou empresa utilizando um Software LIVRE para o desenvolvimento de algum projeto e/ou para oferecer a prestação de serviços a entidades públicas e/ou privadas, eu não vejo o menor problema nisso, desde que as licenças sejam devidamente respeitadas e o código fonte do projeto continue disponível e livre.
-
Infelizmente temos diversos órgãos e instâncias públicas que não conseguem compreender a importância do uso de Softwares Livres no Poder Público, tanto quanto existem diversos movimentos sociais (ONGs ou não) que dizem militar por uma sociedade mais democrática, participativa, livre, colaborativa, não capitalista e etc, mas que em seu dia a dia não praticam isso, utilizando diversos softwares proprietários (sistemas operacionais, softwares de edição de imagem e vídeo, suítes de escritório, etc). Então o buraco é bem mais embaixo.
-
Eu acho ótima a ideia de interoperabilidade de projetos e "integração entre ONGs". Entretanto, não acho que as "ONGs" vão "salvar o mundo". Além disso, nós (PoliGNU/Radar Parlamentar) não somos sequer uma ONG. Nosso projeto é completamente voluntário e tem um caráter educativo na área de Ciência/Engenharia de Computação também, servindo também como "laboratório didático". Gostaria de reforçar que EU não acho que "ganhar dinheiro" seja algo ruim. Gostaria de ver muito mais iniciativas de prestação de serviços (seja a instituições públicas ou não) que se utilizam se Tecnologias Livres e que se apresentam como negócios sustentáveis, que permitem aos envolvidos ganhar dinheiro suficiente para manter a qualidade de vida que desejam. Eu realmente quero que minha carreira profissional se dê ao redor de tecnologias livres e que isso consiga bancar a minha vida.
Por fim, apenas retomo que o grande problema não é uma ONG utilizar SL para vender serviço, mas sim algum órgão público fechar um acordo/parceria/contrato para utilização de software proprietário... isso sim é péssimo, não-produtivo e deveria ser evitado e combatido.
Abs
@diraol Bom dia!
Não sei se houve confusão, não existe atualmente uma ONG ou empresa de software aberto ganhando dinheiro com o VoteNaWeb... O que lembrei é que poderíamos prestar o mesmo serviço (como brasileiros de ONGs e/ou de empresas honestas)... E teríamos pleno potencial de fazer algo superior, dignamente e honestamente, se nos entrosarmos melhor (!)... Meu parecer é de que ao não desenvolvermos projetos integrados (que seriam mais uteis e difíceis de serem ignorados), nos contentando em "ficar na praia", estamos estimulando o oportunismo de espertalhões. É estratégico: ou nos profissionalizamos e nos integramos um pouquinho mais, ou criaremos lacunas perfeitas para oportunismos de sempre.
Pensando mais pragmaticamente, a essa altura, uma resposta simples a esse caso da VoteNaWeb seria oferecer um demonstrativo de horas-desenvolvimento que consumiríamos para fazer desenvolver algo e chegar no mesmo resultado: tenho certeza que não seria de graça, mas que seria 10 ou 100 vezes mais barato... Mesmo para fazer uma estimativa simples dessas, precisaríamos de um pouco mais de integração entre as ONGs e os projetos... Fica por hora a sugestão de um mutirão para estimar horas.
Respondendo por item,
- O pessoal do VoteNaWeb, que eu saiba, não utiliza nossas tecnologias (...)
Sim, sendo um software fechado não tem como saber se usou ou não, portanto há que se supor que usou (ate que se prove o contrário abrindo o software), a existência de um software publico e um projeto pronto como o EuVoto barateou o processo (dos requisitos ao layout!).... O VoteNaWeb usou também da nossa iniciativa foi a proposta como um todo, a mobilização da demanda, etc. Criamos um mercado que não existia, deveríamos ser os primeiros a serem consultados... a CAPES já vez coisa semelhante ao excluir as editoras nacionais, que criaram o mercado e possuem plena capacidade de atendimento à demanda.
A CAPES poderia estimular a formação de um consórcio, assim como a Câmara poderia estimular empresas e ONGs cooperarem na produção de um software publico melhor.
- Se existe algum grupo e/ou empresa utilizando um Software LIVRE para o desenvolvimento de algum projeto (...)
sim, concordo, mas não é esse o ponto.
- Infelizmente temos diversos órgãos e instâncias públicas que não conseguem compreender a importância do uso de Softwares Livres no Poder Público, (...)
Sim, concordo, mas vejo que o contexto era bem legitimo, não precisamos ficar apenas chorando "a posição do buraco"... ;-)
- Eu acho ótima a ideia de interoperabilidade de projetos e "integração entre ONGs". Entretanto, não acho que as "ONGs" vão "salvar o mundo". (...)
Sem duvida, mas as ONGs podem e devem dar exemplo... Cabe a quem levantou a bandeira dar exemplo e estimular a "nova cultura", que inclui a cultura da interoperabilidade, e de não amarrar as nossas ações ao lobby interno das proprias ONGs... estamos discutindo aqui em público justamente por acreditarmos na transparência, no trabalho das ONGs, nas pessoas que colaboram, etc.
Ganhar dinheiro com software livre é algo que muita gente vem fazendo, a décadas, mesmo não sendo tão evidente no Brasil... Nesse contexto sistemas online (e integração do processo legislativo), tem um exemplo interessante de empresa que usa software aberto, a OpenLegis, fork do SAPL, aparentemente adotado em diversas Câmaras municipais... Modelos de negócio honestos existem vários, assim como modelos saudáveis e produtivos de parcerias das empresas com ONGs e/ou governo.
O problema em questão é a ausência de uma licitação governamental (VoteNaWeb sob grave suspeita) e a ausência de consultas públicas para legitimar requisitos, protocolos de interoperabilidade, etc. ...
Integração entre projetos: eu já fui pessoalmente no Vote na Web conversar com eles sobre isso. A proposta era simples pra ambos os lados: utilizar as preferências de voto do internauta no Vote na Web para que ele visse seu posicionamento no Radar. Da parte deles seria só montar um request com os votos do cidadão. Mas na prática eles não demonstraram tanto interesse, ou no mínimo não priorizaram isso.
Durante o mestrado eu já trabalhei num grande projeto envolvendo quase 20 instituições. O espírito é sempre procurar unir esforços para tentar evitar trabalho replicado a toa. Mas na prática o custo de coordenação entre as partes é muito grande. Só com o tempo que é preciso gastar para se coordenar com outros parceiros, daria pra implementar bastante coisa no Radar. Por isso, cada eventual parceria deve ser pensada com calma e estrategicamente, e não meramente por um abstrato "unir esforços".
@leo, sobre seu comentário de "grande projeto envolvendo quase 20 instituições", existem de fato muitos exemplos de insucesso, mas não devemos esquecer exemplos com algum sucesso, como o Interlegis, que cresceu no sentido de integrar poder Judiciário e Executivo junto com o Legislativo... E até pariu, mais tarde, em ~2008 o LexML... O próprio LexML ganho autonomia em 2009 e é hoje bom exemplo de interinstitucional.
Também existe o ePING, outro grande sucesso (dadas as proporções de fracassos no Brasil).
O que estou sugerindo é gastarmos alguns minutos ou horas de colaboradores Radar para plugar nessa grande iniciativa, endossada pelo EPING, que é o LexML! Em paralelo, agora em 2016, estamos retomando o lado da própria produção e gestão dos documentos nos Diários Oficiais, como Diário Livre, LexML na CGM e iniciativas menores.
Reparei que existe um modelo de dados do Radar... Temos talvez uma alternativa simples para registrar as URNs LEX na base SQL do Radar,
- tabela Radar
CasaLegislatuiva: prefixo URN LEX de "autoridade" das normas. - tabela Radar
Proposição: restante da URN, podendo usar apenas ano no lugar de data ISO completa.
Enfim, se alguém se interessar, podemos conversar sobre implantação das URNs LEX no Radar, e sobre as portas que se abrem com a interoperabilidade criada — tanto para plugar com sistemas e iniciativas nacionais, como para plugar com internacionais (ver demandas #333 e #334).
Yep, colocar a URN LEX na entidade Proposicao seria o primeiro grande (e simples) passo. Peter, acho q vc seria o cara para isso :) Se vc quiser contribuir c o Radar nesse sentido, terei prazer em ajudar te indicando os pontos a serem alterados e revisando seus pull requests.
Oi @leonardofl , como sugere fazer isso? O ideal para mim seria ter um dump enxuto (apenas amostras relevantes de dados não precisamos da base inteira) da base de dados e fazer as modificações nesse dump, para poder testar e mostrar exemplos. Tem como criar esse dump e disponibilizar num zip?
Aí também precisaríamos decidir se crio um git a parte ou se criamos uma pasta aqui mesmo (algo como /experimentos) onde eu iria postando o que der certo. Talvez precisemos de um CSV próprio ou externo (ex. okfn-brasil/getlex/data) que garantiria a expressão de prefixos sem maior trabalho.
Em seguida plugar no Radar como SQL-View ou SQL-Function seria talvez o mais simples e suficiente.