1. Uniqueness -- Each address should be globally unique and identifiable.
2. Readability -- The addresses should be simple and easy for humans to read
3. Infinitely scalable -- Because geo-addresseses represent a GPS point on Earth, then the domain of possible available points is (almost)infinite. Hence, the design of the scheme should reflect this eventuality while still maintaining global uniqueness.
Naming and addressing convention usually feature multi-part variables e.g Personal Names(2-3 names), Vehicle Registration numbers(2+ parts) and IP addresses(4 parts). This methodology works well because it enables one to form a 'union' of two or more parts to get a unique identifier without using sequential numbering that would eventually out-grow the original targets.
In the case of geo-addresses, it's important that the addressing scheme inherits a high level of scalability for the future as well as the ability to add new variables to form the eventual *intersection. Therefore, I propose a scheme that would be constructed in the following notation:
A-B-C..-N where
A is the base variable which should be as wide as possible so as to minimize the need for other sub-set variables.
B is a subset variable that should ideally be able to map to a general localized area e.g(Chiromo)
C is the most precise point within the locale(i.e B)
N is other variables that would ideally hold metadata about the location(e.g routes, etc)
'-' is the separator between the different variables.
The aim is that An ∩ Bn ∩ Cn..∩..Nn generates an almost infinite set.
where *∩ is the Intersection and
Xn is the entirety of that domain sub-set.
A point to note is that A or B or C etc need NOT all be in the same format. One can me Numeric, another alphabetical, and another alphanumeric. Also, the wide ASCII set of characters can let us use different characters as prefixes and postfixes to further define the address e.g
@A -- Can represent that A in this instance is a named town/city
#A -- Can represent that A is geographical location based on co-ordinates
etc..
*Intersections enlarge the domain more than Unions.
References:
http://rina.tssg.org/docs/FutureNetTutorialPart2-100415.pdf
As always, comments and suggestions are welcome below :)
As always, comments and suggestions are welcome below :)
For part B, how do you propose identifying the local area? An easier alternative would be to go to a national level; country domain names would suffice
ReplyDeleteAm looking forward to input on the precise method on how to achieve that. This article presents (hopefully) and good and sound theoretical platform of what's needed and how to go about it. Once read through, it's my hope that each one of us will have suggestions on how to come up with the water-tight addressing system.
ReplyDeleteForgive my stickling on this point, but in my opinion, the address defines the product and therefore I think it worthwhile to crack our heads on it to get it right.
Thinking on a global implementation scale, how would we identify the specific locales for B and C?
ReplyDeleteThanks for the well thought out article and you're right, we must get the addressing scheme right.
ReplyDeleteDividing the addressing in terms of locale is not the only way. In our earlier design sessions, we had discussed the idea of including domains for individuals, organizations and government institutions i.e GEO, ORG and GOV. Its worth exploring.
Yes, that's a great way to look at it. Instead of approaching it from a locational point-of-view, we could think of it from a people aspect. Their identities both in life and a particular area.
ReplyDelete