Does anyone have the contact of people in "Data harmonization" team of Google, Facebook, Foursquare, Yelp, etc? Could you share this idea with them to see if we can discuss it further? my email is javier at touristeye.com
1. I wrote in another comment here (ctrl+f) but there's overlap with other standards. One of our main multi-million EU projects was about seamless integration of different standards for representing information about resources (i.e. details of a factory) when integrating between very large entities (i.e. BMW and Honda). It was more on the mathematical/computer-science side than technical (i.e. not "Is some path for business.txt better than others"). When two IT departments/armies of consultants use different standards for everything from Address to TaxReceiptCode and you try to integrate it's ugly. When it's a large N of such, you need multi-million EU-sanctioned research projects. Moral of the story: please use standards. That said:
2. There's definitely a turing tarpit[1] situation with RDFs and RDF Schema(s). As you said on github, "Other local businesses may think on adding to their website some metadata (using http://schema.org/). The problem is that it's too complicated for a non-developer". The best standard is the one being used instead of being forgotten in an hundred pages design document. If you find yourself thinking about the problems RDF (and schemas) tries to solve, please take into consideration a clear and standard one-to-one conversion between the specification and some other more established and expressive specification. For example, define an RDF Schema and a clear conversion between RDF using that schema to and from business.txt. The main benefit for the project if you take such a conversion into consideration while designing the document is that it promises a clear way for future spiders to interpret the data regardless of expressiveness and may give the more knowledgeable authors of such document that more expressiveness, where needed. The default should be clear and easy. Case in point:
3. People here commented how the address format is very American. They are right. But for ease of use, maybe the default should be American and add an option to explicitly express the address differently (i.e. different administrative entity than states) and let there be a canonical conversion to something like this, including a way to explicitly express the address using something like the Freebase schema for addresses[2]. Notice how complex are the types for the different fields, like State/Province. This is because encompassing an Address entity globally is a complex problem. Heck, in some countries usage of place descriptors ("fourth junction after the main entrance to town") is still common. I once read some research paper on it, but it eludes me at the moment.
EDIT: 4. Some people here say what's the use. I'm sure you can address this better than myself, but the main "selling point" for me is the ease of use. The focus should be on very easy defaults. Properly defining namespace URIs or microdata itemtype for example is already error-prone/requires too much thinking for the general user. I do think there may be a room for this project.
That's it for now. Too much long of an HN break as it is :-)