Geo-token: mudanças entre as edições

4 285 bytes adicionados ,  6 de novembro de 2023
→‎Potenciais soluções: adaptando do Fredy para Potenciais soluções
Sem resumo de edição
(→‎Potenciais soluções: adaptando do Fredy para Potenciais soluções)
 
(9 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 1: Linha 1:
'''AFA-tokens''' são [[osmc:Convenções/Identificadores inteligentes|identificadores inteligentes]] (de ''datasets'' ou de localizações) com capacidade de registro cartorial e a capacidade de se manter atualizado, com rastreabilidade das versões precedentes.
'''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 41: Linha 52:
== Problemas periféricos==
== Problemas periféricos==


* [[wikipedia:Data_lineage#Data_provenance|proveniência dos dados]]
...


=== Exemplos concretos===
=== Exemplos concretos===
...


== 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''.
2 391

edições