a4a:Convenções/GeoTerm

O Projeto Geoterm lida com termos, principalmente nomes próprios de entidades geográficas (termos designadores de objetos geográficos). Também efetua o registro de nomes e abreviações oficiais de vias, cidades, estados, etc. Garante que o nome seja associado a um ID e sua expressão canônica.

Além dos "nomes por extenso" canônicos são registrados os sinônimos válidos, as abreviações canônicas e abreviações válidas.

Ver https://git.AddressForAll.org/geoterm

Os termos dependem apenas da língua, o GeoTerm é um dicionário de termos, o que determina a semântica é o uso do termo no seu contexto geográfico. Quanto a "nomes oficiais", cada jurisdição é soberana sobre as regras de abreviação e escolha dos nomes canônicos. A jurisdição controla a unicidade e as regras de validade dos termos locais.

Objetivo

Proporcionar registro eficiente e recuperação eficiente de termos canônicos. Termos válidos (alternativos aos canônicos) e seus sinônimos (não-válidos ou com falhas de grafia) também são controlados e recuperados com eficiência.

Implementa uma “terminologia por demanda”, com busca e resolução de terminologias controladas.

Modelo de dados

Diagrama de classes UML do SQL-schema TermStore, implementado como tabelas e visualizações, na estrutura Mode1:

A tabela Term é muito simples: cada termo, canônico ou não, é uma linha da tabela principal. Uma tabela secundária para namespaces, ns, divide os termos em grupos "base" (tema, corpus ou projeto) e seus grupos "auxiliares", para traduções (um namespace para cada idioma) e outros namespaces dependentes.

Conceitos básicos

Para detalhes específicos de cada idioma ou jurisdição, ver por exemplo a4a:Convenções/GeoTerm/pt-BR para a jurisdição Brasil e a4a:Convenções/GeoTerm/pt para o idioma Português geral.

Termo canônico

Em Linguística (morfologia canônica) e Computação (forma canônica) o elemento canônico de um conjunto de variantes é uma amostra utilizada como representante ou como "forma preferida".

No Projeto Geoterm, que lida com termos, principalmente nomes próprios de entidades geográficas, o elemento canônico requer a definição prévia ou contextualização de "termos variantes".

Processo de canonização ortográfica

Infelizmente a determinação do termo canônico não é simples e nem sempre estará pronto quando os dados são inseridos na base de dados. É um processo que, em geral, requer confirmação estatística (portanto tempo para a acumulação de dados) ou avaliação humana (tempo na fila de espera para alguém avaliar).

Alguns processos, como o uso de acento, podem ser automatizados. Por exemplo os nomes de rua oficiais, fornecidos pela prefeitura de Pato Branco, não apresentavam acento, mas puderam ser "corrigidos" pelos dados do OpenStreetMap (planilha). Ainda assim algumas falhas da comunidade OSM podem passar desapercebidas, sendo que a revisão humana é que determina a finalização do processo... Até que, por exemplo, a Câmara Municipal de Pato Branco forneça as leis e os nomes oficiais conforme grafados nas leis, e uma correção final possa ser realizada.

Outros processos, como a revisão de nomes "quase iguais", mesmo podendo ser automatizados, requerem a decisão humano de "tratar como erro ortográfico" ou "tratar como variante local". Ainda tomando Pato Branco como exemplo, as variantes por Metaphone-ptBR, é difícil decidir o que seria ou não erro ortográfico. Tupi e Tupy são certamente variantes sonoras, e Tupi o nome oficial, portanto canônico. Já "Pedro Vieira" e "Padre Vieira" poderiam até ser nomes de rua distintos, não podendo constar como variantes ortigráficas do mesmo nome: apenas localmente, no município, pode-se eventualmente considerar variantes.

Uma vez decidido que um termo tem variante ortográfica, a distinção entre termo canônico e seus variantes (sinônimos) fica registrada na tabela tstore.term e a eleição do canônico precisa ser "propagada" para a tabela de optim.vianame, o que é um processo crítico, precisa ser sempre monitorado e homologado.

Processo de canonização entre variantes locais

Sempre que um nome de rua for aceitável como entrada, a sua conversão para canônico, caso cabível, precisa ser realizada. Essa regra vale para nomes de rios, de bairros, etc. E se a conversão não for tratada como ortográfica, ela necessaiamente será tratada como variação local.

Um dos problemas da canonização das variantes locais é o contexto de uso:

termo praticado. Por exemplo para um taxista, um carteiro, e aplicações logísticas em geral, o que tem "valor de oficial" é a placa de rua. Se uma placa é grafada com nome "errado", não importa, é o nome que será adotado por todos. Hoje há ainda o problem do "nome praticado pelo Google", que cria um problema adicional até para as placas. Na comunidade OpenStreetMap de qualquer forma o que vale é a evidência empírica, que é a placa.
termo oficial. É o nome de rua que consta nos dados fornecidos oficialmente, que podem ser uma simples planilha fornecida pela prefeitura, ou uma compilação de "leis de batismo" fornecida pela Câmara Municipal. Infelizmente a propagação do nome oficial para placas e outros meios, que servirão de evidência empírica para o cidadão, pode demorar bastante.

Esse tipo de decisão requer configuração do muncípio: por default podemos adotar o nome oficial, que é a longo prazo o mais adequado, mas em municípios problemáticos pode ser mais adequado ficar com os critérios do OpenStreetMap de opção pelo termo praticado. Em Pato Branco, por exemplo, configuramos o OSM com "acento do oficial", e o restante conforme planilha fornecida pela prefeitura.

Buscas e indexação

Além do metaphone_ptbr sugere-se testar o uso da extensão pg_trgm, "trigrama". Ao invés da busca "like" pode-se garantir maior chance de listar semelhantes através dos operadores de comparação por trigrama, com indexação prévia. A comparação entre termos, apesar de ser CPU intensiva, pode ser feita de tempos em tempos para conferir demanda por canonização.

Ver artigos em

Ver também

osmc:Convenções/Abreviações e sinônimos de município