2 402
edições
(→Potenciais soluções: adaptando do Fredy para Potenciais soluções) |
|||
(8 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
''' | '''Geo-tokens''' são [[osmc:Convenções/Identificadores inteligentes|identificadores inteligentes]] de escopo geográfico (identificam localizações ou seus metadados), com capacidade de registro cartorial e a capacidade de se manterem atualizados (com rastreabilidade das versões precedentes). Essas duas capacidades requerem que o ID seja também um [[wikipedia:Non-fungible token|token não-fungível]] (em inglês: non-fungible token, '''NFT'''). Daí o nome "NFT geográfico", reduzido para "token geo" ou geo-token. | ||
== Escopo == | |||
[[wikipedia:Geographical feature|Objetos geográficos]] de [[Interesse público e curadoria|interesse público]], tais como ruas, pontos de endereço e polígonos de lote, reconhecidos pelas [[Jurisdição|jurisdições]] que reforçam sua definição. | |||
A relação esperada entre ID (ou nome) e sua resolução, é que o resolvedor retorne uma ''feature'' GeoJSON distinta para cada geo-token. Ou seja, há garantia de unicidade também seria bijetora. | |||
=== Tokens sem georeferência única === | |||
Objetos não-georeferenciados (ex. topônimos ou nomes de rua sem georeferenciação), podem ser grosseiramente georeferenciados pelo contexto, adotando um esquema de [[wikipedia:Toponym resolution|resolução de topônimos]], tipicamente municípios e seus quadrantes de cobertura. Nesse caso o comportamento será diferente: muitos IDs retornaram a mesma feature de GeoJSON. O status do geo-token fica como "pendente georeferenciação", devido à pendência de unicidade geográfica. | |||
== Problema principal == | == Problema principal == | ||
Para o governo municipal, '''garantir o "endereço oficial"''' dos imóveis do município. A garantia só é possível quando todas essas condições são satisfeitas ao fornecermos um identificador único do endereço: | Para o governo municipal, '''garantir o "endereço oficial"''' dos imóveis do município. Para o cidadão, que necessita demonstrar certificado de endereço ou localizar com confiabilidade endereços vizinhos, ele também requer um "endereço oficial garantido". | ||
# Integridade cartorial e jurídica: uma vez registrado o ID e seus metadados, não podem mais ser adulterados, e ficam "gravados na pedra", não se perdem. Por ter valor de cartório, a data, licença, etc. são juridicamente válidas. | |||
# Auto-suficiência mínima: com apenas o ID é possível localizar razoavelmente o ponto, sem demandar consulta a uma base de dados central. | A garantia só é possível quando todas essas condições são satisfeitas ao fornecermos um identificador único do endereço: | ||
# Versionamento: o ID não precisa ser imutável, podem ser atribuídos novos IDs e os velhos apontarão para os novo. | # '''Integridade''' cartorial e jurídica: uma vez registrado o ID e seus metadados, não podem mais ser adulterados, e ficam "gravados na pedra", não se perdem. Por ter valor de cartório, a data, licença, etc. são juridicamente válidas. | ||
# '''Perenidade''': o endereço e seu identificador único precisam ser "eternos enquanto durem". | |||
# '''Auto-suficiência''' mínima: com apenas o ID é possível localizar razoavelmente o ponto, sem demandar consulta a uma base de dados central. | |||
# '''Versionamento''': o ID não precisa ser imutável, podem ser atribuídos novos IDs e os velhos apontarão para os novo. | |||
# Situação corrente: qualquer que seja a versão, por mais antigo que seja o ID, o sistema resgata a sua situação corrente. | # Situação corrente: qualquer que seja a versão, por mais antigo que seja o ID, o sistema resgata a sua situação corrente. | ||
# Rastreabilidade completa: | # '''Rastreabilidade''' completa: | ||
#* dos dados originais: permite resgatar a [[wikipedia:Data_lineage#Data_provenance|proveniência dos dados]] de endereço, saber qual foi a origem e confirmar sua integridade, data, licença, etc. | #* dos dados originais: permite resgatar a [[wikipedia:Data_lineage#Data_provenance|proveniência dos dados]] de endereço, saber qual foi a origem e confirmar sua integridade, data, licença, etc. | ||
#* dos dados correntes: metadados mais atuais (cadastro atualizado). | #* dos dados correntes: metadados mais atuais (cadastro atualizado). | ||
Linha 14: | Linha 25: | ||
=== Problema do cartório oficial === | === Problema do cartório oficial === | ||
... | |||
=== Problema da atualização e rastreabilidade === | === Problema da atualização e rastreabilidade === | ||
... | |||
=== Problema do cadastro oficial === | === Problema do cadastro oficial === | ||
Endereços (ex. de correspondência) são caracterizados por um ponto geográfico, mas esse ponto não é eterno nem preciso, e, principalmente, é '''difícil fixar uma "definição oficial" do endereço'''. | Endereços (ex. de correspondência) são caracterizados por um ponto geográfico, mas esse ponto não é eterno nem preciso, e, principalmente, é '''difícil fixar uma "definição oficial" do endereço'''. | ||
Linha 47: | Linha 58: | ||
== Potenciais soluções == | == Potenciais soluções == | ||
Alternativas para a implementação da Geo-Token: | |||
# '''[[wikipedia:Blockchain|Blockchain]]''': aproveita a natureza descentralizada e a integridade inalterável dos blockchains para registrar e rastrear cada endereço e suas alterações subsequentes. Como as geo-tokens não são criptográficas, elas seriam consideradas dados, que por sua vez podem ser registrados na forma de dataset ao invés de um dado por token do blockchain. Conforme a natureza mais lenta (dados frios) ou mais rápida (dados quentes), existem diversas soluções: | |||
#* [[wikipedia:Blockchain#Sidechains|Sidechain]]: para realizar operações com dados quentes, por sua rapidez e barateamento, é a mais indicada. | |||
#* Side-git: numa arquitetura sidechain, mantemos o blockchain principal e substituimos a sidechain por um git. Isso barateia e simplifica ainda mais o processo. | |||
# '''Sistema Centralizado''': Sistema mais tradicional que depende de um banco de dados centralizado para armazenar e gerenciar endereços, complementado pelo Token AFA como identificador único. Ainda assim pode-se usar controle de versões como faz a Mediawiki, ou com tecnologias mais sofisticadas, como [arquitetrua kappa](https://milinda.pathirage.org/kappa-architecture.com/). | |||
# '''[[wikipedia:git|''Git'']]''' (Sistema de Controle de Versão): Utiliza a arquitetura e os princípios de controle de versão do Git, permitindo um registro detalhado de cada mudança de endereço e associando-as a um identificador baseado no hash do comprometer-se. | |||
# Ouras: identificadores hibridos, por exemplo geo-token de lote e contador sequencial, para designar o geo-token de um endereço... Existem dezenas de outras alternativas. | |||
Cada uma destas alternativas apresenta vantagens e desafios únicos, e a escolha ideal dependerá do equilíbrio desejado entre segurança, praticidade, escalabilidade e custo. | |||
=== Estado de arte === | === Estado de arte === | ||
Soluções completas similares: | |||
* ... | |||
* https://www.placekey.io/ | |||
* ... | |||
Recursos para a implementação: | |||
* lotes de tokens em baixa maturidade: git | |||
* "gestão a quente" de tokens maduras: arquitetura Kappa suficiente, https://pt.slideshare.net/juantomas/aspgems-kappa-architecture | |||
=== Maturidade da token === | |||
Do ponto de vista econômico e tecnológico, a criação de uma nova ''token'' tem custo, e em geral risco e custo altos enquanto não se torna um padrão com quantidade mínima de jurisdições aderindo. No processo inicial de "maturação da token" tecnologias mais simples que blockchain podem ser adotadas. | |||
Para reduzir o custo de teste e desenvolvimento da ''token'' e suas aplicações, recomenda-se iniciar com a tecnologia [[git]]. Ela também pode ser útil para o processo de legitimação dos blocos: enquanto os dados não forem homologados e legitimados como oficiais, podem permanecer em ''git''. |
edições