|
||
The concept of a universal directory does not exist on the Internet. There are thousands of directories of all kinds and online Yellow Pages in many countries. All of these websites are different, accessed differently and operated differently: for example, Yellow Pages in France are different from their equivalent in Spain and Italy. There is no standard directory operated behind the same name worldwide.
The Universal Directory
The Yellow Pages can be trademarked, but they remain a directory of data which require being maintained. Sometimes, such directories are difficult to access involving too many clicks to find information, they can be full of ads or slow to load. Also, shops and other businesses can be required to pay to be listed.
A universal directory operated using a new domain name extension, and a different business model can change this.
Cities are the entry point
There are a lot of cities worldwide, and when searching for a hotel or a dentist, a search engine won’t necessarily show all available options: it will show some of them but not the complete list of them. Also, it will show different information than the one requested: articles about the subject and… other things. When searching for a dentist in my neighborhood, a search engine will bring results, but I want more than this: I want all results and results only, I don’t need articles about dentists. Using a dedicated directory for each city name worldwide using a https://cityname.TLD is something that has never been done in the history of the Internet: a game changer for digital cities.
The .TEL legacy TLD and Dmoz
The .TEL domain name extension was a serious innovation in the world of domain names: the only one actually. It didn’t just offer a domain name but access to a platform where one could fill-in empty fields with information. It required no coding but a login and a password: no website to develop. The .TEL cost a lot to create and lost traction. The new gTLD flood did not help. With an agreement signed in 2006, its domain name registration numbers approached the 350,000 registrations. They’re close to 100,000 today and the registry agreement was recently changed to allow users to do what they want with their “.tel” domain name: the exact same as what all other domain name extensions offer. The .TEL initial model was abandoned (note that it is still possible to use its platform).
Dmoz has nothing to do with domain names but was a massive directory maintained by volunteers and operated using one single domain name (dmoz.org). This huge directory lost traction: data became inaccurate, volunteers just dropped the job and actually… the only way to generate cash was based on donations. Good luck with that. Dmoz closed in 2017.
The universal directory is a combination of these two models, but using a new gTLD and with a completely different business model.
An alternative to Google?
There is no alternative to Google. Google is a search engine which does its job well. The universal directory is a platform focusing on cities, offering advantages to its residents and the people operating each directory. Google does not do that: welcome to digital cities.
The universal directory also allows giving a role to cities interested in operating their directory platform. A city wants to offer its residents and businesses free services: it is what the universal directory does. For cities not interested in participating, external moderators, media agencies, and SEO experts are granted that role and will generate an extra income from managing a city: each city domain name… is unique and belongs to the network of directories operated behind a single domain name extension. No farm linking here, it is precisely what the project wants to avoid.
The .YELLOWPAGES new gTLD
You might have noticed the .YELLOWPAGES new gTLD application from the first round of the ICANN new gTLD program. It was withdrawn, and I asked about the reason for this. I received an answer to talk to someone else, but I was also informed that the company behind the application had been acquired by another one. I took this as an answer, but I would be interested in learning if this application was submitted for a defensive reason or if there was a real project behind it. For me, this is where the concept of a universal directory starts: Yellow Pages standardized for each country.
Found out more about our innovative business model behind “Project John Wolley”.
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byCSC
A World-Renowned Source for Internet Developments. Serving Since 2002.
History repeats itself as new generations come on the scene.
This capability has been attempted many times before. Even with the backing of national Administrations worldwide in simple times, the pursuits were a failure.
The first instantiation was in the OSI internet domain name system for OIDs introduced by the world’s telecom Administrations back in the 1980s. You can still resolve those on the Orange Labs OID repository site. The CCITT rolled out the X.500 standard to attempt the original trusted implementations with X.400 as the value proposition for email. Later, the Administrations and telecom operators rolled out the E.115 directory standard to implement the capabilities after X.500 failed in the marketplace. That also largely failed to take hold.
When the DARPA DNS for its tcp/ip internet was rolled out in 1986, the ISO country domains of the world were supposed to have locality subdomains that would further resolve to more granular levels. It was implemented for the .US domain, but never really took off anywhere. Ironically, Bob Kahn has used CNRI.RESTON.VA.US as his organization’s domain for decades.
Probably the most significant effort that has some possibilities was the .post domain that the postal administrations worldwide would operate and maintain - and be coordinated via the Universal Postal Union. When I was at VeriSign at decade ago, I was a champion of that system as a potential business opportunity. It seems, however, that it is still a great idea on the UPU website that hasn’t gone anywhere.
There are several reasons for the lack of success. One is the enormous complexities and burdens of maintaining an accurate tree and the associated resolvers. Another is that end users plainly do not care. Lastly, there are so many other ways of accomplishing this today that are more effective and less costly, that the idea remains a non-starter.
History just repeats itself.
Thanks.
You’d need more levels than just city, there’s too much duplication of city names and a lot of locations that aren’t inside cities. And how would such a directory be searched? It’s not just “How do we categorize listing so I can identify all entries that are dentists as opposed to dental schools or machine shops?”, but “How do I search for entries in a given city vs. entries in a given county vs. entries in a given postal code?”. BTW, if your answer to that is that each “hostname” in the directory is a search engine for that locality, I’d simply discard your directory in favor of going to Google Maps and typing in my query (which’ll automatically limit the results to addresses and within the displayed region). In fact, even if all the issues of representing such a directory in DNS are solved, why not simply take advantage of Google Maps or a similar interface to standard directory data? The headache, after all, is in maintaining and updating the actual data and it’s exact representation in the directory doesn’t really affect that headache much one way or the other.
All of these points are very interesting ones but the two comments received above are based on things that have been done in the past. It is obvious that these questions are raised and answered. Of course Google can be seen as a competitor, unless it is part of the project: Google Maps is part of the project for example. How to maintain and update datas is also a question that we have solved in a very different way Dmoz tried to.
Thank you.
.Name tries to do this for people even reserving domains at the third level but not at the second, resulting in very unusual reserve hierarchy. Of course ambiguity remains, but if its your domain then people just type your name in with a dot separator and .name suffix. .museum also tries to do this. Some of the resulting domains are so long I can't imagine typing them in correctly. A number of CCTlds do as well, such as Italy and US. Does this make things any more simple? It does not seem so. With a decent search engine the exact domain does not even matter as many difference "descriptions" (as people think differently) get resolved to a short list of "addresses" that typically include the one desired. There is no need to remember an address or hierarchy structure, just a need to be able to reasonably describe what is desired. And then there is language. Do we read left to right or right to left? Do we "trigger" someone is we use the "wrong" direction? Yes its a hierarchy, so there is an implied direction, but not everyone thinks like us geeks.
The direction shouldn't matter, that's what we have user interfaces for. You enter information in the proper order for your locale/language, it gets shuffled into the correct order for the API before the call's made, the results are shuffled back into the proper order before display.
If the direction does not matter, then the user is not interacting with the directory directly, in which case the exercise seems academic. As for API, mine is Google Search, it even works across hierarchy directory transitions such as between domain names and web pages. Point being do what you will, and search engines will sort it out for me. In the end I care not how the data is structured, I only care that I can find what I am looking for and so is the case for most content providers. I am also a horrible speller as my posts on CircleId demonstrate. Sadly Google is very supportive of my incompetence, virtually always giving me what I am looking for no matter how badly I type it. In fact long ago I stopped bothering fixing typos on my search terms as its just a waste of my time.
I agree Google is very efficient, that is why its "technology" is part of the project. In fact, we think that the Google Cloud Platform should be the place to develop it.
Irrespective of the benefits of the proposal, you also need to look its cost to searchers. Typically, switching costs are high.
I am not sure if you are referring to the cost of the project/platform (and I am familiar with what it cost Telnic to launch .TEL) or something else. Are you referring to what it cost in time for a searcher to use such new tool?
Yes, cost to switch to a new mind set.
Nailed it.
The project not only offers to searchers: subscribers register for free and moderators are compensated for their job (based on our business model). In fact, it becomes the role of moderators to attract users to come and maintain the quality of the content for the city they manage. Let's say that it is a new offer so the time it takes for a searcher to use such tool is not considered here. But I see your point.
It is mystifying why this would even be attempted when 1) it has nothing to do with "TEL" (assuming it is short for E.164 based international public telephony); and 2) there is a functioning .post domain that was created for that purpose with the additional value proposition of being managed globally together with the postal administrations that are responsible for street addresses. In addition, the diverse and varied schemes worldwide for designating geographical areas, really makes geospatial identifiers with a map interface the only viable approach.
I was referring to the .TEL registry which is the only one that offered a dedicated platform for its domain names. I am not sure that you are writing about the same thing. In regard to .POST, I see two things:
1) It is an English word and project John Wolley is a universal directory (worldwide at least :-) so the TLD (the domain name extension) has to be understood by all, not only by users who read and understand English.
2) .POST is already in use and our project requires a Top-Level Domain dedicated to it.